Привет, Хабр! Меня зовут Максим, и я тестирую мобильные приложения. Знакома ситуация, когда кнопка не работает, приложение виснет, анимации тормозят, но при этом нет никаких ошибок на экране? Можно часами играть в детектива, гадая по UI и строя догадки, что пошло не так. А можно за несколько минут найти настоящего преступника — ведь iOS щедро оставляет улики в виде логов. Нужно лишь знать, где их искать. Секрет — в грамотном выборе способа, как собрать доказательства. Но обо всём по порядку.

Логи: что, зачем и как

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

Вот пример креш‑лога из .ips‑файла, который показывает критическую ошибку в некогда популярной игре Pokemon GO:

Incident Identifier: 4EB9D661-045D-4AA9-9483-6EC5A03417B1

Hardware Model: iPhone16,2

Process: PokmonGO [3085]

Exception Type: EXC_BAD_ACCESS (SIGSEGV)

Exception Subtype: KERN_INVALID_ADDRESS at 0x00622e7cbcfaba50

Date/Time: 2025-08-25 13:17:58.8625 +0300

Этот фрагмент из live‑логов утилиты Console говорит о потенциальных проблемах в производительности из‑за выполнения операций ввода‑вывода на главном потоке:

Hang Risk com.apple.runtime-issues
message: This method does I/O on the main thread underneath that can lead to UI responsiveness issues...
antipattern trigger: -[NSBundle bundleIdentifier]
...
libRPAC.dylib	сбой	19:12:18.350727+0300	AtiClient

А эти логи, собранные с помощью log collect CLI, указывают на сетевую ошибку в клиенте, связанную с тайм‑аутом запроса к удалённому ресурсу:

2025-10-14 19:12:15.443811+0300 Error AtiClient: (CFNetwork)
Task <10355B97-785F-4857-BA66-D231F55D2431> finished with error [-1001]
Error Domain=NSURLErrorDomain Code=-1001 "Превышен лимит времени на запрос."
NSErrorFailingURLStringKey=https://ep2.facebook.com/v17.0

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

Зачем тестировщикам и разработчикам логи?

Что можно узнать из логов:

• убедиться, что нужная функция действительно была вызвана

• узнать, ушёл ли запрос к серверу и какие данные приложение передавало

• понять, как приложение среагировало на ответ с сервера

• понять, почему после тапа на кнопку ничего не произошло

• поймать ошибку или предупреждение, которое не видно визуально

Как логи помогают в работе:

• становятся первичным источником данных, если со стороны UI нет или мало информации

• помогают быстрее локализовать баги (особенно нестабильные)

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

Все логи можно условно разделить на:

• креш‑отчёты — логи, которые связаны с неожиданной остановкой приложения. Обычно информация о крешах на проде служит поводом для выпуска срочного хотфикса.

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

В этой статье сделаем упор на логи в общем и разберём 7 проверенных способов, как их собрать с iOS‑приложения. Как собрать данные конкретно по крешам, — разберем в следующей статье.

1. Файл .ips на устройстве (sysdiagnose)

Где применимо: реальное устройство

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

Не требуются: файлы создаются автоматически.

Как найти:

1. Перейти на устройстве: Настройки → Конфиденциальность и безопасность → Аналитика и улучшения → Данные Аналитики

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

При этом именование файлов происходит по определенному принципу:

тип_события_дата_время.ips

Пример: AtiClient-2024-08-14-152242.ips

Данные файлы формируются благодаря инструменту системной диагностики sysdiagnose от Apple. Этот инструмент собирает детальную информацию о работе системы и является одним из наиболее полных источников диагностических данных. Каждый файл — это отчёт определённого типа, среди которых можно выделить:

• CrashReport. Аварийное завершение приложение (Exception/Signal) или по‑простому — креш. Появляется, когда приложение «падает», при запуске или во время работы.

Креши удобно искать по bundle id приложения, который обычно похож на название приложения (например, VKClient ).

• JetsamEvent. Выгрузка приложения из системной памяти при нехватке RAM (Out‑of‑Memory). Часто намекает на утечку памяти или слишком тяжёлые экраны. Появляется, когда работа в приложении забивает RAM под лимит, приложение начинает тормозить или неожиданно завершает свою работу.

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

