Ой, всё упало: 4+ способа достать креш-отчет с iOS-приложения

На связи снова Максим. В прошлой статье ^[1] мы научились собирать логи на iOS устройствах самыми разными способами и теперь для нас не вопрос разобраться, почему кнопка не нажимается, а данные не грузятся.

Но бывают ситуации куда страшнее. Вы запускаете приложение, а оно… тут же исчезает. Или вы работали в приложении, раз… и вы видите домашний экран. А еще приложение может так зависнуть, что помогает только полная перезагрузка самого устройства. Все это — его величество креш (a.k.a. краш, крэш, crash, вылет, сбой, падение).

Если привести аналогии, то логи — это жалобная книга, а креш‑отчет — это заключение судмедэксперта. В нём написано точное время смерти, причина и состояние памяти ^[2] устройства в последний момент жизни приложения.

Для тестировщиков поймать креш и не допустить его до прода — это как для сапёра обезвредить мину раньше, чем на неё наступят. Работу можно сделать и после взрыва, но цена вопроса уже совсем другая. Сегодня я расскажу о 4+ проверенных способах собрать информацию о креше: от уже знакомых нам способов из предыдущей статьи до продвинутых систем мониторинга.

Креш-отчеты: что это вообще такое?

Креш‑отчет (crash report) — это технический документ, который создается автоматически самим устройством. В нем фиксируется состояние ОС и самого приложения в момент его аварийного завершения. Он служит основным источником для разработчиков и тестировщиков при поиске и устранении причин сбоев.

Содержимое креш‑отчета может варьироваться в зависимости от способа, которым вы его получили. Выделим следующие основные разделы (разберем на примере креша из игры Pokemon Go):

-------------------------------------
Translated Report (Full Report Below)
-------------------------------------
Process:             PokmonGO [47604]
Version:             0.395.1 (1)

Date/Time:           2026-02-25 08:04:10.3778 +0300
Hardware Model:      iPhone16,2
OS Version:          iPhone OS 26.2.1 (23C71)

Incident Identifier: 0BF82780-64D6-4F94-919A-F4D31C50C428

Triggered by Thread: 0, Dispatch Queue: com.apple.main-thread

Exception Type:    EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x000000000000035f

Что, где и когда сломалось?

Основная информация, с которой обычно начинают анализ креш‑отчета — что, где и когда сломалось:

• Номер креша:
  Incident Identifier: 0BF82780-64D6-4F94-919A-F4D31C50C428
  Уникальный код этого конкретного сбоя.

• Что сломалось:
  Process: PokmonGO [47604]
Version: 0.395.1 (1)
  Приложение Pokémon GO (версия 0.395.1).

• Где сломалось:
  Hardware Model: iPhone16,2
OS Version: iPhone OS 26.2.1 (23C71)
  Устройство iPhone 15 Pro Max с iOS 26.2.1. Почему iPhone16,2 — это iPhone 15 Pro Max — см. тут ^[3].

• Когда сломалось:
  Date/Time: 2026-02-25 08:04:10.3778 +0300
  25 февраля 2026 года в 08:04.

Почему сломалось?

Краткое описание, что именно пошло не так на уровне устройства и ОС. По этой информации можно примерно понять, за что ОС «убило» приложение:

• В чем проблема:
  Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x000000000000035f
  Приложение попыталось залезть в чужую или несуществующую память по адресу 0x35f.

• Как отреагировала система
  SIGSEGV
  ОС принудительно закрыла приложение, чтобы оно не сломало что‑то еще.

Что сломало?

Приложение может делать много задач одновременно. Каждая задача — это отдельный «поток». Здесь можно узнать, работа какого потока привела к сбою:

• Виновник:
  Triggered by Thread: 0, Dispatch Queue: com.apple ^[4].main-thread
  Главный поток, который обычно отвечает за интерфейс, обработку касаний и события приложения

• На чем прокололся:
  platform_memmove
  Если копнуть дальше — можно найти последнюю выполненную функцию. Прямо перед «смертью» приложение пыталось выполнить функцию, которая отвечает за копирование данных в памяти.

Наша задача — найти файл со всей этой информацией и передать разработчику. Это может значительно упростить задачу по локализации креша. Погнали разбираться, где они прячутся.

0. Знакомые способы

