Заказчик хочет мобильное приложение и почти всегда хочет его сразу под две платформы. iPhone взяли руководители и продавцы, Android растёт у массового пользователя и в корпоративных закупках. Делать две независимые команды, два кодовых дерева и два графика релизов – значит платить дважды за один продукт. Ниже разбираем, как выпустить приложение под iOS и Android, не дублируя работу там, где дублировать не нужно.
Что дублируется, а что нет
Мобильное приложение состоит из трёх слоёв, и стоимость дублирования у них разная. Интерфейс дублировать придётся: Objective-C и Cocoa Touch на iPhone, Java и Android SDK на Android – это разные миры, и попытка сделать «один экран на обе ОС» через ранние кросс-платформенные обёртки даёт вялый отклик и чужой вид. Пользователь это чувствует сразу.
А вот бизнес-логику и работу с данными дублировать не нужно и вредно. Правила расчётов, валидация, формат заявки, протокол обмена с сервером – это одно и то же на обеих платформах. Расхождение здесь означает два набора багов вместо одного.
Практический вывод: рисуем границу. Нативный UI под каждую ОС – отдельно. Логика и сетевой слой – общие по спецификации, продублированные минимально и проверяемые одними и теми же тестовыми сценариями. На Android части ядра можно вынести в C/C++ через NDK и переиспользовать тот же код, что и в iOS-сборке; решать стоит по объёму вычислений, а не из принципа.
Бэкенд решает за две платформы сразу
Самый дешёвый способ не дублировать – перенести максимум в серверный API. Клиент тонкий: показывает данные и отправляет действия, а считает, валидирует и хранит сервер. Тогда новая бизнес-логика выкатывается один раз на бэкенде и работает на обоих телефонах без релиза в магазинах. Это особенно важно для госсектора, где цикл согласований длинный, а правила меняются приказом.
Под мобильный трафик нужен нормальный бэкенд: единый REST/JSON-контракт, версионирование API, кэширование и работа в офлайне. Для отчётов и аналитики его удобно стыковать с уже накопленными данными – мы об этом писали в материалах про аналитику поверх больших данных и про запуск Hadoop-кластера в продакшене. Мобильный клиент становится ещё одной витриной над теми же данными, а не отдельной системой со своей правдой.
Безопасность – общий слой, а не довесок
Две платформы делят один периметр: канал, авторизацию, хранение токенов на устройстве. Свежий взлом Sony PlayStation Network напомнил, чем оборачивается слабая защита учётных данных и хранение лишнего. Для корпоративных и государственных приложений это база, а не опция.
Поэтому шифруем канал по TLS, не складываем пароли в открытом виде в локальное хранилище, проектируем отзыв доступа на стороне сервера и логируем действия централизованно. Решение принимается один раз на уровне архитектуры и одинаково применяется на iOS и Android – это ещё один пласт, который не нужно изобретать дважды.
Вывод
Дублирование в мобильной разработке – это не «две платформы», а две команды, пишущие одно и то же без общего плана. Разделите слои честно: нативный интерфейс под каждую ОС, общая логика по единой спецификации, тяжёлая работа и безопасность на сервере. Тогда вторая платформа стоит не вдвое дороже, а заметно дешевле первой. Именно так устроена мобильная разработка для бизнеса и госсектора: от контракта API до релиза в обоих магазинах.
