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

Вступление: сколько можно терпеть эти кривые поделки?

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

Глава 1. Кто такие эти «эксперты по мобильным приложениям» и почему 99% из них  — шарлатаны

Прежде чем мы начнём, давай разберёмся, кого сегодня называют «экспертом». Любой мальчик, который установил Android Studio и скачал чужой исходник с Github, уже считает себя специалистом. Приходит к тебе такой «гуру», смотрит на твоё приложение 5 минут, говорит: «Да, есть баги, но это не критично», берёт 30 тысяч рублей и выдаёт отписку на трёх листочках. А в суде этот «эксперт» рассыпается через 5 минут перекрёстного допроса. Настоящая компьютерно-техническая экспертиза мобильных приложений  — это не гадание на кофейной гуще. Это:

• Полная декомпиляция бинарного кода (IPA/APK) с восстановлением архитектуры.
• Статический анализ всех зависимостей, библиотек и фреймворков.
• Динамическое тестирование на десятках реальных устройств с замерами энергопотребления, памяти, CPU.
• Пентест безопасности (ищем дыры, через которые утекают пароли и данные).
• Сравнение с ТЗ, ГОСТами и здравым смыслом.
  Если эксперт не может назвать хотя бы 10 метрик из стандарта ISO 25010  — гоните его в шею. Мы же называем и доказываем каждый свой вывод.

Глава 2. Почему разработчики ненавидят независимую экспертизу (и это их главная проблема)

Знаешь, почему студии-разработчики так боятся настоящей компьютерно-техническая экспертиза мобильных приложений? Потому что она вскрывает то, что они умело прячут: халтурную архитектуру, копипасту чужого кода, отсутствие тестирования, ложь в отчётности. Типичные приёмы, которые мы разоблачаем:
🔪 «Это не баг, это фича»  — превращаем в «нарушение пункта ТЗ № 47».
🔪 «Проблема на стороне сервера»  — показываем дамп сетевого трафика, где сервер возвращает корректные данные, а клиент их игнорирует.
🔪 «У пользователей старые телефоны»  — тестируем на 20 моделях, включая заявленные, и баг проявляется везде.
🔪 «Мы не успели оптимизировать, но в следующей версии починим»  — а по договору уже прошли все сроки, и «следующая версия» не оплачена.
После нашей экспертизы разработчики либо признают вину, либо получают иск на миллионы. И мы ни разу не проиграли.

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

💸 Фабула: Крупный региональный банк заказал мобильное приложение для интернет-банкинга у «топовой» студии, которая брала по 5000 рублей за час. Студия отдала проект с задержкой в 6 месяцев. Но самое страшное началось после запуска: клиенты жаловались, что списания дублируются, а поступления исчезают из истории. Банк создал резерв в 23 млн рублей для компенсаций, потерял 30% активных пользователей. Студия заявила: «Это баги бэкенда, переделывайте сервер».
🔥 Что мы сделали:

Получили APK (Android) и IPA (iOS) файлы, а также исходный код (по определению суда). В коде нашли класс TransactionHandler.java. В методе saveTransaction() при сбое сети данные записывались в локальную БД, но не было механизма повторной синхронизации (retry policy). Через 24 часа кэш очищался, и транзакции «испарялись».

Провели динамическое тестирование: на 10 устройствах (Android 11-14, iOS 15-17) эмулировали обрыв сети через Network Link Conditioner (50% потерь пакетов). В 34% случаев транзакции терялись.

Анализировали бэкенд-логи (предоставлены банком): сервер получал все транзакции, но приложение не делало повторного запроса после восстановления соединения.

Дополнительно нашли утечку памяти: при многократном открытии экрана «История операций» потребление RAM росло с 80 МБ до 450 МБ за 10 минут, что приводило к крашу на устройствах с 2 ГБ памяти.
⚖️ Результат: Студия пыталась оспаривать, привлекла «своего эксперта», который написал, что «дефекты некритичны». Мы провели перекрёстный допрос, задали 15 вопросов, и «эксперт» признал, что не изучал WAL-логи SQLite. Суд взыскал 23 млн рублей убытков плюс 5 млн штрафа. Компьютерно-техническая экспертиза мобильных приложений уделала «профессионалов» в сухую.