Читали прошлую статью ^[5]? Тогда вы уже знаете несколько способов найти информацию по крешам!

Кратко о них напомню:

• Файл.ips на самом устройстве ^[6]. Ищите файлы, название которых начинается с имени нужного приложения. Формат имени: <AppName>-yyyy-mm-dd-hhmmss.ips. Если приложение зависло, ищите файлы с префиксом JetsamEvent (нехватка памяти) или HangTracer (зависание UI).

• Open Recent Logs в Xcode ^[7]. Все то же самое, что и в способе выше, но с помощью интерфейса Xcode.

• Console (Утилита «Консоль») ^[8]. Креш‑отчеты можно найти, если перейти в блок Reports на панели слева.

• idevicesyslog ^[9]. Посмотреть все crash‑логи позволит команда idevicecrashreport -e ./crashes

Дальше разберём способы, которые не только содержат данные по конкретному крешу, но и агрегируют их по определенному признаку. Это даёт возможность оценить статистику, понять масштаб проблемы и выставить приоритет, что будем исправ��ять в первую очередь.

1. Xcode Organizer

Откуда приходят данные: реальное устройство.

Предварительные действия: получить права на аккаунт разработчика в App Store Connect, которые зависят от роли. Проверить, что в полномочиях в рамках приложения есть доступ на «Просмотр показателей и диагностических отчетов в Xcode Organizer».

Как найти:

1. В Xcode открыть меню Window → Organizer (⌥⇧⌘O).

2. Выбрать вкладку Crashes на панели слева.

Что это и как использовать:

Xcode Organizer — это встроенный в Xcode инструмент, который позволяет разработчикам и тестировщикам управлять своими проектами, устройствами, архивами приложений и данными о производительности.

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

Что нужно учитывать при работе с отчетами Xcode Organizer:

• Символикация. Чтобы вместо адресов памяти в стеке вызовов видеть понятные названия методов и строк кода, необходимо, чтобы на вашем Mac были файлы корректно загружены в App Store Connect ^[10].

Пример без символикации:

Thread 0 Crashed:
0   MyApp                0x000000010245671c 0x102400000 + 354844
1   UIKitCore            0x0000000185b3d898 -[UIViewController loadViewIfRequired] + 936
2   UIKitCore            0x0000000185b3dca0 -[UIViewController view] + 28
3   MyApp                0x0000000102456120 0x102400000 + 352544

Пример с символикацией:

Thread 0 Crashed:
0   MyApp                MyViewController.viewDidLoad() + 128  (MyViewController.swift:42)
1   MyApp                FeatureService.fetch() + 84           (FeatureService.swift:105)
2   UIKitCore            -[UIViewController loadViewIfRequired] + 936
3   UIKitCore            -[UIViewController view] + 28

• Согласие пользователя. В Organizer отображаются только креши от пользователей, которые дали согласие на отправку аналитики разработчикам. Поэтому реальное количество сбоев может быть значительно выше, чем отображается в статистике.

• Задержка данных. Отчеты появляются не моментально. Сбор и агрегация данных со стороны Apple может занимать до нескольких дней.

Основные функции Xcode Organizer:

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

• Управление архивами. Хранит все готовые сборки приложения. Отсюда их можно проверить на ошибки ^[11] и отправить в App Store или тестировщикам в TestFlight.

• Метрики производительности. Показывает, как приложение работает у реальных пользователей. Здесь можно узнать, как быстро оно запускается, сколько памяти потребляет и не зависает ли интерфейс.

• Отчеты об энергопотреблении. Показывает, насколько сильно приложение разряжает аккумулятор устройства, что очень важно для оптимизации.

• Аналитика сбоев: Собирает все падения приложения от пользователей и объединяет одинаковые сбои в группы. Это помогает понять, какие баги нужно чинить в первую очередь.

  Разберем последний пункт подробнее. Чтобы найти нужный креш‑отчет, в Organizer предусмотрена гибкая система фильтрации на панели Crashes. Можно отфильтровать данные по:

• Периоду времени: например, за последний день, две недели или за целый год.

• Версии приложения: чтобы найти сбои, характерные только для определенных релизов.

• Продукту: полезно, если приложение поддерживает не только iOS, но и другие ОС от Apple.

