How Long Does It Take to Build an App?

With a written scope, an app takes 6–10 weeks to build on one platform and 10–16 weeks for iOS and Android together, on Caliency's typical timeline. That covers the time until the code is ready. Before the app shows up in a store, there is a second set of steps that Apple and Google set.

Some of those steps are measured in hours, others in weeks. They include the D-U-N-S number needed to open an account as a company, the 14-day closed test Google asks of new personal accounts, and both stores' review times. A developer cannot speed up most of them. Started at the right time, though, they run in parallel with the build.

In this post we compiled those steps from the platforms' own documentation: who each one applies to, the duration the source gives, and where the source gives none. Then we placed them all on a week-by-week sample timeline.

The bigger picture — platform choice, budget and choosing a team — is in our mobile app development guide. This post is only about the timeline.

How long does it take to build an app?

The short answer: once the scope is written, 6–10 weeks for one platform and 10–16 weeks for two. These are the typical delivery windows Caliency publishes on its service pages. They are not an industry statistic; they are the timelines of our own fixed-scope packages.

The range is wide because of scope. An app with one type of user and no outside systems stays near the low end. Several roles, payments or an internal integration push it to the high end.

That also answers "how many months does an app take": roughly one and a half to four months for a first release with a defined scope. A project that starts without a written scope cannot be given a number of months. Its length depends on when the decisions get made.

The part of the timeline the developer doesn't set

An app development timeline has two parts: the build and the platform steps. The team and the scope set the build. Apple, Google and Dun & Bradstreet set the platform steps.

The table below collects those steps between "code ready" and "live in the store". Each duration is the source's own wording, from Apple Developer, Play Console Help and Dun & Bradstreet. We accessed every page on October 27, 2026; none shows a last-updated date.

The longest row in that table has nothing to do with code. If your company has no D-U-N-S number, the longest wait may be for an identifier.

What steps does Apple add?

The short answer: a D-U-N-S number to enroll as a company, App Review for every release and a TestFlight review for external testing. Of these, Apple publishes a duration only for App Review.

Organization enrollment and D-U-N-S

Apple requires companies and educational institutions to provide a D-U-N-S number registered to their legal entity (Apple Developer, D-U-N-S). Individuals don't need one. Enrollment uses the legal entity's name; DBAs, trade names, fictitious businesses and branches are not accepted. Sole proprietors are directed to enroll as individuals.

The same page gives the timing. After requesting a number, Apple asks you to allow up to 5 business days for it to arrive from D&B, and says expediting will not shorten that wait. Once it arrives, it can take up to 2 more business days to reach Apple.

Organization enrollment has other conditions too. Apple asks for a work email on the organization's domain and a public, working website on that domain (Apple Developer, enroll). Social media pages and sites with minimal content are not accepted. Notarized business documents may also be requested (Apple Developer, enrollment support).

Apple gives no duration for verifying an organization. It only says that you can buy the membership once Developer Support has verified the information and emailed you. So we put this step on the timeline as an open risk, not a fixed number of days.

App Review and TestFlight

Apple's statement on review time is clear. App Review typically reviews at least 50 percent of submissions in less than 24 hours and 90 percent in less than 48 hours (Apple Developer, App Review). The same page says incomplete submissions may take longer.

That is review time, not approval time. If a submission is rejected, the fix and resubmission go on the timeline. Apple says more than 40 percent of unresolved issues, on average, relate to guideline 2.1, which covers crashes and incomplete content. Which rules cause the most rejections is covered in why apps get rejected.

In TestFlight, inviting testers from outside your team requires the first build to pass review (Apple Developer, TestFlight). Apple says the first build gets a full review and later builds of the same version might not (App Store Connect Help). No duration is published for this review.

What steps does Google Play add?

The short answer: the account type changes the timeline. An organization account needs a D-U-N-S number. A new personal account faces a 14-day closed test before it can publish.

Organization accounts and D-U-N-S

Google makes a D-U-N-S number mandatory for organization accounts. It says the process can take up to 30 days and that you should plan ahead (Play Console Help, required information). Without the number, an organization account cannot be created.

The same page describes a second wait. Developers who earn through Play's billing system have to verify their payment method, and Google says that verification can take up to 5 days. If you plan in-app sales or subscriptions, don't leave this step for launch week.

The sources don't agree on D-U-N-S timing. Apple says 5 business days and Google says 30 days. Dun & Bradstreet's US page says normal processing can take up to 30 business days, or eight with paid expedited service (Dun & Bradstreet). We plan for the longer one.

The 14-day closed test for new personal accounts

Google requires personal accounts created after November 13, 2023 to test their apps before publishing (Play Console Help, testing requirements).

The requirement: a closed test with at least 12 testers who have been opted in continuously for at least 14 days. If a tester opts out and back in, the 14 days must be consecutive. Once that's met, you apply for production access, and Google says that review usually takes seven days or less.

For the timeline this means: an Android app on a personal account may stay out of the store for about three weeks after a testable build. That is Google's 14 days plus its seven days; the sum is ours. Starting the closed test mid-build hides that time inside the build.

Google's page defines this requirement for personal accounts. Organization accounts have the D-U-N-S requirement above instead. So for companies, the trade-off is plain: one waits for an identifier, the other for testers.

Review time

Google says it takes more time to review apps from certain developer accounts. In those cases review can take up to seven days, or longer in exceptional cases (Play Console Help, publish your app). It doesn't say which accounts fall into that group.

The upload gate: SDK and target API

