Глава 1: Цифровой фронт  — мобильные приложения как арена битвы

Представь себе мир, где каждый твой шаг контролируется программой, которая живёт у тебя в кармане. 📱 Ты просыпаешься  — будильник (приложение). Заказываешь кофе  — приложение доставки. Платишь в метро  — приложение банка. Записываешься к врачу  — медицинский портал. Голосуешь за любимого певца  — приложение шоу. И каждый раз ты доверяешь этим невидимым программам своё время, деньги, здоровье, а иногда и жизнь. Но что, если они врут? Что, если они работают неправильно, специально или по ошибке искажают реальность? Кто ответит за баг, который стоил человеку миллиона? Кто докажет, что «случайный сбой» был на самом деле запрограммирован? 😈

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

Акцент мы сделаем на претензиях к качеству работы приложения. Потому что именно здесь скрывается большинство споров: заказчик заплатил за идеальный продукт  — получил сырую поделку. Пользователь пострадал от бага  — разработчик пожимает плечами: «А вы подписали лицензионное соглашение». Судьи и адвокаты часто не понимают технических деталей. И тогда появляемся мы  — эксперты, которые объяснят, почему «случайное зависание» на самом деле  — критический дефект архитектуры. 🛠️

Мы разберём три реальных кейса из нашей практики (с изменёнными деталями, но без потери смысла), методологию исследования, типичные ловушки разработчиков и способы их разоблачения. Будет много технического жаргона, но я переведу на человеческий. Обещаю, будет интересно. Погнали! 🚀

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

Инженерная экспертиза мобильных приложений  — это род судебной компьютерно-технической экспертизы, объектом которой являются программные продукты для мобильных устройств (iOS, Android, HarmonyOS, реже  — Windows Phone). Она исследует не только сам код (хотя и его тоже), но и архитектуру, пользовательский интерфейс, производительность, безопасность, соответствие техническому заданию (ТЗ) и условиям договора. 📄

Зачем она нужна? Ситуаций масса:

Заказчик нанял студию разработки за 10 миллионов рублей, а получил приложение, которое вылетает каждый пятый запуск. Он хочет вернуть деньги. 💰

Банковское приложение «по ошибке» списало со счетов пользователей миллионы рублей, а потом разработчик сказал «баг, извините». Но пострадавшие подали в суд.

В приложении для голосования были «накручены» голоса  — кто-то встроил скрытый модуль, искажающий результаты.

Приложение для управления медицинским оборудованием дало сбой, пациент пострадал (вплоть до летального исхода). ⚕️

Два разработчика спорят, кто из них украл чужой код  — экспертиза определяет плагиат.

Наша задача  — ответить на вопросы суда: работало ли приложение в соответствии с заявленными требованиями? Если нет  — то какие именно дефекты имели место? Являются ли эти дефекты критическими? Могли ли они привести к заявленным убыткам? И самое главное  — являются ли эти дефекты следствием некачественной работы разработчика или же пользователь сам нарушил правила эксплуатации? ⚖️

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

Глава 3: Методологический базис  — как мы исследуем приложения

Прежде чем нырять в кейсы, давай разберёмся, из каких этапов состоит наша работа. Методология  — это карта, без которой нельзя. 🗺️

Этап 1. Анализ документации. Мы запрашиваем у сторон всё, что есть: техническое задание (ТЗ), макеты, протоколы тестирования, переписку разработчиков, договор. Если ТЗ нет  — это плохо, но не безнадёжно. Мы можем опираться на «обычаи делового оборота» или на явные несоответствия здравому смыслу.

Этап 2. Статический анализ кода. Мы получаем исходный код приложения (если он доступен) и анализируем его на предмет архитектурных ошибок, уязвимостей, недокументированных функций. Используем статические анализаторы (SonarQube, PVS-Studio, Android Lint). Ищем «закладки», неиспользуемые разрешения, подозрительные сетевые вызовы. 🔬

