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

Введение: мобильные приложения как объект судебного инжиниринга

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

Союз «Федерация судебных экспертов» проводит экспертизу мобильных приложений на высоком научно-техническом уровне. В отличие от поверхностного «тестирования», судебная экспертиза устанавливает юридически значимые факты: действительно ли приложение не соответствует заявленным характеристикам; были ли внесены изменения в код после приёмки; является ли сбой критическим и воспроизводимым; какие именно претензии к работоспособности обоснованы. Особое внимание мы уделяем претензиям к работоспособности приложения  — это самый частый предмет споров.

В данной статье мы рассмотрим инженерные методы анализа мобильных приложений (iOS, Android), разберём типовые дефекты и способы их выявления, а также приведём три реальных кейса. Ключевая фраза, которую мы повторим пять раз: ЭКСПЕРТИЗА МОБИЛЬНЫХ ПРИЛОЖЕНИЙ. Это комплексная дисциплина, требующая знаний в области reverse engineering, статического и динамического анализа, сетевых протоколов и судебной практики. Приступим.

📱 Раздел 1: Инженерная классификация претензий к работоспособности мобильных приложений

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

Категория А: Критические дефекты работоспособности (блокирующие работу).

• Приложение не устанавливается на заявленные версии ОС (например, указана поддержка Android 11+, но на Android 11 крашится при запуске).
• Приложение вылетает (crash) при выполнении базовых сценариев (авторизация, оплата, отправка формы).
• «Белый экран» (ANR  — Application Not Responding) при старте или переходе между экранами.
• Потеря данных пользователя без возможности восстановления (например, после обновления).

Категория Б: Дефекты функциональной полноты (несоответствие ТЗ).

• Отсутствие заявленных функций (например, «пуш-уведомления не приходят», «не работает геолокация», «QR-сканер не распознаёт коды»).
• Некорректная реализация бизнес-логики (неправильный расчёт суммы, некорректная сортировка, ошибки валидации).
• Невыполнение требований по безопасности (передача паролей в открытом виде, хранение данных без шифрования).

Категория В: Дефекты производительности (UX-проблемы).

• Медленная загрузка экранов (более 3 секунд на современных устройствах).
• «Подтормаживания» при прокрутке списков (loss of frames, jank).
• Избыточное потребление трафика, батареи, памяти.
• Приложение «вешает» устройство.

Категория Г: Дефекты совместимости.

• Разное поведение на разных моделях устройств (например, на iPhone 14 работает, на iPhone 12  — нет).
• Проблемы с разными версиями ОС.
• Конфликты с другими приложениями.

Категория Д: Дефекты поддержки и обновляемости.

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

ЭКСПЕРТИЗА МОБИЛЬНЫХ ПРИЛОЖЕНИЙ должна начинаться с чёткой классификации предъявленных претензий. Далее эксперт выбирает методы, адекватные каждой категории.

🛠️ Раздел 2: Инструментарий судебного эксперта мобильных приложений

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

Аппаратные средства:

• Стенд из 20+ реальных устройств (iPhone 11-15 на разных версиях iOS, Android-смартфоны Samsung, Xiaomi, Pixel с Android 10-14).
• Аппаратные перехватчики трафика (LAN Tap, Wi-Fi Pineapple) для анализа сетевых запросов.
• Логические анализаторы для USB-трассировки (при отладке через USB).

Программные средства (статические анализаторы):

• Jadx  — декомпилятор APK/DEX в читаемый Java-код.
• Ghidra (NSA)  — дизассемблер для нативных библиотек (.so).
• IDA Pro  — профессиональный дизассемблер для iOS (IPA) и Android.
• MobSF (Mobile Security Framework)  — автоматизированный анализ безопасности и манифеста.

Программные средства (динамический анализ):

• Frida  — инъекция JavaScript-скриптов в работающее приложение для перехвата функций, отслеживания вызовов, изменения поведения.
• Objection  — надстройка над Frida для удобного runtime exploration.
• Burp Suite / Charles Proxy  — перехват и модификация HTTP/HTTPS трафика (с установкой собственного сертификата).
• ADB (Android Debug Bridge)  — управление Android-устройствами, получение логов logcat, дампов памяти.
• Xcode Instruments (iOS)  — профилирование производительности, отслеживание утечек памяти.
• Средства для анализа логов и crash-reports:
• Logcat (Android)  — системный лог, содержит стек-трейсы при крашах.
• Crashlytics / Firebase  — если разработчик передал доступ, можно получить агрегированные отчёты.

