Разработка мобильных приложений в Ташкенте

Flutter даёт одну кодовую базу на iOS и Android, и экономия в нём реальна там, где интерфейс по обе стороны одинаков: каталог, формы, личный кабинет, история заказов. Нативная разработка — Swift и SwiftUI, Kotlin и Jetpack Compose — выигрывает, когда приложение живёт близко к железу: фоновая геолокация курьера, BLE и NFC на проходной, плотная работа с камерой, виджеты и Live Activities.

Честная оговорка, которую редко произносят вслух: Flutter не отменяет платформенный код, а локализует его. Payme Business, например, публикует SDK под Android — для iOS ту же логику приходится собирать поверх Merchant API самостоятельно. Это platform channel, две ветки тестирования и отдельный бюджет времени. Заложить их надо в оценку, а не обнаружить на третьей неделе.

Поэтому стек мы выбираем после того, как разложим требования на список системных API, а не наоборот.

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

Три системы — три разных протокола, и разница видна именно на бэкенде. Payme Business ходит на ваш сервер по JSON-RPC 2.0 и вызывает CheckPerformTransaction, CreateTransaction, PerformTransaction, CancelTransaction, CheckTransaction и GetStatement — транзакцию ведёт сервер, а не приложение. Click устроен иначе: двухэтапный сценарий Prepare и Complete в SHOP API либо Merchant API с привязкой карты и подтверждением по SMS. Uzum Checkout закрывает привязку карт, возвраты, статусы и фискализацию. Под всеми тремя лежат Uzcard и Humo, для зарубежных карт — Visa и Mastercard.

Инженерная часть, на которой чаще всего горит прод. Приложение не должно хранить номер карты: PAN уходит провайдеру, у вас остаётся токен. Обработчики платёжных колбэков обязаны быть идемпотентными — при таймауте платёжная система повторит запрос, и второй PerformTransaction не имеет права списать деньги дважды.

Отдельная история — чек. Онлайн-оплата в Узбекистане фискализируется: данные уходят оператору фискальных данных и в Налоговый комитет, а покупатель сверяет чек в приложении Soliq. Виртуальную кассу закладывают в архитектуру на старте, а не прикручивают после релиза.

Аккаунты оформляются на компанию, и это первый срок, который от нас не зависит. Apple требует номер D-U-N-S, зарегистрированный на юридическое лицо; Google Play привязывает платёжный профиль и сверяет юридическое название, адрес и тот же D-U-N-S. Для аккаунта физического лица в Узбекистане нужны государственный документ с фотографией и подтверждение адреса. С марта 2026 года верификация разработчиков Android распространена на всех, а на установку приложений она начнёт влиять с 30 сентября 2026 года в первых странах и дальше, глобально, — в 2027-м.

Технические пороги известны заранее, и мы планируем их как вехи. С 31 августа 2026 года новые приложения и обновления в Google Play собираются под Android 16 (API 36), уже опубликованные — минимум под API 35; отсрочку можно запросить до 1 ноября. Apple по пункту 5.1.1(v) не пропустит приложение с регистрацией, если удалить аккаунт нельзя изнутри приложения, а при входе через Sign in with Apple токен нужно отзывать через REST API.

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

Закон ЗРУ-1125 от 26 марта 2026 года смягчил локализацию, и это заметно упростило архитектуру. Обязательное хранение на территории Узбекистана осталось для биометрических и генетических данных, а также для данных абонентов операторов связи; такие базы подлежат регистрации в Государственном реестре баз персональных данных. Остальное разрешено обрабатывать за рубежом при соблюдении условий трансграничной передачи — от перечня стран с адекватным уровнем защиты до стандартных договорных условий.

Практический вывод для мобильного приложения. Вход по лицу или отпечатку через Face ID, Touch ID и BiometricPrompt не делает вас оператором биометрических данных: шаблон не покидает Secure Enclave или TEE, приложение получает только ответ «да» или «нет». А если проект действительно собирает биометрию — распознавание лиц на проходной, удалённая идентификация клиента, — меняются и юридический контур, и площадка размещения. Этот вопрос мы поднимаем до архитектуры, а не на приёмке.

Аккаунты App Store Connect и Google Play Console оформляются на ваше юридическое лицо и остаются вашими вместе с историей отзывов и рейтингом — переносить приложение между аккаунтами долго и болезненно, поэтому мы делаем правильно сразу. В Google Play действует Play App Signing: ключ подписи приложения хранит Google, ваш upload-ключ остаётся у вас. Для iOS сертификаты, профили и APNs-ключ .p8 живут в вашем аккаунте. Репозиторий, макеты и документация передаются вместе с проектом.

Обновления выкатываем поэтапно: staged rollout процентами в Google Play, phased release по дням в App Store. Если растёт доля падений, раскатка останавливается раньше, чем её заметит вся аудитория. Crashlytics или Sentry подключаем до релиза, а не после первой жалобы. Пуш-уведомления идут через APNs и FCM с одного бэкенда, чтобы сегменты и расписания не расходились между платформами.

• Исходный код, макеты и документация — по акту
• Аккаунты разработчика и ключи подписи — на вашу компанию
• Мониторинг падений и аналитика подключены до первого релиза