Этап 3. Динамический анализ. Запускаем приложение в контролируемой среде (эмулятор или реальное устройство, подключённое к отладчику). Мониторим сетевой трафик (Wireshark, mitmproxy), потребление ресурсов (CPU, память, батарея), логи (Logcat для Android, Console для iOS). Ищем воспроизводимые сценарии падений, зависаний, утечек памяти.

Этап 4. Нагрузочное тестирование. Если есть подозрение, что приложение не выдерживает реальную нагрузку (например, 1000 пользователей одновременно), мы эмулируем эту нагрузку с помощью специальных инструментов (JMeter, Locust). Смотрим, при каких условиях приложение начинает тормозить, вылетать или терять данные. 📊

Этап 5. Анализ безопасности. Проверяем, защищены ли данные пользователя: передаются ли пароли в открытом виде, можно ли перехватить трафик, есть ли проверка целостности (certificate pinning). Ищем уязвимости из OWASP Mobile Top 10.

Этап 6. Экспертный эксперимент. Воспроизводим заявленный дефект (например, «при нажатии на кнопку Купить происходит списание средств дважды»). Документируем каждый шаг, снимаем видео, делаем скриншоты. Фиксируем, зависит ли дефект от версии ОС, модели устройства, региона.

Этап 7. Формулирование выводов. На основе всего этого мы пишем заключение, где чётко, без «воды» отвечаем на вопросы суда: соответствует ли приложение ТЗ, есть ли критические баги, чья это вина  — разработчика, заказчика или железа. 🏛️

Все эти этапы требуют высокой квалификации. Нельзя просто «посмотреть приложение пальцем». Инженерная экспертиза мобильных приложений  — это синтез программирования, тестирования, криминалистики и юриспруденции. И мы владеем этим синтезом в совершенстве. 💪

Глава 4: Кейс первый  — «Торговая площадка, которая не могла торговать» (претензия к качеству)

🛍️ История первая, классика жанра «заказчик vs разработчик». Компания «Золотое Руно» (название изменено) заказала разработку маркетплейса  — мобильного приложения для продажи товаров ручной работы. Договор  — 8 миллионов рублей, срок  — 4 месяца. Через 6 месяцев разработчик сдал приложение. Но оно работало ужасно: при попытке загрузить фото товара вылетало, поиск выдавал не те товары, а после оплаты иногда списывалась сумма, а заказ не создавался. Заказчик отказался платить второй транш (4 млн). Разработчик подал в суд.

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

Что мы сделали:

📌 Шаг 1. Анализ ТЗ и документации. В ТЗ было чётко прописано: «приложение должно поддерживать одновременную работу 1000 пользователей, время отклика  — не более 2 секунд, загрузка фото  — не более 3 секунд». Разработчик предоставил протоколы своего тестирования, где якобы все показатели соблюдены.

📌 Шаг 2. Воспроизведение дефектов. Мы установили приложение на 5 реальных устройств (разные модели Android и iOS). На каждом повторили сценарии: регистрация, добавление товара (с фото), поиск, оформление заказа. Результаты:

На 3 из 5 устройств при добавлении фото приложение вылетало (крэш) с ошибкой OutOfMemoryError. Причина  — неэффективное сжатие изображений. 📸

Поиск: при вводе на кириллице выдавал пустой результат, на латинице  — работал. Ошибка в кодировке запроса к серверу.

Оплата: в 5% тестовых транзакций (специально прогнали 200 операций) происходило двойное списание. Деньги уходили, но заказ не создавался. Серверный лог показал дублирование запросов из-за отсутствия идемпотентности.

📌 Шаг 3. Нагрузочное тестирование. Мы запустили эмуляцию 500 пользователей (JMeter). При 300 пользователях время отклика выросло до 10 секунд. При 500  — сервер начал падать (HTTP 500). Разработчик, видимо, тестировал на одном мощном телефоне и локальном сервере, а в реальном облаке всё рухнуло. ☁️

📌 Шаг 4. Анализ кода (нам предоставили доступ). Нашли классические «грабли»:

Отсутствие кэширования запросов

Синхронные вызовы сети в UI-потоке (приложение «зависало»)

Использование библиотеки для фото без обработки исключений