• SpinReport. Приложение активно использует процессор (CPU), но не отвечает пользователю. Может быть следствием дедлоков или бесконечных циклов в коде. Возможные признаки: устройство сильно греется или подвисает интерфейс.

• NotificationServiceExtension. Сбой расширения UNNotificationServiceExtension, которое обрабатывает push‑уведомления. Появляется, когда расширение уведомлений завершает работу аварийно: креш, ошибка обработки, завершение по таймауту.

Можно вручную сгенерировать отчёт sysdiagnose, если одновременно нажать обе кнопки громкости и боковой кнопки в течение 1–1,5 секунд. На экране «Данные Аналитики» появится новый файл под названием stacks с датой и временем генерации файла.

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

• если произошёл сбой в приложении в тот момент, когда устройство не было подключено к Xcode

• для анализа производительности, проблем с памятью, сетями и пр. без необходимости подключения к Xcode

Любой .ips‑файл можно удобно экспортировать прямо с устройства (напр., через AirDrop), чтобы отправить разработчику или прикрепить к баг‑репорту.

iOS автоматически удаляет старые .ips‑файлы через некоторое время, поэтому лучше собирать логи сразу после инцидента.

2. log collect CLI

Где применимо: реальное устройство / симулятор

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

• установить Xcode Command Line Tools (или Xcode)

• подключить устройство по проводу

• запустить Terminal

• получить UDID устройства (напр., как мы рассмотрим в способе 5 с помощью libimobiledevice)

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

log collect CLI — менее известный способ, который использует возможности командной строки и позволяет выгрузить большой архив логов для офлайн‑анализа. Отлично работает при отладке нестабильных ошибок, которые сложно поймать в live‑режиме.

Практика показывает значительные различия между данными, полученными через sysdiagnose (1-й способ), и log collect CLI. sysdiagnose собирает очень подробный срез состояния системы на момент генерации файла. Он включает в себя много различных данных: логи, конфиги, состояние процессов и так далее. Это глубокое покрытие, но с ограниченным временным диапазоном. В то же время log collect CLI собирает только логи. При этом можно выгрузить данные за длительный период — обычно до 10 дней, пока логи не будут вытеснены системой.

Команда log collect CLI

Работа с log collect CLI ведётся через базовую команду sudo log collect и её параметры. Для выполнения команды требуются права администратора. Например:

sudo log collect --device-udid <UDID> --last 10m --output iphone_logs.logarchive

Ключевые параметры команды

--output — определяет путь сохранения архива.

sudo log collect --output ~/Desktop/iphone_logs.logarchive # создаст архив с именем iphone_logs на рабочем столе

sudo log collect --output ~/Desktop/ # создаст архив с автоматически присвоенным именем system_logs на рабочем столе

Если не указать --output, файл создается с временной меткой в текущей директории.

--last — ограничивает сбор логов за определённый период.

sudo log collect --last 30m  # за последние 30 минут

sudo log collect --last 2h   # за последние 2 часа  

sudo log collect --last 1d   # за последний день

--start / --end — также ограничивает сбор логов, но с / по определённую дату и время.

sudo log collect --start "2025-08-20" # с 20 августа 2025 г

sudo log collect --start "2025-08-20 14:00:00" --end "2025-08-20 14:30:00" # c 20 августа 2025 г 14:00 по 20 августа 2025 г 14:30

--size — ограничивает размер собираемых данных.

sudo log collect --size 100k  # максимум 100 КБ

sudo log collect --size 50m  # максимум 50 МБ

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

sudo log collect --last 3d --size 100m

Параметры для работы с iOS‑устройствами

--device — автоматически выбирает первое найденное устройство.

sudo log collect --device --last 10m

Не рекомендуется использовать эту команду, поскольку целевое и найденное устройство могут не совпасть.

--device-name — указать устройство по имени.

sudo log collect --device-name "iPhone 16 Pro Max" --last 15m

--device-udid — указать устройство по UDID (рекомендуемый метод)

sudo log collect --device-udid A1B2C3D4R5F8G8H8I1J0 --last 20m

