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

> Нативные и Flutter-приложения для iOS и Android: релиз в App Store и Google Play, оплата через Payme, Click и Uzum. Разработка в Ташкенте.

Источник: https://i7team.uz/uslugi/razrabotka-mobilnyh-prilozheniy
Поставщик: i7 Team, Ташкент, Узбекистан

Мы делаем мобильные приложения, которые доходят до магазина и остаются в нём: нативные на Swift и Kotlin, кроссплатформенные на Flutter — с оплатой через Payme, Click и Uzum, фискальным чеком и пуш-уведомлениями. i7 Team работает в Ташкенте с 2019 года и ведёт проект целиком: архитектура, бэкенд, приложение, релиз в App Store и Google Play, поддержка после запуска.

## Flutter или нативная разработка: решаем до первого экрана

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, Click и Uzum: оплата и фискальный чек

Три системы — три разных протокола, и разница видна именно на бэкенде. 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. Виртуальную кассу закладывают в архитектуру на старте, а не прикручивают после релиза.

## Релиз в App Store и Google Play: что действительно двигает дату

Аккаунты оформляются на компанию, и это первый срок, который от нас не зависит. 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.

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

## Персональные данные: что изменилось 27 марта 2026 года

Закон ЗРУ-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 с одного бэкенда, чтобы сегменты и расписания не расходились между платформами.

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

## Частые вопросы

### Сколько времени занимает разработка мобильного приложения?

Срок задают четыре вещи: число ролей и экранов, есть ли готовый бэкенд или его надо писать с нуля, сколько внешних систем подключается (платежи, 1С, CRM, склад) и нужен ли офлайн-режим с синхронизацией. К разработке добавляется релизный хвост: проверка в App Store и Google Play измеряется днями, но отказ обнуляет очередь, а выпуск номера D-U-N-S от нас не зависит вовсе. График мы даём после сбора требований и привязываем к вехам, а не к обещанию «за месяц».

### Что нужно с вашей стороны, чтобы начать?

Юридическое лицо и банковский счёт: без них не заключить договоры с Payme, Click и Uzum и не открыть корпоративные аккаунты разработчика. Дальше — доступ к вашему бэкенду или учётной системе, логотип и фирменный стиль, содержательный контент на нужных языках и политика конфиденциальности, согласованная юристом: без неё Apple отклоняет приложение по пункту 5.1.1(i). Если чего-то нет, мы говорим об этом на старте и учитываем в графике.

### Flutter действительно дешевле нативной разработки?

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

### Кому принадлежат код и аккаунты?

Вам. Исходный код, макеты и документация передаются по акту, аккаунты App Store Connect и Google Play Console оформляются на вашу компанию, upload-ключ и APNs-ключ хранятся у вас. Мы работаем в вашем репозитории или отдаём свой целиком. Лицензионных конструкций, при которых приложение остаётся заложником подрядчика, мы не используем.

### Что происходит после релиза?

Приложение — не разовая поставка. Магазины ежегодно поднимают требования к целевому API, операционные системы обновляются каждую осень, платёжные провайдеры меняют протоколы, а сертификаты и ключи имеют срок годности. Мы держим мониторинг падений, выпускаем обновления под новые версии платформ и следим за дедлайнами Google Play и Apple. Объём поддержки фиксируется отдельно — от «поддерживаем совместимость» до полноценного развития продукта.

### Можно ли принимать оплату за подписку прямо в приложении?

Зависит от того, что продаётся. Физические товары, доставка и офлайн-услуги проводятся через Payme, Click или Uzum — это ровно тот сценарий, который нужен большинству компаний в Ташкенте. Цифровой контент и подписки внутри приложения Apple требует продавать через In-App Purchase со своей комиссией, у Google действует сопоставимое правило. Это влияет на юнит-экономику, поэтому модель монетизации мы разбираем до того, как начнём рисовать экраны.

## Смежные услуги

- [Разработка сайтов и веб-платформ](https://i7team.uz/uslugi/veb-razrabotka-saytov)
- [Разработка Telegram-ботов и Mini Apps](https://i7team.uz/uslugi/razrabotka-telegram-botov)
- [Автоматизация торговли и кассовые решения NetPOS в Ташкенте](https://i7team.uz/uslugi/avtomatizaciya-torgovli-netpos)

## Обсудим ваше приложение

Расскажите, что должно уметь приложение и какие системы к нему подключаются, — вернёмся с составом работ, стеком и графиком по вехам. Ташкент, +998 77 372 21 12, info@i7team.uz

Связаться: info@i7team.uz · +998 77 372 21 12 · https://i7team.uz/contact