Нет защиты от повторной отправки формы (отсюда двойное списание)

Вывод эксперта: Приложение имеет множественные критические дефекты, не соответствующие условиям договора и обычаям делового оборота. Разработчик не исполнил обязательства надлежащим образом. Суд встал на сторону заказчика, взыскал с разработчика часть выплаченного аванса (3 млн) и обязал исправить дефекты за свой счёт. 🏆

Методологический урок: Инженерная экспертиза мобильных приложений способна отличить единичный баг от системного дефекта качества. В данном случае дефекты были системными, что и доказало наше нагрузочное тестирование.

Глава 5: Претензии к качеству  — что это такое с точки зрения закона

Давай теперь разберём юридическую сторону. Что значит «некачественное приложение»? В договоре между заказчиком и разработчиком обычно есть пункты о соответствии ТЗ, об отсутствии критических ошибок, о производительности. Но в реальности ТЗ часто составлено плохо, а разработчик ссылается на «неустранимые ограничения платформы». Так как же быть? 🤷

Виды претензий к качеству:

🔸 1. Несоответствие функциональным требованиям (что-то не работает вообще или работает не так, как описано). Например: кнопка «Вход» не нажимается, список не прогружается, уведомления не приходят.

🔸 2. Дефекты производительности (работает медленно, ест батарею, греет телефон, много весит). Субъективно, но есть объективные метрики: время запуска, FPS (кадры в секунду), потребление памяти, трафика.

🔸 3. Ошибки безопасности (данные пользователя утекают, можно перехватить пароль, можно взломать приложение и украсть деньги). Это уже уголовщина.

🔸 4. Несовместимость (приложение работает только на iPhone 14 Pro с последней версией iOS, а на остальных  — нет). Если в ТЗ не оговорены конкретные устройства, это недостаток.

🔸 5. Проблемы с юзабилити (интерфейс нелогичен, пользователь не может понять, как выполнить действие). Это спорная зона, но если приложение предназначено для массового пользователя, а оно непонятно и неинтуитивно  — это может быть основанием для претензии.

Наша задача  — доказать, что дефект действительно имеет место, что он не является следствием неправильных действий пользователя, что разработчик мог и должен был его предотвратить (используя современные инструменты и практики). Мы не принимаем отговорки: «А у вас телефон кривой» или «Вы не обновили прошивку». Мы проверяем на эталонных устройствах. 📱

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

Глава 6: Кейс второй  — «Финансовый супермаркет с двойным списанием» (претензия пользователей)

💳 Вторая история, уже из области потребительского права. Финансовое приложение «Кошелек-Супермаркет» (название вымышленное) позволяло оплачивать услуги ЖКХ, штрафы ГИБДД, налоги. В какой-то момент пользователи по всей стране начали жаловаться: при оплате квитанции списывалась сумма дважды, а вторая транзакция часто «зависала» и не возвращалась неделями. Банк, процессинг, разработчик  — перекладывали вину друг на друга. Десятки пострадавших подали иски на суммы от 5 до 150 тысяч рублей. Суд назначил комплексную экспертизу, включая инженерную экспертизу мобильных приложений. 🧑‍⚖️

Наша работа:

🔹 Этап 1. Сбор данных. Мы запросили у разработчика исходный код (они сначала отказывались, но суд обязал). Получили APK-файлы (Android) и IPA-файлы (iOS). Также запросили логи сервера процессинга и банка-эквайера (согласие дали).

🔹 Этап 2. Статический анализ кода. В коде iOS-версии (Swift) нашли такую конструкцию (упрощённо):

swift

func processPayment(amount: Decimal) {

let request = createPaymentRequest(amount)

api.send(request) { result in

if result.success {

// обновить UI

} else {

// показать ошибку

}

}

}

Проблема: метод send не гарантирует идемпотентность. Если сервер ответил, но клиент не получил ответ (таймаут), он повторял запрос. А сервер обрабатывал повторный запрос как новую транзакцию. Это классическая ошибка распределённых систем. 🐛