UDID — это ID устройства, который всегда является уникальным. В свою очередь имя устройства не гарантирует уникальность. При подключении нескольких устройствах --device выберет первое найденное. Именно поэтому предпочтительнее использовать UDID устройства вместо его имени.

Анализ собранных логов

После создания .logarchive-файла его можно проанализировать с помощью команды log show. Например:

log show --archive system_logs.logarchive # базовый просмотр архива

log show --archive system_logs.logarchive --predicate 'process == "AtiClient"' # фильтрация по конкретному приложению

log show --archive system_logs.logarchive --start "2025-08-20 14:00:00" --end "2025-08-20 14:30:00" # анализ определенного временного периода

log show --archive system_logs.logarchive --predicate 'process == "AtiClient" AND messageType == "error"' # фильтрация всех ошибок в приложении

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

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

• пользователи жалуются на ухудшение производительности, но проблема накапливается постепенно. Архив за несколько дней покажет тренды использования памяти, CPU и сетевой активности.

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

3. Open Recent Logs в Xcode

Где применимо: реальное устройство

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

1. Установить Xcode.

2. Подключить устройство по проводу / Wi‑Fi.

Для подключения по Wi‑Fi устройство должно быть предварительно добавлено как доверенное, а также должна быть активирована опция «Connect via Network when wired connection is not available» на карточке устройства.

Как найти:

1. В Xcode открыть меню Window → Devices and Simulators (⇧⌘2).

2. На панели слева во вкладке «Devices» найти в списке нужное устройство.

3. Нажать на кнопку «Open Recent Logs».

4. Откроется окно Finder со списком .ips‑файлов.

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

На самом деле это те же самые .ips‑файлы, которые хранятся на самом устройстве (способ 1). По сути, Xcode просто предоставляет удобный интерфейс к аналитическим файлам устройства. Эти логи автоматически скачиваются с устройства на Mac при каждом подключении устройства.

Логи устройства не будут отображаться в Xcode до тех пор, пока устройство не будет хотя бы раз подключено к Mac. При этом логи сохраняются, даже если потом отключить устройство: их можно открыть повторно без переподключения устройства.

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

Все те же самые кейсы, что и в 1-м способе (sysdiagnose), но с преимуществами интерфейса Xcode:

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

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

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

Любой .ips‑файл, как и в способе 1, можно удобно экспортировать прямо с устройства (напр., через AirDrop), чтобы отправить разработчику или прикрепить к баг‑репорту.

Альтернативные способы достать .ips файлы на Mac

Основная директория Xcode

~/Library/Developer/Xcode/DeviceLogs/[Имя_устройства]

• архивы логов, доступные через интерфейс Xcode;

• файлы сгруппированы по имени подключённого устройства;

• содержат все типы .ips‑файлов (отчёты о крешах, фризах и завершениях процессов);

• удобны для быстрого просмотра и экспорта логов прямо из Xcode.

  Системная директория крешей

~/Library/Logs/CrashReporter/MobileDevice/ 

• хранит сырые системные креш‑логи, которые создаются самим iOS и системными службами;

• эти отчёты формируются через процесс launchd — системный менеджер, который запускает и контролирует все процессы в iOS (аналог systemd в Linux);

• в отличие от логов Xcode, здесь можно найти более детальные технические данные:

  • полный стек вызовов;

  • информацию о загрузке памяти и процессора;

  • отчёты об ошибках системных служб.

4. Console (Утилита «Консоль»)

Где применимо: реальное устройство / симулятор

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

1. Подключить устройство по проводу / Wi‑Fi.

2. Собрать приложение на реальном устройстве / симуляторе любым удобным способом (Xcode, .ipa‑файл, App Distribution, Test Flight и так далее).

iOS‑устройство должно быть доверенным, и Mac должен иметь доступ к логам (по проводу или Wi‑Fi с авторизацией).

Как найти:

1. В Finder перейти в Applications → Utilities и открыть утилиту Console.

2. Выбрать устройство или симулятор на панели слева в блоке Devices.

3. Нажать на Start streaming → начнётся поток логов.

