iOS App with Static Lib crashes ONLY on launch of Archive Build loaded Ad Hoc. Can't reproduce in Debugger - iphone

I realize this is a stretch and I can't give much info to help but I am reaching for anything. My App has been under continuous development for 3 years and never seen anything like this. I recently submitted a small point release to Apple for Release, and twice now it has been rejected for Crashing on Launch on ALL their devices?
The Crash reports point to some code in static library but the key lines are not getting symbolicated. Tried Atos no luck.
The key point is that I have 7 devices I have tested the app on in every mode I can think of, in particular no connection to anything: Wifi-OFF, AirplaneMode-ON, Location services-OFF. I can NEVER simulate what they claim to be seeing, which is App crashes on launch every time?!
I found one report in the AAPL Dev Forums that sounded similar, but he never got any explanation as to what was up. After he submitted an app with loads of logging in it out of desperation and asked them to send the logs. They got that version and... approved it in hours.
Anyone have ANY ideas. I NEED to get this release out.
NOTE: Resolved
This turned out to NOT be a weak link issue. We only saw the crash when running the App using Ad Hoc distribution of the Archive version as Brad suggested... so that was helpful.
However the resolution turned out to be some compiler flags which I listed here:
https://stackoverflow.com/a/10302012/754494

I'll repost and expand upon my comment from above so that this question can have an accepted answer.
I recently came across a case similar to this when building my GPUImage framework. It appears that the build process is slightly different when archiving than when building and directly installing an application on the device via Xcode.
This can be exposed by building and archiving the application, then choosing to distribute it for ad hoc or enterprise distribution. Take the .ipa and place it in iTunes and manually load it on one of your test devices that way. The behavior of an application prepared in this manner may differ from one built and installed through Xcode, and should be closer to how a build submitted for review will act.
In my case, the problem was due to a lack of proper weak linking. On SDKs newer than iOS 4.3, you should no longer need to weak link whole frameworks if you wish to conditionally use classes and functions that are present in newer SDKs but missing in older ones. If you target 4.0 and higher, the linker should now perform class- and function-level weak linking.
However, this was failing for people using my static library, which does runtime checks for the presence of the new texture cache functions in iOS 5.0, but it only failed in these archived builds. I never saw it in all my testing against 4.x devices, because that was done by installing via Xcode. In the end, I needed to have users explicitly weak link the entire Core Video framework in order to get applications using this framework to run properly when archived and installed via iTunes.
Note that this wasn't due to the Release vs. Debug build configurations, because I tried switching between these in my build schemes when deploying to the device through Xcode and it made no difference there. Something else is different in the way that archived applications are built and linked.

Related

iOS 8.0.2 Library Not Loaded libswiftCore.dylib

