Сравнение TestFlight Live, QuincyKit и Crashlytics

Я собираюсь запустить приложение в AppStore, и я хотел бы отслеживать сбои и исправлять их как можно скорее. Если возможно, было бы неплохо собрать дополнительную информацию о деятельности пользователя и других полезных материалах. Для этого я искал некоторые инструменты отчетности о сбоях и наиболее интересные из них: TestFlight Live, QuincyKit и Crashlytics.

Среди этих трех, QuincyKit должен быть самым легким, но два других, кажется, очень интересны, поскольку они предоставляют более сложные отчеты и другие интересные вещи.

Моя цель состоит в том, чтобы иметь как можно больше информации о любой проблеме, которую может испытать пользователь, но в то же время я не хочу, чтобы приложение замедлялось или потребляло больше ресурсов.

  • По вашему мнению и из вашего личного опыта, какой из этих инструментов является лучшим (с учетом моей цели и моих потребностей)?
  • Используя TestFlight Live или Crashlytics, я сделал бы приложение слишком медленным?
  • Есть ли риск перегрузить устройство?
  • Отчеты QuincyKit достаточно точны? Сколько информации я могу получить от них?

Спасибо!

Вот что я решил:

Я использую Crashlytics для отчетов о сбоях (да, это действительно здорово) и TestFlight для отслеживания активности пользователей (контрольные точки действительно полезны для выяснения того, что пользователи обычно делают и выясняют, что такое тенденция). Я выполнил инструкции, написанные здесь

Ответы

Ответ 1

Я честно думаю, что Crashlytics - лучшее решение, чем Testflight для отчетов о сбоях.

Вот что вы получаете с Crashlytics, что вы не получаете с другими.

  • Дублировать отбраковку (TF тоже делает это, но ее не слишком хорошо на ней, Crashlytics проклят почти идеально)
  • Фактически вы можете отмечать сбои как закрытые/разрешенные, и вывести их из списка для данной версии.
  • Crashlytics делает все отчеты TF Crash, но лучше, а затем некоторые (протоколирование, трассировки стека и т.д.).
  • Процент затронутых пользователей и числа, которые идут с этим. (то есть: должен ли я исправить ошибку, которая произошла с одним парнем или с тем, что происходит с 10k?) Testflight не говорит вам об этом.
  • Приоритезация основана на возникновении. Это, вероятно, самый важный выигрыш, на мой взгляд.

Это всего лишь несколько, но я считаю, что они, вероятно, самые важные для вас.

Мы использовали отчет о сбое Testflight в течение почти двух лет в чрезвычайно популярном приложении (несколько миллионов D/Ls). Это определенно лучше, чем ничего, и очень удобно, если вы используете TF для распространения, но вы получаете гораздо больше преимуществ от Crashlytics. Этим летом мы перешли на Crashlytics, и теперь мы действительно можем управлять сбоями и принимать умные решения о том, что исправить, и когда вместо простого просеивания гигантского бесконечного списка.

Я вижу, что вы уже приняли ответ, но я бы серьезно посмотрел на него, даже если вы решите продолжить тестирование. Мне было трудно понять, чего вам не хватает, пока ваше приложение не отправлено, и в этот момент еще труднее изменить.

Ответ 2

Crashlytics не имеет аналогов для отчетов о сбоях.

Мы были в одной лодке, когда вы пытались найти лучшее решение для отчетов о сбоях. После некоторых тщательных исследований и тестов TestFlight, HockeyApp и Crashlytics мы изначально выбрали HockeyApp, потому что они позволили нам распространять бета-версию вместе с отчетами о сбоях как на iOS, так и на Android (мы хотели как в одном решении для обеих платформ). Тем не менее, HockeyApp исключение backtracing просто не дает нам никаких дополнительных данных о сбоях. Здесь сияет Crashlytics. Исключительное исключение - это потрясающе. Период.

Итак, вот мое резюме всех 3 SDK:

Crashlytics

  • Отчет о сбое <1 >
  • # 1 исключение backtracing, bar none (предоставляет очень полезные дополнительные сведения о сбоях)
  • Чрезвычайно быстрый и легкий
  • Пользовательское ведение журнала для дополнительного контекста сбоя
  • Лучшее дублирование распознавания и отбраковки
  • Автоматические обновления SDK (их приложение Mac автоматически обновляет SDK Crashlytics iOS в вашем проекте)
  • Нет бета-дистрибутива (мне бы понравилось одностановленное решение для отчетов о сбоях и бета-рассылке)
  • Автоматическая поддержка сервера сборки