Самый быстрый способ открыть Console (как и любые другие утилиты из этой статьи) — найти через Spotlight (⌘ + пробел).

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

Console — это встроенное приложение macOS, которое идет «из коробки» и не требует дополнительной установки. С его помощью можно смотреть живой поток системных логов, то есть всё, что приходит с устройства или симулятора в режиме реального времени. По своей сути, Console имеет схожее назначение с debug‑area в Xcode — отображение логов во время работы приложения. Но преимущество Console состоит в том, что оно не требует запуска или даже установки Xcode.

В Console есть 2 стандартные вкладки:

• All Messages — отображаются все события подряд, то есть полный поток системной активности.

• Errors and Faults — фильтрует и отображает только ошибки (в колонке Type отображаются с жёлтым кругом).

Console поддерживает гибкую и быструю фильтрацию по таким параметрам, как:

• Subsystem — системный компонент;

• Message type — тип сообщения;

• Process — конкретный процесс;

• Library — библиотека;

• Category — категория события.

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

• Crash Reports — отчёты о крешах;

• Spin Reports — отчёты о зависаниях;

• Log Reports — архивы логов;

• Diagnostic Reports — диагностические отчёты;

• Mac Analytics Data — аналитические данные Mac;

• system.log — системные логи.

Любое событие из Console можно удобно и быстро экспортировать через кнопку Share в правом верхнем углу, чтобы отправить разработчику или прикрепить к баг‑репорту.

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

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

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

• приложение работает в фоне (background refresh, push‑уведомления), нужно отследить его активность. Console показывает все системные вызовы и ошибки, даже когда приложение не на переднем плане.

• если есть проблемы с системными фреймворками, такими как HealthKit, CloudKit, Core Data и др. Системные логи покажут ошибки взаимодействия с iOS API, которые не всегда видны в логах самого приложения.

  Альтернативные способы открыть Console

Логи по каждому конкретному симулятору также можно найти в Finder, если перейти в

~/Library/Logs/CoreSimulator/[Device_UDID]/

Руководство пользователя приложения «Консоль»

5. simctl

Где применимо: симулятор

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

1. Установить Xcode (simctl поставляется в комплекте).

2. Настроить проект приложения.

Как найти:

1. Переключиться на нужную ветку проекта.

2. Запустить Xcode.

3. Выбрать необходимый симулятор или настроить новый (устройство + версия iOS) в меню Window → Devices and Simulators (⇧⌘2).

4. Собрать проект на симуляторе (⌘ + R).

5. Запустить Terminal.

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

simctl — это утилита командной строки для взаимодействия с симуляторами. По своим возможностям и принципу работы похожа на ADB для Android. simctl устанавливается вместе со средой разработки Xcode и используется вместе с Xcode‑runner командной строки — xcrun (proxy‑утилита, перенаправляющая вызовы к simctl).

Для просмотра логов с симулятора в командной строке необходимо выполнить базовую команду, которая по умолчанию показывает логи уровня default, error и fault.:

xcrun simctl spawn booted log stream

В iOS используются пять уровней логирования:

1. Default. Информация о потенциальных причинах сбоев.

2. Info. Полезная, но необязательная отладочная информация.

3. Debug. Детальная информация для разработки и диагностики.

4. Error. Информация об ошибках процесса.

5. Fault. Системные ошибки и мультипроцессные сбои.

Если нужно вывести логи с расширенными уровнями, то можно воспользоваться параметрами:

xcrun simctl spawn booted log stream --level=info # добавляет уровень info

xcrun simctl spawn booted log stream --level=debug # добавляет уровень info и debug

Также есть параметры, которые позволяют отфильтровать все логи по определённому признаку:

xcrun simctl spawn booted log stream --predicate 'processImagePath endswith "AtiClient"' # по конкретному приложению

xcrun simctl spawn booted log stream --predicate 'eventMessage contains "error" and messageType == info' # по типу событий и сообщений

Примеры полезных команд с параметрами для фильтрации:

xcrun simctl spawn booted log stream --predicate 'NOT (process == "kernel" OR subsystem beginswith "com.apple.system")' # исключить системный шум

xcrun simctl list devices # получить список доступных симуляторов