• Каналу распространения: позволяет разделить сбои пользователей из AppStore и тестировщиков из TestFlight.

Информация о конкретном креше

Если выбрать конкретный креш‑отчет на панели Crashes, открывается детальная информация о сбое. Одними из ключевых элементов являются Thread и номер строки стека вызовов (выделенная красным строка — команда, при выполнении которой произошел креш).

Thread (поток) — это отдельная последовательность команд, которую выполняет процессор. Приложения часто используют несколько потоков одновременно (например, один для интерфейса, другой для загрузки данных). Информация о потоке показывает стек вызовов — цепочку функций и методов, которые выполнялись в момент сбоя. Поток с пометкой креша указывает, в какой именно части кода произошла фатальная ошибка.

Crash Log Details

На панели справа, в блоке Crash Log Details, собрана основная информация о контексте сбоя:

• Binary: версия и билд приложения, в котором произошел сб��й;

• Thread: номер потока, в котором возникла ошибка (как описано выше);

• iOS: версия ОС на устройстве пользователя;

• Device: модель устройства пользователя;

• Architecture: архитектура процессора устройства пользователя;

• Distribution: канал распространения приложения — как приложение было установлено на устройство (через AppStore или TestFlight).

Statistics

В этом же боковом меню находится блок Statistics, в котором отображаются агрегированные данные по выбранному крешу. Здесь также доступны полезные фильтры:

• По периоду времени: помогает отследить динамику появления и исчезновения сбоя после его исправления (день, 2 недели, год).

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

• По типу устройства: позволяет понять, специфичен ли сбой для iPhone или iPad.

• По версии ОС: помогает определить, является ли ошибка зависимой от конкретной версии iOS.

• По каналу распространения: показывает, сталкиваются ли с проблемой реальные пользователи или только бета‑тестировщики.

Дополнительные инструменты

В Xcode Organizer есть еще несколько полезных функций для работы с креш‑отчетами:

• Кнопка «Open in Project…»: позволяет мгновенно перейти от анализа лога к исправлению кода. Xcode автоматически откроет нужный файл и подсветит проблемную строку, на которой приложение завершило работу. Это экономит кучу времени, избавляя от ручного поиска нужного метода в проекте.

• Блок Notes: текстовое поле ниже статистики, где разработчики и тестировщики могут оставлять комментарии или заметки о креше.

• Кнопка «Mark As Resolved»: позволяет скрыть уже исправленные сбои из общего списка, чтобы сосредоточиться на актуальных проблемах.

• Кнопка Sharing: создает диплинк на креш‑отчет в Xcode, который можно прикрепить к задаче или отправить разработчику.

Также любой креш‑отчет в формате .xccrashpoint можно открыть в Finder и прикрепить его к задаче.

Наконец, на панели справа есть вкладка Show Feedback Inspector. Сюда попадают отзывы от бета‑тестировщиков из TestFlight. Если тестировщик нашел баг или поймал креш — система предлагает ему описать действия, которые к этому привели, и этот комментарий появится именно здесь, что упрощает воспроизведение бага.

Как отправляют отчет бета-тестировщики

Показать последовательность действий, которые привели к крешу, при помощи снимков — теоретически можно, но крайне неудобно. Скринкасты, в данный момент, прикреплять к отзыву нельзя.

Когда использовать:

• Для быстрой локализации креша: если нужно не просто увидеть лог, а сразу увидеть причину падения. Кнопка «Open in Project» — это эксклюзив Xcode: она откроет проект и подсветит ту самую строку кода, где всё упало.

• Для поиска «железных» проблем: это единственный инструмент, который показывает отчеты о перегреве и нагрузке на диск. Если устройство пользователя превращается в обогреватель, Organizer расскажет почему.

• Когда лень возиться с dSYM: при загрузке сборки в App Store Connect, Xcode сам подтянет символы. Никаких ручных загрузок файлов — всё работает «из коробки».

2. Firebase Crashlytics

Откуда приходят данные: реальное устройство / симулятор

Предварительные действия:

• интегрировать Firebase SDK ^[12] в проект

• получить необходимые доступы для работы в Firebase

Как найти:

1. Открыть консоль Firebase ^[13].

2. Выбрать нужный проект.

3. В левом меню, в категории Run, открыть вкладку Crashlytics.

