Слушай, заказчик, инвестор, юрист или просто человек, который однажды вложил деньги в мобильное приложение, а получил вечно вылетающую, тормозящую, жрущую батарейку и теряющую данные поделку.  Знаешь, сколько к нам приходит людей с одинаковой историей? «Мы заплатили студии N миллионов, прошло полгода, а приложение работает как сырая бета.  Разработчики говорят:  «Это особенности платформы», «У вас телефон кривой», «Обновите прошивку», «Почистите кэш».  И ты сидишь, как дурак, с миллионными убытками и чувством собственного бессилия.  Хватит! Мы, Союз «Федерация судебных экспертов», устали от этого цирка.  Экспертиза мобильных приложений  — это наш тяжёлый артиллерийский снаряд, который мы запускаем по нерадивым разработчикам.  Сегодня будет три реальных кейса, в которых мы разорвали в клочья аргументы «профессиональных» студий и заставили их платить за несоблюдение технического задания.

Глава 1.  Что такое техническая экспертиза мобильного приложения и почему это не «тестирование» 🧩

Ваш штатный тестировщик  (или нанятая контора) проводит функциональное тестирование:  нажимает кнопки, смотрит, работает ли.  Это не экспертиза.  Это поверхностное обтирание.  Инженерная экспертиза мобильных приложений  — это комплексное исследование архитектуры, кода, сетевых взаимодействий, потребления ресурсов, безопасности, соответствия документации и, главное, скрытых дефектов, которые проявляются только при нагрузке или в особых условиях.  Мы не просто говорим «приложение тормозит».  Мы измеряем время отклика API, анализируем утечки памяти, декомпилируем бинарники  (в рамках закона), проверяем, как приложение хранит токены и пароли, и сравниваем реальное поведение с техническим заданием.  И если разработчик обещал загрузку за 1 секунду, а она грузится 10 секунд  — добро пожаловать в суд.  Экспертиза мобильных приложений в нашем понимании  — это комплексная диагностика:  функциональное тестирование, нагрузочные прогоны, статический анализ кода, проверка безопасности, юзабилити-оценка и криминалистический анализ.

Глава 2.  Почему 90% претензий к мобильным приложениям разбиваются о стену «это особенность платформы» 🔍

Типичный газлайтинг от разработчика:  «Это не баг, а фича», «У вас андроид фрагментированный», «В iOS обновили SDK, всё сломалось».  Друзья, запомните:  если в техническом задании  (ТЗ) написано «приложение должно корректно работать на iOS 15+ и Android 10+»  — значит, оно должно работать.  Без исключений.  Если разработчик использовал устаревшие библиотеки или не учел особенности версий  — это его проблема.  Наша экспертиза мобильных приложений фиксирует каждый сбой, каждый ANR  (Application Not Responding), каждую утечку памяти.  Мы создаем чек-лист из 300+ пунктов и проверяем приложение в десятках конфигураций.  И если выясняется, что разработчик сэкономил на тестировании  — он ответит рублем.

Глава 3.  Кейс №1:  Финансовое приложение с «потерянными» транзакциями на 8 миллионов рублей 💸

Фабула:  Банк заказал разработку мобильного приложения для управления инвестициями у крупной студии.  Студия отдала проект с задержкой в 4 месяца, а в продуктиве началось веселье:  транзакции удваивались, а иногда исчезали из истории.  Банк потерял доверие клиентов, общая сумма претензий  — 8 млн рублей.  Студия заявила:  «Это глюки серверной части, не наше приложение».

Что сделали мы:  Получили исходные коды  (по постановлению суда), IPA/APK файлы, логи с серверов, ТЗ и акты приемки.

Методика:

• Декомпилировали iOS-приложение (через Hopper Disassembler и IDA Pro) и Android  (Jadx, Bytecode Viewer).  Нашли в коде класс TransactionManager, который при сбое сети не ставил транзакции в очередь, а просто терял их.
• Провели нагрузочное тестирование в эмуляторах с эмуляцией плохой сети (Charles Proxy, Network Link Conditioner).  Воспроизвели потерю 247 транзакций.
• Проанализировали локальную базу SQLite приложения: она хранила только последние 50 операций, хотя в ТЗ было требование «хранить историю за весь период».
• Сравнили с требованиями безопасности ЦБ РФ (Положение № 719-П):  приложение не шифровало локальное хранилище, пароли лежали в SharedPreferences в открытом виде.  Критический дефект.

Результат:  Студия признана виновной в некачественной разработке.  Суд взыскал 8 млн рублей убытков, плюс штраф за нарушение сроков  — еще 2.4 млн.  Экспертиза мобильных приложений доказала, что проблема не в сервере, а в кривых руках программистов.

Глава 4.  Кейс №2:  Доставка еды, которая сожрала батарейку за 2 часа 🍕

Ситуация:  Сетевой ресторанный холдинг заказал мобильное приложение для доставки  (iOS + Android).  Заказчики жаловались:  после установки приложения телефон садился за 2-3 часа, грелся как утюг.  Разработчик  (дешевая студия из условного «аутсорса») сказал:  «Это у вас батарейки старые, покупайте новые».  Холдинг потерял 40% пользователей за месяц, убыток оценили в 15 млн рублей  (упущенная выгода).

Наша экспертиза:

• Провели инструментальный анализ энергопотребления. На iOS использовали Instruments  (Energy Log), на Android  — Battery Historian от
• Обнаружили, что приложение в фоне (в состоянии background) каждые 2 секунды посылало геолокацию через GPS  (не через Wi-Fi/соты, а именно GPS, самый жоркий режим).  Это было прописано в коде:  requestLocationUpdates(…, 2000, 0, …)  — минимальный интервал 2000 миллисекунд, точность 0 метров  (т.е.  максимальная).  В ТЗ было написано:  «Периодичность отправки геопозиции  — 1 раз в 5 минут только при активном использовании».
• Декомпилировали код серверной части (бэкенд для приложения)  — нашли, что сервер не проверял флаги активности, просто принимал все запросы.  Это архитектурная ошибка.
• Провели нагрузочное тестирование: 100 эмуляторов одновременно.  Батарея в тестовом телефоне  (iPhone 12) разрядилась с 100% до 0 за 1 час 53 минуты.

Результат:  Экспертное заключение признано неопровержимым.  Суд взыскал 12 млн рублей реального ущерба и 3 млн штрафа.  Экспертиза мобильных приложений показала, что жадность до геоданных убила бизнес.

Глава 5.  Кейс №3:  Медицинское приложение, которое потеряло результаты анализов пациентов 🏥

Фабула:  Стартап «Здоровье в кармане» разработал приложение для врачей и пациентов  (синхронизация анализов, рецептов, истории болезней).  Через месяц после запуска пациенты массово жаловались:  результаты анализов исчезали из приложения спустя 2 дня.  Врачи не могли вести историю, клиника получила несколько исков на общую сумму 9 млн рублей.  Разработчик заявил:  «Вы неправильно настроили сервер».

Как мы копали:

• Получили билды приложения (Android APK) и дампы клиентских БД SQLite с устройств  (с согласия владельцев по решению суда).
• Анализировали код: нашли класс DatabaseManager.java, который при синхронизации с сервером выполнял DELETE FROM results WHERE date < datetime(‘now’, ‘-2 days’).  То есть автоматически удалял записи старше 2 дней.  В ТЗ такого требования не было  — наоборот, было «хранить историю бессрочно».
• Проверили серверную логику: сервер хранил копию анализов, но из-за бага в API мобильное приложение не загружало старые записи обратно, только новые.
• Эмуляция: на 10 тестовых устройствах  (разные версии Android 11-14) через 48 часов записи исчезали в 100% случаев.
• Дополнительно нашли уязвимость: приложение передавало данные пациента в открытом виде через HTTP  (не HTTPS), нарушая 152-ФЗ «О персональных данных».

Результат:  Разработчик признан виновным, суд взыскал 9 млн рублей ущерба.

Глава 6.  Инженерный протокол:  как мы работаем с ТЗ 📋

Анализ соответствия техническому заданию  (ТЗ)  — ядро любой судебной экспертизы по спорам с разработчиками.  Мы не просто смотрим, «есть ли функция».  Мы проверяем:

• Реализован ли функционал в полном объеме. Часто разработчики «забывают» реализовать часть функций, особенно «неудобные» или ресурсоемкие.
• Соответствует ли реализация описанию в ТЗ. Например, в ТЗ  — «кнопка должна быть синей», а в приложении  — «зеленой» и в другом месте.
• Работает ли функция корректно во всех заявленных сценариях. Если в ТЗ сказано «работает при плохом интернете», а приложение падает  — это нарушение.
• Соблюдены ли нефункциональные требования: производительность, безопасность, нагрузка.  Если в ТЗ написано «время загрузки < 2 секунд», а по факту  — 10 секунд  — это нарушение.

Глава 7.  Какие данные нужны для проведения экспертизы мобильного приложения? 📋

Для проведения полноценной экспертизы мобильных приложений потребуется предоставить комплекс материалов:

• Само мобильное приложение (установочные файлы APK/IPA или ссылки на магазины).
• Исходный код приложения (при его наличии и доступе).
• Техническое задание и договор на разработку.
• Серверная часть приложения, API-интерфейсы и базы данных (при необходимости).
• Журналы событий (логи) работы приложения, серверные логи, отчёты о сбоях  (Crashlytics, AppMetrica).
• Скриншоты и видеозаписи, демонстрирующие проблему.
• Переписка между заказчиком и разработчиком, связанная с проектом.
• Определение суда о назначении экспертизы (для судебной экспертизы).

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

Глава 8.  Какие вопросы ставит суд перед экспертом мобильных приложений? ❓

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

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

Глава 9.  Эксперт vs.  Тестировщик:  в чём разница? 👨💻

Часто слышу:  «У нас есть тестировщики, они всё проверили».  Тестировщик находит баги.  Эксперт устанавливает юридически значимые факты.  Разница принципиальная:

• Цель: тестировщик  — найти ошибки и помочь их исправить.  Эксперт  — установить истину и дать заключение для суда.
• Методы: тестировщик  — функциональные тесты.  Эксперт  — комплексный анализ  (код, логи, безопасность, нагрузка).
• Ответственность: тестировщик  — внутренняя.  Эксперт  — уголовная  (ст.  307 УК РФ за дачу заведомо ложного заключения).
• Результат: тестировщик  — отчёт об ошибках.  Эксперт  — заключение, принимаемое судом как доказательство.

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

Глава 10.  Заключение 🔏

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

Подробнее с услугами по экспертизе мобильных приложений вы можете ознакомиться на нашем официальном сайте:  https://patexp.ru