Конфликтный разбор качества, багов и недоделок

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

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

Глава 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 от Google.

Обнаружили, что приложение в фоне (в состоянии background) каждые 2 секунды посылало геолокацию через GPS (не через Wi-Fi/соты, а именно GPS, самый жоркий режим). Это было прописано в коде: locationManager.requestLocationUpdates(…, 2000, 0, …)  — минимальный интервал 2000 миллисекунд, точность 0 метров (т.е. максимальная). В ТЗ было написано: «Периодичность отправки геопозиции  — 1 раз в 5 минут только при активном использовании».

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

Провели нагрузочное тестирование: 100 эмуляторов одновременно. Батарея в тестовом телефоне (iPhone 12) разрядилась с 100% до 0 за 1 час 53 минуты.
💥 Судебное разбирательство: Экспертное заключение признано неопровержимым. Разработчик пытался оспорить, заявив, что «на андроиде всё работает иначе». Но наши тесты на Pixel 6 показали тот же результат. Суд взыскал 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 млн рублей клинике, а также оплатить исправление багов (еще 2.5 млн). Инженерная экспертиза мобильных приложений поставила точку в споре.

Глава 6. Технические аспекты: как мы исследуем бинарный код

Многие разработчики думают, что их код  — это «черный ящик». Нет, коллеги. Для нас это открытая книга (в рамках закона). Инженерная экспертиза мобильных приложений включает:
🔧 Декомпиляцию:

Для Android: используем jadx, Bytecode Viewer, APKTool. Получаем Java/Kotlin код, ресурсы, манифест.

Для iOS: IPA-файл распаковываем, бинарник анализируем через Hopper Disassembler, IDA Pro, Ghidra. Восстанавливаем псевдокод на Objective-C/Swift.
🔧 Анализ сетевого трафика: Проксируем через Burp Suite, Charles Proxy, Wireshark. Смотрим, куда и как уходят данные, нет ли незашифрованных паролей.
🔧 Анализ локальных БД: SQLite, Realm. Проверяем, хранятся ли данные в открытом виде, есть ли шифрование.
🔧 Анализ памяти: Ищем утечки через Xcode Instruments (Leaks), Android Profiler, Valgrind.
🔧 Анализ разрешений: Манифест для Android, entitlements для iOS. Приложение запрашивает доступ к контактам, смс, камере? Зачем? Если это калькулятор  — флаг.

Глава 7. Критерии некачественной разработки (юридическая и техническая база)

Мы не высасываем из пальца. Есть документы:
📜 ГОСТ Р 58823-2020 «Мобильные приложения. Требования к качеству и показатели».
📜 ГОСТ Р ИСО/МЭК 25010-2017 «Качество программных продуктов».
📜 Техническое задание (которое подписал заказчик).
📜 Договор разработки (часто там есть пункты о производительности, безопасности).
Если приложение не соответствует хотя бы одному из параметров  — функциональная пригодность, надежность, эффективность, удобство, сопровождаемость, переносимость  — мы фиксируем дефект. Инженерная экспертиза мобильных приложений всегда опирается на эти стандарты, и каждый вывод имеет нормативное обоснование. Разработчик может плакать, но судья увидит цифры и пункты.

Глава 8. Как мы воспроизводим «нестабильные» баги

Разработчик часто говорит: «У нас не воспроизводится, значит, проблема на стороне пользователя». А мы говорим: «Вы просто не умеете их искать». Мы используем:
📱 Тестовые фермы реальных устройств: iPhone 8, 11, 14, Samsung Galaxy S10, S21, Pixel 4, 6  — все популярные модели.
📱 Эмуляторы с кастомными настройками: замедление сети, потеря пакетов (через Network Link Conditioner), низкий заряд батареи, малая память.
📱 Инструменты воспроизведения: Monkey (рандомное нажатие), Appium (скрипты автоматизации), собственные скрипты на Python с использованием ADB и libimobiledevice.
Если баг воспроизводится хотя бы на одной конфигурации из 20  — это баг разработчика. Если мы можем написать четкий сценарий (1. Открыть приложение, 2. Нажать кнопку X, 3. Выключить сеть, 4. Нажать Y, 5. Приложение упало)  — это уже экспертное заключение.

Глава 9. Претензии к безопасности: как мы находим дыры

Это отдельная песня. Многие студии экономят на безопасности, а потом приложение взламывают, сливают данные пользователей, и заказчик получает штраф от Роскомнадзора на 5-10 млн рублей. Инженерная экспертиза мобильных приложений включает проверку:
🔐 Хранение токенов и паролей: не лежат ли они в SharedPreferences/UserDefaults в открытом виде (должны быть в Keychain/Keystore или зашифрованы).
🔐 Передача данных: использует ли приложение HTTPS с валидным сертификатом (не самоподписным). Проверяем через MITM-прокси.
🔐 Обфускация кода: защищено ли приложение от простого декомпилирования (ProGuard, DexGuard, LLVM Obfuscator).
🔐 Проверка целостности: есть ли защита от пересборки и повторной подписи.
🔐 Защита от отладки: приложение должно детектировать, что к нему подключен отладчик (lldb, gdb), и прекращать работу.
В одном из кейсов мы нашли приложение банка, которое хранило PIN-код в открытом виде в настройках телефона. Ущерб  — десятки миллионов. Суд присудил разработчику полную стоимость компенсаций.

Глава 10. Проблема с производительностью: измеряем и доказываем