TestFlight

  • Немного тяжело, и добавляет вздутие к вашему пакету приложения.
  • Отличное распространение бета-версии
  • Поддержка Android (по крайней мере, когда мы тестировали назад 6 месяцев назад)

HockeyApp (HockeyKit - бета-дистрибутив, QuincyKit - отчеты о сбоях)

  • Легкий вес
  • Сбой ввода сообщений об ошибках
  • Исключительное ограничение обратного трассировки сильно ограничено (по крайней мере, когда мы тестировали в марте 2011 года)
  • Очень хорошее бета-распределение.

Все, что сказано, мы выбрали Crashlytics для отчетов о сбоях и HockeyApp для бета-распространения. Но вы должны выбрать, что лучше всего подходит для ваших нужд.

Ответ 3

Определенно рекомендую Crashlytics.

TestFlight Live дал мне проблемы в прошлом. Кажется, каждый раз, когда я иду использовать TestFlight, он все равно не работает.

Crashlytics потрясающе. Вот почему:

  • Добавление его в ваш проект не может быть проще. Существует приложение Mac, которое выполняет большую часть тяжелой работы для вас.
  • Автоматически обновляет себя
  • Приоритизация сбоев для вас
  • Обеспечивает удобную статистику, например, проценты ОС и устройств, а также среднюю доступную память и т.д.

Я использую Crashlytics во всех моих приложениях. Я добавил его в Hipstamatic, когда я был там, и данные, которые мы получили, были шокирующими. Это действительно помогло улучшить наш продукт. Я также попробовал TestFlight Live и быстро удалил его после первой бета-версии, так как он вызывал сбои.

Crashlytics потрясающе. Вы должны использовать его.

Ответ 4

Если мы говорим только о сбоях, Crashlytics намного лучше, чем TestFlight. (Никогда не пробовал QuincyKit, поэтому я не могу сравнить 3 варианта)

Мы используем Crashlytics более года на Weddar, и это было здорово. Попробовав другие решения, прежде чем я должен сказать, что перед его установкой я был довольно подозрительным в отношении замечательных функций, которые они заявляли, но установка действительно была выполнена примерно через 5 минут, и она добавила только около 40-45 КБ в приложение.

Отчеты о сбоях невероятно детализированы, что позволяет быстро определить решения для ошибок, а обновления для sdk довольно стабильны и стабильны. Команда невероятно поддерживает. Я помню, что у нас возникла проблема с новыми ARM7, когда вышел iPhone5, и они решили его примерно через 30 минут.

Я использую TestFlight для управления бета-тестированием пользователей, поэтому летом я попробовал TestFlight Live SDK, чтобы проверить, было ли это решение для интеграции в один сервис, но у нас был очень плохой опыт. У меня было 2 обновления, отклоненные в одобрении App Store в первый раз (Weddar был запущен в апреле 2011 года), и мы потеряли около месяца, пытаясь поймать ошибку. Когда LIVE бета-тестирование, никто не будет жаловаться на какие-либо проблемы, мы "решили" его, удалив TF SDK. Никогда не понимал, в чем проблема. Мы связались с командой TestFlight и не имели контакта. (Еще одна большая деталь: TF SDK добавила около 800 кб в наше приложение.)

Итак, даже если я все еще использую TestFLight для бета-тестирования, если вы ищете большой и легкий отчет SDK для отчетов о сбоях, я определенно говорю, что вы должны использовать Crashlytics.

Надеюсь, что это поможет.

Ответ 5

Я бы сказал, что с TestFlight (Live)

По моему опыту, TestFlight SDK не приведет к сбою/замедлению вашего устройства и имеет очень универсальную отчетность о сбоях, позволяющую довольно точно отлаживать сообщенные ошибки.

TestFlight также удваивается как пакет обратной связи для тестирования в процессе разработки.

Это также довольно легкий SDK.

Чтобы быть более конкретным (отвечая на свой список вопросов):

  • TestFlight позволяет скальпировать для пользовательских "контрольных точек" и имеет собственную версию NSLog, которая позволяет динамически регистрировать события во время выполнения.
  • Ваше приложение не будет замедляться, так как сетевые запросы обрабатываются с основного потока.
  • Я не понимаю, почему устройство будет перегружено с помощью любого из упомянутых вами SDK.
  • Отчеты QuincyKit кажутся достаточно точными, однако вам нужно составить свой собственный подход к точности, в которой вы нуждаетесь, - вы можете найти документы QuincyKit here.