These are some of the lessons learned that I would like to share so that you don’t have to go through similar frustration in case you encounter the same challenges in your other mobile projects. It took about 3 weeks for DEV team to resolve this issue so I thought it will be useful to share this with you to save you some time and frustration, and to help you avoid delaying production release. The issues are due to new changes from Apple.
The Problem
App crashes while running the archived exported .ipa but works on simulator and side loading the app onto device. Without successfully creating the .ipa, we could not distribute the app for internal testing or eventually deliver the app to the App Store for Production release.
A month ago, there were several problems found with the build/Xcode configuration when we started preparing to support iOS 9. We migrated our code from Xcode 6.4 to Xcode 7 beta. Then havoc started as we were starting SDF testing and we could not possibly load the app onto a device for QA to start their official testing. The problem was that the app was using custom frameworks that we created internally at RBC and they were not found while launching the app from the device. Investigation and trials were happening as the error message below kept reappearing on the crash logs:
It took about 2 weeks of a developer’s time to resolve this issue and we were finally able to side load the app onto the device and launch the app without crashing anymore. The problem was resolved by adding the custom frameworks as part of the embedded frameworks and change the build phase to copy the frameworks to a frameworks folder in addition to linking the binary with the libraries as part of the Xcode configurations. The strange thing is that if you have the embedded frameworks, we would not be able to run the app on a simulator. To further fix this quirk, we created two scheme in Xcode, one for loading the app onto a device and another for loading the app onto a simulator.
Yay! Everything looked good or so it seemed.
Finally, we engaged the build team as we couldn’t possibly have a developer sitting on his/her desk side loading the app onto 50+ devices for SDF testing. The goal was for the build team to help us automate the build and create an IPA for the app distribution via OTA and without having to provision the devices. Then the same error message appeared where the library could not be loaded once the build team archived the build and signed with the distribution certificate. The IPA was created successfully but once deployed on the device, the app crashed as soon as it was launched.
I lost sleep as I did not want us to have another 2 weeks downtime before we could create an IPA (iOS App Store Package) for distribution to a broader audience. So for a week before we could come to the solution that made this work, the build team and I tried all the suggested solutions that we could find from the online forums including:
- Checked on the framework search path and played with other possible configurations
- Tried installing on iPhone 5 rather than iPhone 6+ and the same issue occurs
- Checked on the architecture of the frameworks on command line and they looked fine
- Extracted the IPA and found that the frameworks were also included in the package
- Tried creating a simple Hello World app and generated the IPA successfully. The app launches on the device with the enterprise profile, so this tells us that the certs are working.
Further thing to note is that there are no entitlements associated with the custom frameworks when we exported the Archive on the Organizer tool. I was not sure if we are supposed to have any. Here is a screenshot of similar issue without the entitlements for the libraries:
https://drive.google.com/file/d/0B68-3G8aSUUHdjZWdjJrcHZEVEU/view
(To save your doubts, the entitlements are not required since we were able to fix the problem as is!)
Other possible solutions for similar issue that we tried but no avail.
- Custom framework not loaded dyld: Library not loaded: @rpath/Custom.framework/
- dyld: Library not loaded for a Framework within a Framework
- http://solvedstack.com/questions/ios-app-with-framework-crashed-on-device-dyld-library-not-loaded-xcode-6-beta
The Solution
It was on a Monday morning around 3am and before giving up and contact Apple support to help, I wanted to give it one more try to search on Google for one more possible solution. I found a link with some information that we have not tried yet and I was anxiously waiting to get into the office to try.
And it worked!
Finally, we reached to the conclusion that the error message was misleading. The issue was not due to the frameworks not being found, but rather the signing issue! This was not a well known signing issue since the certificates signs an app without custom frameworks correctly and it is able to launch successfully. To correct our app’s problem, we needed to sign the app using code signing certificates with the Subject Organizational Unit (OU) set to the Team ID. Apple has made a change to their certificates so we needed to revoke the distribution/developer certificate and re-create the new certificate for signing our app.
The solution provided in this Q&A helped us achieve this solution:
and I copied the most important part that you will need to know:
The new certificates are needed when building an archive and packaging your app. Even if you have one of the new certificates, just resigning an existing swift app archive won’t work. If it was built with a pre-iOS 8 certificate, you will need to build another archive.
Important: Please use caution if you need to revoke and setup up a new Enterprise Distribution certificate. If you are an in-house Enterprise developer you will need to be careful that you do not revoke a distribution certificate that was used to sign an app any one of your Enterprise employees is still using as any apps that were signed with that enterprise distribution certificate will stop working immediately. The above only applies to Enterprise Distribution certificates. Development certs are safe to revoke for enterprise/standard iOS developers.
Today we have a working build for SDF testing! Just in case anyone asks, all the builds (from other mobile projects) signed with the old certificate stopped working.
So lessons learned from this:
- Expect to set aside some time to resolve any new changes when migrating to any Xcode beta releases
- Always have the developers test on the devices and not rely solely on the simulator
- Engage the build team early to create the app for you and verify that the app launches successfully on the device
- Confirm with release team that the new changes from Apple have been applied to the production signing certificates