Приложение iOS не может быть открыто после обновления

У нас есть приложение, которое работает в магазине приложений почти год, и мы получили несколько плохих отзывов от клиентов, которые не могут открыть приложение после его обновления.

Пользователи сообщают, что не могут запустить приложение после удаления и последующей переустановки приложения. Один пользователь указал, что может запустить приложение только после сброса настроек своего iPhone.

Мы полагали, что проблема была связана с Цепочкой для ключей, так как это кажется устойчивым в системе. По этой причине мы обновили стороннюю библиотеку, которую мы используем для доступа к цепочке для ключей, по https://github.com/soffes/sskeychain. Это изменение было сделано в версии 1.4.1.

После выпуска 1.4.1 пара пользователей указали, что наконец-то смогли открыть приложение. К сожалению, поскольку мы не можем отладить проблему, мы не смогли определить, какая возможная проблема могла быть решена. Кроме того, мы видели, что другие пользователи все еще сталкивались с той же проблемой при обновлении до 1.4.1 и до 1.4.2

Мы также рассматриваем проблему, возможно, с одной из наших зависимых библиотек:

  • Flurry аналитика
  • Facebook iOS SDK
  • PayPal MPL
  • Hockeyapp IOS Lib
  • ASIHTTPRequest
  • мы не используем CoreData

Мы не можем отладить это с помощью стандартных инструментов iOS и даже не можем ожидать, что хоккейное приложение предоставит нам отчет о сбое, так как приложение закрыто перед отправкой.

Это поведение мы не понимаем, и у нас явно нет контроля над приложением, пока оно обновляется из магазина приложений. Есть ли что-нибудь, что сохраняется для приложения при его удалении? Если нет, знаете ли вы что-нибудь, что может помешать открытию переустановленного приложения?

РЕДАКТИРОВАТЬ: мы настраиваем hockeyapp lib в applicationDidFinishLaunching: метод делегата приложения следующим образом:

[[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

идентификатор приложения настраивается в настройках сборки и отличается для каждой конфигурации.

Источник

3 ответа

В общем случае при запуске может возникнуть несколько проблем:

  1. Требуемая библиотека не связана правильно: но это НЕ может быть проблемой, так как тогда все запуски приложения потерпят крах!

  2. Запуск занимает слишком много времени, и приложение убивает сторожевой таймер.

    Это может быть вашей проблемой, если вы делаете, например, миграцию большого количества данных в главном потоке прямо в applicationDidFinishLaunching: runloop и, следовательно, приложение не реагирует на ввод пользователя и, следовательно, будет остановлено сторожевым таймером примерно через 20 секунд.

    Обязательно выполняйте миграцию, не блокируя основной поток!

  3. Вы испытываете сбой (не убийство!) При запуске. Поскольку приложение аварийно завершает работу до того, как HockeyApp SDK может отправить сообщение об ошибке, вы не сможете получить эти отчеты о сбоях.

    HockeyApp iOS SDK предоставляет механизм для их решения, следуйте инструкциям, приведенным на следующей странице: http://support.hockeyapp.net/kb/how-tos-faq/how-to-handle-crashes-during-startup-on-ios

Так что 2. или 3. это ваша проблема. Если у вас есть возможность напрямую связаться с пользователем, который затронут, вы можете запросить сгенерированный отчет о сбое iOS. В противном случае проверьте рекомендации, которые я дал.

Источник

У нас была эта проблема однажды. Приложение отлично работало как Ad Hoc build. Apple проверила и одобрила его; тем не менее, конечные пользователи будут аварийно завершать работу сразу после открытия.

Для нас оказалось, что мы неправильно передали наш ключ API HockeyApp Production.

Как только мы получили, что фиксированным пользователям было хорошо идти. Например:

[[BITHockeyManager sharedHockeyManager] configureWithBetaIdentifier:@"betaKeyHere"
                                                     liveIdentifier:@"liveKeyHere"
                                                           delegate:self];
Источник

Я не могу в это поверить, но я наконец-то нашел причину сбоя приложения.

[[NSLocale currentLocale] objectForKey: NSLocaleCountryCode] иногда возвращает ноль. Я сделал предположение, что это всегда было правильно, но, видимо, я ошибался.

Я нашел этот другой вопрос здесь NSLocaleCountryCode возвращает ноль. это должно быть правильное место для продолжения этого вопроса.

Благодаря предложению @kerni я смог заставить hockeyapp отправлять отчеты о сбоях при запуске приложений, но, к сожалению, этого было недостаточно, чтобы понять, что произошло: трассировка стека отчета не была ясна.

После нескольких попыток я обнаружил еще одну плохую вещь, связанную с суматохой. Это захват системных исключений и избегание hockeyapp для правильной обработки сбоя и создания разумного отчета. Это обсуждение было очень полезным для меня, чтобы идентифицировать и исправить мой код интеграции Flurry: http://support.hockeyapp.net/discussions/questions/1359-more-information-for-crashes-with-reason-no-reason-found

После этого изменения я наконец смог увидеть достойный отчет о сбое на hockeyapp и определить мою проблему: текущую локаль.

Источник
Другие вопросы по тегам