Mobile app development timeline: how long it takes to build an app

The short answer

As an orientation for studios in Ukraine and Eastern Europe in 2026, timelines for business apps fall into these bands. The costs of the same tiers are in how much it costs to build a mobile app.

These are ranges, not promises. Two apps with the same screen count can differ by months if one of them has offline mode, live tracking or a payment flow with refunds and payouts.

At EVA-X our median MVP takes about four weeks; a simple first version in AI Build can be faster, and a platform with several roles takes longer. The build format — AI Build, AI + DEV or DEV — is a choice made per project, and it moves the timeline as well as the price.

Where the weeks actually go

Scoping

Turning an idea into a list of modules, flows and acceptance criteria. This can take days, and it's the cheapest place to save months. Every unclear requirement here becomes a rework later.

Design

Key flows first: sign-up, the main action, payment. A focused app doesn't need every screen drawn before development starts; it needs the core flows agreed and a design system the rest can follow.

Backend and admin

Accounts, data, permissions, payments, notifications and the admin your team will run the app from. Often this is at least as much work as the screens, and it's the part people forget when they estimate by counting screens.

App screens

With React Native and Expo, most screens are written once for iOS and Android. Native development roughly doubles this part, because most features are written twice. See React Native vs native for when that's worth it.

Integrations

Payment providers, maps, delivery services, CRMs, accounting. Each one adds sandbox setup, testing and handling of its failures. A poorly documented API can cost more time than ten screens.

QA on real devices

Different screen sizes, OS versions, slow networks, permissions denied, the app sent to the background during payment. This is where unreviewed shortcuts surface.

Store release

Builds, store listings, screenshots, privacy details and the review itself. More on this below, because part of it is outside anyone's control.

What makes an app take longer

• More roles. A customer app is one product. Customers, staff and admins are three, even if they share a backend.
• Payments with money flowing out. Taking a payment is simple. Refunds, payouts to sellers, commissions and disputes are not.
• Offline mode and sync. Forms that work without a connection and sync later need careful conflict handling.
• Real-time features: live tracking, chats, live statuses.
• Integrations with weak sandboxes or slow partner approval.
• Custom animation and design beyond a clean, standard interface.
• Content and data that aren't ready: product catalogues, texts, legal documents, test accounts.
• Compliance: identity checks, financial or medical data, age restrictions.
• Force majeure. Contracts with Ukrainian teams may adapt force majeure clauses to martial law; ours does. Read how yours handles it, and ask the team how they work through power outages.
• Slow decisions. A week waiting for feedback is a week added to the timeline. A well-written contract extends deadlines by delays on the client's side; ours does.

What makes it shorter

• One codebase for iOS and Android with React Native and Expo.
• An existing backend or API the app can connect to.
• A first release cut to what the first users need. Our guide to mobile app MVP features helps decide what can wait.
• An AI-assisted build format for the routine parts, with engineers owning the critical logic.
• One decision-maker on your side who answers questions within a day.
• Developer accounts registered early, so store setup doesn't wait for paperwork.

The store steps you can't speed up

Developer accounts

Apps should be published under your own developer accounts, so the store listings are yours from the first release. Register them early. An Apple Developer Program account for a company requires a D-U-N-S number, and getting one can take a while if your company doesn't have it yet. Google Play also verifies developer identity. None of this is hard, but it can quietly block a finished app.

Google Play testing for new accounts

New personal developer accounts on Google Play must run a closed test with a minimum number of testers for a set period before they can publish to production. At the time of writing, that is 12 testers for 14 days in a row. Organisation accounts are treated differently. Check the current rules in Play Console Help before you plan your launch date, and if this applies to you, start the test while the last modules are still being built.

Apple review

App Store review is often quick, but plan for a rejection round on the first submission. The usual reasons are avoidable:

• the reviewer can't sign in, because no demo account was provided;
• privacy details in the listing don't match what the app collects;
• the app lets people create an account but gives no way to delete it;
• digital goods are sold without Apple's in-app purchase;
• crashes or placeholder content.

Prepare the listing materials while the app is still in development: screenshots in the required sizes, a short and a full description, a privacy policy page, a support contact and the age rating questionnaire. Writing them the night before submission is a common, avoidable delay.

Store review typically adds a few days to the first release; Apple's App Review page says that, at the time of writing, most submissions are reviewed within 48 hours. Later updates are usually faster, and with Expo, small fixes to JavaScript can go out over the air without a new review.

A hard date? Fix the date, not the scope

Sometimes the date is the requirement: a season, a trade show, a marketing campaign that's already booked. Then say so at the very start. A team can plan backwards from a date, putting the flows the launch can't live without first and moving the rest to a second release. What doesn't work is fixing both a large scope and an early date and hoping. Something gives, and it's usually testing.

A useful exercise is to sort every feature into three columns: needed on launch day, needed within a month after, and nice to have. The first column sets the timeline. The other two become the next releases.

A rough self-check before you ask for a timeline

You can get a feel for your timeline before talking to anyone:

• Count the roles. Who uses the app, and who manages it? Each role is its own set of screens and permissions.
• List the main flows. Sign-up, the main action, payment, and the few things people do every day. Not every screen, just the paths.
• List the outside systems. Payments, maps, delivery, CRM, accounting, identity checks. Note which of them you already have accounts and access for.
• Mark the unknowns. Anything you'd describe as "we'll figure it out" is where timelines stretch.

Bring this list to any vendor. A good one will turn it into modules with a timeline for each, and tell you which unknowns worry them.

An illustration: an eight-week first version

For a hypothetical booking app with payments and an admin, a realistic plan might look like this:

1. Week 1. Scope confirmed, key flows designed, developer accounts in progress.
2. Weeks 2–3. Accounts, profiles, catalogue of services; backend and admin basics.
3. Weeks 4–5. Booking, calendar, payments and receipts.
4. Week 6. Admin tools, notifications, reports.
5. Week 7. QA on devices, fixes, store listings.
6. Week 8. Store submission, review, release.

It's an illustration, not a quote. Add a role, an integration or offline mode, and the plan moves.

After launch: how fast can you change things?

The first release isn't the end of the timeline. The first weeks with real users almost always bring fixes and small changes, so plan a buffer for them rather than starting the next big feature the day after launch.

Small fixes in an Expo app can often ship the same day as an over-the-air update. Changes that touch native code or new permissions go through store review again, usually faster than the first time. New features are planned like any other module: scoped, estimated and scheduled.

How the timeline is fixed at EVA-X

The estimate shows a timeline for your scope alongside the modules and the price, and the contract fixes it. The clock starts when the contract is signed and the first payment arrives. We deliver module by module, and each module comes with 7 calendar days for you to accept it or send it back with a reasoned list of fixes, so plan your own time for reviewing deliveries, because it is part of the calendar too.

If you're working out a budget as well as a date, read how much it costs to build a mobile app and our guide to publishing in the App Store and Google Play. For a timeline and a fixed price for your app, describe it on the estimate, or see our mobile app development service.