> Как смотреть логи мобильного приложения и какими способами? (iOS, Swift, Android)

Короткий ответ

Основные способы: логирование через системные инструменты (Logcat для Android, Console.app и Xcode для iOS), интеграция сторонних сервисов (Crashlytics, Sentry, Datadog), а также перехват сетевых запросов (Charles, Proxyman, mitmproxy). Для iOS также доступен os_log и unified logging, для Android - Timber и adb logcat. Выбор зависит от задачи: отладка, мониторинг продакшена или анализ сетевого трафика.

Подробное объяснение

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

Системные логи - это вывод операционной системы и приложения в единый поток. На Android это adb logcat, который показывает все сообщения от системы и приложений с фильтрацией по процессу, уровню важности и тегу. На iOS - Console.app (macOS) или команда log stream через Xcode, работающие на базе unified logging (os_log).

Логи приложения - это то, что разработчик закладывает в код. На Android часто используется Timber (обёртка над Log), на iOS - print или os_log. Важно понимать, что print в Swift не пишет в системный лог, а только в stdout, поэтому для прод-мониторинга лучше использовать os_log.

Сетевые логи - перехват HTTP/HTTPS трафика. Инструменты: Charles Proxy, Proxyman, mitmproxy, а также встроенные в приложение перехватчики (например, OkHttp Interceptor на Android, URLSession delegate на iOS). Это помогает диагностировать проблемы с API, статус-коды, тайминги и тела запросов.

Сторонние сервисы - Crashlytics (Firebase), Sentry, Datadog, New Relic. Они собирают логи, краши и метрики с продакшена, позволяют фильтровать по пользователям, версиям приложения и устройствам.

Для QA важно уметь комбинировать: локальная отладка через adb/Xcode, перехват сети для проверки API-контрактов и подключение к crash-репортингу для анализа багов на реальных устройствах.

На практике

Начни с локальной отладки: подключи устройство или эмулятор, открой Logcat (Android Studio) или Console (Xcode), отфильтруй по пакету/процессу. Для сетевых запросов настрой Charles или Proxyman - не забудь установить сертификат на устройство для HTTPS. Для прод-аналитики используй Crashlytics или Sentry: там логи приходят автоматически, можно искать по stack trace и добавлять кастомные ключи.

Полезные команды для Android:

• adb logcat -s TagName - фильтр по тегу
• adb logcat | grep -i error - поиск ошибок
• adb logcat -c - очистить буфер

Для iOS:

• В Xcode: Window → Devices and Simulators → Open Console
• Команда xcrun simctl spawn booted log stream --level debug --predicate 'process == "YourApp"'

Как отвечать на собеседовании

Структурируй ответ по уровням: сначала системные инструменты, потом сетевой перехват, затем прод-мониторинг. Упомяни, что выбор зависит от задачи: для бага на конкретном устройстве - logcat, для проверки API - Charles, для регресса на продакшене - Crashlytics. Покажи понимание ограничений: print в iOS не попадает в системный лог, а для HTTPS нужен сертификат. Если спросят про конкретный инструмент - опиши, как им пользуешься, с примерами фильтров.

Что проверяет интервьюер

Интервьюер оценивает: знание платформенных инструментов (adb, Xcode), умение фильтровать и читать логи, понимание разницы между локальной и прод-средой, навыки работы с сетевым перехватом. Также важно, что ты знаешь, как логировать в коде (Timber, os_log) и как интегрировать crash-репортеры. Косвенно проверяется способность диагностировать проблему: например, по логам определить, упало ли приложение или сервер вернул 500.

Типичные ошибки

• Путать print в Swift с системным логированием - это разные вещи.
• Забывать про установку сертификата для HTTPS-перехвата.
• Смотреть логи только в IDE, не зная команд adb.
• Не фильтровать логи - тонуть в мусоре.
• Игнорировать прод-логи, считая, что достаточно локальных.
• Не упоминать про уровни логирования (debug, info, error) и их роль в фильтрации.