xcrun simctl spawn [DEVICE_ID] log stream --level=debug # получить логи конкретного симулятора

xcrun simctl spawn booted log stream --predicate 'process == "AtiClient" and category == "launch"' --level=debug # отследить запуск приложения

xcrun simctl spawn booted log stream --predicate 'eventMessage contains "memory" or eventMessage contains "malloc"' # мониторинг использования памяти

xcrun simctl spawn booted log stream --predicate 'eventMessage contains "network" and messageType in {error, fault}' # отслеживание ошибок сети

Чтобы выключить вывод логов, нужно нажать ⌃ + C в окне Terminal.

C помощью команды log collect можно сделать архив логов для дальнейшего анализа:

xcrun simctl spawn booted log collect # создает файл .logarchive в текущей директории

Команда diagnose позволяет сгенерировать подробный отчёт всего, что происходило во время сессии приложения «Simulator»:

xcrun simctl diagnose

Содержимое отчёта:

• системные логи

• логи симулятора

• информацию об устройстве и окружении

• настройки устройства

• дополнительная диагностическая информация

В отчёте может содержаться конфиденциальная информация, поэтому нужно быть осторожным при передаче содержимого отчёта третьим лицам.

После генерации откроется окно Finder с расположением файла в формате .gz, который содержит полный диагностический отчёт.

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

• автотесты периодически падают на CI, но локально воспроизвести не удаётся. simctl интегрируется в скрипты CI и может собирать детальные логи автоматически при падении тестов.

• симулятор ведет себя нестабильно, зависает или не запускается. diagnose создаёт полный слепок состояния симулятора для анализа системных проблем.

• нужно быстро оценить производительность без запуска тяжёлых инструментов профилирования. Debug‑логи покажут временные метки и использование ресурсов в реальном времени.

• отладка взаимодействия с системными сервисами (CoreData, CloudKit, HealthKit) без влияния реального устройства. Симулятор предоставляет чистую среду с детальным логированием системных вызовов.

6. idevicesyslog

Где применимо: реальное устройство

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

1. Установить libimobiledevice (напрямую с сайта или если установлен brew — через brew install libimobiledevice ).

2. Подключить устройство по проводу / Wi‑Fi.

3. Запустить Terminal.

4. Собрать приложение на реальном устройстве любым удобным способом (Xcode, .ipa‑файл, App Distribution, Test Flight и так далее).

iOS‑устройство должно быть доверенным, и Mac должен иметь доступ к логам (по проводу или Wi‑Fi с авторизацией).

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

libimobiledevice — это кроссплатформенная библиотека для взаимодействия с iOS‑устройствами. Включает в себя множество полезных утилит для iOS‑разработки, одна из которых — idevicesyslog. Это утилита, которая позволяет получать системные логи iOS‑устройства в реальном времени. Она работает напрямую с подключённым устройством и выводит поток логов, аналогичный тому, что можно увидеть в Console (способ 4).

В первую очередь необходимо получить UDID устройства через команду в Terminal:

idevice_id -l

Важно получить UDID устройства — так можно убедиться, что устройство подключено и его видит система. Если команда не срабатывает — попробуйте разблокировать устройство.

Запустить сбор логов с устройства можно через команду:

idevicesyslog

В окне Terminal начнётся поток логов, аналогичный Console:

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

idevicesyslog | grep "AtiClient" # по конкретному процессу

idevicesyslog | grep -i "error\|fault\|crash" # поиск только ошибок

Также можно настроить работу с idevicesyslog по Wi‑Fi. Для этого сначала нужно подключить устройство по проводу, а затем ввести команды:

idevicepair pair # содзаёт пару с устройством

idevicepair wifi on # включает Wi-Fi

Дополнительные утилиты libimobiledevice

# информация по устроству

ideviceinfo # получить детальную информацию об устройстве

ideviceinfo -k DeviceName # получить имя устройства
ideviceinfo -k ProductVersion # получить версию устройства
ideviceinfo -k UniqueDeviceID # получить UDID устройства

# управление приложением

ideviceinstaller -l # получить список установленных приложений