Глава 4. Как мы считаем убытки от некачественного приложения: формула конфликта

Один из самых острых вопросов: как доказать, что именно баги приложения привели к потерям денег? Разработчик всегда кричит: «Это не мы, это маркетинг плохой, это конкуренты, это сезонное падение». Наша методика включает несколько этапов:
📉 Прямой ущерб: Компенсации клиентам (если приложение списало лишнее), штрафы госорганов (Роскомнадзор за утечку данных), стоимость восстановления потерянной информации (например, пересдача анализов в медицинском приложении).
📉 Упущенная выгода: Снижение количества заказов/транзакций после появления критического бага. Мы анализируем метрики за 3 месяца до и после, исключаем сезонность (например, декабрь выше февраля). Разница  — упущенная выгода. В кейсе с доставкой еды мы доказали падение на 40% именно из-за фризов и вылетов.
📉 Репутационный ущерб: Сложнее, но оценивается через стоимость удаления негативных отзывов, PR-кампании по восстановлению доверия. Суды поддерживают, если есть экспертиза маркетолога.
📉 Стоимость исправления: Час работы сеньора, умноженный на трудоёмкость (которую мы определяем через анализ кода). Часто это превышает первоначальную стоимость разработки.
Компьютерно-техническая экспертиза мобильных приложений даёт суду цифры, а не эмоции.

Глава 5. Кейс №2: Приложение доставки, которое сожрало батарею и убило бизнес

🍕 Фабула: Сеть пиццерий (средний бизнес, 120 точек) вложила 9 млн рублей в мобильное приложение для заказа еды. Разработчик (студия из двух человек) обещал «высокую производительность и низкое энергопотребление». Через месяц после запуска владелец сети заметил странное: приложение установили 5000 человек, но 90% перестали им пользоваться через неделю. Почему? В отзывах в App Store и Google Play клиенты писали: «Смартфон греется и разряжается за 2 часа». Разработчик ответил: «У пользователей старые телефоны, купите новые».
💥 Наше расследование:

Закупили 6 подержанных телефонов (iPhone XR, 11, 12; Samsung S9, S20, Pixel 4a)  — именно те модели, что были у клиентов.

Установили приложение. Замерили энергопотребление через Battery Historian (Android) и Energy Diagnostics (iOS). Результат: в фоновом режиме приложение жрало 22% батареи в час! Это в 11 раз выше нормы (2% в час считается допустимым).

Декомпилировали код. Нашли сервис LocationService, который запрашивал геолокацию с точностью GPS, интервал 0 метров и 0 миллисекунд. Более того, сервис перезапускался после каждого сворачивания приложения (баг с onTaskRemoved).

В ТЗ было чётко написано: «Геолокация используется только на экране карты, интервал обновления  — 1 раз в 5 минут, приоритет NETWORK_PROVIDER (не GPS)». Разработчик нарушил ТЗ и не провёл тестирование.

В дополнение: приложение при сворачивании не останавливало видео-плеер рекламы, который продолжал проигрывать видео в фоне, создавая нагрузку на GPU.
⚖️ Суд: Экспертное заключение признано. Студию обязали вернуть 9 млн рублей (стоимость разработки) + выплатить 6 млн рублей упущенной выгоды (снижение заказов на 25% за 3 месяца). Компьютерно-техническая экспертиза мобильных приложений поставила жирный крест на карьере горе-разработчиков.

Глава 6. Хранение паролей в открытом виде: почему это уголовщина

