# Mobile app development in Tashkent

> Native iOS and Android apps and Flutter builds: App Store and Google Play release, Payme, Click and Uzum payments. Engineered in Tashkent.

Source: https://i7team.uz/en/services/mobile-development
Provider: i7 Team, Tashkent, Uzbekistan

We build mobile apps that reach the store and stay there: native in Swift and Kotlin, cross-platform in Flutter, with Payme, Click and Uzum payments, fiscal receipts and push notifications. i7 Team has worked in Tashkent since 2019 and takes the whole project — architecture, backend, app, App Store and Google Play release, and support once it is live.

## Flutter or native: decided before the first screen

Flutter gives you one codebase across iOS and Android, and the saving is real wherever the interface is the same on both sides: catalogues, forms, account areas, order history. Native development — Swift with SwiftUI, Kotlin with Jetpack Compose — wins when the app lives close to the hardware: background location for couriers, BLE and NFC at a door reader, heavy camera work, widgets and Live Activities.

The caveat nobody says out loud: Flutter does not remove platform code, it localises it. Payme Business, for instance, ships an Android SDK — on iOS the same logic has to be built over the Merchant API yourself. That means a platform channel, two test branches and a separate slice of the schedule. It belongs in the estimate, not in a discovery during week three.

So we choose the stack after breaking the requirements down into a list of system APIs, not the other way round.

- Flutter — when screens and logic match on both platforms and time to market matters
- Native — when background work, sensors, memory or system integrations are critical
- Hybrid — Flutter as the base plus native modules where nothing else will do

## Payme, Click and Uzum: payments and the fiscal receipt

Three providers, three different protocols, and the difference shows up on the backend. Payme Business calls your server over JSON-RPC 2.0 using CheckPerformTransaction, CreateTransaction, PerformTransaction, CancelTransaction, CheckTransaction and GetStatement — the server owns the transaction, not the app. Click works differently: a two-stage Prepare and Complete flow in the SHOP API, or the Merchant API with card binding and SMS confirmation. Uzum Checkout covers card binding, refunds, statuses and fiscalisation. Underneath all three sit Uzcard and Humo, with Visa and Mastercard for foreign cards.

The engineering detail that most often burns production: the app must never store a card number. The PAN goes to the provider and you keep a token. Payment callback handlers have to be idempotent — on a timeout the provider will retry, and a second PerformTransaction must not charge the customer twice.

Then there is the receipt. Online payments in Uzbekistan are fiscalised: the data goes to a fiscal data operator and on to the Tax Committee, and the customer checks the receipt in the Soliq app. A virtual till belongs in the architecture from day one, not bolted on after launch.

## Releasing on the App Store and Google Play: what actually moves the date

Developer accounts are registered to the company, and that is the first deadline outside our control. Apple requires a D-U-N-S number registered to the legal entity; Google Play links a payments profile and verifies the legal name, address and the same D-U-N-S. An individual account in Uzbekistan needs a government-issued photo ID and proof of address. Android developer verification was extended to all developers in March 2026, and it starts affecting how apps install from 30 September 2026 in the first markets, with global rollout through 2027.

The technical thresholds are known in advance and we plan them as milestones. From 31 August 2026, new apps and updates on Google Play must target Android 16 (API 36), while apps already published need at least API 35; an extension can be requested until 1 November. Apple will not pass an app with sign-up under guideline 5.1.1(v) unless the account can be deleted from inside the app, and if you offer Sign in with Apple the token must be revoked through the REST API.

Review itself is measured in days, but every rejection resets the queue. That is why we work through the review checklist before we cut the release build, not after the first refusal.

## Personal data: what changed on 27 March 2026

Law ZRU-1125 of 26 March 2026 relaxed data localisation, and it noticeably simplified architecture decisions. Mandatory storage inside Uzbekistan now applies to biometric and genetic data, and to subscriber data held by telecoms operators; those databases must be registered in the State Register of personal data bases. Everything else may be processed abroad provided the cross-border transfer conditions are met — an adequacy list of countries, standard contractual terms, or binding corporate rules.

