Нативное или кроссплатформенное мобильное приложение: как выбрать архитектуру по рабочим сценариям

Начните с результата сотрудника

В понедельник сотрудник заполняет заявку на телефоне, прикладывает фотографию и убирает устройство в карман. Связь пропадает. Когда он снова открывает приложение, возникает простой вопрос: заявка сохранена, отправляется или уже принята? Для выбора архитектуры этот вопрос полезнее спора о том, на каком языке нарисована кнопка.

Это сценарный пример, а не история проекта НТА. Он показывает, почему одинаковые экраны ещё не означают одинаковую работу. Экран описывает видимую часть. Рабочая операция включает локальное сохранение, доступ к устройству, обмен с сервером, переход в фон и возвращение пользователя. Каждый переход способен изменить условия исполнения, даже если интерфейс выглядит прежним.

ИТ-директору стоит начать с трёх обязательных сценариев. Три — удобный масштаб первой встречи, а не технический норматив. Для каждого нужно записать начало, ожидаемый результат и допустимое поведение при исключении. «Создать заявку» недостаточно. «Сохранить заполненную заявку без сети, показать её после повторного открытия и позднее получить подтверждение сервера» уже позволяет составить проверку.

Затем отделите обязательное от желательного. Если сотрудник может завершить операцию только при открытом приложении, это одно требование. Если процесс зависит от фонового выполнения без участия пользователя, это другое. Если нужен результат строго к определённой секунде, нужно сначала проверить допустимость самого требования на целевой ОС. Переписывание интерфейса не добавляет приложению полномочий, которых платформа ему не даёт.

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

Наше правило выбора таково: сначала исключить варианты, которые не выполняют обязательные сценарии, затем сравнить сопровождение оставшихся. Это редакционная методика принятия решения, а не доказанная универсальная формула минимальной стоимости. Её преимущество логическое: низкая цена неподходящего варианта не делает рабочую операцию выполнимой.

Три варианта вместо спора о двух ярлыках

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

Первый вариант — отдельные нативные клиенты. Команда Android и команда iOS реализуют свои экраны и обращения к ОС. Общими могут оставаться требования, сервер, форматы данных и проверочные примеры. Совпадающее бизнес-правило приходится согласованно отражать в двух реализациях, зато платформенная интеграция не требует дополнительного общего интерфейса лишь ради повторного использования.

Это разумный кандидат, если значимая часть продукта связана с различающимися возможностями ОС или если организация уже умеет сопровождать соответствующие клиенты. Но отдельные реализации тоже требуют обновления зависимостей, проверки разрешений и приёмки. «Нативно» не означает «совместимо навсегда» и не доказывает отсутствие ошибок.

Второй вариант — общий интерфейс и логика с платформенными расширениями. React Native и Flutter позволяют строить такое решение, но их устройство различается. React Native описывает компоненты, связанные с нативными представлениями. Flutter объясняет собственный механизм отрисовки и встраивание в платформу. Поэтому ставить им общий знак равенства по скорости, поведению элементов или сложности интеграции нельзя.

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

Третий вариант — общая бизнес-логика и нативные экраны. Он полезен как отдельный кандидат, когда правила и данные совпадают, а пользовательское поведение существенно различается. Kotlin Multiplatform прямо предусматривает разделение логики с сохранением нативного интерфейса. Возможность такого разделения не обязывает выбрать именно этот инструмент: сначала нужна сама граница ответственности.

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

×

Схема НТА по документации React Native, Flutter и Kotlin Multiplatform. Одинаковый цвет означает общие исходники, включаемые в отдельные сборки; размеры блоков не показывают долю кода или трудозатрат.

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

Фон: кто управляет временем исполнения

Фоновую работу легко записать одним пунктом и дорого неправильно понять. Продолжить начатую отправку, периодически обновить данные, реагировать на событие и непрерывно выполнять задачу — разные требования. Их нельзя подтвердить одним испытанием «свернули приложение, оно ещё работало».

В обзоре Android выбор механизма связан с типом работы и жизненным циклом. Асинхронная операция внутри приложения не тождественна устойчивой фоновой задаче. Для многих случаев предусмотрен WorkManager; выбор конкретного API всё равно зависит от сценария. Отсюда узкий вывод: наличие общего языка или библиотеки не заменяет выбор платформенного механизма.

На iOS Apple разделяет стратегии фонового выполнения. Продолжение работы после ухода с экрана получает ограниченное время; отложенную работу планирует система. Приложение должно учитывать завершение выделенного времени. Это не обещание, что любая операция запустится в заданный бизнесом момент.