🔹 Этап 3. Воспроизведение дефекта. Мы создали тестовую среду с эмуляцией плохого соединения (пакетный фильтр, который теряет 30% пакетов). На 100 транзакциях в 32 случаях произошло двойное списание. Причём на Android дефект проявлялся реже (там была другая сетевая библиотека), на iOS  — чаще. Разработчик утверждал, что «так задумано» для надёжности, но суд не оценил.

🔹 Этап 4. Экспертиза серверной логики. Мы проанализировали код платежного шлюза (предоставлен банком). Там тоже не было проверки дубликатов (по id транзакции). Ошибка была на стороне разработчика мобильного приложения (не генерировал уникальный id для запроса) и на стороне шлюза (не проверял). Банк согласился компенсировать двойные списания (для сохранения репутации), но потом подал регрессный иск к разработчику. ⚖️

Итог: Суд обязал разработчика выплатить компенсации всем пострадавшим пользователям (в сумме около 5 млн рублей), а также оплатить экспертизу (800 тыс.). Приложение было временно заблокировано в магазинах до исправления.

Методологический урок: В инженерной экспертизе мобильных приложений важно исследовать не только само приложение, но и его взаимодействие с серверной частью. Иногда ошибка лежит на границе систем, и нужно выяснить, чья это территория. 🗺️

Глава 7: Инструментарий эксперта  — от статики до динамики

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

Для статического анализа (исходный код):

Android Studio + Lint  — проверка на потенциальные баги и утечки.

PVS-Studio (платный, но мощный)  — поиск ошибок в C++, C#, Java, Swift.

SonarQube  — анализ качества кода, выявление «запахов».

Jadx  — декомпиляция APK (если нет исходников).

Ghidra / IDA Pro  — для анализа нативных библиотек (так бывает, если приложение использует C++ код).

Для динамического анализа (запущенное приложение):

Android: ADB (Android Debug Bridge)  — логи, скриншоты, эмуляция событий.

iOS: idevicesyslog, libimobiledevice  — логи на неджейлбрейкнутых устройствах.

Frida  — фреймворк для внедрения JavaScript-скриптов в работающее приложение. С его помощью мы можем перехватывать методы, менять поведение, подменять данные. 🔄

Burp Suite / mitmproxy  — анализ сетевого трафика, перехват HTTPS (с установкой своего сертификата).

Charles Proxy  — тоже хорош, особенно для iOS (легче настраивать).

Для нагрузочного тестирования:

Apache JMeter  — эмуляция множества пользователей.

Locust  — на Python, удобен для сценариев.

Appium  — для автоматизации действий на реальных устройствах.

Для восстановления данных (если приложение что-то скрывает):

SQLite Browser  — базы данных приложений часто хранятся в SQLite.

Realm Studio  — для Realm баз.

Autopsy / The Sleuth Kit  — анализ файловой системы смартфона (только при наличии физического доступа и разрешения суда).

Каждый инструмент требует отдельной квалификации. Наш эксперт владеет десятками утилит и знает, когда какую применить. Инженерная экспертиза мобильных приложений без инструментов  — как хирургия без скальпеля. Невозможна. 🔪

Глава 8: Кейс третий  — «Онлайн-школа, где никто не учился» (претензия к работам)

🎓 История третья, из сферы EdTech. Компания «Знание-Сила» заказала разработку мобильного приложения для онлайн-обучения: видеолекции, тесты, домашние задания, чат с преподавателем. Разработчик сдал проект, но заказчик был недоволен:

Видео грузились по 2-3 минуты, постоянно буферизировались.

Результаты тестов сохранялись не всегда (студент проходил тест, а на следующий день прогресс обнулялся).

Чат работал с задержками, иногда сообщения не доставлялись.

Разработчик утверждал, что всё соответствует ТЗ, а проблемы из-за плохого интернета у пользователей. Заказчик подал иск о расторжении договора и взыскании 12 миллионов рублей.

Назначена инженерная экспертиза мобильных приложений.

Наши действия:

🔸 Шаг 1. Анализ ТЗ. В ТЗ было чётко прописано: «Приложение должно обеспечивать воспроизведение видео в разрешении 720p при скорости интернета 5 Мбит/с без задержек». Мы проверили: на скорости 5 Мбит/с видео действительно грузилось и буферизировалось каждые 10 секунд. Причина  — разработчик не использовал адаптивный битрейт (HLS или DASH), а грузил видео целиком через обычный HTTP. Это непрофессионально. 📹

🔸 Шаг 2. Исследование сохранения результатов. Мы провели 50 тестов на 10 устройствах. В 12 случаях результаты теста не сохранились. Причина  — конкурентное состояние (race condition) между запросом на сервер и закрытием страницы теста. Запрос не успевал отработать до того, как пользователь переходил к следующему вопросу. Ошибка архитектуры  — отсутствие очереди запросов и механизма повторной отправки.

🔸 Шаг 3. Анализ чата. Чат использовал WebSocket, но не имел механизма подтверждения доставки (ACK). Сообщения отправлялись в сокет и «забывались». Если соединение рвалось (на мобильных устройствах это часто), сообщение терялось. Это нонсенс для мессенджера в 2024 году. Разработчик пытался оправдаться: «Вы не требовали надёжности», но суд не принял. 🤦

🔸 Шаг 4. Экспертиза кода (предоставлен). Мы нашли более 50 предупреждений SonarQube уровня «Blocker» и «Critical»: утечки памяти, необработанные исключения, дублирование кода, отсутствие модульных тестов. Проект явно делали новички.

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

Урок: Инженерная экспертиза мобильных приложений помогает отличить «профессиональный брак» от «субъективных хотелок». Здесь брак был очевиден. 🏚️

Глава 9: Скрытые дефекты  — как найти то, что разработчик тщательно спрятал

Иногда разработчики не просто допускают ошибки, но и намеренно прячут «закладки» или маскируют недочёты. Мы это умеем находить. 🕵️

Примеры скрытых дефектов:

Троянские функции (приложение собирает данные пользователя и отправляет их на сервер разработчика без согласия).

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

Логирование паролей (разработчик оставил в коде отладочную печать, которая пишет пароли в лог  — потом он их читает).

Бэкдоры (скрытая команда, по которой приложение может выполнить любое действие, например, перевести деньги).

Как мы ищем:

Анализ сетевого трафика  — смотрим, куда и что отправляет приложение. Используем mitmproxy или Burp. Если видим запросы на незнакомый домен, пытаемся расшифровать. 🕸️

Декомпиляция и поиск строк  — ищем в коде URL, API-ключи, подозрительные комментарии.

Динамический анализ с Frida  — перехватываем методы, которые работают с сетью, файловой системой, криптографией.

Сравнение версий  — если есть две версии (например, для App Store и для «специального клиента»), сравниваем их бинарно. Часто в «особой» версии есть код, которого нет в публичной.

Анализ разрешений  — приложение запрашивает доступ к контактам, SMS, геолокации. Зачем? Если явная функция не нуждается в этом  — подозрительно.

В одном из наших кейсов мы нашли в приложении такси скрытый модуль, который каждые 5 минут отправлял координаты телефона на сервер третьей стороны (не компании-агрегатора). Оказалось, разработчик продавал данные конкурентам. Инженерная экспертиза мобильных приложений вскрыла это. 🔓

Глава 10: Ошибки заказчиков, которые мешают экспертизе

Мы хотим помочь, но иногда заказчики сами себе враги. Вот типичные ошибки. Не делайте так. 🙅

Ошибка 1. «Мы потеряли исходный код, экспертируйте по бинарнику».
Без исходного кода анализ сложнее, но возможен (через декомпиляцию). Однако это дороже и может быть неполным. Храните код в репозиториях (GitHub, GitLab, Bitbucket). 🗄️

Ошибка 2. «Мы не подписывали ТЗ, разработчик сам предлагал решения».
Это плохо. Без ТЗ сложно доказать, что приложение работает «не так». В этом случае мы ориентируемся на обычаи делового оборота и явные критические баги, но шансы на успех ниже. Подписывайте ТЗ! 📑

