How long does it take to make an app in 2026?

By Sigsten Gustavii· 26 October 2026· 10 min read

A small app takes anywhere from one afternoon to several months to make, depending on who writes the code, and Apple's own steps add a few days at the end on every route.

There is no single answer to how long an app takes, because two things vary: how big the app is, and who is writing the code. What has changed in the last couple of years is the lower end. A small app that once took a developer weeks can now be described to an AI and tried on a live iPhone in an afternoon. The waits that belong to Apple have not changed much, and those are worth planning around.

How long it takes, by route

These are rough ranges for a small, useful app: a handful of screens, data that is saved, maybe sign-in. A bigger app stretches every column.

The ranges overlap, and an experienced developer can beat any of them. The pattern still holds: the less code you have to write or learn, the faster you get to something you can tap.

The phases of making an app

Whatever the route, an app moves through the same phases. What changes is who does each one and how long it takes.

The waits you cannot skip

Some of the calendar belongs to Apple, not to you or your tools. Plan these early, because they run in parallel with the building if you start them in time.

Joining Apple's Developer Program

To publish, you need Apple's Developer Program, $99 a year. As an individual you enroll with your Apple Account and legal name, and Apple sends a confirmation once the purchase is processed; Apple asks you to contact it if nothing arrives within 24 hours. Enrolling as an organisation adds a D-U-N-S number, which is free but, according to Apple's D-U-N-S page, can take Dun & Bradstreet up to 5 business days to issue, plus up to 2 business days to reach Apple. If you are publishing as a company, start this on day one.

TestFlight for outside testers

TestFlight lets up to 100 people on your team test straight away. Inviting outside testers, up to 10,000 of them, needs a build approved by TestFlight's own review before invitations go out, as Apple's TestFlight page explains. That is usually quick, but it is one more step to plan for.

App Review

Every App Store app goes through Apple's App Review. On its App Review page, Apple says it typically reviews at least 50% of submissions in under 24 hours and 90% in under 48 hours. A rejection restarts the clock after you fix the problem, so the fastest review is the one that passes on the initial try, which is where a careful checklist pays off.

What makes an app take longer

• Scope that keeps growing. Every feature added before the app is out pushes the date. Write the smallest useful version down and protect it.
• Accounts and shared data. As soon as several people share data, you need sign-in, a server and rules about who sees what.
• Payments. In-app purchases need products set up in App Store Connect and a paywall that handles buying and restoring.
• Hardware features. The camera, location and Face ID all need permission prompts and testing on a real phone.
• No Mac. Building by hand on Windows means buying, renting or borrowing a Mac before you can even compile. See making iPhone apps on Windows.
• Rejections. Missing information, placeholder text or a broken link sends the app back, and each round costs days.

After the app is out: how long updates take

An app is never quite finished. People will ask for changes, you will spot things you want to improve, and Apple releases a new iOS every year. Each update goes through the same last steps as the original version: build, upload, and App Review. So it is worth knowing what an update costs you in time on each route.

• By hand: the change itself, plus a rebuild with the Xcode version Apple currently accepts (Xcode 26 or later since April 28, 2026), plus review.
• Hired: everything waits on the developer's availability. A small fix can wait weeks if they are busy with another client.
• On Borel: describe the change, try it on the live iPhone, and publish the new version from the same Publish flow. The build on Borel's Mac uses current tools, so there is nothing to upgrade on your side.

Updates are also where an app gets good. Many of the apps people love started small and improved in short steps, guided by how people actually used them. A route that makes each step cheap and quick helps far more than a perfect plan.

How to make an app faster

1. Describe the app in three sentences before building anything: who it is for, what it does, and the one thing it must get right.
2. Start the Apple paperwork early if you plan to publish, especially as an organisation.
3. Use a builder that handles the backend, so accounts and a database are not a separate project.
4. Test on a real iPhone early and often, not the day before you submit.
5. Prepare the store listing while the app is being built: the name, a clear description and a privacy policy.
6. Check the app against Apple's guidelines before you submit, to avoid a lost round of review.

How to make an app fast with Borel, step by step

Here is how a small app typically moves on Borel, from idea to App Store. The exact days depend on you and on Apple, not on a clock we set.

1. Hour one: describe and try. Tell Borel what the app is for. It plans the app, writes it in Swift and SwiftUI, and Xcode builds it on Borel's Mac. If Xcode finds a mistake, Borel reads the error and tries to fix it. When it finishes, the app runs on a live iPhone in your browser.
2. Day one onwards: change it. Ask for changes in plain words. Every version is saved, so you can go back to any of them.
3. When it feels right: your own phone. On Pro, Borel Companion installs the app on your iPhone over a cable once, then over Wi-Fi.
4. Meanwhile: Apple. Join the Developer Program if you have not already.
5. Publish. The Publish flow asks for the name, icon, category, screenshots and a description, checks the build for App Review risks, then builds, signs and uploads it to App Store Connect. It shows up in TestFlight, and you submit it for review from the same window.
6. A day or two later: review. Apple decides. Borel shows the live review status read from Apple.

What saves the most time is a clear opening message. Name who the app is for, what it does and the one thing it must get right, then change it in small, specific steps:

A study timer for students: 25-minute focus sessions with a 5-minute break, a count of sessions per day, and a reminder at 4 pm if I haven't studied yet.

Show this week's sessions as a bar chart under the timer, and let me name each session after the subject I studied.

Each message like these is one round instead of three. For a longer walk through the building part, read how to make an iPhone app with AI; for the Apple side, publishing to the App Store without a Mac.

For a step-by-step walk through the building part, see our guide to making your own iPhone app, and the Learn page on publishing for the rest.

How to choose

• You want the app this week: use [Borel](/signup). Free to start, a working app the same session, and the App Store on Pro when you are ready.
• You want to learn iOS development: give yourself months, and build something small before something big.
• You are hiring: agree a written scope and timeline, and ask how the developer handles Apple's review and future iOS updates.

The bottom line

In 2026 the building part of a small app can take hours instead of months, if an AI writes the code. Apple's parts, joining the program and passing review, still take a few days, and testing properly is time well spent on any route. If you want to see how quickly your idea can become a real iPhone app, describe it to Borel and try it on a live iPhone in your browser today.

I think the fastest way to know if an app is worth months is to have a version of it today. If you try that on Borel, I would love to hear how long it took you.

– Sigsten

Make your iPhone app in Borel

Describe the app you want and see its first screens before you pay anything.