A mobile app for iOS and Android is more than the screens on a phone: the project also covers the backend, the database, an admin panel, integrations with your company systems and developer accounts in two stores. The work runs through eight stages, from analysis to post-launch support. The budget is driven by the feature list, the number of integrations and the rules set by Apple and Google — not by the screen count.
Key takeaways
A finished product has five parts, and users see only one of them. The rest decide whether the app holds up under load and whether your team can run it without a developer.
| Part of the product | What it does | Who works with it |
|---|---|---|
| Phone client | Screens, navigation, forms, behaviour on a weak connection, calls to the server | Customer or employee |
| Backend and API | Stores data, calculates orders, checks access rights, connects the app to external services | Company systems |
| Database | Users, orders, payments, documents, action history | Engineering and analytics |
| Admin panel | Catalogue, prices, orders, users, messaging, reports | Your employees |
| Store accounts | Store listing, releases, install statistics, payouts | Product owner |
The server side is the most underestimated line in an estimate: speed, security and the link to your CRM all depend on it. How it works and which API methods an app needs is covered in the article on the backend and API for a mobile app.
There are two options: build two separate apps — Kotlin for Android and Swift for iOS — or assemble both versions from a single codebase with Flutter, React Native or Kotlin Multiplatform.
| Comparison point | Native development | Cross-platform development |
|---|---|---|
| Codebase | Two separate ones | One shared codebase plus a platform layer |
| Access to camera, sensors and NFC | Direct | Through a ready plugin or your own native module |
| Changes after launch | Made twice | Ship to both platforms at once |
If the app mostly works with screens and data, cross-platform wins; if it constantly talks to the camera, sensors and radio modules, go native. The full comparison, with selection criteria and a breakdown of the frameworks, is in the article “Native or cross-platform development”.
Which platform to start with depends on the devices your paying customers use. According to StatCounter data for August 2026, Android accounted for about 83% of mobile web page views in Uzbekistan and iOS for about 17%. That is a share of traffic rather than a device count, but the gap is clear: for many products it makes sense to launch on Android first.
A project runs through eight stages, and each one produces a result the client can review and accept.
Design is separate work with its own rules: touch targets, gestures, onboarding and permission prompts are covered in the article on UX/UI design for a mobile app.
The stores require a build made with current SDKs, completed declarations about the data you collect, a way to delete an account and functionality beyond a repackaged website. That belongs in the specification rather than in a checklist at the end of the project: these rules shape the architecture, the design and the estimate.
Important Since 28 April 2026 App Store Connect has accepted only builds made with Xcode 26 and the iOS 26 SDK. Since 31 August 2026 new apps and updates on Google Play must target Android 16 (API 36), while already published apps must target at least Android 15 (API 35) or they stay invisible to new users on newer Android versions. If you need more time, an extension can be requested until 1 November 2026.
Developer accounts, closed testing, review times and rejection reasons are covered in the article “How to publish an app on the App Store and Google Play”.
A first version usually holds sign-in by phone number, a catalogue, an order with online payment, a personal account and notifications. The set is assembled from scenarios rather than from a catalogue of possibilities: every feature answers the question of what a person does in the app and why they come back.
Everything else waits for the second version. The fewer features in the first release, the sooner you see whether people use the app or install it and forget it.
The app is wired to company systems through APIs: data flows both ways, and employees keep working in the tools they already know.
If you run several systems that are not connected to each other, set up the data exchange before the app reaches the stores. Otherwise the app becomes one more source of scattered data that somebody has to reconcile by hand.
The cost comes from the scope of features, the number of integrations, data requirements and what the company already has in place. An estimate is more accurate when the inputs are gathered in advance.
Development is only the first payment. After that the app lives by store rules, and the fees are the same whichever development approach you choose.
On top of the fees come the server and backups, updates for new iOS and Android versions, changes after user feedback and work with store reviews. Plan these costs a year ahead instead of paying for them as they appear.
An app is not needed where customers come to you once: nobody installs software for a single purchase. It pays off when people come back regularly — they order food, book a slot, track a delivery, spend loyalty points.
The second test is installation. An app has to be found, downloaded, granted permissions and not deleted a week later. For one-off tasks — event registration, bookings, requests, repair status — a cabinet inside Telegram or on the website is cheaper: no installation and no store fees.
We build a bot for requests and bookings from $1,200. Compare that option with an app before you approve a budget: often it covers the task in full, and the app becomes the next step.
At Syntra Systems we start with analysis and a specification with acceptance criteria, not with assembling screens. From there one team carries the project: design, client side, backend, integrations with CRM and payment systems, publishing in both stores and support after launch.
Our portfolio includes mobile products. For QADAM we created the brand identity, the interface and the architecture of an express delivery app, and described every state and colour in an interactive brand book of 14 sections. For KruchuVerchu we built the design system and more than 30 screens of a delivery app for iOS: storefront, dish configurator, cart, payment and courier tracking.
Let’s discuss your project
Tell us what you need, and we will estimate the timeline and cost and suggest a solution.
Yes, and many products do. Pick the first platform by the devices your paying customers use: check website analytics, order data and ad reports. Add the second version once the first one has confirmed demand.
Through an API, in both directions: registration in the app creates a contact in the CRM, a request creates a deal, and stock and prices come from the accounting system. If there are several disconnected systems, the exchange is set up before launch, or the app just becomes another data source that has to be reconciled by hand.
The company that owns the product. The account defines who owns the app, who receives payouts, who sees the statistics and who can ship updates. If the account belongs to a contractor, the business depends on them for every release.
An app makes sense when customers return regularly and you need push notifications, usable behaviour on a weak connection, or access to the camera and location. For one-off visits a mobile website is usually enough.
Store fees — $99 a year for Apple and a one-off $25 for Google — plus a server with backups, updates for new iOS and Android versions, and handling reviews. Updates are mandatory: since 31 August 2026 Google Play only accepts new versions targeting Android 16 (API 36).
Sources