Neither store adds a wait here, but both reject builds made with old tools. Since April 28, 2026, Apple requires uploaded apps to be built with Xcode 26 and the iOS 26 SDK (Apple Developer, upcoming requirements). Since August 31, 2026, new apps and updates on Google Play must target Android 16 (API level 36) (Play Console Help, target API level).

How these dates affect the choice of framework is covered in native vs cross-platform.

A week-by-week sample timeline

The table below is a 12-week sample for iOS and Android. Twelve weeks sits inside the 10–16 week window we give for two platforms. The split of weeks between phases is illustrative; the real split changes with scope. How time roughly divides between phases is shown in the guide.

The critical rows are weeks 5–7. To fit Google's 14 days and its seven-day review before week 11, the closed test has to start by the beginning of week 8 at the latest. On a single-platform project the same logic squeezes into a 6–10 week timeline.

What makes app development take longer or shorter?

The short answer: scope and decision speed matter most; the technology choice comes after. What lengthens a project is usually outside the code.

What lengthens it:

• Scope changing mid-build. Every new feature reopens design, development and testing.
• Backend and integrations. An app with its own server, payments or a link to an internal system takes longer. We compared the options in choosing a backend.
• Late content. If copy and product data aren't ready, testing stays incomplete.
• Approval chains on the client side. If three people sign off every design round, that wait belongs on the timeline.
• Late accounts. If the platform steps above start after the build ends, waits that can run for weeks get added to the end.

What shortens it:

• One platform first. Launching on one platform falls into our 6–10 week window; the second platform follows with real user data.
• Cross-platform. A single codebase cuts the repeated work of two separate builds. When it isn't the right fit is in native vs cross-platform.
• A narrow first release. Features you wouldn't miss if they arrived three months later move to version two.

Time and budget depend on the same variables. Why the same scope gets very different quotes is in what an app really costs.

What should you start on day one?

The short answer: start the platform waits alongside the build, and open the accounts in your company's name. Both are cheap in week one and expensive later.

1. Look up your D-U-N-S number. Google says many organizations already have one. Apple's and Google's pages both point to a lookup tool. If you don't have one, request it now; it's free.
2. Match your company details to your D&B record. Google requires the name and address on your payments profile to match D&B. If a mismatch isn't fixed, the account can be restricted and its apps removed (Play Console Help).
3. Have a work email and a working website ready. Apple's organization enrollment asks for both on your own domain.
4. Open the Apple Developer Program and Google Play Console accounts in the company's name. The development team is added by invitation; you remain the account holder.
5. Line up your testers now. If you'll publish from a personal Play account, you need a list of at least 12 people.
6. If you'll take payments, verify the payment method early. Google says this can take up to 5 days.

Opening the accounts in your name is also about ownership. An app whose store account sits with the agency has to be moved the day the relationship ends; we cover that in who owns the code.

The part we can't control

Caliency is an LLC founded in Delaware in 2025. On mobile app projects we give a fixed price once the scope is written. The code repository and store accounts are in the client's name from day one. We don't subcontract the work, and we work remotely.

What we can't do is shorten the platform waits in this post. Nobody can promise when D&B will issue a number, when Apple will finish verifying an organization or when a review will conclude. That's why we advise against announcing a firm launch date before store approval arrives.

Nor do we recommend publishing from our own account to save time. It might skip a few weeks of waiting, but the app would be live under our name, not yours. The price of that shortcut is an account transfer later.

Frequently asked questions

How long does it take to build an app?

For a first release with a written scope, Caliency's typical window is 6–10 weeks on one platform and 10–16 weeks for iOS and Android together. Store-side waits come on top. Apple says it reviews 90 percent of submissions in less than 48 hours; Google says review can take up to seven days or longer for certain accounts. If the accounts and the D-U-N-S number are started in week one, most of those waits run in parallel with the build.

How many months does app development take?

Roughly one and a half to four months for a first release with a defined scope. Caliency's typical delivery window is 6–10 weeks for a single-platform app and 10–16 weeks for iOS and Android together. A project that starts without a written scope cannot be given a number of months; its length depends on when decisions get made.

How long does App Store review take?

Apple says App Review typically reviews at least 50 percent of submissions in less than 24 hours and 90 percent in less than 48 hours. It adds that incomplete submissions may take longer. In TestFlight, the first build sent to external testers also gets a full review; Apple publishes no duration for that review.

Who does Google Play's 12 testers and 14 days requirement apply to?

Personal developer accounts created after November 13, 2023. These accounts cannot apply for production until the app has run a closed test with at least 12 testers opted in continuously for 14 days. Google says the review of that application usually takes seven days or less. Google's page defines the requirement for personal accounts; organization accounts must provide a D-U-N-S number instead.

What is a D-U-N-S number and how long does it take to get one?

A free nine-digit company identifier issued by Dun & Bradstreet. Apple and Google require it to open an account as an organization. Apple allows up to 5 business days for the number to arrive and up to 2 more for it to reach Apple. Google says the process can take up to 30 days, and D&B's US page says normal processing can take up to 30 business days. Plan for the longer one.

In short

With a written scope, an app takes 6–10 weeks on one platform and 10–16 weeks on two, on Caliency's typical timeline. Apple and Google set the rest. Apple reviews 90 percent of submissions in under 48 hours. On Google Play, a new personal account waits through a 14-day closed test and an application review that usually takes up to seven days.

The longest wait often comes from company identity, not code: sources give anywhere from 5 to 30 business days for a D-U-N-S number. Start it and the developer accounts in your company's name in week one, and most of those waits disappear inside the build.

If you'd like to write down your app's scope and get a realistic timeline, get in touch. In the first conversation we'll separate which parts of the timeline depend on us and which depend on the platforms.