The practical consequence for a mobile app is worth spelling out. Face or fingerprint login through Face ID, Touch ID and BiometricPrompt does not make you an operator of biometric data: the template never leaves the Secure Enclave or the TEE, and the app only receives a yes or a no. If a project genuinely collects biometrics — face recognition at a turnstile, remote customer identification — both the legal position and the hosting decision change. We raise that before the architecture is fixed, not at acceptance.

## What you are left holding after launch

App Store Connect and Google Play Console accounts are registered to your company and stay yours, along with the review history and the rating — moving an app between accounts is slow and painful, so we set it up correctly at the start. Google Play uses Play App Signing: Google holds the app signing key, and your upload key stays with you. On iOS, the certificates, profiles and the .p8 APNs key live in your account. The repository, design files and documentation are handed over with the project.

Updates go out gradually: staged rollout by percentage on Google Play, phased release by day on the App Store. If the crash rate climbs, the rollout stops before the whole audience notices. Crashlytics or Sentry is wired in before release, not after the first complaint. Push notifications run through APNs and FCM from a single backend so that segments and schedules cannot drift apart between platforms.

- Source code, design files and documentation handed over formally
- Developer accounts and signing keys registered to your company
- Crash monitoring and analytics live before the first release

## Common questions

### How long does it take to build a mobile app?

Four things set the timeline: the number of roles and screens, whether a backend already exists or has to be written from scratch, how many external systems connect (payments, 1C, CRM, warehouse), and whether you need an offline mode with synchronisation. On top of development sits the release tail: App Store and Google Play review is measured in days, but a rejection resets the queue, and issuing a D-U-N-S number is entirely outside our hands. We produce the schedule once requirements are gathered, and we tie it to milestones rather than to a promise of a month.

### What do you need from us to start?

A legal entity and a bank account — without them you cannot sign contracts with Payme, Click or Uzum, nor open corporate developer accounts. After that: access to your backend or accounting system, your logo and brand assets, real content in the languages you need, and a privacy policy reviewed by a lawyer, since Apple rejects apps without one under guideline 5.1.1(i). If something is missing we say so at the start and build it into the schedule.

### Is Flutter genuinely cheaper than native development?

At the start, usually yes, because the screens are written once. In maintenance the gap narrows. New versions of iOS and Android arrive every autumn, and you end up updating both the app and the framework with its dependencies. Flutter pays off when the app is mostly about data and interface. If the core of the project is background work, sensors, camera or battery behaviour, the native build is often the cheaper one by the second year.

### Who owns the code and the accounts?

You do. Source code, design files and documentation are handed over formally, App Store Connect and Google Play Console accounts are registered to your company, and the upload key and APNs key stay with you. We work in your repository or hand ours over in full. We do not use licensing arrangements that leave an app hostage to its contractor.

### What happens after launch?

An app is not a one-off delivery. The stores raise their target API requirements every year, operating systems update each autumn, payment providers change protocols, and certificates and keys expire. We keep crash monitoring running, ship updates for new platform versions and track the Google Play and Apple deadlines. The scope of support is agreed separately, from simply maintaining compatibility to developing the product properly.

### Can we take subscription payments inside the app?

It depends what you are selling. Physical goods, delivery and offline services go through Payme, Click or Uzum, which is exactly the scenario most companies in Tashkent need. Digital content and in-app subscriptions are a different matter: Apple requires them to be sold through In-App Purchase with its commission, and Google applies a comparable rule. That affects unit economics, so we work through the monetisation model before anyone starts drawing screens.

## Related services

- [Website and web platform development](https://i7team.uz/en/services/web-development)
- [Telegram bot and Mini App development](https://i7team.uz/en/services/telegram-bots)
- [Retail automation and NetPOS till systems in Tashkent](https://i7team.uz/en/services/pos-automation)

## Let's talk about your app

Tell us what the app has to do and which systems it connects to, and we will come back with a scope, a stack and a milestone schedule. Tashkent, +998 77 372 21 12, info@i7team.uz

Get in touch: info@i7team.uz · +998 77 372 21 12 · https://i7team.uz/en/contact