XCode: How can I verify an IPA is valid before uploading? - ios

I have a problem with creating IPA files and TestFlight is showing me this reason.
http://help.testflightapp.com/customer/portal/articles/402843-mismatched-keychain-access-groups
I get a mismatch with keychain access groups but it takes a while to upload the IPA file to TestFlight before it can tell me the file is not valid. I'd like to test the file before I even upload it. I would also like to know how to get information abou the IPA file so that I can diagnose and fix the problem. I have no idea how it is failing since I am using the same Code Signing Identity in the Debug/Release builds as well as signing the IPA from the Archive. I have no idea what is wrong or how to fix it.
Any help is appreciated.

If your Distribution Provisioning profile bundle identifier matches your App's bundle identifier (eg your bundle id is com.mycompany.appname and your App's bundle id has at least com.mycompany.* then you shouldn't run into this error.
Another way to check validity feedback in Xcode 4.3 is to archive the app, and hit the Validate button in the Archives section of your Organizer. (Note that it won't allow you to to validate and gives a 'No application records found' error until you've created an App ID in your iTunes Connect account, and followed the steps until you've set it to "Waiting for Upload ". Don't worry if you're not ready to upload to the store yet, you can still validate without uploading anything.)

Go to terminal and use it like below
/Applications/Xcode.app/Contents/Applications/Application\ Loader.app/Contents/Frameworks/ITunesSoftwareService.framework/Support/altool -v -f APP.ipa -u itunesconnect#user.com -p password

You can use the altool that comes with Xcode
cd /Applications/Xcode.app/Contents/Applications/Application\ Loader.app/Contents/Frameworks/ITunesSoftwareService.framework/Versions/A/Support/
./altool --validate-app -f <'ipaFile'>

You can use the command to extract entitlements info from the signed application:
codesign -d --entitlements
Then try to compare it with the Entitlements part of provision profile. If they dont match there must be some problem with your signing process.

Related

Resigned IPA is not verified correctly by codesign

I have an IPA file exported for development and I want to sign the IPA file using a valid enterprise certificate. Actually, I have gone through all the steps mentioned here amd here and used various available tools such as ota-tools and iResign to sign the file.
The app is actually a very small swift app and only uses app groups and key-chain sharing capabilities and is developed by members of my enterprise team using the App ID and team identifier that we have defined using Xcode in our enterprise account.
I have done the resigning process without any problem and the app is installed successfully on my iPhone. But it immediately crashes upon startup.
So, I doubted the resigning process and did some checks. I tried to check the resigned IPA file using 'codesign -v' command but it says "code object is not signed at all".
I also unzipped the IPA file did all the code-signing on the main app and Frameworks folder but still head no luck with codesign verification. it still says "code object is not signed at all".
I would appreciate if someone can help me with this problem.
I'm having the same problem where the app won't start after resigning and installing. Did you have any success resolving this problem?
About the codesign verification, if you've successfully installed the app on the phone that means that the resign is OK. Also you should run the 'codesign -v' command on the .app itself in the ipa file, because that's the file you're actually signing, the ipa is just a zip you create after the resigning.
I had the same problem (resigned app crashed on launch). I figured out that this happens only for IPAs with embedded bitcode.
Removing bitcode support from project settings (ENABLE_BITCODE = NO) fixes the problem.
I understand that this is limitation, for this reason I opened an issue on fastlane sigh (the main tool I use for resigning) on Github.

Build contains beta entitlement - still get error

The embedded profile in my IPA's payload contains the beta-reports-active key with a following true value. When those builds are uploaded, and later listed within itunesconnect pre-release tab they are flagged as NOT having that entitlement. I am inspecting the embedded.profile with this command
security cms -D -i
In the p-list that is returned I see the Entitlements dict and within that <key>beta-reports-active</key> followed by <true/>.
Has anyone encountered this? Could there be some other source of entitlements?
EDIT:
I should add the profile is being embedded by jenkins via it's XCODE plugin.
Okay, got it:
Problem was that xcodebuild run by Jenkins could not find my correct mobileprovision during build, only during resining. Moving the certificate into ~/Library/MobileDevices/Provisioning Profiles solved it.
Look for this line
Provisioning Profile: "XYZ"
in the build output, that's what being used to build (not to resign for the packaged IPA) and it has to be the right file.
I will probably switch to a more modern tool like fastlane to avoid stuff like this from now on...

Need to re-sign the IPA file with my ad hoc profile

I tried to resign one IPA file (Project is build under HTML 5) using this following scripts,
unzip application.ipa
rm -r "Payload/Application.app/_CodeSignature" "Payload/Application.app/CodeResources" 2> /dev/null | true
cp "/Users/playdom/Desktop/BA/Code/Profiles/something.mobileprovision" "Payload/Application.app/embedded.mobileprovision"
/usr/bin/codesign -f -s "iPhone Distribution: something" --resource-rules "Payload/Application.app/ResourceRules.plist" "Payload/Application.app"
zip -qr "Application.test.ipa" Payload
=========================
And it changes the sign and I can install the Build at my device. But the problem is whenever I tried to start my application it shows the splash screen and crash!!! I checked the IPA with default Profile (I wanted to change...) and it works ok. That means the problem is in the resign process!!!
I tried check the Xcode/Organizer/Console and saw it shows entitlement issue!!. I followed the same script and process with other IPA (Build under Obj C) it works fine. I don't understand what is the issue? Do I need to change the info.plist, Bundle identifier? I tried that but after that it don't even install!!. Any body has any idea?
I don't know how that's supposed to work. You can't run a build that's signed for the App Store distribution on a device. I always take my App Store builds and re-sign them with a development provisioning profile to test them on a device.

Codesigning iOS applications (APNS Enabled) without using XCode

I want to build a single window Mac application, which can be used to codesign iOS applications without using XCode.
Many of our clients use "Enterprise License" to distribute their apps. Each year they need to be resigned and its a repetitive work. Their requirements are following
Apps make use of APNS
They don't want to share their Enterprise License
Bundle identifier should be replaceable while signing with their certificate
They have certificates with same name in Keychain
Userinterface has the following fields
Path to the *.ipa file
Path to the *.mobileprovision file
Keychain name (optional incase more than one certificate with same name exists)
Name of the certificate (iPhone Developer : .....)
I was able to codesign application, but APNS is not working after resigning. Or is it not possible to resign applications making use of bundleIdentifier?
And also I would like to add a feature of drop down list of certificates available in Keychain for improved useability. Any pointers would be great help
To enable push notifications, the app ID and provisioning profile will need to have that configured and allowed by Apple (through the portal). You can't enable it for arbitrary provisioning profiles/apps just by resigning.
During codesigning, the entitlements need to have the apns-environment key set to sandbox/production depending on what the app uses. This will then be verified at runtime by iOS. If you are using a third-party signing tool, it should take the apns-environment value from the provisioning profile.
For debugging, you can look at the entitlements for a .app with this command:
codesign -d --requirements - --entitlements - path/to/My.app
You should see an apns-environment value, but only if the provisioning profile had that enabled.
Just spent several hours researching this same issue and discovered the following process. Taking Mike's comments one step further, providing the following command line for others running into the same issue.
I am starting with an xcode release build using a bundle id that has been configured for production push notification.
From the terminal window run the following commands - replacing the "CAPITAL SECTIONS" with your info
codesign -d --entitlements -"NAME OF APP.app" > entitlements.plist
codesign -f -s "SIGNING CERTIFICATE NAME" --resource-rules "NAME OF APP.app/ResourceRules.plist" --entitlements entitlements.plist "NAME OF APP.app"
Hope this helps the next person struggling with this same issue

Name of the Certificate/Authority who signed IPA [iOS]

Other question show how you can sign an already signed IPA, like this, or this. Specially this part is what interests me:
/usr/bin/codesign -f -s "iPhone Distribution: Certificate Name" --resource-rules "Payload/Application.app/ResourceRules.plist" "Payload/Application.app"
Once I have the re-signed ipa, how can I see/know that in fact the IPA I currently have has been signed by "iPhone Distribution: Certificate Name"?
codesign -d -vvvv /path/to/The.app
-d for displaying signature info, lots of vs for lots of verbosity.
I don't know if its the best way. By using Terminal you can browse the contents of signed ipa file. Change the extension to zip and extract it. Then try browsing to following path >Payload/AppName.app/embedded.mobileprovision.
You can copy the embedded.mobileprovision to some other location and open in text editor to see the details.
To my knowledge, 'codesign' do not have any option to actually check that the resigning of the app is ok.
Actually, it can go wrong for many reasons (entitlements, provisioning, id mismatch ...).
The only way to check is to install the IPA (via Xcode, iPhone Configurator or iTunes if no other choice) on a device and see if the app launches.

Resources