Собственные скрипты на Python для парсинга логов и поиска аномалий.

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

🧩 Раздел 3: Инженерный анализ логов мобильного приложения

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

• Android (Logcat):
  Система логирует сообщения от всех приложений. Уровни: VERBOSE, DEBUG, INFO, WARN, ERROR, ASSERT. Для судебной экспертизы важны:
• Краши (FATAL EXCEPTION)  — содержат тип исключения (NullPointerException, IndexOutOfBoundsException и др.) и стек-трейс с номерами строк исходного кода (если приложение не обфусцировано).
• ANR (Application Not Responding)  — сообщения, когда приложение не отвечает более 5 секунд.

Сообщения, помеченные тегом приложения (обычно com.example.app). Анализируя их, можно восстановить хронологию действий пользователя и ошибки.

iOS (системные логи через Xcode или консоль):
iOS более закрыта, но можно получить логи через Xcode (если приложение отлаживается) или через устройство, подключённое к Mac с включённым режимом разработчика. Формат похож: сообщения с уровнем Error, Fault.

Проблема: Логи могут быть перезаписаны (буфер ограничен). Эксперт должен извлечь логи как можно раньше после инцидента. Если устройство было перезагружено, старые логи теряются. В некоторых случаях можно извлечь crash-логи из системной директории (в Android: /data/system/dropbox/, доступно только с root-правами). В iOS краш-логи хранятся в Settings -> Privacy -> Analytics & Improvements -> Analytics Data.

Пример анализа: В одном из кейсов эксперт обнаружил в Logcat повторяющуюся ошибку: java.lang.IllegalStateException: Fragment already added. Это указывало на ошибку в навигации (двойное добавление фрагмента). Разработчик утверждал, что «баг случайный и невоспроизводимый». Эксперт предоставил 15 воспроизведений за 2 минуты, снятых на видео. Суд признал претензию обоснованной.

📦 Раздел 4: Статический анализ APK/IPA  — что можно найти без запуска

Статический анализ  — это исследование кода и ресурсов приложения без его выполнения. Эксперт получает файл APK (Android) или IPA (iOS), распаковывает и изучает.

Android APK:

• Манифест (AndroidManifest.xml)  — содержит запрашиваемые разрешения (permissions), объявленные Activity, Services, BroadcastReceivers. Если приложение запрашивает разрешение на SMS, но в ТЗ это не было оговорено  — это признак либо избыточности, либо потенциально вредоносного поведения.
• DEX-файлы (Dalvik Executable)  — скомпилированный байт-код. Декомпиляция в Java (через Jadx) позволяет увидеть логику: как обрабатываются нажатия, как проверяются введённые данные, какие сетевые вызовы делаются.
• Ресурсы (res/layout)  — XML-файлы интерфейса. Можно проверить, есть ли заявленные экраны, правильные ли идентификаторы.
• Нативные библиотеки (lib/*.so)  — код на C/C++. Анализируется через IDA Pro или Ghidra.

iOS IPA:
IPA  — это ZIP-архив, содержащий исполняемый файл (Mach-O) и ресурсы. Декомпиляция затруднена из-за компиляции в машинный код (ARM64). Но можно использовать:

• otool  — просмотр загруженных библиотек, секций.
• Hopper / IDA Pro  — дизассемблирование Mach-O.
• class-dump  — извлечение заголовков Objective-C классов (если приложение не обфусцировано).

Что ищет эксперт при претензиях к работоспособности:

• Проверяет, реализован ли заявленный функционал (например, есть ли класс PaymentActivity и метод processPayment). Если нет  — это прямое доказательство невыполнения ТЗ.
• Ищет потенциально опасные конструкции: обработка исключений без логирования (пустой catch block), отсутствие проверок на null, некорректные таймауты.
• Анализирует сторонние библиотеки (SDK). Если разработчик использовал устаревшую библиотеку с известными багами  — это его ответственность.

ЭКСПЕРТИЗА МОБИЛЬНЫХ ПРИЛОЖЕНИЙ методом статического анализа часто выявляет дефекты, которые невозможно увидеть при поверхностном тестировании. Например, в одном кейсе эксперт обнаружил, что приложение отправляет пароль в открытом виде (http вместо https), хотя в ТЗ был пункт о безопасности. Это стало основанием для расторжения контракта.

📡 Раздел 5: Динамический анализ и отладка работающего приложения

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

Метод 1: Перехват сетевого трафика (MITM  — Man in the Middle).
Эксперт настраивает прокси (Burp Suite, Charles Proxy) и устанавливает на устройство свой SSL-сертификат. Все HTTPS-запросы расшифровываются. Что можно выявить:

• Отправка данных на неожиданные сервера (например, геолокация уходит в Китай, хотя ТЗ говорило о российских серверах).
• Отсутствие шифрования (HTTP вместо HTTPS)  — прямая претензия к безопасности.
• Повторяющиеся запросы из-за ошибок в логике (например, запрос каждую секунду, что убивает батарею).
• Ответы сервера с ошибками (HTTP 400, 500), которые приложение не обрабатывает и вылетает.

Метод 2: Инъекция скриптов через Frida.
Frida позволяет внедрить JavaScript-код в процесс приложения на лету. Примеры использования:

• Перехват функции onClick и запись стека вызовов.
• Модификация возвращаемого значения функции (например, заставить проверку подписки всегда возвращать true  — для тестирования).
• Отслеживание утечек памяти через трассировку выделений.
• Вызов внутренних методов, недоступных из UI (например, принудительная синхронизация).

Метод 3: Мониторинг производительности.

• Android Profiler (в Android Studio)  — замеры CPU, Memory, Network, Energy.
• Xcode Instruments (iOS)  — Time Profiler, Leaks, Allocations, Energy Log.
• Эксперт записывает сценарий (например, 100 прокруток ленты) и фиксирует средний FPS, максимальное потребление памяти, время отклика.

Метод 4: Воспроизведение крашей.
Краш может быть недетерминированным (race condition). Эксперт выполняет сценарий многократно (500+ раз) с помощью автоматизации (Espresso для Android, XCTest для iOS). Фиксирует частоту крашей. Если краш воспроизводится хотя бы в 1% случаев  — это уже дефект, особенно для критических функций (оплата, регистрация).

В одном из кейсов (будет рассмотрен далее) именно Frida помогла выявить, что приложение падает при получении push-уведомления определённого формата. Разработчик 3 месяца не мог воспроизвести баг, а эксперт воспроизвёл за 2 часа.

🔩 Раздел 6: Инженерный анализ претензий к работоспособности  — типовые дефекты

На основе десятков экспертиз мы выделили наиболее частые инженерные дефекты, которые приводят к судебным спорам.

Дефект 1: Memory Leak (утечка памяти).
Приложение постепенно «съедает» всю оперативную память и вылетает. Типичные причины: неоткреплённые слушатели (listeners), замыкания (closures), некорректная работа с WebView. Эксперт использует профилировщик: если память растёт бесконечно при повторяющихся действиях  — утечка доказана.

Дефект 2: Race Condition (состояние гонки).
При параллельной работе потоков приложение может выдать некорректный результат или упасть. Например, если пользователь быстро нажимает кнопку «Купить» дважды, может списаться двойная сумма. Эксперт использует автоматизированное тестирование с эмуляцией задержек.

Дефект 3: NullPointerException (или его аналог в Swift  — fatal error: unexpectedly found nil).
Разработчик не проверил переменную на null. Эксперт находит в логах стек-трейс, затем в декомпилированном коде смотрит, какая именно переменная не была инициализирована. Если подобные ошибки повторяются  — это признак низкого качества кода.

Дефект 4: Необработанное исключение при сетевом вызове.
Приложение ожидает, что сервер всегда отвечает корректно. Но если ответ пришёл с ошибкой (500, 404) или таймаут, приложение вылетает. Эксперт поднимает свой mock-сервер (например, WireMock) и эмулирует ошибочные ответы. Если приложение не показывает сообщение об ошибке, а крашится  — дефект.

Дефект 5: Проблемы с совместимостью.
Один и тот же код по-разному работает на разных версиях ОС или разных моделях. Эксперт тестирует на стенде реальных устройств. Особенно часты проблемы с камерами (разные разрешения, форматы), с биометрией (Face ID vs Touch ID), с разрешениями (Android 13+ требует новых разрешений для уведомлений).

Дефект 6: Нарушение гайдлайнов платформы (например, Human Interface Guidelines для iOS).
Строго говоря, это не всегда дефект работоспособности, но влияет на пользовательский опыт. Жесты работают не так, как ожидается, кнопки слишком маленькие, некорректная работа с клавиатурой. В ТЗ часто ссылаются на «соблюдение стандартов платформы», поэтому такие претензии тоже исследуются.

📱 Раздел 7: Кейс №1  — Претензия к работоспособности приложения банка (Android, Memory Leak)

Контекст: Банк «Приоритет» заказал разработку мобильного приложения для управления счетами у компании «SoftLab». После приёмки и оплаты (50 млн руб.) приложение выложили в Google Play. Пользователи начали жаловаться: приложение вылетает после 10-15 минут активного использования (просмотр истории, оплата счетов). Банк предъявил претензию разработчику, требуя устранить дефект или вернуть часть денег. Разработчик утверждал, что проблема «на стороне телефонов пользователей» и что приложение работает корректно. Назначена судебная экспертиза.

Претензии к работоспособности (конкретные):

• Приложение нестабильно, часто вылетает без сообщения об ошибке.
• Время работы без краша не превышает 15 минут.
• Дефект воспроизводится на разных моделях Android (Samsung, Xiaomi, Pixel).

Инженерная методика эксперта:

Воспроизведение: Эксперт установил приложение на 5 реальных устройств с Android 11-13. На всех запустил автоматизированный скрипт (на основе UI Automator), который имитировал пользователя: открыть историю, скроллить, открыть детали платежа, вернуться, повторить.

Мониторинг: Через Android Profiler фиксировал потребление памяти. Через 7-8 циклов память выросла с 200 МБ до 1.2 ГБ, затем приложение вылетело с ошибкой OutOfMemoryError.

Анализ дампа памяти (Heap dump): Экспорт получил heap dump через Android Studio. С помощью Eclipse MAT (Memory Analyzer Tool) выявил, что объекты класса TransactionAdapter (адаптер списка транзакций) не уничтожаются. Каждый раз при открытии истории создавался новый адаптер, но старый не освобождался, так как на него держал ссылку слушатель (listener), не откреплённый в методе onDestroy.

Статический анализ: Экспорт декомпилировал APK (Jadx) и нашёл в коде: в onCreateView вызывался registerForContextMenu, но в onDestroyView не было unregisterForContextMenu. Это прямая ошибка.

Воспроизводимость на стенде: Эксперт создал модифицированную версию приложения (исправил ошибку) и показал, что на том же устройстве утечка исчезла.

Вывод: Претензии к работоспособности обоснованы. Дефект критический, связан с ошибкой разработчика. Суд обязал разработчика вернуть 20% оплаты и устранить дефект за свой счёт. Экспертиза мобильных приложений (первое повторение ключевой фразы) помогла доказать, что «плавающий» баг имеет железную техническую причину.

🔐 Раздел 8: Анализ безопасности мобильного приложения как часть экспертизы работоспособности

Часто претензии связаны не только с функционалом, но и с уязвимостями. Заказчик может требовать, чтобы приложение было «безопасным», но в ТЗ это может быть не прописано. Однако есть общепринятые стандарты (OWASP Mobile Top 10), на которые можно ссылаться.

OWASP Mobile Top 10 (ключевые пункты):

• M1: Improper Platform Usage (неправильное использование платформы).
• M2: Insecure Data Storage (небезопасное хранение данных).
• M3: Insecure Communication (небезопасная коммуникация).
• M4: Insecure Authentication (небезопасная аутентификация).
• M5: Insufficient Cryptography (недостаточная криптография).
• M6: Insecure Authorization (небезопасная авторизация).
• M7: Client Code Quality (качество клиентского кода  — это напрямую относится к работоспособности).

Инженерные методы проверки безопасности:

Проверка хранения данных: Эксперт проверяет, хранит ли приложение пароли, токены, персональные данные в открытом виде в SharedPreferences (Android) или UserDefaults (iOS). Если да  — это уязвимость. Приложение может быть признано не соответствующим 152-ФЗ (о персональных данных).

Проверка шифрования сетевого трафика: Перехват через Burp Suite. Если приложение не использует SSL Pinning, и эксперт может подменить сертификат  — это означает, что злоумышленник может перехватить трафик. В некоторых ТЗ это требование явное.

Проверка обфускации кода: Если APK легко декомпилируется и код читаем, злоумышленник может извлечь ключи API, логику оплаты и т.д. Эксперт оценивает степень обфускации (ProGuard, R8, DexGuard). Недостаточная обфускация  — претензия к разработчику.

Проверка на наличие бэкдоров или недокументированных функций: Статический анализ может выявить вызовы нестандартных URL, debug-бэкдоры (например, активация через скрытую комбинацию жестов). В одном из кейсов эксперт нашёл скрытый экран с просмотром всех данных пользователей  — это был явный бэкдор, о котором заказчик не знал.

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

⚙️ Раздел 9: Нагрузочное тестирование и проверка производительности

Претензии к производительности («приложение тормозит», «очень долго загружается», «разряжает батарею за час») должны быть подтверждены инженерными замерами.

Методика нагрузочного тестирования:

Определение базовых метрик: время запуска (cold start), время перехода между экранами, частота кадров при скроллинге (FPS), потребление памяти, потребление ЦП, потребление энергии (через Battery Historian для Android, Energy Log для iOS).

Сравнение с заявленными в ТЗ. Если в ТЗ указано «время открытия экрана истории  — не более 1 секунды», а эксперт замеряет 3 секунды  — претензия обоснована. Если ТЗ не содержит цифр, эксперт сравнивает с рыночными аналогами (бенчмаркинг) или со средними значениями по платформе (например, Google рекомендует время отклика < 100 мс, время загрузки < 3 с).

Стресс-тестирование: Эксперт запускает приложение на маломощном устройстве (например, iPhone SE 2016, Android с 2 ГБ ОЗУ). Если на нём приложение неработоспособно, но в ТЗ не указаны минимальные требования  — это может быть основанием для претензии (разработчик обязан был оговорить минимальную конфигурацию).

Автоматизация прогонов: 1000 прогонов одного сценария, фиксация времени выполнения каждого. Статистический анализ (среднее, медиана, процентиль) показывает, есть ли деградация со временем.

Пример: В деле о приложении-агрегаторе такси, заказчик жаловался, что карта «подтормаживает» (низкий FPS). Эксперт замерил FPS на флагманском устройстве  — 15 кадров/с при пролистывании карты. Это ниже комфортного уровня (30 FPS). В ТЗ было указано «плавная работа карты». Суд принял позицию эксперта. Причина оказалась в том, что разработчик использовал WebView для отображения карты вместо нативного API. Это технически не ошибка, но некачественная реализация.

📊 Раздел 10: Кейс №2  — Претензия к мобильному приложению интернет-магазина (iOS, несоответствие ТЗ)

Контекст: Компания «Товары-24» заказала разработку iOS-приложения для интернет-магазина. Техническое задание (ТЗ) включало: «фильтрация товаров по цене, бренду, рейтингу; корзина должна сохранять товары после закрытия приложения; push-уведомления о статусе заказа». После сдачи заказчик обнаружил, что:

• Фильтрация по рейтингу работает некорректно (отображаются товары с рейтингом 2, даже если выбрано 4+).
• Корзина сбрасывается при полном закрытии приложения (свайп вверх).
• Push-уведомления приходят с задержкой до 30 минут.

Разработчик утверждал, что всё соответствует ТЗ (рейтинг  — «субъективное понятие», корзина  — «это фича, а не баг», задержка пушей  — «проблема провайдера»). Назначена экспертиза.

Инженерная методика:

Анализ ТЗ и сравнение с фактическим поведением: Эксперт составил матрицу соответствия. По каждому пункту провёл тест-кейсы.

Фильтрация по рейтингу: в ТЗ был пример (показан UI с выбором «4+»). Эксперт открыл приложение, выбрал «4+», получил в результатах товары с рейтингом 2.3  — несоответствие зафиксировано на видео. При этом экспорт декомпилировал IPA (через Ghidra) и нашёл, что в методе applyRatingFilter просто сравнивается product.rating >= selectedRating. Ошибки нет  — значит, проблема в данных? Но в базе данных значения рейтинга были корректны. Выяснилось, что при синхронизации с сервером рейтинг округлялся до целого, но 2.3 округлялся до 2, и в фильтре 4+ не должен был проходить. Ошибка в синхронизации.

Корзина: эксперт провёл тест: добавил товары, закрыл приложение через многозадачность (свайп), открыл заново  — корзина пуста. В ТЗ было сказано «корзина сохраняется между сессиями». Несоответствие. Статический анализ: в коде был метод onDestroy (в UIKit аналог deinit), который явно очищал корзину. Разработчик вставил эту строку по ошибке.

Push-уведомления: эксперт настроил перехват трафика через Charles Proxy. Обнаружил, что приложение регистрирует push-токен, но затем не отправляет подтверждение серверу. Провайдер (Firebase) доставлял сообщения мгновенно, но приложение не обрабатывало их из-за неверного ключа в didReceiveRemoteNotification. В коде была опечатка: userInfo[«aps»] вместо userInfo[«aps»]?  — неправильный опциональный доступ, из-за чего уведомление игнорировалось.

Вывод: Все три претензии обоснованы. Это дефекты разработки, а не особенности платформы. Суд обязал разработчика исправить дефекты без дополнительной оплаты и выплатить неустойку за просрочку (45 дней). Экспертиза мобильных приложений (второе повторение) позволила доказать, что несоответствие ТЗ  — не «интерпретация», а измеряемый факт.

📲 Раздел 11: Особенности экспертизы кроссплатформенных приложений (React Native, Flutter, Xamarin)

Всё чаще приложения разрабатываются с использованием кроссплатформенных фреймворков. Это создаёт дополнительные сложности для экспертизы, так как код на JavaScript/Dart не компилируется в нативный машинный код, а выполняется в рантайме.

• React Native (JS):
• Статический анализ сложен: APK содержит бандл (файл index.android.bundle)  — это JavaScript, упакованный в строку. Эксперт может извлечь его и декомпилировать (достаточно убрать обфускацию, если она есть). С помощью инструментов (react-native-decompiler) можно восстановить приблизительную структуру компонентов.
• Динамический анализ через Frida проще: можно перехватывать вызовы JS-функций, так как RN имеет мост к нативному коду. Эксперт внедряет скрипт, который логирует все вызовы методов Redux-хранилища или UI-компонентов.
• Типичные дефекты: ошибки в мосте (bridge), плохая производительность при большом количестве элементов в FlatList (из-за отсутствия виртуализации), проблемы с нативными модулями (камера, геолокация).

Flutter (Dart):

• Flutter компилируется в нативный ARM-код (AOT), что усложняет дизассемблирование. Однако можно использовать flutter build apk —analyze-size и инструменты типа blutter (проект с открытым кодом для обратной разработки). Эксперт может извлечь слой Dart (snapshot) и попытаться декомпилировать.
• Преимущество Flutter в предсказуемой производительности, но недостаток  — большой размер APK (часто > 30 МБ). Претензии могут быть связаны с тем, что приложение занимает слишком много памяти (из-за Skia-рендеринга).
• Xamarin / MAUI (C#):
• Mono-рантайм, код на C# компилируется в IL (Intermediate Language), который лежит в сборках .dll внутри APK. Эксперт может использовать ildasm или dnSpy для декомпиляции в читаемый C#.
• Дефекты: утечки памяти из-за неправильной работы с Xamarin.Forms (несоответствие жизненному циклу страниц), проблемы с привязкой данных (data binding).

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

🔋 Раздел 12: Претензии к энергопотреблению и трафику  — инженерные замеры

Современные пользователи мобильных приложений крайне чувствительны к тому, сколько энергии тратит приложение и сколько мегабайт «съедает» за сессию. Претензии типа «приложение убивает батарею за 2 часа» могут быть предметом экспертизы.

Метод измерения энергопотребления (Android):

• Использование Battery Historian (инструмент Google). Эксперт:
• Заряжает устройство до 100%.
• Запускает приложение и выполняет типовой сценарий (например, 30 минут пользования).
• После этого через ADB получает файл bugreport.

Загружает в Battery Historian (web-интерфейс), анализирует: какие компоненты (Wi-Fi, GPS, CPU, экран) потребляли энергию, есть ли аномально высокая частота wakeup-событий (приложение слишком часто будит устройство из сна).

Для iOS аналогичный инструмент  — Energy Log в Xcode Instruments.

Типичные дефекты, приводящие к высокому энергопотреблению:

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

Метод измерения трафика:

• На Android: Network Profiler в Android Studio или tcpdump с правами root.
• На iOS: Remote Virtual Interface + Wireshark. Эксперт подключает iPhone к Mac, включает удалённый интерфейс и перехватывает все пакеты.
• Нормативные значения: для приложений с не-видеоконтентом нормальным считается 1-5 МБ в час. Если эксперт фиксирует 50 МБ в час при простом скроллинге новостей  — это дефект.

Кейс: В экспертизе приложения-навигатора заказчик жаловался, что приложение в фоновом режиме тратит по 200 МБ в день на передачу данных. Эксперт перехватил трафик и увидел, что приложение каждые 10 секунд отправляет на сервер координаты (даже когда пользователь не в пути). В ТЗ было прописано «минимальный расход трафика в фоне». Эксперт оценил избыточный трафик в 20 раз выше необходимого. Суд признал это несоответствием.

🔄 Раздел 13: Кейс №3  — Претензии к работоспособности приложения после обновления (iOS, регрессия)

Контекст: Медицинская компания «Здоровье онлайн» разработала приложение для записи к врачам. Версия 1.0 работала стабильно. После выхода версии 2.0 (добавлены видеозвонки и чат) пользователи начали жаловаться: приложение вылетает при открытии расписания; видеозвонки не устанавливаются; старые записи к врачам пропали. Компания предъявила претензию разработчику (аутсорсеру). Разработчик заявил, что это «проблемы на стороне пользователей, у них старые версии iOS». Назначена экспертиза.

Претензии к работоспособности:

• Приложение крашится на iOS 15.6+ при открытии экрана расписания (100% воспроизводимость).
• Видеозвонки устанавливаются лишь в 30% случаев, остальные завершаются ошибкой через 10 секунд.
• У некоторых пользователей пропали записи (данные не отображаются, но в базе есть).

Инженерная методика:

Воспроизведение краша: Эксперт установил версию 2.0 на iPhone 13 (iOS 15.6) и iPhone 11 (iOS 16.1). На обоих краш при открытии расписания. Собрал crash-логи через Xcode (устройство разработчика). Анализ: EXC_BAD_ACCESS (SIGSEGV) при обращении к UITableCell с индексом -1. Ошибка в коде: при обновлении данных не проверяется, что индекс ячейки существует.

Анализ видеозвонков: Эксперт перехватил трафик WebRTC (через tcpdump на роутере). Выяснил: приложение отправляет SDP-предложение, но не обрабатывает ответ, если он приходит более чем через 2 секунды (хардкод в коде, хотя сеть может быть медленной). Таймаут был увеличен в версии 1.0 (10 сек), но в версии 2.0 разработчик случайно вернул 2 сек. Исправление  — 5 строчек кода.

Пропажа записей: Эксперт проанализировал локальную базу данных (Core Data). Обнаружил, что в версии 2.0 изменилась модель данных (добавлено поле appointmentUUID), но миграция не была выполнена. При запуске приложение создавало новую пустую базу, а старые данные игнорировались. Это грубая ошибка: разработчик не протестировал обновление с существующими данными.

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

📊 Раздел 14: Оценка качества кода и документации  — инженерные метрики

В сложных спорах может потребоваться оценить не только «работает или не работает», но и качество кода в целом (соответствие стандартам, поддерживаемость, наличие тестов). Это необходимо, например, при расторжении контракта с разработчиком, когда заказчик хочет передать код другому подрядчику.

Инженерные метрики (SonarQube, PMD, ESLint, Detekt):

• Плотность ошибок (ошибки на 1000 строк кода). Более 5  — плохо.
• Цикломатическая сложность (чем выше, тем код сложнее для понимания и тестирования). Среднее по модулю не более 10.
• Покрытие кода тестами (unit tests, UI tests). Норма  — более 70% для критических модулей.
• Дублирование кода: >10% дублей  — признак плохой архитектуры.
• Наличие «запахов кода» (code smells): длинные методы, большие классы, глубокие вложенности.

Анализ документации:

• Наличие и актуальность архитектурного описания (UML-диаграммы, схема данных, описание API).
• Инструкция по сборке и развёртыванию. Если отсутствует, другой подрядчик не сможет продолжить разработку.
• Руководство пользователя (соответствует ли реальному поведению).

Инженерный подход: Эксперт не просто даёт оценку «код плохой», а приводит конкретные метрики и сравнение с отраслевыми стандартами (например, стандарты кодирования Google для Android, Apple для iOS). Если в контракте были указаны требования к документации (например, «должна быть предоставлена техническая документация в формате Confluence»), эксперт проверяет, выполнено ли это.

В одном из кейсов заказчик отказывался платить последний транш, утверждая, что код «нечитаемый и его нельзя сопровождать». Эксперт проанализировал код с помощью SonarQube: цикломатическая сложность средняя 28, покрытие тестами 8%, 20% дублирования. Суд признал, что код имеет критическое техническое состояние, не соответствующее стандартам качества, и снизил цену контракта на 40%.

🔐 Раздел 15: Процессуальные аспекты экспертизы мобильных приложений  — рекомендации сторонам

Для заказчика (истец):

Подготовьте ТЗ и приложения к нему (экраны макетов, Use Case). Без внятного ТЗ эксперт не сможет установить несоответствие. Если ТЗ нет, эксперт может опираться на переписку сторон (технические задания в чатах, протоколы встреч).

Предоставьте доступ к репозиторию кода (Git). Если код закрыт, эксперт будет работать только с дистрибутивом (APK/IPA), что ограничивает возможности (например, статический анализ будет неполным). Суд может обязать разработчика предоставить код.

Фиксируйте дефекты на видео. Заблаговременно составьте протоколы тестирования (какой сценарий, на каком устройстве, что наблюдалось).

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

Для разработчика (ответчик):

Передавайте эксперту все артефакты: исходный код, документацию, тест-кейсы, отчёты о тестировании. Если вы утверждаете, что дефект не воспроизводится, предоставьте детальную среду воспроизведения (версии ОС, модель, фоновые приложения).

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

Проверьте, не вносил ли заказчик изменения в код после приёмки. Эксперт может это сделать (сравнить хеши исходного кода и кода в APK). Если заказчик самостоятельно модифицировал приложение, это может снять ответственность с разработчика.

Для суда:

• Привлекайте эксперта со специализацией именно в мобильной разработке (не «общий IT-эксперт»). Разница между Android и iOS огромна.
• Разрешите эксперту использовать реальные устройства, а не эмуляторы (эмуляторы не воспроизводят проблемы с батареей, GPS, камерой).

Учитывайте, что для динамического анализа может потребоваться root или jailbreak устройства. Это законно, если эксперт действует в рамках судебного поручения (ст. 57 УПК, ст. 85 ГПК). Но извлечённые данные не должны использоваться для взлома других приложений.

🏁 Заключение: инженерная истина в мобильном мире

Мы рассмотрели 15 развернутых разделов, охватывающих практически все аспекты судебной экспертизы мобильных приложений с акцентом на претензии к работоспособности. Инженерный подход позволяет превратить «приложение тормозит» в «среднее время отклика экрана оплаты составляет 5.2 секунды при заявленных 1 секунде». Без экспертизы суд утонул бы в субъективных мнениях.

Союз «Федерация судебных экспертов» обладает уникальным стендом, квалифицированными экспертами (сертификация по Android и iOS) и многолетним опытом. Мы помогли десяткам заказчиков доказать некачественную разработку и десяткам разработчиков  — опровергнуть необоснованные претензии.

Если вы столкнулись с некачественным мобильным приложением, если разработчик не выполняет ТЗ, если приложение вылетает, тормозит, теряет данные  — обращайтесь к нам. Наш сайт: https://krimexpert.ru/ekspertiza-kachestva-razrabotki-mobilnyh-prilozhenij/ (ссылка на наш ресурс). Мы проведём исследование, которое устоит в любом суде. Цифровая справедливость начинается с инженерной точности. 🟩