How long does it take to build an app?

How long does each type of app take?

These are our planning estimates at our Sydney studio. The clock runs from kickoff to live on both stores, with one React Native codebase for iOS and Android.

They assume a dedicated team, one decision-maker on your side and feedback within a couple of days.

An MVP means a small first release, not a simple product. A marketplace MVP with buyer and seller accounts, payments and payouts usually sits in the large band.

Other Australian studios publish similar or longer ranges. WebAlive’s 2026 guide gives 1–3 months for simple apps, 3–6 for mid-level and 6–12+ for complex ones.

Taking over an existing app starts differently. We do a code audit first, usually 1–2 weeks, then plan and quote the work. Our app development cost guide has the dollar figures for each size.

What happens in each phase?

This is a typical medium app. The phases overlap, which is how 12–21 weeks of phases fit into 3–4 months.

Our development process page shows how each phase runs with us.

What do real projects look like?

Two of our own products show both ends of the range. Both clocks start at the first commit, so they leave out earlier research.

yourwedding.app was our own product, so there was no client approval loop. The scope was tight, and it reused the AWS setup from our earlier projects. Don’t plan on that pace unless your scope is just as small.

Read the full Pantry Pic case study for how the AI detection and subscriptions were built.

How long do the App Store and Google Play accounts take?

Identity and business checks can hold up a finished app. Start store enrolment in week one, while design is happening.

How long does App Review take?

Apple says it reviews 50% of submissions in under 24 hours and 90% in under 48 hours. Google doesn’t publish a typical time. It says reviews for certain accounts can take up to 7 days or longer in exceptional cases.

Rejections are common. In 2025 Apple reviewed more than 9.1 million submissions and rejected over 2 million, more than 1 in 5. Over 1.2 million of those were new apps. A rejection can mean changes and a resubmission, so leave a week in the plan.

• No way in. Guideline 2.1 asks for a demo account or demo mode, and for your backend to be live during review.
• No account deletion. Guideline 5.1.1(v) requires users to be able to start deletion in the app if they can create an account.
• Wrong payment method. Guideline 3.1.1 generally requires in-app purchase for digital features and subscriptions.
• Too thin. Guideline 4.2 rejects apps that are little more than a repackaged website.
• Social login without an alternative. Guideline 4.8 covers third-party logins used to create or sign in to the main account. It asks for a privacy-friendly option too, like Sign in with Apple. There are exceptions, such as company sign-in systems.

The full rules are in Apple’s App Review Guidelines. If your launch is tied to an event you’re directly part of, Apple lets you request an expedited review. Don’t rely on it.

Which rules add time in Australia?

Privacy and store rules add design and testing work. Plan them into the first weeks, not the week before submission. This isn’t legal advice.

• The Privacy Act. It covers businesses with turnover over $3 million and some smaller ones, such as health service providers. Map what personal data the app collects during requirements.
• Automated decisions. From 10 December 2026, APP entities’ privacy policies must cover some automated decisions that use personal information and could significantly affect people. The OAIC’s guidance explains when it applies.
• Store privacy forms. Apple’s privacy details and Google Play’s Data safety form must match what the app and its SDKs actually collect.
• Account deletion. If users can create an account, Google Play wants an in-app path and a web link for deleting the account and its data.
• Australian Consumer Law. Where the consumer guarantees apply, services must be supplied in a reasonable time if no timeframe was agreed. Put milestone dates in the contract.
• AI features. Apple’s guideline 5.1.2 says you must disclose when personal data goes to third-party AI and get explicit permission first. That’s a screen to design, not a line in the privacy policy.

What slows an app down?

• Slow decisions. Feedback that blocks the next step adds that time to the end.
• Scope that grows mid-build. New ideas are good. Put them in phase 2.
• Store accounts started late. See the table above.
• Third parties. Payment provider checks, API access and partner contracts can block development or release while approval is pending.
• Content nobody owns. Product data, legal terms, help text and store screenshots need a name next to them.
• Platform deadlines. Since 28 April 2026, Apple needs apps built with Xcode 26 or later. Since 31 August 2026, new Android apps and updates generally need to target Android 16. An old codebase may need upgrading first.
• Holidays. Many Australian businesses, testers and partners are away from Christmas to mid-January. Confirm everyone’s shutdown dates early.

How do I plan backwards from a launch date?

Start from the date and subtract. Here’s a medium app aiming to launch on Monday 15 March 2027.

1. Count the build. The 16-week schedule above runs from kickoff to approval on both stores.
2. Add the summer break. Assume 2 weeks over Christmas and New Year, then confirm the real dates.
3. Add 2 weeks of buffer for a rejection or a late change.
4. That’s 20 weeks. Counting back from 15 March 2027, kickoff lands on Monday 26 October 2026.
5. Request the D-U-N-S number and start the store accounts in week one.
6. Start the beta on Monday 25 January. If you use a new personal Google account, run the closed test as part of it. 14 days of testing plus up to a week for Google’s review clears by 15 February.
7. Submit to both stores in the week of 15 February. Approval by the end of February leaves 2 weeks of buffer.
8. Set the Apple release to manual, so you choose the day. Allow up to 24 hours for it to appear. Google’s managed publishing isn’t available for a first release, so plan the Android go-live separately.

If the date can’t move, the scope has to. Cut features from version 1 rather than squeezing testing. Launch isn’t the end either. Plan for monitoring and a first update in the weeks after.

How can I launch sooner?

1. Cut version 1 to the smallest complete workflow that solves the main problem.
2. Build one cross-platform app instead of two native ones. Our React Native page explains why.
3. Use managed services for sign-in, payments, subscriptions and email.
4. Name one person who can make decisions, and book a weekly check-in.
5. Create the store accounts and gather content while design is happening.
6. Write a short brief before the first meeting. Our app brief template shows what to include.

A team in your time zone helps too. We work Sydney hours from North Bondi, so feedback you send in the morning can be acted on the same day.

Common questions