Что это и как испо��ьзовать:

Firebase Crashlytics — это система мониторинга сбоев реального времени от Google. Она автоматически собирает, анализирует и группирует креши приложения, помогая разработчикам и тестировщикам быстро находить и устранять критические ошибки до того, как они массово затронут пользователей. В отличие от Xcode Organizer, Crashlytics собирает данные как с реальных устройств, так и с симуляторов, а данные появляются в системе практически мгновенно. Также Crashlytics можно использовать и для приложений под управлением Android.

Если открыть основную вкладку Dashboard в Crashlytics, то можно увидеть общую картину стабильности приложения. В верхней части экрана отображаются ключевые метрики:

• Crash‑free users (пользователи без крешей): процент уникальных пользователей, которые не столкнулись ни с одним крешем за выбранный период времени. Это важный показатель качества приложения в глазах аудитории и бизнеса.

  Формула расчета:

  

  Например, если в выбранный период в приложении было 100 000 активных пользователей, и у 1 000 из них приложение вылетело, то расчет будет таким:

  

  Crash‑free sessions (сессии без крешей): процент сессий (запусков приложения), которые прошли без аварийного завершения. Эта цифра обычно выше, чем Crash‑free users, так как один пользователь может запускать приложение много раз, а сбой может произойти только в одной из сессий.

  Формула расчета:

  

  Для примера, из 1 000 000 сессий сбой произошел в 1 000 случаев:

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

Для удобства на главной странице есть гибкие фильтры:

Также на дашборде есть полезный блок Latest release. Он показывает, как ведет себя самая свежая версия приложения прямо сейчас: сколько пользователей уже обновились до нее, какой у нее процент Crash‑free users и Crash‑free sessions, а также топ крешей в данный момент. Если вы только что раскатили обновление, этот блок позволяет держать руку на пульсе и оперативно реагировать ^[14] на проблемы.

Вкладка Issues

На вкладке Issues отображается сгруппированный список всех крешей. Firebase автоматически объединяет одинаковые падения в еди��ую проблему (issue), чтобы не тонуть в тысячах однотипных отчетов.

Список можно дополнительно отфильтровать:

Rollout: фильтр по активным экспериментам Firebase Remote Config, чтобы посмотреть сбои только у тех пользователей, которые участвуют в конкретном А/Б тесте.

В самом списке для каждого Issue отображается следующая информация:

• Event type: тип события (креш или нефатальная ошибка).

• Library name: библиотека, в которой произошел сбой.

• File name: файл, в котором произошел сбой.

• Issue title: название сбоя по имени метода или функции, которая вызвала ошибку (например, NotificationsListTableAdapter.isScrolledToBottomTable(indexPath:list:)).

• Issue subtitle: тип исключения (например, EXC_BREAKPOINT или SIGABRT).

• Issue signal: метки от Firebase. Типы перечислены выше.

• Versions: в каких версиях приложения встречается этот креш.

• Events: общее количество раз, когда произошел этот сбой.

• Users: количество уникальных пользователей, затронутых сбоем.

• Variants: Количество подвариантов одного и того же креша (если Firebase нашел небольшие различия в стеке вызовов, но решил, что это одна и та же проблема).

Также у креша может быть пометка Note — по аналогии с Note в Organizer. Комментарий разработчика или тестировщика по этому сбою. Через Note удобно линковать креши с задачами в Jira / Kaiten, чтобы наглядно было видно, какие креши занесены в TMS и взяты в работу.

Информация о конкретном креше

Если кликнуть на конкретный Issue, откроется страница с детальной информацией о проблеме. В верхней части можно найти агрегированную статистику:

• Total events by version: график распределения сбоев по версиям приложения.

• Devices: на каких моделях устройств креш встречается чаще всего.

• Operating systems: распределение по версиям iOS.

• Device states: состояние устройства в момент падения. Здесь видно, сколько процентов сбоев произошло в фоне (Background), было ли устройство с джейлбрейком (Jailbroken), и сколько свободной оперативной памяти (RAM) оставалось в момент падения.

Блок Events

Ниже статистики находится блок Events. Здесь каждый креш представлен в виде события, каждый из которых можно просматривать отдельно и переключаться между ними. Для каждого события доступно несколько вкладок:

• Event summary: краткая выжимка — точная версия приложения, версия ОС, модель устройства и точное время сбоя.

• Stack trace (стек вызовов): главная часть отчета. Это последовательность методов, которые выполнялись потоком в момент падения. Именно здесь разработчик может увидеть строчку кода, на которой всё сломалось. Стек вызовов можно скопировать или выгрузить в виде текстового файла (.txt), чтобы прикрепить его к баг‑репорту.

• Keys (ключи): пользовательские пары «ключ‑значение», которое приложение может отправлять в Crashlytics вместе со сбоем (если настроено в проекте). Например, здесь может быть ID текущего экрана, статус авторизации пользователя или выбранный язык. Это помогает понять контекст ошибки.

• Logs & Breadcrumbs (логи и хлебные крошки): текстовые логи приложения, которые записываются прямо перед сбоем. Breadcrumbs автоматически логируют действия пользователя (нажатия кнопок, переходы между экранами), помогая восстановить цепочку шагов, которые привели к крешу. Логи также можно выгрузить в виде текстового файла (.json)

• Data (данные): детальная системная информация об устройстве в момент сбоя (модель устройства и версия ОС, ориентация экрана, объем свободной оперативной памяти, версия приложения, наличие джейлбрейка, ID пользователя).

• Rollouts (раскатки): если используется Firebase Remote Config для постепенной раскатки новых фич, здесь будет показано, какие именно эксперименты и настройки были активны у пользователя в момент падения. Это помогает выявить сбои, связанные с конкретными А/Б тестами.

Где настраивается Velocity Alerts?

Настройка происходит в два этапа: установка «порога срабатывания» (когда считать баг критическим) и выбор каналов связи (куда придет алерт).

• Настройка порогов:

  • Перейти в консоль Firebase → Crashlytics.

  • Нажать на иконку «колокольчика» (Firebase alerts) на дашборда или перейти в Project Settings (шестеренка) → Alerts.

  • Перейти на вкладку Velocity Alert.

Здесь нужно задать 2 условия, которые должны сработать одновременно для преодоления порога срабатывания:

1. Min. # of users: минимальное количество уникальных пользователей, у которых случился этот креш. По умолчанию это 25 человек. Это защищает от спама, если один и тот же тестировщик уронил приложение 100 раз подряд.

2. Min.% of users: минимальный процент затронутых пользователей от общего числа активных юзеров. По умолчанию порог установлен на 1% сессий, но для крупных приложений это слишком много (при миллионе сессий это 10 000 падений до первого уведомления). Для стабильных проектов лучше снизить его до 0.1% или даже 0.01%.

• Настройка каналов связи:

  • Чтобы алерты не терялись в почте, их лучше выводить в командный мессенджер. Это можно сделать в разделе Settings → Integrations.

  • Также можно подключить Slack, Discord или Jira. После интеграции можно выбрать, в какой конкретно канал слать уведомления о критических крешах.

Когда использовать:

• Для тушения пожаров в режиме реального времени: благодаря функции Velocity Alerts можно узнать о критическом баге через минуту после его появления, а не через два дня, когда Apple обновит статистику.

• Для понимания контекста через Custom Keys: Это лучший инструмент для отладки бизнес‑логики. Можно передавать в отчет любые ключи, чтобы понять, в каком состоянии было приложение перед падением.

• Для командной работы: самая «нативная» интеграция с Jira и Slack. Если креш массовый — задача в TMS создастся автоматически.

3. AppMetrica Yandex

Откуда попадают данные: реальное устройство / симулятор

Предварительные действия:

• интегрировать AppMetrica SDK ^[15] в проект

• получить необходимые доступы для работы в AppMetrica

Как найти:

1. Открыть сайт AppMetrica ^[16].

2. Выбрать нужное приложение.

3. В меню слева выбрать Отчеты → Крэши и ошибки → Крэши · iOS

Что это и как использовать:

AppMetrica — это платформа аналитики и маркетинга от Яндекса, которая, помимо прочего, предоставляет инструмент для отслеживания стабильности мобильных приложений. По своему функционалу и назначению раздел с крешами в AppMetrica очень похож на Firebase Crashlytics. Он также автоматически собирает отчеты об ошибках, группирует их и предоставляет удобный интерфейс для поиска причин падений как на реальных устройствах, так и на симуляторах. Также, как Crashlytics, AppMetrica можно использовать для приложений под управлением iOS и Android.