Ошибка 3. «Мы уже изменили код после скандала, теперь проверяйте».
А вот это катастрофа. Экспертиза должна исследовать ту версию приложения, которая была сдана и на которую есть претензии. Если вы внесли изменения  — вы уничтожили улики. Фиксируйте состояние до спора, создавайте архивы, бэкапы. 💾

Ошибка 4. «Мы не дадим вам доступ к серверной части, только мобильное приложение».
Многие дефекты связаны именно с взаимодействием с сервером. Без серверных логов и кода эксперт может ошибиться. Суд может обязать предоставить доступ, но лучше сотрудничать добровольно.

Ошибка 5. «Проведите экспертизу за три дня, у нас суд на следующей неделе».
Полноценная инженерная экспертиза мобильных приложений занимает от 2 до 6 недель (в зависимости от сложности). Экспресс-режим возможен, но он дороже и не для гигабайтных проектов. Планируйте время. ⏰

Глава 11: Процессуальный статус экспертизы в суде

Что происходит после того, как мы подготовили заключение? Оно становится доказательством по делу. Но его ещё нужно «провести через суд». Несколько важных моментов. 🏛️

Назначение экспертизы. Судья выносит определение, в котором формулирует вопросы к эксперту. Мы не можем выходить за рамки вопросов. Если вопрос поставлен некорректно (например, «виновен ли разработчик»  — это правовой, а не технический вопрос), мы просим уточнить.

Предоставление материалов. Стороны предоставляют нам все необходимые объекты: APK-файлы, исходный код, ТЗ, логи серверов, доступы к тестовым стендам. Если одна сторона уклоняется  — суд может принудительно изъять.

Процесс исследования. Мы работаем с копиями, а не с оригиналами. Фиксируем каждый шаг. Срок  — от 10 дней до 2 месяцев (суд назначает). При необходимости запрашиваем продление.

Составление заключения. Заключение  — это не просто «вердикт». Это структурированный документ с вводной частью, исследовательской, синтезом и выводами. Мы прилагаем скриншоты, видеозаписи, фрагменты кода, логи, хэш-суммы.

Допрос эксперта. В судебном заседании стороны могут задавать нам вопросы. Адвокаты пытаются «завалить» эксперта: «А почему вы использовали эту версию Android? А почему не взяли больше устройств?» Мы отвечаем спокойно, обоснованно. Наша подготовка позволяет парировать любые атаки.

Оценка заключения судом. Судья не обязан слепо верить эксперту. Но если заключение мотивированное, научное, не противоречит другим доказательствам  — оно ложится в основу решения. В 90% дел именно так и происходит.

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

Глава 12: Сравнение платформ  — Android vs iOS с точки зрения эксперта

Многие спрашивают: на какой платформе легче проводить экспертизу? Отвечаю. 📱

Android:

Плюсы: доступ к файловой системе (даже на не-rooted устройствах через ADB backup), большое количество инструментов, возможность установки отладочных версий без магазина.

Минусы: фрагментация (тысячи моделей, версий ОС, оболочек), приложение может работать на Samsung, но падать на Xiaomi. Нужно тестировать на разных.

Сложность анализа кода: APK легко декомпилируется (Java/Kotlin), но если есть нативные библиотеки (C++), сложнее.

iOS:

Плюсы: единообразие (ограниченное число устройств и версий), отличные инструменты от Apple (Xcode, Instruments).

Минусы: закрытая файловая система, без джейлбрейка доступ ограничен. Приложение должно быть подписано сертификатом для установки на реальное устройство. Анализ трафика требует подмены сертификата (иногда iOS сопротивляется).

Сложность анализа кода: IPA-файл можно декомпилировать (Swift/Objective-C), но с нативными библиотеками сложно.

Наш подход: мы не выбираем платформу. Мы работаем с любой. Для Android у нас парк из 20+ реальных устройств (Samsung, Pixel, Xiaomi, Huawei). Для iOS  — 10+ устройств (iPhone SE, 11, 12, 13, 14, iPad). Инженерная экспертиза мобильных приложений должна быть всеядной. 🦁