I have an application that uses HealthKit and Swift in it, everything compiles and runs fine when I test it from Xcode on a simulator or a device. I tested, debugged it, and submitted it to the iTunes store. When the application was approved I downloaded the new version from the store and it crashed right away. This was extremely puzzling as I have never had this issue before. I look at the diagnostic and usage logs on my phone and the crash report for the application says this:
Dyld Error Message:
Library not loaded: #rpath/libswiftCore.dylib
Reference from: /path/to/my/app
Reason: no suitable image found.
Did find: /path/to/my/app/Frameworks/libswiftCore.dylib: mmap() error 1 at address=0x100174000, size=0x0194000 segment=__TEXT in Segment::map()
Has anyone seen anything like this or know how to deal with it?
Thank you
EDIT:
The crashing issue magically fixed itself on the morning of October 4th, which tells me that this was an Apple issue. I have been emailing iTunes Connect Support, but they have not said one way or another what happened. I also opened a technical ticket without even a response back from Apple. This is pretty disappointing, not just for the fact that Apple is not being transparent about the issue, but also it makes me feel like I have no course of action later on down the road if this ever were to happen again.
Simply do the following two steps:
1) Delete the App from the device (or simulator)
2) Clean your workspace (CMD+SHIFT+K or via menu Product->Clean)
3) Build and run your app again.
Magically helps every time with all that startup / deploy stuff...
I also often get something like "application not found on device" or signing problems etc. Minutes before everything worked well.
This appears to possibly be a code signing issue on Apple's part, and the issue seems affect apps with embedded frameworks (including non-Swift apps). There are multiple accounts of developers being affected (myself included) who had only submitted an update, without changing any build settings. Some high profile apps appear to have been affected and tickets have been filed with Apple, but there has been no official response from them at this time.
EDIT: This has been confirmed.
Edit:
The app was rejected, after making this change, for the same reason, however, I am confident that the problem has to do with a missing architecture version in the libswiftCore.
I am going to post this as the provisional answer.
Xcode 6 Standard architectures exclude armv7s
Notice how the error says: Did find: /path/to/my/app/Frameworks/libswiftCore.dylib
So it did find the lib but it also says: Reason: no suitable image found.
After running lipo against the archived build it didn't contain armv7s in the swift library, or in the app binary. I manually added it per the link above and the binary now contains support for armv7s though the swift library still did not. My app is in expedited review so I should get feedback farily quick. I will follow up when that does happen.
I had the exact same problem with one of my app version updates (FunKeyBoard 1.1).
After doing some research, looks like it was an Apple side issue for many apps updated on October 3rd. Apple fixed the issue on October 4th by releasing an update, same version number, without needing any fix/re-upload from the app developer.
Obviously an Apple side issue, but I'm surprised Apple is very quiet about it. Many developers, including myself, got angry emails from users, and poor app reviews, as a result.
This error typically occurs when signing Swift apps with certificates that lack "OU" (Organizational Unit). All certificates created after the release of iOS 8 should have this. The simple solution is to create a new certificate to sign with.
For more details, see the official Apple comment here: https://developer.apple.com/library/ios/qa/qa1886/_index.html
It seems that my on the iTunes store is now downloading and opening as expected. From what I have been reading in the Apple Developer Forums, other apps are also working now too. I have not received any word from Apple on why this happened or what caused this. I opened up a technical support ticket with them and I also contacted iTunes Connect support and there is no
explanation or any information on this issue being resolved. This is pretty poor customer service on their part.
I had the same problem. I removed support for arm64 and added armv7s and now apple review team approve the app.

iTunes Connect Vague App Rejection - Pulling My Hair Out

So, I recently uploaded about 9 apps that were mutations of an original one, just with different content and the same framework...
So, today all 9 of the apps went into review at the exact same time although they were each uploaded a day apart, which I thought was really odd. 5 hours later I get 9 rejection emails and the same rejection as follows:
2.2
We found that your app failed to launch on iPhone 5 running iOS 6, on both Wi-Fi and cellular networks.
We encountered the issue when selecting the application on the Home screen - the app displayed a launch image then quit unexpectedly.
This may be because iOS 6 uses a watchdog timer for applications; if
an application takes too long to complete its initial startup, the
operating system terminates the application.
For information about the watchdog timer, please see Technical Q&A: Application does not crash when launched from debugger but
crashes when launched by user..
Another possibility could be a missing entitlement. For more information, please see the Technical Note: Resolving "0x800003A",
applications not launching and "missing entitlement". For discrete
code-level questions, you may wish to consult with Apple Developer
Technical Support. Please be sure to:
include the complete details of your rejection issues
prepare any symbolicated crash logs, screenshots, and steps to reproduce the issues for when the DTS engineer follows up.
For information on how to symbolicate and read a crash log, please see Tech Note TN2151 Understanding and Analyzing iPhone OS
Application Crash Reports.
If you have difficulty reproducing this issue, please try testing the workflow as described in
https://developer.apple.com/library/ios/qa/qa1764/Testing Workflow
with Xcode's Archive feature".
I've uploaded a number of apps before and have never received this sort of issue.. So, I followed their suggestions and it's not the dogwatch timer, as the app runs absolutely flawless when ran from xcode on my iPhone 4s with iOS6, and also runs without any issues when I distribute it as ad-hoc enterprise, and sync the app through a .ipa file onto my iphone...
Although, before testing any of this I went through and revoked my development and distribution certificates, went through my keychain and deleted all instances of any certificates related to apps, and keys. Then refreshed everything. All my code signing / provisioning profiles are valid, I re-added my device to the provisioning portal as well.
Does anyone else have any ideas? I'd like to be positive I fixed the problem before uploading my apps again, waiting a week just to be rejected once again and have to start all over. Any help or leads would be greatly appreciated!
I have also double checked all of my info.plist bundle identifiers and they all match the dist and development profiles associated with each app.
I finally got around to finding a friend with an iPhone 5. The crashing WAS due to armv7s architecture being used. So I stripped out all architectures and used only armv7. Worked like a charm and the app ran as smoothly on my 4s as it did on my friend's iphone 5.
Did you try compiling in armv7 only? (forget the armv7s support). By the way, yeah, it's impossible to test it without any iphone5 hardware, and the simulator actually don't simulate anything. With only armv7 feature it should (i really say "should") behave like in iPhone 3G/4/4s on ios6.
Or did you have some runtime behavior depending on the device? What are you actually set on startup?
Look at this post:
http://wanderingcoder.net/original-armv7s-psa/
Even if it talk about linker error, here is the philosophy: Don't publish something you haven't, can't test. Use armv7s only when you will get rich an have an iPhone 5