Дашборд AppMetrica

Если перейти раздел с крешами, то откроется главный экран отчета, где сразу отображаются ключевые метрики стабильности в виде графиков:

• Crash‑free: процент успешной работы приложения без сбоев. На графике этот показатель разделен на две линии:

  • Crash‑free сессий: процент запусков приложения, в которых не было аварийных завершений.

  • Crash‑free устройств: процент уникальных устройств (пользователей), которые не столкнулись со сбоями за выбранный период. Как и в Firebase, этот показатель считается главным индикатором качества релиза.

• Количество крэшей: Абсолютные цифры падений. График также разделен на две кривые:

  • Общее количество крешей (одно устройство могло упасть много раз, и каждый раз будет учитываться).

  • Количество уникальных устройств, на которых произошел этот сбой.

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

• Выбор периода: можно посмотреть статистику за нужный период времени (за сегодня, за неделю и так далее).

• Группировка на графике: данные можно отобразить по дням, не��елям или месяцам, чтобы сгладить колебания и увидеть общие тренды.

• Фильтр по типу сессий: можно анализировать все сессии вместе, смотреть только фоновые (background) сессии или исключить их, оставив только те, когда приложение было активно (foreground).

• Сегментация: можно фильтровать креши по признакам пользователей (события, демография, история запусков или установок и др. параметры) или по событиям самих крешей (география, устройство, версия приложения, тип сети).

Таблица с группами крэшей

Под графиками располагается таблица, где все креши сгруппированы по схожим причинам падения. По умолчанию таблица отображается именно «По группам крэшей», но можно переключить вид, чтобы посмотреть сгруппированные данные по «Версии приложения», «Версии ОС» или «Устройству».

Для каждой группы в таблице выводится:

• название (обычно это класс и метод, где произошел сбой);

• общее количество крешей в этой группе;

• количество уникальных устройств, которые затронула проблема;

• процент этих устройств от всех активных устройств (очень полезно для оценки масштаба проблемы);

• версия приложения, в которой этот сбой был впервые обнаружен;

• самая свежая версия приложения, в которой этот сбой воспроизводился в последний раз.

Детали крэш‑группы

Если кликнуть на любую группу в таблице, откроется страница с подробной информацией о проблеме. В верхней части экрана находится сводная статистика по этому конкретному крешу:

• Версия приложения: в каких версиях встречается этот сбой.

• Количество устройств: число уникальных устройств с этим крешем и их доля от общего числа активных устройств.

• background: процент падений, произошедших в фоновом режиме, относительно всех падений (фон + активный режим).

• Количество сессий: общее число сессий с этой ошибкой и их доля от всех сессий вообще.

• Jailbroken: процент взломанных устройств среди тех, на которых произошел креш (иногда баги связаны именно с джейлбрейком).

• Версия ОС и Модель устройства: распределение падений по ОС и железу.

На этом же экране есть инструменты для командной работы над сбоем:

• Статус крэш‑группы: можно перевести проблему из статуса «Открыт» в статус «Закрыт», когда ее починили.

• Комментарий: как и в других инструментах — поле, куда можно добавить произвольную заметку для коллег или вставить ссылку на задачу в Jira, Kaiten или другом таск‑трекере.

Ниже статистики отображается список всех конкретных случаев (событий) этого креша. В таблице видно дату и время каждого падения, модель устройства, версию ОС и версию приложения.

Крэш‑лог

Если в списке событий нажать на кнопку «Посмотреть крэш‑лог», откроется окно с максимальной детализацией конкретного падения.

В заголовке окна продублирована базовая информация: дата и время, устройство, версия приложения, версия ОС, был ли это background, статус джейлбрейка и Profile ID (идентификатор профиля пользователя в AppMetrica).

Внутри окна есть две основные вкладки:

• Stacktrace: cам стек вызовов, показывающий цепочку методов, которая привела к ошибке.

• Environment: дополнительные данные об окружении устройства в момент падения.

Для удобной работы с отчетом предусмотрены две кнопки:

• Экспортировать stacktrace: позволяет скачать стек вызовов в формате .txt, чтобы прикрепить его к задаче.

Пример содержания stacktrace:

# URL: https://appmetrica.yandex.ru/..
# App ID: 123456
# App version: 1.18.0 (5)
# Crashed at: 2026-02-24 19:17:22
# Crash group: 11524376499420636147
# Crash event: 855503626785074254
# Device: 679022513738390278
# Device model: iPhone13,4
# OS version: iOS 26.2.1
# Background session: false
# Jailbroken: false
# SDK Version: 4.2.0

#0. SIGABRT 0x0000000000000000
Fatal error: Attempted to read an unowned reference but object 0x121c73f00 was already deallocated

• Посмотреть события сессии: эта кнопка — настоящая киллер‑фича AppMetrica, если у вас логируются действия пользователя в приложении в виде событий. Она перекидывает прямо в карточку профиля пользователя и показывает хронологию его действий в ту самую дату и время, когда произошел креш. Это позволяет восстановить последовательность шагов пользователя перед падением, что критически важно для локализации багов.

Когда использовать:

• Для отслеживания действий пользователя: главная киллер‑фича — кнопка «Посмотреть события сессии». Она позволяет увидеть не просто стек вызовов, а хронологическую цепочку шагов (нажатия, переходы), которые совершил пользователь перед тем, как всё упало.

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

• Для гибкой сегментации: здесь проще всего отфильтровать креши по кастомным атрибутам, например: «покажи падения только у пользователей из Казахстана на iPhone 15 Pro».

4. App Store Connect

Откуда попадают данные: реальные устройства.

Предварительные действия: получить права на аккаунт разработчика в App Store Connect, которые зависят от роли.

Как найти:

1. Открыть сайт App Store Connect.

2. Перейти в раздел Приложения.

3. Выбрать нужное приложение.

4. В верхнем меню переключиться на вкладку TestFlight.

Что это и как использовать:

App Store Connect — это официальная платформа Apple для управления приложениями, которая также включает встроенные инструменты для сбора обратной связи от бета‑тестировщиков. В отличие от сторонних систем, этот инструмент собирает креши исключительно с реальных устройств.

Важное ограничение: сбор отчетов работает только для тестировщиков, использующих устройства на iOS 13, visionOS 1.0, macOS 12 или более новых версиях операционных систем.

В левом меню в блоке Отчеты есть два основных раздела для анализа: Сбои (Crashes) и Снимки экрана (Screenshots). Нас интересует раздел Сбои, куда попадают отчеты, отправленные тестировщиками при вылете приложения.

Список отчетов о сбоях

В разделе Сбои находится таблица со всеми собранными крешами. Для каждого отчета отображается базовая информация, которая помогает быстро понять контекст проблемы:

• Дата: когда произошел сбой;

• Сборка: конкретная версия приложения и номер билда;

• Модель устройства: на каком устройстве произошел вылет;

• Версия: версия ОС;

• Комментарий: текст, который тестировщик написал при отправке отчета. Часто это поле оказывается полезным, так как содержит информацию о том, какие действия делал тестировщик перед тем, как поймал креш.

Отчет о сбое

Если кликнуть на конкретный отчет в таблице, откроется страница с подробной информацией о сбое и устройстве пользователя в момент падения. Здесь собраны полезные технические данные:

Информация о тестировщике:

• Имя и email (если тестировщик согласился их передать);

• Комментарий от тестировщика.

Устройство и система:

• Модель устройства и версия ОС;

• Архитектура процессора;

• Разрешение экрана;

• Часовой пояс;

• Заряд аккумулятора;

• Тип подключения и оператор связи;

• Объем доступного хранилища.

Отчет со страницы можно выгрузить в виде архива. Внутри архива будет находиться JSON‑файл с основной информацией о креше, который можно прикрепить к задаче в Jira, Kaiten или в другом таск‑трекере.

Пример структуры JSON‑файла:

{
  "id" : "AKDlrItcop_bNtdwV--DsO0",
  "timestamp" : "2025-09-24T16:56:54.063Z[UTC]",
  "cfBundleShortVersion" : "4.27.0",
  "cfBundleVersion" : "2",
  "deviceModel" : "iPhone16,2",
  "osVersion" : "26.0",
  "locale" : "en-RU",
  "carrier" : "VinaPhone",
  "timezone" : "Europe/Moscow",
  "architecture" : "arm64e",
  "connectionStatus" : "WI_FI",
  "pairedAppleWatch" : "",
  "appUptimeMillis" : 6000,
  "availableDiskBytes" : 24739221504,
  "totalDiskBytes" : 255514353664,
  "networkType" : null,
  "batteryPercentage" : 30,
  "screenWidth" : 430,
  "screenHeight" : 932,
  "emailAddress" : "test@icloud.com",
  "comment" : "Крешик"
}

