2

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.

nebillo
  • 1,257
  • 10
  • 21
  • Have you used core data or .sqlite database in your application? – P.J Mar 14 '13 at 12:39
  • no, we do not use coredata nor any other sqlite db. – nebillo Mar 14 '13 at 12:41
  • Small note about the HockyeApp initialization: Please call the `setDebugLogEnabled` **BEFORE** calling `startManager`! – Kerni Mar 14 '13 at 13:26
  • If we ignore HockeyApp: Are you storing large data in the keychain and/or the user defaults? – Soph Mar 14 '13 at 20:42
  • I use the keychain just to store the user credentials and read it to check if the user is logged. So a very light usage. About the user defaults: the heaviest data I'm storing in an array on 50 items. This operation is performed very close in time of the app launch. – nebillo Mar 15 '13 at 10:06

3 Answers3

4

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.

Kerni
  • 15,241
  • 5
  • 36
  • 57
  • thanks so much for pointing this thing out. we'll definitely try to see what's happening in the app in this way. I was considering the keychain the incriminated thing because the its behavior matches what we see from these users. what do you think about it? – nebillo Mar 14 '13 at 15:59
  • That is sadly impossible to say without an actual crash report. It could be anything. Also, why should that specific library crash? That would probably mean that you are using it incorrectly or introduced a bug while using it. But to know that, one would need to see that specific code. Even then it might not be obvious. You are searching the needle in the haystack, and the best way I think is to slowly get rid of more and more of the haystack until you can identify the needle so to say :) – Kerni Mar 14 '13 at 16:57
  • yeah I know that can be everything, my hope is actually to collect a lot of similar cases and get closer to the needle :) the key fact that should be considered is that this issue persists even after deleting the app and reinstalling it (and restarting the phone). – nebillo Mar 15 '13 at 10:53
  • Oh, I somehow missed that part. Yeah, that hints that something might be happening when reading/writing from the keychain. You might want to create a new question with code examples on what you are doing. Maybe someone catches something seeing the code. – Kerni Mar 15 '13 at 13:20
  • I followed your documentation but timeintervalCrashInLastSessionOccured method always returns -1. what does it mean? (maybe I am using a dated version of hockeyapp lib) – nebillo Mar 25 '13 at 15:31
  • Please contact us via support directly with more details on what you are doing, which SDK version you are using etc, so we can help. -1 is the default value, which means it didn't detect a crash. – Kerni Mar 25 '13 at 16:12
0

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];
radesix
  • 5,834
  • 5
  • 24
  • 39
  • that sounds interesting. let me include our hockey app configuration in my question. – nebillo Mar 14 '13 at 12:56
  • I updated my question, let me know if it sounds good to you. isn't hockeyapp suppose to affect every users updating the app though? we have noticed just few of them having this issue. – nebillo Mar 14 '13 at 13:08
  • looks like you are missing an important statement. The configureWithIdentifier method is no longer used in the newer SDK. Are you upgrading from an older version? see my example above. – radesix Mar 14 '13 at 13:12
  • Yeah you right, but both methods seem to be accepted. if you take a look at the source code, the class implementation of the methods seem to do the same thing: https://github.com/bitstadium/HockeySDK-iOS/blob/3.0.0/Classes/BITHockeyManager.h – nebillo Mar 14 '13 at 13:19
  • 1
    This cannot be the issue: 1. There was a bug in an older version checking the validity of the `AppIdentifier` which is long fixed. 2. This bug did cause all app starts to crash! 3. The used initializer is still valid! See http://hockeyapp.net/help/sdk/ios/3.0.0/Classes/BITHockeyManager.html#//api/name/configureWithIdentifier:delegate: (Disclaimer: I am one of the Co-Founders of HockeyApp and I write the iOS SDK) – Kerni Mar 14 '13 at 13:24
  • This can be an issue if you are not passing in the live identifier correctly. And it was! It had nothing to do with the SDK in our case. We were using an NSUserDefault that was supposed to contain the live identifier. It was null; therefore, CRASH! That's fine if the old initializer is still valid.. but how does the liveIdentifer get set if you still use the old method? – radesix Mar 14 '13 at 13:36
  • Amazing! I get downvoted for describing an exact problem we experienced and the solution. SO is becoming a forum full of haters. – radesix Mar 14 '13 at 13:41
  • 1. The crash happened because the code checking if the used identifier is a possibility valid one didn't consider the that you might enter `NULL` or `nil`. That was a bug in the SDK and fixed in version 2.5.3. Again, this would have caused all (!!) app starts to crash. If the identifier is invalid, the SDK will turn itself off. 2. Some users do use one app entry on HockeyApp for beta and live releases, so there is no need to use different app identifiers (even though we don't recommend this). Also you can use `#ifdef` statements depending on your build configuration instead. – Kerni Mar 14 '13 at 13:42
  • You got down voted because your solution is **NOT** the solution for the question! This has nothing to do with hating. I am happy you found the solution for your problem, and sorry we had this bug in the first place. But again, this is not the solution for the question. – Kerni Mar 14 '13 at 13:43
  • @Kerni - don't be so defensive man. This affected us as recently as December. I'm just sharing an exact issue and resolution that we experienced in our shop. It may be useful to someone. Don't be a hater. How do you KNOW it's not the solution? You don't know what version of the SDK he is running. You're making a lot of assumptions. – radesix Mar 14 '13 at 13:43
  • Hey, I am not a hater. I am trying to help. I cannot remove the down vote any more. You might want to add a statement that this solved your problem, but actually isn't a solution for the question to clarify. (Hint: once you edit the answer I seem to be able to remove the down vote) – Kerni Mar 14 '13 at 13:46
  • And I too am trying to help. That's why I started the answer by describing that "We too had this problem once". It may or may not be a fix for this guy. It also may be valid fix for someone else on an older SDK who runs across this post. You shouldn't be making broad assumptions about what will help someone and what wont just because you wrote the SDK. – radesix Mar 14 '13 at 13:48
0

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.

Community
  • 1
  • 1
nebillo
  • 1,257
  • 10
  • 21