Отдельная песня  — безопасность. Многие студии экономят на шифровании. В результате пароли, токены, медицинские данные, номера карт валяются в файловой системе телефона как на ладони. Достаточно подключить телефон к компьютеру или получить root-доступ  — и всё. Компьютерно-техническая экспертиза мобильных приложений всегда проверяет:
🔐 SharedPreferences / UserDefaults: лежат ли пароли в открытом виде? Мы читаем XML-файлы в папке приложения. Если там виден логин и пароль base64 (или вообще без кодирования)  — это грубейшее нарушение.
🔐 Локальная база данных SQLite: проверяем, есть ли шифрование (SQLCipher). Если нет  — данные извлекаются любым менеджером БД.
🔐 Передача по сети: перехватываем трафик через Burp Suite с подменой сертификата. Если используется HTTP, а не HTTPS, или сертификат не проверяется  — это уже нарушение 152-ФЗ.
🔐 Код на стороне клиента: ищем API-ключи, токены доступа, зашитые в коде (хардкод). Они легко извлекаются декомпиляторами.
В кейсе с медицинским приложением мы нашли 2000 записей пациентов (ФИО, диагнозы, адреса) в открытой SQLite. Разработчик утверждал: «Это примеры». Но мы сопоставили с реальными паспортными данными  — полное совпадение. Иск на 15 млн рублей плюс уголовное дело по ст. 183 УК РФ (коммерческий шпионаж) и штраф Роскомнадзора. Вот тебе и «примеры».

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

🏥 Фабула: Медицинский центр «Здоровье+» (условное название) заказал приложение для пациентов: просмотр анализов, запись к врачу, онлайн-консультации. Разработчик (довольно известная студия, между прочим) сдал проект. Через месяц пациенты начали массово жаловаться, что их анализы исчезают из приложения спустя 3-5 дней. Центр получил несколько исков от пациентов на общую сумму 8 млн рублей (моральный вред, пересдача платных анализов). Разработчик в ответ: «Это пользователи сами удаляют историю, нажимают не туда».
🔪 Методы экспертизы:

Получили APK-файл и дампы приложения с 3 устройств пациентов (с их согласия).

Декомпилировали через jadx. В коде нашли метод cleanOldRecords() в классе DbHelper.java. Он запускался по таймеру каждые 48 часов и выполнял DELETE FROM lab_results WHERE created_at < datetime(‘now’, ‘-2 days’). То есть всё, что старше 2 дней, удалялось автоматически.

В ТЗ (предоставленном заказчиком) было чёрным по белому: «История анализов хранится бессрочно, возможно удаление только вручную пользователем». Разработчик это требование либо проигнорировал, либо «забыл».

Восстановили удалённые записи из WAL-файлов SQLite (журнал упреждающей записи). Даже после DELETE данные оставались в нераспределённом пространстве до перезаписи страниц. Восстановили 2800 записей из 3000 (93%).

Проверили сетевую синхронизацию: сервер хранил анализы, но приложение при повторном входе не загружало старые записи, только новые. Архитектурный дефект.
💣 Итог: Суд признал разработчика виновным в ненадлежащем качестве. Взыскано 8 млн рублей прямого ущерба (пациентам) + 2 млн рублей на переработку приложения. Компьютерно-техническая экспертиза мобильных приложений спасла медицинский центр от разорения.

Глава 8. Почему техническое задание  — это святое, а отговорки разработчиков  — это ложь

Сколько раз мы слышали: «В ТЗ это не точно сформулировано», «Мы реализовали по-своему, потому что так архитектурно правильнее», «Заказчик сам не знал, чего хотел». Знаете наше мнение? Всё это попытки оправдать халтуру. Компьютерно-техническая экспертиза мобильных приложений разбирает каждое требование ТЗ по косточкам:
📄 Измеримые требования (например, «время запуска не более 3 секунд»)  — проверяем инструментально. Не прошёл тест  — дефект.
📄 Функциональные требования («приложение должно отображать карту с филиалами»)  — проверяем навигацию, наличие всех элементов, работу в оффлайн-режиме.
📄 Требования к дизайну («кнопка должна быть зелёной»)  — сравниваем с макетом в Figma.
📄 Требования к безопасности («передача данных только по HTTPS»)  — перехватываем трафик.
Если разработчик реализовал функцию, но она работает неправильно (например, карта есть, но не загружаются метки)  — это дефект реализации. Если функции нет вообще  — это невыполнение обязательств. Суды нас поддерживают. Никакой «творческий подход» не отменяет условия контракта.

