iOS app cannot be opened after update

Question

We have an app live in the app store for almost an year, and we've been receiving several bad reviews from customer which cannot open the app after updating it.

Users have reported they are unable to launch the application following deleting and subsequently reinstalling the application. One user did indicate they could launch the application only following a factory reset of their iPhone.

We believed the issue was related to the Keychain, since this seems to be persistent in the system. For this reason we updated the third party library we are using to access the keychain to https://github.com/soffes/sskeychain. This change was made in version 1.4.1.

After releasing 1.4.1, a couple of users indicated they were finally able to open the app. Unfortunately, as we are unable to debug the issue we were unable to determine what possible issue might have been resolved. Furthermore, we saw other users still having the same issue upgrading to 1.4.1 and also to 1.4.2.

We are also considering the issue may be with one of our dependent libraries:

• Flurry analytics
• Facebook iOS SDK
• PayPal MPL
• Hockeyapp ios lib
• ASIHTTPRequest
• we do not use CoreData

We are unable to debug this with the standard iOS tools and we can't even expect hockey app to provide us a crash report since the app is closed before sending it.

This behaviour we do not understand, and we clearly have no control on the app while is being updated from the app store. Is there anything that persists for an application on its deletion? If not, are you aware of anything that might prevent the opening of the reinstalled app?

EDIT: we are configuring hockeyapp lib in applicationDidFinishLaunching: app delegate's method in this way:

[[BITHockeyManager sharedHockeyManager] configureWithIdentifier:QUINCY_APP_IDENTIFIER delegate:self];
[[BITHockeyManager sharedHockeyManager] setDisableUpdateManager:YES];
[[[BITHockeyManager sharedHockeyManager] crashManager] setCrashManagerStatus:BITCrashManagerStatusAutoSend];
[[BITHockeyManager sharedHockeyManager] startManager];
#ifdef DEBUG
  [[BITHockeyManager sharedHockeyManager] setDebugLogEnabled:YES];
#endif

the app identifier is configured in the build settings and distinct per each configuration.

Answer 1

We had this problem once. The app worked fine as an Ad Hoc build. Apple tested and approved it; however, end users would crash immediately upon opening.

For us, it turned out to be that we were not properly passing our HockeyApp production API key in correctly.

Once we got that fixed users were good to go. For Example:

[[BITHockeyManager sharedHockeyManager] configureWithBetaIdentifier:@"betaKeyHere"
                                                     liveIdentifier:@"liveKeyHere"
                                                           delegate:self];

Answer 2

In general there can be multiple issues happening on startup:

1. A required library is not linked correctly: But this can NOT be the issue, since then all app starts would crash!

2. Startup is taking taking too long and the app is killed by the watchdog.

   This could be your problem if you are doing e.g. migration of a lot of data on the main thread right in the applicationDidFinishLaunching: runloop and hence the app is not responsive for user input and hence will be killed by the watchdog after about 20 seconds.

   Make sure to do migration without blocking the main thread!

3. You are experiencing a crash (not a kill!) on startup. Since the app crashes before the HockeyApp SDK can send the crash, you won't be able to get those crash reports.

   The HockeyApp iOS SDK provides a mechanism to handle these, follow the instructions given in the following page: http://support.hockeyapp.net/kb/how-tos-faq/how-to-handle-crashes-during-startup-on-ios

So either 2. or 3. are your issue. If you have a chance to directly contact a user who is affected, you could ask for the iOS generated crash report. Otherwise check the recommendations I gave.

Answer 3

I can't believe it, but I finally found the reason why the app crashes.

[[NSLocale currentLocale] objectForKey: NSLocaleCountryCode] sometimes returns nil. I made the assumption this was always valid, but apparently I was wrong.

I found this other question here NSLocaleCountryCode returns nil. it should be the right place for a follow up on this issue.

Thanks to @kerni suggestion I was able to made hockeyapp send reports of application launching crashes, but unfortunately this wasn't enough to understand what happened: the stack trace of the report was not clear.

After a couple of tries, I discovered another bad bad thing related to flurry. This was capturing the system exceptions and avoid hockeyapp to correctly handle the crash and produce a reasonable report. This discussion was very helpful for me to identify and correct my flurry integration code: http://support.hockeyapp.net/discussions/questions/1359-more-information-for-crashes-with-reason-no-reason-found

After this change, I was finally able to see a decent crash report on hockeyapp and identify my issue: the current locale.