IPhone crash reporting framework

I wanted to add crash reporting capabilities to my iPhone app. Kind of the type that prompts you to send a crash report the next time the app launches after a crash (I have seen this capability in NYTines iPhone app, but I am sure there must be others apps doing this as well). Is this a 3rd party framework that can be easily included in any app?
There are alot of these frameworks, a good article about them can be found here
However i would suggest using http://www.crittercism.com/
Crittercism caters to my needs at present. The support team is good too.
I'm using QuincyKit. Word of caution though - you'll need to redownload the crash reporter framework from the home site - the build that Quincy site has misbehaves on certain Xcode/iOS conbinations.
But server-side installation is a snap, and symbolication infrastructure is easy to set up, too.

iPhone app crash immediately after update

today my app update it has been released in the store, when updated or downloaded for the first time the app immediately crash on start.
I've tested the app on simulator and on device (the same where I've installed the update from the store) and I never experienced this problem.
My update it has been submitted with Organizer after the archiving, in the Distribute section.
Apple do not perform these types of controls before to release an app?
Anyone experienced a similar problem? I have no idea what could be the cause..
Thank you, Stefano.
Here's the best way to test a production build without deploying to the store:
Set your build Scheme to "iOS Device"
Do an Archive build
Select your archive and click Distribute
Choose "Save for Enterprise or Ad-Hoc Deployment"
Pick your code signing cert
After saving the ipa file, use Apple's iPhone Configuration Utility(*) to install it on your device
You should always perform two tests:
installing on a blank device after uninstalling your app *and any profiles in Settings -> General -> Profiles"
installing over the top of the previous version of your app, to make sure any files/preferences/etc are properly converted to the new format
(*) the iPhone Configuration Utility is mostly used for enterprise app deployment, but it's also useful for developers and is available as a free download for mac and windows at support.apple.com. You can also use iTunes instead, but it's convoluted.
As for why your app is crashing? No idea... it could be anything. Standard debugging advice applies.
The issue is related to the Framework. I had this exact error. It wasn't a case of logic as it was crashing before the AppDelegate was even called and my usage of NSMetadataQuery was much later in the life cycle than that.
It turns out that weak linking the Foundation framework was required.
Problem was solved by changing (under the Project Info in Xcode) the dependency option of the Foundation.framework from required to optional. Check for any such frameworks.
Try deleting any old versions of the app you have on your device, and reinstall. Also try on a different device, maybe with a different apple id to your developer account.
This happened to our app also, and apparently, other apps too.
Apple is aware of the problem and is currently working on a solution.
see this article:
http://techcrunch.com/2012/07/05/apple-responds-to-app-crashing-issues-has-a-dedicated-team-working-on-a-fix/
If you are using core data & you have updated database in your latest version without versioning core data in that case app crashes on launch after update.

Will building & running another iOS project disassociate existing provisioning or app id's?

I recently recovered from not being able to test on my device in Xcode. After much headache, it turned out that I only needed to uninstall/reinstall iTunes, but I'd certainly rather not do so frequently.
(See: prior thread)
The troubles seemed to begin after I built and ran some sample projects which obviously did not have my App id, etc. Is this always the case? Should I live in fear of compiling other projects that I haven't previously associated with my device and/or developer profile?
I'm not exactly sure if the App id/bundle/provisioning/keychain/whatever needs to be done per test ad hoc App or if it only matters that your device is provisioned and your plist matches what Apple has when you go to upload to the iTunes store.
I've run many samples on my device through Xcode and never had any issues. There's certainly no reason why this should happen.
It's hard to say "No, you shouldn't be worried" without knowing what the issue is, but it's not intended to break in this way, and it doesn't for most of us!