How to make an iPhone app in 2026: the practical guide

1. Learn Swift and build it yourself. Swift is a readable language, SwiftUI shows you the interface as you type, and in 2026 you learn with an AI agent beside you — Apple built agents into Xcode itself. You pay nothing but time, and you own everything, including the understanding. The honest cost is months before the first useful version, and the honest question is whether you want to become a developer or to own an app. If it’s the former, this is the best route there is; the by-skill-level guide maps where to start.

2. Hire an agency or a freelancer. You describe, they build. Best when the project is complex, the horizon is long, and the budget exists. We won’t give you a price range — every article that does is quoting private quotes for hypothetical apps, and the spread between them is the only real information. Write a one-page spec, get three quotes against the same spec, and ask two questions before signing: who owns the code, and whose name is on the Apple Developer account. The second one decides who owns the App Store listing, the reviews, and the users.

3. Describe it to an AI builder. You write what the app does; an agent writes the code, builds it, fixes its own build errors, and runs it. This is the route most of this page is about, because it is the one most readers of this page will take — and because it has a fork inside it that most guides skip. Some AI builders produce a web app in an app-shaped wrapper. Some produce React Native — JavaScript that runs on the phone through a bridge. A few produce real Swift and SwiftUI in an Xcode project. The output decides what your app can do on the phone, who can work on it later, and whether Apple’s review will accept it. How to choose by output is its own page; the tool table below is the short version.

For most non-technical people, route three is now the fastest and the cheapest by a wide margin — a sentence our competitors also write, and one we agree with. The difference between the tools is what you end up holding.

Whatever the route, every iPhone app is made of the same parts, and the checklist before the first screen is short.

An Apple Account with two-factor authentication. Enough to build, test in the simulator, and run on your own iPhone. Apple’s enrollment page requires an account with two-factor on and “the legal age of majority in your region.”

The Apple Developer Program — only when the app leaves your phone. TestFlight and the App Store need the membership: “99 USD per membership year.” Two things trip individuals: the name must be your legal name — Apple says “Do not enter an alias, nickname, or company name” — and companies need a D-U-N-S Number, which takes business days no tool can shorten. The full enrollment walkthrough covers the timeline.

Xcode, and therefore a Mac — for native builds. Xcode is free from the Mac App Store and it is the only thing that compiles, signs and uploads an iOS app. Cloud builders compile on their own Macs so you don’t need one; we come back to this question honestly below.

An iPhone to test on. Optional, and the thing every experienced builder tells you not to skip: the simulator is polite, a thumb is not.

A description of the app. Five sentences: who it’s for, what it does, three “user does X, sees Y” scenarios, and what version one leaves out. Every route consumes exactly this document — as a brief for an agency, as a plan for yourself, as the prompt for an agent — and it is the part no tool can write for you.

The five steps are the same in every AI builder; what differs is how much structure the tool imposes between them. Here is the sequence as it runs in Modaal, with the parts that generalize marked.

1. Write the five sentences. Who, what, three scenarios, the cut list. In Modaal you paste this into the new-project screen and attach screenshots or a Figma link if you have them; every tool has an equivalent box. The quality of everything after this step tracks the quality of this step.

2. Get a plan before code. This is the part that separates a demo from an app. In Modaal the agent’s first turn writes a product document and a spec for the first feature — scenarios, approach, risks, how to test — and you read and approve it before any code exists. Tools that skip this improvise an architecture per prompt, which is fine for feature one and expensive by feature twenty.

3. Build, and watch it run. The agent writes Swift and SwiftUI, compiles through Xcode, reads its own build errors, fixes them, and runs the app in the simulator. You don’t touch the code; you look at the result.

4. Refine in sentences, not in code. “The button belongs at the bottom, thumb reach.” “Reminder defaults to the evening before.” Each sentence runs the loop again against everything already built. This is the step where iteration cost matters: on a credit meter, the fortieth correction costs; on a flat plan with your own AI subscription, it doesn’t.

5. Put it on a phone, then on TestFlight, then in the store. Run it on your iPhone early. When the three scenarios work, TestFlight — Apple’s beta service, up to 10,000 external testers, builds valid for 90 days — puts it in strangers’ hands. Then the listing and App Review; Apple says “90% of submissions are reviewed in less than 24 hours,” and the publishing guide walks the listing, screenshots and review step by step.

What you hold at the end, on Modaal, is a standard Xcode project on your Mac — the same artifact a hired iOS developer would hand you — which is the honest test of whether an AI builder “made an iPhone app” or made a demo of one.