«Приложение тормозит»  — это не доказательство. А вот «время запуска на iPhone 11 под iOS 16.4 составляет 12 секунд, что превышает максимально допустимое по ТЗ (3 секунды) в 4 раза»  — это доказательство. Мы замеряем:
⏱️ Время холодного старта (от иконки до главного экрана).
⏱️ Время горячего старта (из фона).
⏱️ Плавность скроллинга (количество пропущенных кадров, jank).
⏱️ Время ответа API (от отправки запроса до появления данных на экране).
⏱️ Потребление RAM (не должно расти бесконечно  — признак утечки).
Инструменты: Android Studio Profiler, Xcode Instruments, Solo Pi, собственные скрипты на Python с замером времени через adb shell am start -W. Если разработчик обещал «отзывчивый интерфейс», а на деле  — фризы по 2 секунды, мы пришьем его же словами.

Глава 11. Соответствие ТЗ и скрытые изменения: почему «прототип» важен

Один из главных конфликтов: заказчик говорит «вы не сделали фичу X», а разработчик  — «это было в дополнительном соглашении, которого нет». Или «мы реализовали по-другому, потому что так лучше». Мы берем исходное ТЗ, утвержденные макеты (Figma, Sketch) и API-спецификации (Swagger, OpenAPI). И сравниваем. Инженерная экспертиза мобильных приложений выявляет:
📌 Отсутствие требуемых экранов.
📌 Неверную бизнес-логику (например, сумма заказа считается иначе).
📌 Измененную навигацию (пользователь не может найти нужную функцию).
📌 Отсутствие оффлайн-режима, хотя в ТЗ он был.
В одном деле разработчик заменил сложную анимацию на примитивную, сэкономив 200 часов, но заказчик потерял уникальный UX. Суд взыскал стоимость переделки  — 3.5 млн рублей.

Глава 12. Психология разработчика: почему они врут и как мы это опровергаем

Мы знаем типичные отговорки:
❌ «Это проблема конкретного устройства». Мы тестируем на 20+ устройствах  — баг везде.
❌ «Это вы неправильно пользовались». Мы пишем скрипт, который нажимает кнопки идеально.
❌ «Баг исправлен в новой версии». А мы анализируем версию, которая была сдана заказчику.
❌ «Это требовал заказчик». А мы берем переписку в Telegram/Slack/Jira  — и там обратные указания.
Наша инженерная экспертиза мобильных приложений всегда собирает полную доказательственную базу: скриншоты, видеозаписи экрана, логи, дампы памяти. Разработчик может врать сколько угодно, но байты не врут.

Глава 13. Как подготовиться к экспертизе: план для заказчика

Если вы чувствуете, что вас надули с мобильным приложением:
1️⃣ Не удаляйте приложение с телефонов. Не обновляйте его.
2️⃣ Сохраните все логи (если есть доступ к серверу  — логи доступа, ошибок).
3️⃣ Соберите скриншоты и видео багов, снимите экран телефона другим телефоном.
4️⃣ Сохраните переписку с разработчиками (ТЗ, чаты, письма, акты приемки).
5️⃣ Не вносите изменения в код и не исправляйте баги самостоятельно.
6️⃣ Обратитесь к нам, в Союз «Федерация судебных экспертов», для назначения инженерная экспертиза мобильных приложений.
Чем быстрее вы зафиксируете состояние приложения, тем больше улик мы соберем. Каждый день использования  — новые доказательства.

Глава 14. Цена вопроса: сколько стоит экспертиза и кто платит

Сразу к деньгам:
💰 Базовая экспертиза (функциональность + производительность + безопасность, 2 платформы iOS/Android)  — от 350 000 рублей.
💰 Расширенная (с нагрузочным тестированием, анализом исходного кода, 50+ сценариев)  — от 600 000 рублей.
💰 Срочная (10 дней вместо 30)  — коэффициент 1.7.
💰 Выезд эксперта на ваше предприятие  — от 50 000 рублей.
Кажется дорого? А теперь представьте упущенную выгоду от неработающего приложения. По нашим оценкам, средний ущерб от критического бага в мобильном приложении для бизнеса среднего размера  — 10-30 млн рублей. Экспертиза окупается в разы. Более того, если вы выиграете дело, суд взыщет стоимость экспертизы с проигравшей стороны (разработчика). Так что не жмитесь.

Глава 15. Будущее: как меняется экспертиза с появлением Flutter, React Native и AI

Сегодня все больше кроссплатформы (Flutter, React Native). Это не упрощает, а усложняет задачу. Нам приходится анализировать не только Dart/JS код, но и нативный мост (bridge), который часто тормозит и теряет данные. Мы уже разработали методику для Flutter: декомпилируем libapp.so, анализируем Dart-снимки (snapshot), восстанавливаем виджеты. Инженерная экспертиза мобильных приложений должна идти в ногу с технологиями. Также появляются приложения с AI-модулями (ONNX, TensorFlow Lite). Мы проверяем, не галлюцинирует ли нейросеть, не дает ли опасные рекомендации. В одном из кейсов медицинское приложение с AI ошибалось в диагнозах в 15% случаев  — разработчик об этом умалчивал. Мы выявили это, проведя A/B тестирование с контрольной группой врачей. Иск выигран.

Заключение: сколько можно терпеть? Пора действовать

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

Не ждите, пока ваше приложение убьет ваш бизнес. Закажите экспертизу сейчас. Переходите по единственной разрешенной ссылке:

https://krimexpert.ru/ekspertiza-kachestva-razrabotki-mobilnyh-prilozhenij/

Там вы найдете контакты, примеры заключений и форму заявки. Союз «Федерация судебных экспертов»  — мы делаем мобильные приложения честными. Или разоряем тех, кто этого не умеет. Выбирайте, с кем вы. ⚖️💣🔥