Предположим, заявка должна уйти после блокировки телефона. Сначала уточните, допустима ли отложенная отправка и что должен видеть сотрудник до подтверждения. Если задержка допустима, прототип проверяет сохранение работы и восстановление отправки. Если задержка недопустима, проверяется доступный механизм для точного сценария; результатом может оказаться необходимость изменить процесс, а не победа одного фреймворка.

В протоколе полезно различать блокировку, уход в другое приложение, завершение процесса системой и принудительное закрытие пользователем. Не объединяйте их в одну строку «фон работает». Условия испытания и обещание пользователю должны совпадать. Также нельзя переносить успешный запуск на одном устройстве на весь парк без проверки выбранных версий и настроек.

Если общий модуль передаёт работу нативному API, проверка должна доходить до результата этого API. Если нативный прототип не удовлетворяет тому же требованию, общий вариант не является первопричиной ограничения. В таком случае ИТ-директору нужен согласованный допустимый сценарий: например, завершение действия при открытом приложении или явное ожидание подтверждения. Решение об изменении обязательного условия принимает владелец процесса.

Автономность: где заканчивается сохранение

«Работает без интернета» может означать чтение последнего справочника, создание черновика или полноценное редактирование с последующим согласованием. Эти возможности различаются по последствиям. Просмотр старой записи не равен возможности безопасно принять новое обязательство, пока сервер недоступен.

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

Возьмём сценарий заявки. Сотрудник записал данные локально, затем связь появилась, но ответ на отправку не дошёл. По одному отсутствию ответа нельзя понять, не принял ли сервер заявку. Здесь нужны понятные состояния и договорённость о повторе. Подробный разбор этого механизма есть в статье НТА об ошибках, повторах и идемпотентности API.

Для мобильного решения важно определить, какая часть отвечает за каждый переход. Общая логика может описывать состояние заявки и правила повторной попытки. Платформенная часть может отвечать за местное хранилище и допустимый запуск работы. Сервер остаётся участником подтверждения. Такая граница — вариант проектирования, а не обещание, что выбранная библиотека реализует всё перечисленное автоматически.

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

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

Автономность сама по себе не аргумент за обязательный отказ от общего кода. Она аргумент за явную модель хранения и согласования, реализуемую обоими сравниваемыми вариантами. Если команда оценила только локальную форму, сравнение архитектур ещё не состоялось.

Устройство и системные интеграции

Камера, уведомления, геолокация, сканер, защищённое хранение и корпоративный вход часто оказываются за короткой строкой «интеграция с устройством». Для оценки нужно раскрыть каждую действительно нужную зависимость: поставщик, поддерживаемые версии, платформенный API, способ подключения и ответственный за обновление.

React Native предоставляет нативные модули и компоненты, в том числе для возможностей, которых нет в основной поставке или подходящей библиотеке. Документация отдельно отмечает переход от старых API к новым. Поэтому запись «библиотека существует» недостаточна: нужно проверить её совместимость именно с выбранной сборкой и способом интеграции.

У Flutter каналы платформы позволяют общей части обмениваться сообщениями с кодом целевой ОС. Это объясняет механизм расширения, но не устраняет работу на обеих сторонах границы. Нужно определить вход, результат, ошибки, отмену и поведение при изменении состояния приложения.

Рассмотрим фотографию для заявки. Успешный снимок — лишь один исход. Пользователь может отказать в разрешении, позже изменить решение, прервать действие или вернуться в приложение после паузы. Android рекомендует учитывать запрос разрешения и отказ. Конкретная проверка должна показывать, сохраняется ли заявка и понимает ли сотрудник следующий шаг без фотографии.

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

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

Контракт такой границы полезно оформлять столь же точно, как внешнюю интеграцию: обязательные данные, ошибки и совместимые изменения. Это не превращает мобильный адаптер в HTTP-сервис. Переносится дисциплина описания поведения, а не конкретный транспорт.

Интерфейс и скорость: проверять действие целиком

Одинаковый внешний вид не гарантирует одинаковую управляемость. Важны возврат назад, появление клавиатуры, увеличение текста, фокус, чтение экранным диктором, системные окна и восстановление незавершённой формы. Эти условия надо включить в сценарий, если они влияют на работу целевых сотрудников.

Контрольный список Flutter по доступности предусматривает проверки с TalkBack и VoiceOver. Наличие соответствующих возможностей не делает произвольный экран доступным автоматически. В прототипе сотрудник должен пройти законченное действие: найти поле, понять ошибку, исправить ввод и получить результат. Скриншот удачного состояния не отвечает на эти вопросы.

Из этого следует ограниченная рекомендация: при сравнении общего и нативного интерфейса оценивать один и тот же путь на обеих ОС. Нативный элемент тоже можно неправильно назвать или включить в неудобный порядок фокуса. Общий интерфейс тоже может пройти проверку. Решение определяется наблюдаемым поведением выбранной реализации.