More than most people expect, and less than the ads say. The honest sort is by what the app needs from the phone, not by category.

Realistic today, with any serious AI builder: productivity tools, habit and journaling apps, checklists and trackers, content and reference apps, calculators and converters, booking and membership apps for a small business, internal tools for a team, AI-assistant apps built on an API, simple games with standard mechanics. These are screens, lists, forms, local data, a managed backend, and store payments — the surfaces every tool handles well.

Realistic with a native-output builder, harder with the others: anything that leans on the phone — camera and sensors, widgets, Apple Watch companions, Live Activities, HealthKit, offline-first sync, in-app purchases through StoreKit. A wrapped web app gets little of this; React Native gets most of it through libraries; native Swift gets all of it directly.

Not realistic with any AI builder yet: custom rendering engines, real-time multiplayer at scale, unusual hardware integrations, and anything where the difficult part is an algorithm nobody has written before. Those need engineers — and the sensible order is to prototype the realistic scope first, validate demand, and hire for the hard part only once success justifies it.

The scope decision matters more than the tool decision. A clear five-sentence spec for a realistic app beats an ambitious one for an unrealistic app on every tool on this page.

Only the numbers you can verify, from the company that charges them.

Apple: 99 US dollars per year. For the Developer Program, on every route, the moment you publish. Building and testing on your own iPhone is free.

The AI route: the tool, plus the AI. Modaal’s free plan is one active project with unlimited prompts on one platform and the Xcode project on your Mac; Pro is €9 per month billed annually (€15 monthly) and adds unlimited projects, iOS and Android together, and TestFlight and App Store distribution — the details are on the pricing page. The AI runs on the Claude, ChatGPT, Gemini or Copilot subscription you already have; Modaal adds no charge for it. Credit-metered builders bundle the AI into their plan and charge per request — cheaper if you have no AI subscription, dearer in the weeks when you iterate hardest.

A Mac, if you don’t have one. The one line that varies most between readers; see the Mac question below.

Hiring: a quote, not a range. We don’t publish agency averages because they describe other people’s projects. Three quotes against your own spec is the only number that means anything, and the full cost guide explains how to get them and what to ask.

One rule that applies to every tool you evaluate, on any route: find the plan on which you can publish and take your code with you. We checked nineteen AI app builders’ pricing pages on that single question — the table is where a surprising number of “free” builders start charging.

We won’t give you a figure, because every figure in this genre — “days”, “two weeks to the store” — describes a demo app built by the vendor. What we can give you is the honest shape of the timeline.

On the AI route, the first running version of a small, well-specified app takes a sitting, not a sprint; that part is real. What takes the time is everything a demo skips: the fortieth correction after real people use it, the backend when a scenario finally needs one, the store listing, TestFlight, and Apple’s review. The Developer Program enrollment has its own clock — same-day for individuals with a clean legal-name match, business days for companies waiting on D-U-N-S — and it is the step people start too late.

On the hiring route, the calendar is the agency’s, not yours. On the learning route, it is measured in months before the first useful app, and in years before you stop needing the documentation open. None of these is wrong; they are answers to different questions — “do I want an app?” versus “do I want to be a developer?”

The honest answer, including the part that counts against us.

To build native Swift in an Xcode project you own: yes. Xcode runs only on macOS. That is Apple’s rule, not any vendor’s. It applies to route one, to any hired developer, and to Modaal — we build through Xcode on your Mac, and the price of that is that you need one. A used Mac mini or an older MacBook Air on a current macOS is enough.

To build with a cloud-based AI builder: no. Superapp, for example, now has a web version that builds on its own machines, and cross-platform builders compile in the cloud; a Windows laptop or a Chromebook works. The trade is where the project lives while you build it, and what you get at the end — read the export line on the pricing page before deciding that the Mac is the deciding factor.

A Mac you don’t own: a middle path. Cloud Macs by the hour or month exist for people who need Xcode only to build and sign.

To publish: Apple, regardless. The Developer Program, TestFlight and App Review run through Apple whatever you built with, and Xcode or Apple’s Transporter app does the upload — a cloud builder handles that step for you on its Macs.

If you don’t have a Mac and don’t want one, choose a cloud builder and choose it by output. If you have a Mac, the question disappears and the output question is the only one left.

