For most businesses in 2026, the right build is one cross-platform codebase shipped to both stores, published under your own developer accounts, at roughly 12–20 weeks and a five-figure budget that your scope — not your vendor's hourly rate — decides. Fully native iOS and Android is the exception, and there are specific tests for when it flips. The money most founders lose is not in the build: it is in the accounts, the store gates, the ownership terms and the yearly platform requirements that keep an app publishable.
Short version: Choose the build route on feature ceiling and hiring pool, not on today's price. Scope version one ruthlessly. Open your Apple and Google developer accounts in week one, in your company's name. Get code, design files, the Play signing arrangement and the store accounts in writing before you sign. Then budget for the fact that Apple and Google each force a rebuild roughly once a year.
Four ways to build the same app, and what each one commits you to
This is usually framed as native versus cross-platform. There are four real routes, plus an honest fifth. Cost bands are ranges reported across industry guides — directionally consistent, but every source is a vendor, including us. Use them to orient, not to budget.
| Route | v1 cost band | v1 timeline | Codebases | Device features | Who can take it over | Store distribution | When it's right | Risk you accept |
|---|---|---|---|---|---|---|---|---|
| Fully native — Swift + Kotlin | $45k–$150k+ | 18–30 weeks | Two | Everything, from day one of a new OS | Two hiring pools, highest rates | Yes | Real-time graphics, on-device ML, day-one OS features, watch/CarPlay | Two apps to fund forever; every feature built twice |
| React Native / Expo | $25k–$80k | 12–20 weeks | One (+ small native modules) | Nearly all, via libraries; new APIs lag weeks | Largest pool — any React team | Yes | Most business apps: booking, commerce, services, field ops, internal tools | Dependency churn — the New Architecture is now default and v0.82 is New-Architecture-only |
| Flutter | $25k–$80k | 12–20 weeks | One | Nearly all, via plugins; same lag | Smaller pool; Dart is a hiring constraint in some cities | Yes | Design-led apps wanting identical UI and custom motion on both | UI is drawn, not native — it can drift from platform conventions |
| Kotlin Multiplatform | $40k–$120k | 16–26 weeks | Shared core, two UIs | Everything — UI is genuinely native | Needs Kotlin plus iOS together; smallest pool | Yes | You have an Android team, real shared logic, and both sides must feel native | Highest coordination cost; hardest to re-staff |
| Responsive web app / PWA | $8k–$35k | 6–12 weeks | One | Camera and location yes; background, deep biometrics, widgets, watch effectively no on iOS | Any web team | No — and a thin wrapper is often rejected as too little value | Content, dashboards, forms, one-off transactions, search-discovered use | No store presence, weaker push, no app-shell habit |
The fifth row deserves a real minute. If nobody would keep your app on their home screen and open it monthly, a fast responsive site usually beats a mediocre app: less money, sooner, findable in search, and no annual rebuild to stay alive. We would rather say that at the quoting stage than nine months in.
The tests that genuinely flip you to native
- Sustained real-time graphics — AR, games, live video effects — not just animation.
- Heavy on-device processing: continuous camera analysis, on-device ML, large media encoding.
- Day-one support for a capability announced at WWDC or Google I/O, not support in three months.
- Watch apps, complex widgets, CarPlay or Android Auto as core product, not garnish.
- Background behavior is the product: continuous location, VoIP, health sync.
If none apply, cross-platform is the default and the burden of proof sits with anyone quoting two native codebases.
Should you build for iOS or Android first?
Answer with where your customers are, not folklore about iOS users spending more. StatCounter's June 2026 figures put global share at roughly 69% Android and 31% iOS, but the US inverts to about 58% iOS, and India is around 93% Android. The two platforms together are over 99% of devices, so there is no third option.
For most businesses in 2026 the honest answer is both, from one codebase. On a cross-platform build the second platform typically adds 10–20% — device testing and store work, not a second build. Sequencing platforms made sense when you were writing two native apps.
What does a custom Android and iOS app cost in 2026?
Ranges reported across industry guides: a simple utility app roughly $15k–$25k; a moderate business app with accounts, backend and payments roughly $25k–$60k; a complex multi-role platform $60k–$300k and up. Blended rates run about $15–50/hour in South Asia, $35–120 in Eastern Europe, $80–220 in the US. Rate does not predict total cost — a $20/hour team that needs three attempts at your payments flow costs more than a $60/hour team that gets it right once. Scope decides your band.
The eight questions that place you in a band
- How many user roles? Customer plus provider plus admin is three products sharing a database, and roughly doubles design and QA.
- Does a backend already exist? Working APIs can save 30–40%. Building one is often 30–50% of the total and invisible on screen.
- Do you take money in-app? Card payments are one job; subscriptions with trials, upgrades, refunds and receipt validation on both stores are a much bigger one.
- Anything real-time? Chat and live tracking demo in a week and take months to make reliable.
- Offline? Offline read is manageable. Offline write with sync and conflict resolution is among the most expensive things you can ask for.
- How many integrations? Each ERP, CRM, payment or mapping integration brings its own auth, sandbox, error handling and support load.
- How custom is the design? Platform patterns are fastest. Note that adaptive layout is now mandatory work on Android, not polish.
- What compliance applies? Health, finance and children's data change architecture, not just paperwork.
Answer those honestly and you can predict your own quote within about 30%. Our software development cost guide goes deeper, and an instant project estimate prices your actual scope rather than an average.
How long it takes, including the parts nobody quotes
Typical phases: discovery 2–4 weeks, design 3–6, build 6–16, QA and real-device testing 2–4, submission and review 1–3. Add those up and a well-scoped v1 lands around 14–24 weeks end to end, with the phases overlapping rather than running strictly back to back. Two items sit outside those phases and cause nearly every late slip. Developer account provisioning must start in week one, because both an Apple Developer Program organization account and a Google Play organization account need a D-U-N-S number and that can take several weeks in some regions. And first submissions are commonly rejected at least once — budget the round rather than hoping.
What belongs in version one
Scope is a bigger lever than platform choice. The test we use: list every feature you can imagine, then ask of each, "does the app fail at its core job without this?" If the honest answer is no, it is a version-two feature. Same discipline as our MVP development guide.
The features that always look cheap and never are: in-app chat, offline sync, segmented push, an admin dashboard (a second product), multi-language (it touches every string), and in-app purchases. Any one can add 20–40% to a small build.
The publishing layer nobody quotes for
- Apple Developer Program: US$99 per year; nonprofits, educational institutions and government entities may qualify for a fee waiver.
- Google Play: a one-time US$25 registration, no renewal.
- D-U-N-S number: required for a Play organization account. Supplying it at account creation can trigger automatic verification and skip a manual step. It is admin, not engineering, and it gates everything — start it first.
- The 12-testers rule: personal Play accounts created after 13 November 2023 must run a closed test with at least 12 opted-in testers continuously for 14 days before applying for production access. Google says that review "usually takes 7 days or less, but may occasionally take longer" — it is not a committed turnaround, so do not build a launch date on it. "Opted in" means they accepted and installed. That is two to three weeks between code-complete and live, at best. Confirm your account type in Play Console rather than assuming an exemption.
- Review time: Apple's published figure is that, on average, 90% of submissions are reviewed in less than 24 hours; in practice updates clear in 24–48 hours and first-time apps commonly take 2–5 days.
- Declarations: DSA trader details verified in App Store Connect, Google Play Data safety answers matching every SDK in the build, and — since 1 May 2024 — Apple privacy manifests with required-reason API declarations and valid signatures for listed third-party SDKs. Non-compliant uploads are rejected outright.
Who owns the app when it is finished?
"Confirm ownership in writing" is the standard advice and it is not enough, because source code alone will not let you ship an update. Six things must be yours:
- The developer accounts. Both should be opened in your company's name — not the agency's, and not an employee's personal one. No store rule forces this for a bespoke build, so nobody will stop you getting it wrong; the force is commercial. Ratings, reviews, subscribers and the right to ship an update all follow whoever holds the account. This is the biggest lock-in risk in the transaction.
- The Play app signing arrangement and control of the upload key. Without it, holding the repo does not let you publish.
- The source repository, in your organization from day one — not transferred at handover, which is when disputes happen.
- Design source files, not exported screens.
- Backend, hosting, DNS and domain accounts in your name, with your billing.
- Third-party accounts — analytics, crash reporting, payments, push — under your email domain.
Transfers are possible but conditional: Apple requires at least one released version, both accounts in good standing, no active pre-order, and acceptance within 60 days. Google charges nothing for the transfer, though a new target account still pays the US$25 registration. Starting correctly is far cheaper. Our guide to choosing a development partner covers raising this pre-contract, and live products say more about a team than any deck.
The recurring platform calendar
A mobile app is not a one-time purchase. Both platforms ratchet requirements roughly annually, and an app that is not rebuilt eventually cannot be updated at all.
| What changes | Deadline | Applies to | If ignored | Effort |
|---|---|---|---|---|
| Apple SDK floor — build with Xcode 26 and an iOS 26-family SDK | 28 Apr 2026 | Every upload to App Store Connect | Uploads rejected — you cannot ship even a security fix | Days if dependencies are current, weeks if not |
| Play submission gate — target Android 16 (API 36) | 31 Aug 2026 (extension to 1 Nov 2026 on request) | New apps and all updates | Uploads and updates blocked | Days to weeks |
| Play availability gate — target Android 15 (API 35) | Same 31 Aug 2026 date; the level Google requires here rises roughly every year | Already-published apps, including ones shipping no updates | Apps targeting API 34 or lower stay available only on devices running the same or lower Android version — new users on newer phones cannot install them | Days |
| Android 16 adaptive layout — no edge-to-edge opt-out; orientation, aspect-ratio and resizability ignored at ≥600dp | With API 36; temporary manifest opt-out removed at API 37 | Tablets, foldables, Chromebooks, desktop windowing | Broken or letterboxed large-screen layouts — "portrait phone only" is no longer a saving | Weeks to retrofit |
| EU DSA trader status verified | Since 17 Feb 2025 | EU distribution (declaration required either way) | Removed from EU storefronts | Hours of admin |
| Accessibility under EN 301 549 / WCAG 2.1 AA | Applied from 28 Jun 2025 to new services | Covered EU sectors: e-commerce, banking, transport, telecoms | Regulatory exposure and excluded users | Weeks retrofitted, near-zero designed in |
The usual maintenance budget is 15–20% of build cost per year. That figure is an industry rule of thumb with no traceable source, but the work behind it is real: annual rebuilds, OS migrations, framework major versions, dependency and security patching, new device sizes, certificate and key renewals, crash fixes.
If your app sells anything, the store takes a cut
Apple's commission is 30% standard, 15% under the App Store Small Business Program (up to US$1M in annual proceeds) and for auto-renewing subscriptions after a subscriber's first year, and 0% for physical goods and real-world services bought in-app. An app selling a digital subscription and an app booking a plumber have different unit economics on identical code. The US position on external purchase links is in litigation and unsettled — if your model depends on linking out, check the current rules at build time.
How to pressure-test a partner in one call
- Does the quote itemize discovery, design, build, QA, store submission and post-launch separately?
- Whose developer accounts will the app live under, and when do we open them?
- Who owns the repository from day one, and who holds the Play signing and upload keys?
- What exactly is included in the first 90 days after launch, and what is billable?
- What is the rate for change requests, and how are they approved?
- Can you show a live app published under the client's own account?
- What is your plan for the 31 August 2026 target-API deadline on apps you have already shipped?
The last one is the sharpest. A team that cannot answer it has not thought past invoicing.
How we run mobile projects at MyMind Studio
We work with founders and growing businesses from our offices in California and Florida, India and China, in four steps: a personalized roadmap with scope, timeline and cost mapped before you commit a dollar; pricing agreed upfront with no line items appearing later; end-to-end delivery through development, deployment, launch and support; and a long-term partnership rather than a handover, because the calendar above makes an app a standing commitment.
The part clients notice most is that we design before we code — you tell us what you need, we build the interface and dashboard, you review and approve, then development starts. That matters more on mobile than on the web, because store review cycles make late changes slow and expensive. We build across retail, edtech, travel, healthcare and logistics, with analytics and AI features designed in rather than bolted on. And if a responsive site would serve you better than an app, we will say so while you are still quoting.
Frequently Asked Questions
Should I build a native app or a cross-platform app?
Cross-platform — React Native or Flutter — is the right default for most business apps, because one codebase costs roughly 30–40% less to build and far less to maintain than two. Go fully native when the app depends on sustained real-time graphics, heavy on-device camera or ML processing, day-one support for a brand-new OS capability, or deep watch, widget and CarPlay surfaces. If none of those apply, ask any vendor quoting two native codebases to justify the second one specifically.
How much does a custom Android and iOS app cost in 2026?
Ranges reported across industry guides put a simple utility app at roughly $15k–$25k, a moderate business app with accounts, backend and payments at $25k–$60k, and a complex multi-role platform at $60k–$300k or more. Those come from vendors, so treat them as orientation. Your band is set by scope — user roles, whether a backend exists, payments, real-time features, offline mode, integrations, design fidelity and compliance — far more than by an hourly rate of $15–50 or $80–220.
How long does it take to build a custom mobile app, including app store approval?
A well-scoped version one typically runs 14–24 weeks: discovery 2–4, design 3–6, build 6–16, QA and device testing 2–4, submission and review 1–3. Two things sit outside the build and cause most slippage — developer account setup, which must start in week one because a Play organization account needs a D-U-N-S number, and a likely rejection round. Apple publishes an average of 90% of submissions reviewed in less than 24 hours, but first-time submissions commonly take 2–5 days.
Do I own the app, the source code and the app store listings after it is built?
Only if your contract says so explicitly, and ownership means six things: the source repository in your organization from day one, design source files, your own Apple and Google developer accounts, the Play app signing and upload key arrangement, your backend, hosting, DNS and domain accounts, and third-party service accounts under your email domain. Source code alone is not enough — without the store accounts and signing key you cannot ship an update while holding the entire repository.
Whose Apple and Google developer accounts should the app be published under?
Yours, in your company's name, always. There is no App Store or Play rule that forces this for a custom-built app — which is exactly why it gets skipped — so treat it as a commercial term rather than a compliance one. Publishing under a vendor's account, or an employee's personal one, is the largest lock-in risk in the transaction: ratings, reviews, subscribers and update rights all sit with whoever holds it. Apple's transfer route works but needs a released version and acceptance within 60 days.
What do I need to set up before my app can go live on the App Store and Play Store?
An Apple Developer Program membership at US$99 per year, a Google Play account at a one-time US$25, and — for an Apple or Google Play organization account — a D-U-N-S number, which can take several weeks to obtain in some regions. You also need DSA trader details verified in App Store Connect for EU distribution, accurate Play Data safety declarations, a privacy policy URL, and listing copy and screenshots at every required device size. Start all of it in week one.
Why do apps get rejected, and what happens if mine is?
Common causes are predictable: incomplete metadata or a broken demo account, privacy declarations that do not match what the app collects, missing privacy manifests for third-party SDKs, digital-goods payments routed around in-app purchase, functionality thin enough that a website would do, and crashes on the reviewer's device. Rejection is not a disaster — you fix and resubmit, usually within a day or two. Budget one round into the timeline instead of treating approval as automatic.
How much does it cost to maintain an app each year, and what am I paying for?
The industry rule of thumb is 15–20% of build cost annually. It has no traceable primary source, but it matches the real workload: the platform rebuilds Apple and Google now require each year, OS migrations, framework major-version upgrades, dependency and security patching, support for new device sizes and foldables, certificate and API key renewals, crash monitoring, and small feature changes. Backend hosting, third-party services and store fees sit on top as separate running costs.
Do I need a mobile app at all, or would a responsive website work?
If people would not open your product more than about once a month, a fast responsive website or PWA is usually the better investment — roughly a third of the cost, live in 6–12 weeks, findable in search, with no store review or annual rebuild obligation. Build a native app when you need push notifications people accept, offline use, camera or biometric access, background processing, or home-screen habit. Wrapping a website in an app shell is frequently rejected for offering too little.
Will my app stop working if I do nothing after launch?
It keeps running on phones that already have it, but it stops being publishable. From 28 April 2026, App Store Connect uploads must be built with Xcode 26 and an iOS 26-family SDK, so an unmaintained app cannot ship even a one-line fix. From 31 August 2026, new apps and updates on Google Play must target Android 16 (API 36), and already-published apps must target at least Android 15 (API 35) to stay available to new users on devices running a newer Android version than the app targets. Google raises both levels roughly every year. Annual rebuilds are structural.
If you want numbers against your actual scope rather than an industry average, tell us what the app has to do and we will map the roadmap, timeline and cost before you commit anything — email hello@mymindstudio.ai or start with an instant project estimate.