ideviceinstaller -i AtiClient.ipa # установить .ipa файл

ideviceinstaller -U su.ati.client.ios.appbundle # удалить приложение

# диагностика устройства

idevicecrashreport -e ./crashes # посмотреть crash‑логи

idevicediagnostics diagnostics # проверить статус подключения

idevicediagnostics restart # перезагрузить устройство

Чтобы выключить вывод логов, нужно нажать ⌃ + C в окне Termnal.

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

• при настройке автоматических тестов на CI‑серверах, где нет Xcode. Легковесная утилита командной строки, которая работает на любой Unix‑системе и легко интегрируется в скрипты.

• нужно получить логи с устройства, подключённого к удаленному Mac. Работает через SSH‑сессию без графического интерфейса, в отличие от Xcode или Console.

• работаете на старом Mac. Занимает минимум ресурсов и не требует установки тяжёлых IDE.

• работаете на Linux‑машине и иногда нужно подключиться к iOS‑устройству. libimobiledevice работает на Linux, в отличие от нативных инструментов Apple.

Документация libimobiledevice

7. Console в Apple Configurator

Где применимо: реальное устройство

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

1. Установить Apple Configurator из App Store.

2. Подключить устройство по проводу.

3. Собрать приложение на реальном устройстве любым удобным способом (Xcode, .ipa‑файл, App Distribution, TestFlight и так далее).

Как найти:

1. Открыть Apple Configurator.

2. Дождаться, пока подключённое устройство появится на экране.

3. Открыть карточку устройства.

4. На панели слева перейти в Console → начнётся поток логов.

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

Apple Configurator — это приложение от Apple, которое изначально создано для массового управления iOS‑устройствами в корпоративной среде и предоставляет:
• профили конфигурации для настройки устройств (Wi‑Fi, VPN и пр.);
• массовую установку приложений;
• мониторинг состояния устройств;
• резервное копирование и восстановление.

Также Apple Configurator позволяет получить доступ к системным логам устройства без запуска Xcode или системной Console. Особенно полезен на корпоративных Mac, где могут отсутствовать инструменты разработчика.

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

• при тестировании приложения на устройствах, но на рабочих Mac нет Xcode. Apple Configurator доступен в App Store и не требует AppleDeveloper-аккаунта или CLI.

• когда QA‑команда тестирует приложение на десятках устройств одновременно. Можно открыть несколько окон Console для разных устройств и мониторить их параллельно.

• при работе на чужом Mac, где нет настроенной среды разработки. Установка из App Store занимает минуты, в отличие от полной настройки Xcode.

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

Сравнительная таблица 7-ми способов для снятия логов на iOS:

Умение быстро получать и анализировать логи — это разница между часами мучительных поисков бага и его решением за минуты. В этой статье мы разобрали семь способов получения логов с iOS‑устройств, от экстренной отладки через .ips‑файлы до live‑мониторинга через idevicesyslog.

Теперь у вас есть полный арсенал инструментов для любой ситуации:

• Экстренная отладка → .ips файлы на устройстве или через Xcode (способы 1 и 3)

• Глубокий анализ → log collect CLI для постанализа нестабильных проблем за длительный период времени (способ 2)

• Live‑отладка с Xcode → Console или simctl для сбора логов в режиме реального времени (способы 4 и 5)

• Live‑отладка без Xcode → idevicesyslog через Terminal или Apple Configurator из App Store для сборка логов в режиме реального времени (способы 6 и 7)

Сохраните эту статью в закладки на случай, когда вы столкнётесь с неуловимым багом, который «воспроизводится у меня, но не воспроизводится у разработчика». Теперь вы точно будете знать, с чего начать поиск. Но помните: лог без контекста — просто текст, а лог с пониманием контекста — уже половина решения.

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

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

• Логирование на Mac и команда log: руководство для администраторов Apple

• Как снимать логи с устройств на Android и iOS: разбираемся с инструментами

• Логи в iOS, эпизод 1: os_log

• simctl: управление симуляторами Apple через терминал

P. S. Если статья оказалась полезной, поделитесь в комментариях своими кейсами, какие вы используете способы для сбора логов на iOS и в каких ситуациях.