No — and the sentence needs one qualification. With an AI builder that writes Swift, you never type it; you describe, react, approve. What you need instead is the ability to say precisely what the app should do and to react specifically to what you see. “Wrong” teaches the agent nothing; “the list should sort by deadline, overdue in red” fixes it in one pass. Product people already have this skill; it is most of the job.

Where Swift knowledge helps: reading the plan the agent writes before it builds, and — later — extending the app by hand or handing it to an engineer. That is only possible when the output is real Swift you own; it is the reason to care about the output question even if you never intend to read a line.

And if you want to learn Swift, the AI route is not the opposite of learning: an Xcode project written in front of you, feature by feature, with a plan you read first, is a better first textbook than most.

The question that follows "how do I make an iPhone app" is almost always "and then Android?" — and on two of the three routes the honest answer is you make it again. Learn Swift and you learn Kotlin next. Hire, and the Android version is a second quote. Most AI builders sidestep the question with React Native: one JavaScript codebase, both stores, a bridge in between, and screens that are the same on both phones because they are the same code.

Modaal takes a different route, and it is worth understanding even if you never use it. Duet, our open-source framework, shares the logic, not the screens: the business core of a feature — its state, the actions that change it, the effects it requests — is written once, and each platform gets its own fully native interface, SwiftUI on iPhone and Jetpack Compose on Android. The two apps are not kept in sync by discipline; they are kept in sync by the build. Each feature's scenarios are recorded as fixtures and replayed on both platforms, and the build fails when the two disagree. Divergence is a decision you make in the open, never an accident. The Duet framework overview explains how a feature gets built this way, step by step.

Two things this means for someone starting today. First, you don't have to decide now: Modaal's new-project wizard offers "iPhone and Android together" and "iPhone now, Android later", and the second option records features in exactly the same way, so adding the Android app later is per-feature work in the same repository, not a rewrite. Second, the code is still real: an Xcode project and an Android Studio project on your Mac, in Swift and Kotlin, that any platform developer can open. Whether sharing code between the platforms is right for your app at all — it isn't for every product — is its own honest question, and our documentation argues both sides before recommending anything.

Sort by what comes out. Everything else — speed, polish, price — is secondary to whether the thing you build is a native app, a bridged app, or a website in a shell. Facts from each vendor’s own pages, dated 6 September 2026; prices deliberately left to the pricing pages and to our nineteen-tool export table, because they change.

Real Swift, Xcode project — Modaal, Superapp, Bitrig. Modaal (ours) writes Swift and SwiftUI for iPhone and Kotlin and Jetpack Compose for Android from one project, with a plan you approve before each feature; needs a Mac; the project is on your disk from the first build. It is the only group on this page where the Android app is a second native app from the same core rather than a second project — see the section above. Superapp generates Swift for iOS, has Mac and web versions, and states that you can export the full Xcode project on any plan; iOS-side only. Bitrig generates Swift and includes export on its free plan.

React Native / Expo — Rork, Vibecode, RapidNative, and others. One JavaScript codebase compiled to both stores through a bridge; shippable, and any React Native developer can take it over. Rork’s documentation describes its output as React Native/Expo and states that paid users own the generated code — read the plan gate before you start.

Web app in a wrapper — Lovable, Bolt, v0 (mobile path). Superb for web products; for the phone, Lovable’s own FAQ says it “does not generate React Native projects” and points to a PWA or a Capacitor wrapper. Apple’s review sets a minimum-functionality bar that thin wrappers run into.

Visual builders — FlutterFlow, Bubble, Glide. FlutterFlow assembles Flutter and lets you download code from its Basic plan. Bubble’s docs say there is “no way of exporting your application as code.” Glide builds PWAs and, per its docs, doesn’t publish to the App Store. All three are excellent for apps that will always live where they were born.

Xcode and Swift, by hand. Free, native, yours, and months of learning — the right answer if the developer is who you want to become. The seven tools compared in depth and the full alternatives table go deeper on each.

Three honest ones. AI builders cannot make the app you can’t describe. If you can’t write the three scenarios, no tool can guess them, and the result will be a confident app that does the wrong thing. They cannot do the exotic parts — custom engines, unusual hardware, novel algorithms — and the right response is to build the realistic scope first and hire for the hard part when the app has earned it. And the output is the ceiling. A wrapped website will never do what a native app does, however good the prompt; a native Xcode project will do anything an engineer can make it do, because an engineer can.

The practical strategy, whichever route you take: write the five sentences, build the smallest version that serves the first scenario, put it on a phone in the first week, and let real use tell you what the second version is. That order has produced more shipped iPhone apps than any tool choice.