Раздел «Аналитика»

Помимо TestFlight, в App Store Connect есть отдельный раздел для просмотра статистики сбоев из App Store. Чтобы туда попасть, нужно перейти в раздел Аналитика → Выбрать приложение → Сбои.

Здесь отображается общее число сбоев у пользователей релизных версий приложения. Стоит отметить, что для просмотра самих логов и стектрейсов Apple предлагает использовать Xcode (раздел Organizer, который мы рассмотрели выше).

Ниже — та же самая статистика с выбранным уровнем детализации, но в виде таблицы.

В Аналитике можно строить графики сбоев, выбирая нужный уровень детализации: по дням, неделям или месяцам. График также можно настроить для отображения данных по:

• дате

• версии приложения

• устройству

• ОС и другим параметрам

Важный нюанс: «Сбои» в Аналитике учитывает данные только тех пользователей, которые добровольно согласились на отправку диагностических сведений Apple при настройке устройства. Платформа показывает процент таких пользователей (например: “За последний день согласие на отправку данных дали 28% всех пользователей”). Поэтому реальное число крешей всегда больше, чем видно на графике.

В разделе Аналитика сбои можно сравнивать с другими метриками. Например, можно наложить график сбоев на график загрузок, продаж или показов, чтобы оценить, как падения приложения влияют на выручку или удержание пользователей. Любой построенный отчет можно экспортировать в виде CSV‑файла для дальнейшей работы в Excel или других инструментах.

Когда использовать:

• Для «невидимых» крешей при старте: если приложение падает в первые миллисекунды (еще до того, как успели инициализироваться SDK Firebase или AppMetrica), только TestFlight зафиксирует этот системный лог.

• Для прямой связи с тестировщиками: это один из немногих сервисов (наряду с Organizer), где креш‑репорт приходит вместе со скриншотом и текстовым комментарием тестировщиков.

• Для быстрой проверки бета‑сборок: идеально подходит для внутреннего тестирования, когда нужно оперативно глянуть, не сломалось ли что‑то в новом билде, не дожидаясь агрегации данных в сторонних сервисах.

Вместо выводов

Сравнительная таблица 4-ех способов получить креш‑отчет на iOS:

Существуют и другие инструменты для отлова креш‑отчетов — например, Sentry ^[17], Bugsnag ^[18] или Datadog ^[19]. У каждого из них есть свои фишки и особенности интерфейса, но базовый принцип работы и скоуп предоставляемой информации везде примерно одинаковые. Если разобраться с одной системой по поиску и мониторингу крешей, то освоить любую другую уже не составит труда.

Давайте оглянемся назад. В прошлой статье мы научились собирать логи для ситуаций, когда приложение ведет себя не так, как ожидается. Это база, которая помогает снизить вероятность утечки критических ошибок в прод. Но если креш всё‑таки просочился — теперь мы умеем собирать о нём полную информацию: у кого, когда и почему приложение «померло» в процессе работы. А если повезет — мы сделаем это еще до того, как сбой поймает реальный пользователь. Надеюсь, эта статья сэкономит вам кучу времени и нервов при локализации очередной проблемы.

На этом закрываем тему с логами. Желаю вам 100% crash‑free сессий, зеленых тестов и стабильных релизов! ✨

В следующей статье начнем разбирать на винтики нативные авт��тесты на iOS. Больше пишу про мобильное тестирование и не только в своем канале ^[20].

Если интересно изучить более подробно тот или иной способ поиска креш‑отчетов — оставляю список годных статей по теме:

• Об анатомии крэшей на iOS «по‑взрослому» ^[21]

• SDK AppMetrica — теперь в опенсорсе ^[22]

• Как снять логи при краше мобильного приложения? ^[23]

P. S. Если статья оказалась полезной, поделитесь в комментариях, а какой самый странный креш вам попадался?