С производительностью действует тот же принцип. Flutter рекомендует измерять её на физическом устройстве в режиме профилирования, обращая внимание на слабые целевые устройства. Отладочная сборка и эмулятор могут давать непредставительный результат. Это основание для методики измерения, а не доказательство превосходства Flutter над альтернативами.

До прототипа определите, что именно измеряется: запуск до готовности формы, отклик на ввод, прокрутка нужного объёма данных или завершение операции. Если время включает сетевой ответ, отдельно наблюдайте сеть и сервер. Иначе медленный внешний сервис легко будет ошибочно записан в недостатки мобильного стека.

Порог приемлемости должен исходить из задачи организации. Универсальное число из чужого теста не заменяет требования к вашим устройствам и данным. Для повторяемости сохраняйте режим сборки, версии, набор данных, условия сети и несколько повторов. В этой статье таких испытаний нет, поэтому ни один вариант не получает вымышленной оценки скорости или расхода батареи.

Установка в России входит в архитектуру

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

Для Android российский RuStore описывает публикацию APK и AAB. Для обновлений важны соответствие пакета и подписи предыдущей версии. Это конкретный канал, который можно включить в проектную проверку. Наличие документации не означает автоматическую модерацию приложения и не доказывает работоспособность его сторонних сервисов на устройствах сотрудников.

Для iOS нельзя обещать российскому пользователю альтернативный магазин только потому, что такой способ появился в других странах. Apple описывает региональную доступность альтернативной дистрибуции; Россия в перечисленных доступных регионах на дату проверки, 14 сентября 2026 года, отсутствует. Следовательно, этот путь нельзя считать подтверждённым для обычного российского сценария. Материал не предлагает обходить ограничения аккаунта или местоположения.

У Apple Developer Enterprise Program есть условия: внутреннее использование сотрудниками, требования к организации и проверка допуска. Описание программы не подтверждает, что конкретное российское юридическое лицо сможет вступить в неё или продлить участие. Это проверяется непосредственно для организации; в бюджет нельзя включать предположение как готовый канал.

Другой описанный Apple вариант — распространение приложения по прямой ссылке без включения в поиск магазина. Он требует рассмотрения приложения и не ограничивает скачивание только сотрудниками: ссылку может получить посторонний. Значит, доступ к корпоративным данным должен проверяться внутри приложения и серверного контура. Прямая ссылка не заменяет авторизацию.

Практический результат этого раздела — подтверждённый маршрут для каждой платформы: аккаунт организации, право использования канала, целевые пользователи, установка, обновление и ответственный. Здесь проверены публичные условия, а не аккаунт читателя. Если маршрут iOS не подтверждён, решение о поставке iOS пока не обосновано ни для нативного, ни для общего варианта.

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

Стоимость владения без магического процента

Доля общего кода — характеристика реализации, а не готовая скидка. Для бюджета важно, какие работы повторяются, какие исчезают и какие появляются на границе платформ. Одинаковое число исходных строк может иметь разную стоимость проверки и изменения.

Предлагаем считать стоимость за один согласованный горизонт. В состав входят первоначальная разработка, платформенные расширения, испытания на целевом парке, выпуск и обновления, сопровождение зависимостей, диагностика, поддержка сотрудников и передача знаний. Это структура собственной методики НТА; она не содержит рыночных тарифов или универсальных коэффициентов.

Не сравнивайте полную оценку нативных клиентов с оценкой только общих экранов. В обеих колонках должны быть одинаковые функции, исключения, критерии приёмки и обязанности после запуска. Общие работы сервера учитывайте последовательно: либо в обоих вариантах, либо отдельно, если их объём действительно одинаков. Иначе итог изменится из-за состава сметы, а не архитектуры.

Полезен опыт с небольшим изменением после первого работающего сценария. Например, добавить обязательное поле, изменить правило проверки и сохранить совместимость с существующими данными. Для отдельной реализации оценить обе платформенные правки; для общей — изменение общего правила, подключение в сборки и обе приёмки. Цель не получить эффектную демонстрацию, а увидеть реальный состав работы команды.

Такой опыт не предсказывает весь срок владения. Он даёт ограниченное наблюдение о выбранном классе изменений. Если будущая работа главным образом связана с новыми возможностями ОС, одна правка бизнес-правила не представляет весь продукт. В оценке нужно разделить классы изменений и записать, какие из них проверялись, а какие пока оценены экспертно.