Глава 9. Инструментарий эксперта: чем мы вскрываем гнойники

Не думайте, что мы работаем голыми руками. У нас есть арсенал, которому позавидует любая спецслужба:
🛠️ Для декомпиляции и статического анализа:

• Android: jadx, Bytecode Viewer, APKTool, Procyon, CFR.
• iOS: Hopper Disassembler, IDA Pro, Ghidra, class-dump, otool.
  🛠️ Для динамического тестирования:
• Стенд из 20 физических устройств (iPhone SE до 14 Pro, Samsung A51 до S23, Pixel 4-7).
• Автоматизация через Appium, Espresso, XCTest.
• Мониторинг: Android Profiler, Xcode Instruments, SoloPi.
  🛠️ Для анализа сети:
• Charles Proxy, Burp Suite, Wireshark, Fiddler.
• Эмуляция плохой сети: Network Link Conditioner (Mac), ATE (Android Traffic Emulator).
  🛠️ Для энергопотребления:
• Battery Historian (Google), PowerTutor, Energy Profiler (iOS).
  🛠️ Для восстановления данных:
• SQLite Forensic Toolkit, sqlite3_analyzer, DBeaver с плагинами.
• Собственные скрипты на Python для парсинга удалённых страниц.
  Каждый инструмент лицензионный (мы не пираты), каждый этап логируется. Это позволяет нам в суде под присягой заявить: «Да, я лично видел, как приложение падает при сценарии № 47, и вот видеозапись».

Глава 10. Как мы ловим разработчиков на лжи: протокол эксперимента

Разработчик всегда пытается сказать: «У нас не воспроизводится, значит, проблемы на вашей стороне». Наш ответ: «А мы сейчас всё покажем». Мы составляем протокол эксперимента, который не оставляет камня на камне:
1️⃣ Стенд: модель телефона, версия ОС, версия приложения, настройки сети (Wi-Fi/4G), уровень заряда батареи.
2️⃣ Исходное состояние: приложение установлено впервые, кэш пустой, авторизация под тестовым пользователем.
3️⃣ Шаги: пошаговая инструкция с указанием таймингов (например, «нажать кнопку X, подождать 2 секунды, затем нажать Y»).
4️⃣ Ожидаемый результат (по ТЗ или по здравому смыслу).
5️⃣ Фактический результат: краш, белый экран, некорректные данные, зависание на N секунд.
6️⃣ Скриншот и видеозапись экрана (через скринкаст и камеру на штативе).
7️⃣ Логи: adb logcat, вывод консоли Xcode, дамп памяти.
8️⃣ Повторяемость: если из 5 попыток баг воспроизводится 5 раз  — вероятность 100%. Если 3 из 5  — «часто воспроизводимый».
С таким протоколом в суде разработчик просто не может сказать «а у нас всё работает». Мы предъявляем доказательства, и адвокат противника затыкается.

Глава 11. Соответствие ГОСТам: почему это важно для суда

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

Глава 12. Сколько стоит халтура? Формула расчёта ущерба

Давай о деньгах. Разработчик всегда говорит: «Ну, баги есть, но не смертельно». А мы считаем. Компьютерно-техническая экспертиза мобильных приложений включает экономическую часть:
💰 Реальные убытки:

Суммы, выплаченные клиентам в качестве компенсаций (например, за ошибочные списания).

Штрафы Роскомнадзора, ФНС, ЦБ (за утечку персональных данных, за непредоставление информации).

Расходы на восстановление утерянных данных (например, пересдача 5000 анализов по 2000 рублей = 10 млн).
💰 Упущенная выгода:

Снижение количества заказов/транзакций после бага. Берём средний чек, умножаем на количество потерянных заказов. Доказываем через статистику до и после.

Снижение конверсии (например, было 5%, стало 2%  — разница 3% от трафика).
💰 Расходы на исправление:

Человеко-часы на анализ, фикс, тестирование. Мы определяем трудоёмкость по коду (метод COCOMO II). Часто это 3-6 месяцев работы команды.
В кейсе с банковским приложением мы насчитали 23 млн прямого ущерба + 8 млн исправлений. Разработчик предлагал «скидку 10% на следующий проект». Суд нас поддержал.

Глава 13. Что делать, если вы попали в ситуацию «приложение не работает»  — алгоритм конфликта

Если вы заказчик и понимаете, что разработчик вас кинул:
1️⃣ Не удаляйте приложение с телефонов тестировщиков и пользователей (если есть доступ). Не обновляйте его.
2️⃣ Соберите доказательства: скриншоты, видеозаписи экрана, логи (через adb logcat для Android, Xcode Console для iOS, если есть доступ).
3️⃣ Зафиксируйте переписку с разработчиком (Telegram, email, Jira). Скриншоты, архивы.
4️⃣ Направьте претензию с требованием устранить баги в разумный срок (например, 30 дней). Если не устранили  — фиксируйте.
5️⃣ Наймите независимого эксперта (нас, например) для проведения компьютерно-техническая экспертиза мобильных приложений. Эксперт даст заключение, которое станет доказательством в суде.
6️⃣ Подавайте иск о расторжении договора, взыскании уплаченного, убытков, упущенной выгоды. Штрафные санкции по ст. 333 ГК РФ.
Мы сопровождаем до победы. И помогаем собирать доказательства.

Глава 14. Типичные отговорки разработчиков и наши ответы (памятка для суда)

Собрали для вас таблицу конфликта (на самом деле, мы её зачитываем в судебных заседаниях):
❌ Отговорка: «Это ошибка ОС, мы не виноваты».
✅ Наш ответ: Предъявляем видео, где на чистой ОС без обновлений баг воспроизводится. В ТЗ было требование работы на этой версии ОС.
❌ Отговорка: «Вы сами сломали приложение своими действиями».
✅ Наш ответ: В протоколе эксперимента пошагово описаны действия, которые являются штатными (например, нажатие кнопки «Оформить заказ»). Никто не лазил в код.
❌ Отговорка: «Это редкий баг, встречается у 1% пользователей».
✅ Наш ответ: Если в ТЗ нет ограничения, любой баг, влияющий на работу, должен быть исправлен. К тому же мы доказали, что он воспроизводится на 50% устройств.
❌ Отговорка: «Мы не успели протестировать, но сделаем скидку».
✅ Наш ответ: Тестирование  — обязанность разработчика по договору и ГОСТу. Скидка не покрывает убытки от неработающего приложения.
Компьютерно-техническая экспертиза мобильных приложений уничтожает эти отговорки на корню.

Глава 15. Итог: почему мы, а не кто-то другой

У Союза «Федерация судебных экспертов» за плечами более 70 выигранных дел по мобильным приложениям, общая сумма взысканий  — свыше 500 млн рублей. Наши эксперты  — это не студенты, а люди с 10+ годами разработки и сертификатами (CFCE, CCFP, OSCP). Мы не работаем на процент от иска, мы работаем за факт. Мы не дружим с разработчиками и не берём взятки. Нас боятся недобросовестные студии, потому что знают: наша экспертиза разрушит их ложь.
Компьютерно-техническая экспертиза мобильных приложений  — это ваш шанс на справедливость.
Компьютерно-техническая экспертиза мобильных приложений  — это когда код говорит правду, а разработчик плачет.
Компьютерно-техническая экспертиза мобильных приложений  — это не услуга, а оружие.
Компьютерно-техническая экспертиза мобильных приложений  — это наша профессия и ваш щит.
И последний раз: компьютерно-техническая экспертиза мобильных приложений от Союза «Федерация судебных экспертов»  — это гарантия того, что вы не останетесь один на один с халтурой.

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

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

Заказывайте экспертизу. Побеждайте. А мы поможем. Союз «Федерация судебных экспертов»  — где правда рождается в байтах, а ложь умирает в суде. 💀🔥⚖️