I have an iOS app that is now around 3 years old. It is signed with an enterprise profile. We have released seven versions of the software, the last time being almost a year ago. Currently we are trying to do a new release but have found that due to the new security rules in iOS8 that iOS 8.1.3 devices and greater cannot upgrade and must delete and reinstall.
In researching I found similar issues for people who are signing the app with a different profile, but our app is being signed with the same profile. The error claims that our old application-identifier contained a wildcard, which I cannot figure out since we have never changed the bundle id(but, in the developer portal our general appId for all our apps is com.company.*).
I have found that if I build both version 1 and version 2 of the app with Xcode 6.4 I can upgrade successfully and if I build both versions of the app with Xcode 5.1 I can upgrade successfully, the problem is when trying to install a version of the app built with Xcode 6.4 over a version built with Xcode 5.1
The error we get when we attempt the upgrade is:
"Upgrade's application-identifier entitlement string (6Q39SSX4QT.com.company.appName) does not match installed application's application-identifier string (6Q39SSX4QT.com.company.*)"
I have seen some references to needing to include an entitlements.plist file in our app, we have a AppName.entitlements plist file, but none of our apps have a entitlements.plist file(and our other apps do not exhibit this problem though they have been upgraded multiple times since Xcode 5.1 released).
Anyone have any ideas?
Thanks!
Open Xcode - > Window -> Devices
Click on your device and remove the app you are trying to install from the installed apps list.
Try running now.
After doing some further reading, I found this answer to be helpful. In my case, I am building via a grunt script so I can modify my archive/sign/package step to insert the entitlements during the codesign step.
If you follow the steps I linked, you will want to make sure your entitlements.plist file contains the wildcard as shown below:
<key>application-identifier</key>
<string>com.company.*</string>
If you are doing the app packaging manually, you may want to look at iResign. This will create the entitlements.plist file for you and inject it while signing your app.
I wish there was better documentation available from Apple on this. I cannot get the same effect in XCode no matter what I specify in my target's Code Entitlements settings.
I have just had this error - it was because I had changed the development team used to sign the app. Ie I used our company's distribution profile to sign the development version and the client's distribution profile to sign a release version.
Check that the team id in the entitlements is the correct team id (printed in the error message) -> then its the installed app that is wrong. Also check that you haven't specified an application-identifier in an entitlements file. I didn't have an entitlements file at all.
In this case simply delete the app on the device and reinstall it fresh.
Chris
Related
Previously with Xcode 7.3.1 I was able to build directly over my app store app on my iPad and test the upgrade scenario, which worked perfectly fine. This week I upgraded to Xcode 8 and when I try the exact same approach, I keep getting this upgrade error
"This application's application-identifier entitlement does not match that of the installed application. These values must match for an upgrade to be allowed."
I tried multiple solutions posted on this thread and none of them worked. I also don't have a watch app. Just a simple iOS app target.
App installation failed due to application-identifier entitlement
I deleted my certs and provisioning profiles and recreated them and still the same problem. I then went and downloaded Xcode 7.3.1 and tried it again with the exact same problem.
Now I am stuck without being able to fully test my upgrade scenario.
PLEASE HELP !!
I had the same issue while trying to upgrade application.
And here what I've found:
I checked application-identifier entitlements of old app and new app. You can do that by running codesign -d --entitlements :- path/to/AppName.app/AppName or open file "archived-expanded-entitlements.xcent" at path "AppName.app/AppName".
Application-identifier of old app was "1234XXX5X6.com.mycompany.myapp" but in new app it was "1234XXX5X6.com.mycompany.myapp.develop".
Usually I set "Bundle Identifier" directly in Info.plist.
But I didn't know that there is also a "Product Bundle Identifier" property in project Build Settings.
The previous version of app was built with Xcode 7.3.1 and it had following settings:
Info.plist: com.mycompany.myapp
Build Settings: com.mycompany.myapp.develop
application-identifier: 1234XXX5X6.com.mycompany.myapp
The new version was built with Xcode 8.2.1 and it had following settings:
Info.plist: com.mycompany.myapp
Build Settings: com.mycompany.myapp.develop
application-identifier: 1234XXX5X6.com.mycompany.myapp.develop
Seems like new Xcode have different source for application-identifier.
So I just corrected "Product Bundle Identifier" and my problem was solved.
Remove the existing application from the device and Run again.
To fix this just enable "Automatic manage signing" from general tab of project settings.
I had also problem for running app on my device directly from xcode 8. Deleting and generation profile and certificate did not worked for me. But enabling "Automatic manage signing" worked for me.
Hope this helps!
Check this question of mine:
Xcode 8 shows error that provisioning profile doesn't include signing certificate
Here is one solution if you want to upgrade over your existing App Store app without deleting it but your application-identifier entitlement does not match. Upload an archive of your new build to the App Store and then use TestFlight to download it to your device. This is not as quick as building to the device, but it will overwrite your old app with your new build while keeping your old data in place. For (relatively) quicker turn-around testing of your upgrade process once you have a new build available on TestFlight:
Delete your app off of your device (assuming it was a recent build)
Download your app store build and generate some data
Download your TestFlight build, but don't run it
Build your newest build directly to the device
The TestFlight build overwrites the entitlement without deleting the old data, so Xcode happily will install your new build over the TestFlight build, but you are still testing your upgrade process as if you were building directly on top of the App Store version of your app.
I got this from an .ipa generated as a Jenkins artefact. The problem for me was that Jenkins was using a different provisioning profile.
I manually set Jenkins to use the same profile as the updated version that I was trying to install, and it started working.
Select the App Target and click on General, if you select or ticked checkbox automatically manage signing.
Untick this automatically manage signing and select appropriate signing provisioning profile and #Build and run again.
See the below photo.
Solved!! Short answer - delete old app from your iPhone
I went to my iPhone storage and used the search bar to find the offending app(because it wasn’t showing on the app list) and found an old version hidden, deleted it and now it works.
What worked for me was to go (within Xcode) to Window > Devices and Simulators, then select my iOS device and delete the app there. This is detailed in this Medium article.
I have a certificate & provisioning profile generated this August. They are both valid (unexpired) in the Apple Developer Portal.
When I open my project, which targets 8.3, I get this error:
No certificate matching 'iPhone Developer: My Name (###ABC123)' for team 'Company.'
Select a different signing certificate for CODE_SIGN_IDENTITY, a team that matches your selected certificate, or switch to automatic provisioning.
I can see the private key nested under my certificate in Keychain.
In my Project settings, I click on my target and see my provisioning
profile.
Under Signing Certificate, I see None.
At first I saw an error for "This provisioning profile does not have Wireless Accessory Configuration", which I don't need. When I unselected & reselected the provisioning profile, this error went away.
I've had many similar issues, where the developer portal displayed valid certificates/profiles, and Xcode refused to sign.
Finally found something that seems to do the trick every time I come across it:
• Open the Certificates, Identifiers & Profiles page on the online developer portal
• Go to the Provisioning Profiles -> All tab
• Select the profile you are trying to build for and click on Edit
• Select the certificate you have on your machine, and click 'Generate'
• Download the profile and drag in onto the Xcode icon in your dock
• Clean and rebuild your project
I don't know if this is the golden fix, or just happens to work in my situation... but worth giving this a shot for sure.
I had a different compiling problem after upgrading; what helped me out a lot was someone pointing out that macOS El Capitan 10.11.1 and Sierra 10.12.1 put restrictions on root. I rebooted my computer in recovery mode (command+R), then from utilities -> terminal I typed
csrutil disable
then restarting the computer normally, I made sure that Xcode was installed properly using a download from the apple developer website and reinstalled programs relevant to me. Maybe this will help you?
According to Apple's Xcode 8.1 Release Notes there are numerous signing issues noted. They are included below and have (not so detailed) recommended workarounds:
I've also included a Xcode Signing Configuration Guide that includes known issues and detailed explanations regarding the Xcode 8's Code Signing process and the differences from previous versions. Use the table of contents to visit the Signing in Xcode 8 section, where you should find the steps to resolve the CODE_SIGN_IDENTITY error you're experiencing.
* UPDATE *
The 2016 WWDC video on signing. It's pretty slow but it goes over the changes along with the fundamentals that have been made with the latest iOS updates and Xcode 8.
If you are using Cordova, make sure you are using the latest version of the tools, or else follow the steps in this post: https://dpogue.ca/articles/cordova-xcode8.html. You will need to add a hook (JS file) and update your build.json file (or add one at the root if you don't have one). Don't forget to clean and rebuild your project.
If you also happen to use the Tools for Apache Cordova in Visual Studio, expect ERROR ITMS-90161 when uploading to the store. The only working workaround I'm aware of is described here at Step 4:
I then discovered the Xcode Project in
"...remote-builds/builds/"xxx-buildnmb"/cordovaApp/plattforms/iOS/"
and used Xcode to define the code signing identities in "Build
Settings" and the Team information in "General", created the archive
via Product-->Archive and submitted it in the Organizer - Archives
How we handled this was to regenerate our certs and profiles:
When to Apple Developer Center
Deleted certs and profiles
Created two new certs - dev and distro
Created two profiles - dev and distro
Imported new certs into Keychain
Configured new profiles in Xcode
It worked easily. I'm guessing I could have just done reimported the existing certs and profiles for steps 2 and 3 and not bothered recreating as in 1.
I have two iphone devices( 4s and 5 ) connected to my computer and i am trying to install an application in both the devices. It installs pretty well in iphone 5 but it gives an error 'The application could not be verified.' when attempted to install in the iphone 4s device.
The UDIDs of both the devices have been added in the provisioning profile generated for the application.
Also, to add a note, I have just updated my iphone version to 8.1.3 in my 4s device. I am not sure though if the error has anything to do with it.
Any help on this would be much appreciated. I have been stuck on this for some time now.
EDIT:
I just connected this to another iPhone device and the issue seems to be there again. Basically this means that the app, for some reason, installs only in the phone which I have been using for some time now and not in any other phone. Once again, I am pretty sure that the provisioning profile contains the UDIDs of all these 3 devices.
I had something similar happen to me just recently. I updated my iPhone to 8.1.3, and started getting the 'application could not be verified' error message from Xcode on an app that installed just fine on the same iOS device from the same Mac just a few days ago.
I deleted the app from the device, restarted Xcode, and the app subsequently installed on the device just fine without any error message. Not sure if deleting the app was the fix, or the problem was due to "the phase of the moon".
As I notice The application could not be verified. raise up because in your device there is already an app installed with the same bundle identifier.
I got this issue because in my device there is my app that download from App store. and i test its update Version from Xcode. And i used same identifier that is live app and my development testing app. So i just remove app-store Live app from my device and this error going to be fix.
just delete the app and try again, it happens to me when i try to launch over a device that has the same app but generated by an ipa file.
You probably used the "Fix Issue" option in Xcode when plugging in a new device. Old question but I believe this is the actual answer to WHY this is happening. When you install an app on a device it is signed with a specific development provisioning profile. If, for instance, you plug in another device that is not registered on your developer account Xcode will ask you to "fix the issue". When you press that the device is added and another provisioning profile is created/modified. If you try to overwrite an existing app you'll receive that error. Deleting the app and reinstalling it works since the profile has been altered. I find this often happens when a Team is set and a member plugs in a new device then Xcode "Fixes" the problem.
Might have figured it out... Deleting the app from the device worked for me, as others mentioned before (thanks!).
I think the reason is that the app on the device was actually signed with a separate provisioning profile, specifically a distribution profile in my case.
I faced this issue a lot. I am not sure if this is the issue, but I think, when xCode saw that there is an app with the same bundle identifier as of the app, I am trying to install, it didn't allow me. So, I had to delete the older one and attempted to install and it worked. However sometimes for testing purpose, I needed multiple version of the same app and in that case, I would change the bundle identifier and try to install. It only works if, I am using an wildcard provisioning profile.
To others not using RubyMotion and don't think that deleting the app is acceptable (as in, you want to do upgrade testing). Check out the bottom of these docs from Apple:
https://developer.apple.com/library/ios/technotes/tn2319/_index.html
It looks like they changed something in 8.1.3 to check for this new rule.
The Fix
"[Add] the installed application’s application-identifier value, as logged in the second parentheses, to the previous-application-identifiers entitlement’s array value for the app being installed (by resigning it or re-building it) and requesting new special provisioning profiles as shown below."
<key>previous-application-identifiers</key>
<array>
<string>{Your Old App ID Prefix}.YourApp.Bundle.ID</string>
</array>
EDIT:
In order to do this, you need special provisioning profiles. You can request these from Apple:
"To enable signing with the previous-application-identifiers entitlement new special provisioning profiles are required that can be obtained by going to the Contact US page and requesting them." (from the docs linked above).
Had the same issue on my iPad running 8.1.3 Deleting the app and installing again fixed the issue. I use two different provisioning profiles on two different machines and that could have caused this issue.
Working & tested solution, which does not require to delete application:
It looks like AppStore Distribution Provisioning Profile or just iOS Distribution certificate have special permissions and "Could not be verified..." problem does not apply to them. They will always override previous certificate.
In other words: AppStore release will install successfully, even if already installed (testing, adhoc or enterprise) app has been signed by the certificate from different team.
If you are lucky and have previously uploaded app to the AppStore account owned by the same team as in certificate you have a problem with - then things are very simple: just download & install app from AppStore.
When it installs - app certificate will be the same as the one you want to test with and problem goes away.
If your app is not on the AppStore yet - iTunesConnect beta comes to the rescue:
Disclaimer: I did not tested this but since cert an prev are the same as AppStore release, I bet it works:
Archive your app with AppStore provisioning profile (iOS Distribution cert) and upload to iTunesConnect (to the account owned by the same developer team as included in the provisioning profile not you want to run).
Invite person with the device you want to run on (yourself?) to beta test.
Download & install the app from iTunes connect beta.
Now you are able to install your testing version.
The application could not be verified" , in your device there could be already an app installed with the same bundle identifier.
So Simple solution Just delete the App & try again..
....
TL;DR answer - There is no real solution besides "delete app and reinstall".
This answer is not satisfactory for many situations, when you have an existing database that needs to not get deleted within the app.
Lukasz and plivesey are the only ones with solutions that don't require delete, but neither worked for me.
I resolved this issue by changing the Build System to legacy in xcode.
I had the same problem but the mentioned solutions above didn't work for me. Even I had no previous app on device, I got this error when deploying on my device.
How to do:
Simply, go to menu File > Project Setting, inside Share Project Settings, change Build System from "New Build System (default)" to "Lagacy Build System".
I also encountered the same issue. Deleting the app didn't work, but when I tried deleting another app which was the current one's 'parent'(I copied the whole project from the previous app, modified some urls and images, then I clicked 'Run' and saw the unhappy 'could not be verified' dialog). Seems the issue is related to provisioning and code signing and/or some configurations of the project. Very tricky.
I had changed the team but I forgot to change it in my Tests target it so it caused that. Maybe this helps someone.
Just had the same problem and I found out that the issue is with expired certificate.
My app was distributed (AdHoc) through firebase and few days ago app was working just fine.
Today I've realized that I can't install it because 'The application could not be verified'.
Finally I realized that certificate that I was using for app signing has expired 2 days ago.
You need to upload it again and you'll be able to install it.
I had the same problem. But, I realised I was using a single plist with (debug) and (release) configuration, like this.
So, I changed few things..
Keeping a separate scheme for (release).
I added a new scheme for development purposes.
Edited the new scheme > run > Build Configuration > and set it to (release)
Generated a new archive using the new scheme and voila!!..
I'm able to install on all my devices.
My case:
jailbreak'ed iPhone
Final solution:
Install tweak AppSync Unified via Cydia
to bypass signing/certificate verification
Same issue occurred for me when I was installing through link. I tried to install using different link. Then I could install the app.
I'm struggling with this issue for more than a week now, I've tried all I could find on Google with no luck. This is my first time trying to submit an app to the App Store, but I keep getting this email after each try:
invalid Signature - Make sure you have signed your application with a
distribution certificate, not an ad hoc certificate or a development
certificate. Verify that the code signing settings in Xcode are
correct at the target level (which override any values at the project
level). Additionally, make sure the bundle you are uploading was built
using a Release target in Xcode, not a Simulator target. If you are
certain your code signing settings are correct, choose "Clean All" in
Xcode, delete the "build" directory in the Finder, and rebuild your
release target.
so here is what I'm doing:
I have my distribution certificate in login keychain , with the
private and public key .
I have the distribution provisioning profile with the same certificate i've created earlier .
The bundle ID on my provisioning profile is the same on my iTunes connect app and the
same in Xcode general settings .
The same version (0.8.2) in iTunes connect app and Xcode .
I'm building with device selected not a simulator (but i don't have a device connected to the mac).
the code signing part under build settings (for both target and project).
I have "iPhone Distribution : ... " for everything and also i'm selecting the distribution provisioning profile .
What I am missing? I've looked all over and all I find is people with incorrect versions or incorrect bundle id.
I am using Cordova and Ionic to build my app, I don't know if that has something to do with it.
I've seen the troubleshoot guide of Apple on this issue and ran this command:
codesign --verify -vvvv -R='anchor apple generic and certificate
1[field.1.2.840.113635.100.6.2.1] exists and (certificate
leaf[field.1.2.840.113635.100.6.1.2] exists or certificate
leaf[field.1.2.840.113635.100.6.1.4] exists)' /path/to/the.app
I get : a sealed resource is missing or invalid file modified: /path/to/MyApp.app/MyApp
they suggest to run this to resolve the issue: dot_clean path/to/xcodeproject
But that didn't help, I keep getting the same error.
Please help, I'm out of clues
EDIT ( Solution )
Apple is just a big stupid company, none of the suggested solutions under any of the posts helped me ! it was just the stupid process of apple , I had an invalid character "?" that should have been removed from the App Name. I wish Xcode coulde validate the name first before going into any of the submitting and testing process.
I think you are not using the proper distribution profile.Create a new distribution profile in itunes connect for app store submission not the ad hoc one. see the below image.
1)Then, check your bundle identifier that should exactly match with the newly created appstore certificate.
2)Just Delete your certificates in Provisioning Portal and update the new certificate in Xcode.
3)Goto Organizer / Provisioning Profiles / Refresh and allow Xcode to fetch the latest ones.
4)then go to project target->build settings->build options->validate product and change your release mode to yes. see the image below.
then,clean your project and generate the archive.
I had the same issue because the application archive contained files with non-ASCII characters. I renamed all of them and then it worked.
You can find all files with non-ASCII characters by executing the following command in the terminal from the archive folder path:
LC_ALL=C find . -name '*[! -~]*'
Build Settings-> Build Options: Enable Bitcode = Yes helped for me. I could see the error still, but waiting a little Xcode passed it, and continued to upload the application.
I had the same issue a couple of days ago and in the end I had to clean my distribution certificates from Keychain Access, remove and regenerate them from the developer portal. After reinstalling the certificates I was able to build and run the app on the physical device, then archiving it and sending over to the App Store.
All the steps you listed here are fine. If you can connect to a physical device and make sure your certificate is listed between brackets for the code signing settings.
I had to go through the same
frustration in order to learn that the best resource to learn how
Provisioning works is the App Distribution Guide.
Additionally, there are quite few threads on StackOverflow dealing with the same or similar issues like this one: App Submission: Invalid Binary - Invalid Signature
Good luck!
Make sure your bundle id should match with App ID and Change project edit scheme to release .
If not try this link http://stackoverflow.com/questions/5196309/ios-code-signing-fails-a-sealed-resource-is-missing-or-invalid
I have a same problem with xCode 13+, in my case i just replace the target name with not special caracter.
That fix solved my problem 99% because i have multiple targets on my project and some targets presented this problem because contained special carcters in the target name.
I did run into the same problem as this today, turned out to be a .DS_Store file in the Resource directory. Removed that file before building and then everything worked out.
I have a same problem. Then, I found the best solution to fix it.
Replace your Product Name of your App by the new name in which without Unicode Characters.
Go to [App] > Target [App] > Build Settings > Packaging > Product Name.
Fix Invalid Signature
When we try to upload a new version of our app to Apple's App Store we get the following error in Application Loader:
ERROR ITMS-9000: "This bundle is invalid. New apps and app updates submitted to the App Store
must be built with public (GM) versions of Xcode 5 and iOS 7 SDK. Do not submit apps built with
beta software." at SoftwareAssets/SoftwareAsset (MZItmspSoftwareAssetPackage)
We are already building with the latest available version of Xcode, 5.1.1 (downloaded from the Mac App Store) and v7.1 of the iOS SDK (which came with Xcode 5.1.1).
Our app is built with Marmalade 7.2.1. We've tried rebuilding all of the EDK extensions and static libraries that our app uses.
What could be going wrong? Is there anything more anyone else can tell us about the error to help us track it down?
Starting May 15, 2014, new apps and app updates submitted to the App Store must be built with Xcode 5.1.1
You have to update your xcode.
Just clean all the things.
Check the developer/distribution certificate and mobile provision profile properly created, if not then revoke them from developer account and create all new one.
Remove all profiles from /Users/yourSystemName/Library/MobileDevice/Provisioning Profiles
Now, Export all certificates and keys from your keychain and Save them as backup for using them again.
Now install your developer/Distribution certificate first and install provisioning profile. And upload your application. This is tested way and should resolve your issue. Thanks.
When Xcode creates an .ipa package, it adds a number of elements to your project's Info.plist.
As our package is created with Marmalade's deployment tool, these elements need to be manually included in an Info.plist that is copied directly (with a much smaller amount of pre-processing) into the final .ipa.
Marmalade includes a standard Info.plist file within its installation for this purpose. However, you can override this, and we had done so by making a copy of their file, and updating it with changes we needed to make.
A later version of Marmalade made some changes to this file, and we hadn't copied these over into our file, and the difference is apparently what was causing the App Store to think that the App was built with an earlier version of Xcode than the version actually used.
The values which differed were DTSDKName, DTSDKBuild, DTXCode, DTXcodeBuild, DTPlatformBuild, and DTCompiler.