Отдельно проверьте компетенции. Общая кодовая база не отменяет необходимости разбираться в Android и iOS при диагностике платформенного отказа. Два нативных клиента не гарантируют наличие двух устойчивых команд. Если оценка держится на одном специалисте, это должно быть видно в составе поддержки, доступе к сборке и плане передачи знаний.

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

В договорной оценке отдельно обозначьте владение исходниками платформенных расширений и возможность повторить сборку. Если организация оплачивает общий модуль, но не может самостоятельно собрать iOS-часть, это существенная характеристика поставки. Она не доказывает ошибочность архитектуры, однако меняет состав услуг, которые придётся покупать у исполнителя. Аналогичный вопрос возникает и у полностью нативного решения.

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

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

Как устроить сравнительный прототип

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

Выберите два наиболее правдоподобных варианта из трёх архитектурных подходов. Не нужно автоматически строить полные приложения на всех инструментах. Для каждого варианта реализуется один и тот же ограниченный, но законченный сценарий с одинаковыми исключениями. Различия в функциональности записываются явно, иначе сравнение невозможно интерпретировать.

До начала работы оформите карточку опыта: сценарий, устройство и ОС, исходное состояние, действие, ожидаемый результат, способ наблюдения и условие отказа. Если критерий относится к серверу, нужно проверять серверное состояние. Если к сохранению на телефоне — повторное открытие данных. Если к доступности — прохождение действия соответствующим способом управления.

Затем разделите обязательные ограничения и предпочтения. Потеря локальной заявки может быть основанием исключить вариант; более приятная анимация — предпочтением между прошедшими вариантами. Не складывайте их в непрозрачный общий балл: высокий балл оформления не компенсирует невыполненную обязательную операцию.

×

Сценарная методика НТА. Указаны предметы проверки, а не результаты испытаний. Ограничения фоновой работы основаны на документации Android и Apple; критерий приемлемости задаёт организация.

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

Продолжением успешного прототипа становится ограниченный пилот на подтверждённой группе устройств. В его границах проверяют уже не только технологическую возможность, но и понятность эксплуатации: сотрудник умеет установить версию, распознаёт ожидающую отправки заявку и знает, кому сообщить об ошибке. Это разные вопросы, поэтому удачный технический опыт не нужно объявлять завершённым внедрением.

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

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

Наконец, запишите события пересмотра решения: смена обязательного устройства, появление нового системного комплекта разработчика, изменение канала поставки или существенное расхождение интерфейсов. Тогда архитектура остаётся проверяемой договорённостью. Её не приходится защищать как однажды выбранную идеологию, когда изменился сам рабочий сценарий.

Если оба варианта проходят обязательные условия, выбор переходит к сопровождению и компетенциям. Если один проходит, а другой требует существенной платформенной доработки, стоимость этой доработки входит в сравнение до решения. Если оба не проходят, владелец процесса рассматривает изменение требования или другой способ работы. Не нужно объявлять проигравшим общий код, когда ограничение задаёт сама платформа.

Матрица решения для ИТ-директора

Ниже — образец для обсуждения, а не заполненный протокол мобильного пилота. Формулировки решения условные. В рабочем документе к каждой строке добавляются конкретные версии, ссылка на доказательство, владелец и дата пересмотра.

Матрица не выбирает технологию автоматически. Она делает основания решения видимыми. Для каждой строки руководитель может спросить, кто подтвердил результат, при каких условиях он сохранится и что потребует повторного рассмотрения. Без этих ответов таблица остаётся перечнем намерений.

Тест понедельником

На ближайшей встрече отложите названия инструментов и выберите три обязательных действия сотрудника. Для одного из них запишите условие, которое обычно выпадает из демонстрации: погашенный экран, потерянная связь или отказ разрешения. Затем сформулируйте, какой результат сотрудник вправе считать завершённым.

Попросите команду предложить два варианта реализации именно этой строки. В каждом должны быть названы общая часть, часть ОС, способ установки и человек, который сможет сопровождать интеграцию. Согласуйте одинаковую проверку и условие, при котором вариант исключается. Только после этого сравнивайте оценку работ.

Если требуется участие НТА, предметом первого обсуждения могут стать эти сценарии, граница общего кода и критерии прототипа. Полезный результат начинается с проверяемого решения, которое организация сможет принять независимо от симпатий к фреймворку. Будущее должно выдержать понедельник — в том числе с погашенным экраном.

Важное уведомление

Материал носит информационный характер и не является индивидуальной консультацией, проектной документацией, инструкцией по внедрению или гарантией результата. Применимость описанных подходов зависит от процессов, систем, данных, требований безопасности и иных условий конкретной организации. Перед внедрением или изменением ИТ‑систем необходимо самостоятельно оценить риски и привлечь профильных специалистов.