How to Make an App: The 4 Steps to Follow

How do you make an app? There are four ways to go about it: a no-code tool, AI writing the code for you, learning to code yourself, or hiring someone. Whichever you pick, the path goes through the same four steps: pick an app that can make money, build its core feature, wire up payments, then publish and get found. In that order, with one rule tying them together: every step ends with something concrete, tested on a real phone.

Most first apps don't die from technical problems or budget. They die in the fog: nobody knows what "done" means, features keep piling up, and six months later there's still nothing on the App Store. This is the method I use for my own iOS apps, including Solys (an alarm clock with mini-games) and TradaZen (a trading simulator), both on the App Store, and I refined it by getting rejected by Apple on Solys, Clic and Nolera. So my examples come from the iPhone. When Google Play works differently, I'll point it out.

What are the ways to make an app?

Before the steps, one decision: how are you going to build it? There are four ways, and none of them is the best for everyone.

Approach	For what kind of project	What you pay for	The catch
A no-code tool (Bubble, FlutterFlow, Glide)	Catalog, form, prototype, internal tool	The tool's subscription, for as long as the app exists	The app lives on the tool's platform, and not all of them publish to the stores
AI writing the code (Claude Code, Codex, Cursor)	Your own app, published on the stores, without knowing how to code at first	The AI subscription and the store fees	The code belongs to you, but testing it is your job
Learning to code (Swift, Kotlin, React Native)	You want full control or to make it your career	Time, mostly	The longest road to a first release
Hiring someone (freelancer or agency)	A tool for your business, when you're short on time	Developer time: a day rate multiplied by a number of days	Every change costs money; check who owns the account and the code

The no-code tool. You put the app together with your mouse, without writing a single line. It's fast for a catalog, a form or an internal tool. Before you commit, check that the tool really publishes to the stores. Bubble explains how to publish to the App Store and Google Play, and FlutterFlow offers it starting with its paid Basic plan. Glide, on the other hand, says its apps are web apps and that publishing directly to the App Store or Google Play isn't supported. The limits, case by case, are in making an app without coding.

AI writing the code. You describe what you want, and an assistant like Claude Code, Codex or Cursor writes real code, in a standard format you can take anywhere. This is called vibe coding. It's how I build my apps. The downside: AI gets things wrong with total confidence, and testing is on you. To choose the tool, read which AI to use to make an app. To learn it with some structure, there's the vibe coding course.

Learning to code. This is the path for people who want full control or want to make it a career. Apple's and Expo's tutorials are free; the roadmap is in learning to make an app.

Hiring someone. A freelancer or an agency builds the app for you. It's the right call when the app is a tool for your business and you're short on time. You pay for developer time, and every change costs money too. Get in writing the exact scope, who owns the Apple account and the code, and what happens if Apple rejects the app. The questions to ask are in getting an app developed.

There's a fifth path, straddling the others: build it yourself, but from a ready-made base. That's the idea behind my kit for making a mobile app without starting from scratch, the iOS Kit: the starter code from my apps and a four-step roadmap you follow at your own pace.

How do you decide? Three questions are enough:

1. Does your app need to be on the App Store or Google Play? If so, rule out tools that only produce web apps.
2. Does it need to sell a subscription? Guideline 3.1.1 of the App Review Guidelines requires, with some exceptions, Apple's in-app purchase to unlock features in an app. Check how your build approach handles it before you start.
3. Do you have more time, or more budget? Time: build it yourself, with AI. Budget and no time: have it built.

Native app, web app or cross-platform: which should you pick?

Second decision, simpler than it looks: what type of app?

• A native app installs from a store and has access to the phone's features: notifications, camera, in-app purchases. Written in each platform's language (Swift for iPhone, Kotlin for Android), it needs one project per platform.
• A web app (PWA) is a website that behaves like an app. It doesn't go through any store: no review to wait for, but nobody will find it on the App Store. And wrapping a website in an app isn't enough: Apple's guideline 4.2 requires an app to go beyond a repackaged website.
• A cross-platform app starts from a single project to produce both the iPhone app and the Android app. Expo sums it up as a single JavaScript or TypeScript project that runs natively on your users' devices, Android, iOS and web.

For a first app, I recommend cross-platform, with React Native and Expo. You only have one codebase to maintain, and builds run on Macs hosted by Expo: you can publish an iOS app without a Mac.

iOS or Android first? One codebase doesn't mean one launch: each store has its own listing, its own rules and its own review. Start with a single platform. If your app sells a subscription, I'd go with iPhone; the numbers and the counterarguments are in iOS or Android app: which to start with.

Why do so many apps never make it to the App Store?

Three causes come up almost every time:

• A first version that's too big. Twelve half-finished features instead of one that's done.
• Payments as an afterthought. The revenue model changes the app's structure: bolting it on later means rebuilding.
• Treating publishing as a formality. Apple's review, the listing, privacy: it's a full step of its own, with its own traps, all the way down to an icon rejected with ITMS-90717.

The method below tackles these three causes, one step at a time.

Step 1: how do you pick an app idea that can make money?

Before writing a line of code, answer three questions in writing.

Who is it for? A specific person, with a recurring problem. "People who struggle to get up in the morning" is more useful than "everyone."

What does the app do, in one sentence? If you need two sentences, the first version is too big. The other features can wait until real users ask for them.

How does it make money? Subscription, one-time purchase, ads: decide now. For an app people use regularly, a subscription is often the most logical; for an occasional-use tool, a one-time purchase makes sense. The full comparison is in subscription or one-time purchase for an iOS app.

To check that an idea interests anyone before you spend weeks on it, run it through the 5 tests in finding an app idea. And to put it down in writing, one page is enough: the template is in mobile app requirements document.

By the end of this step, you should also have your technical base set up. For a beginner, that's React Native with Expo, for the reasons given above; the page React Native and Expo for a mobile app explains this choice. Scoping the first version is covered on the iOS app MVP page.

A good first version does one thing remarkably well, not twelve things passably.

Step 2: how do you build the core of your app?

Build only the core feature, and test it on your own iPhone as soon as possible. Not on screenshots, not just in the simulator.

A few rules that saved me a lot of backtracking:

• Test on the smallest and the largest screen. My first Apple rejection on Solys came from an onboarding demo that was impossible to win in a window smaller than my phones' screens: the reviewer was testing on an iPad, where the iPhone app runs in compatibility mode.
• Plan for failures. No network, permission denied, empty screen: every case deserves a clear message.
• Use AI, but review its work. Claude or Cursor write fast, and get Apple's rules wrong with total confidence. The traps are listed in making an iOS app with AI.

This step ends when outside testers are using the app through TestFlight, Apple's beta tool. It's all explained in TestFlight: testing your iPhone app.

Step 3: how do you wire up payments in an iOS app?

This is the step most beginners put off, and it's the one that decides whether the app can make any money.

Onboarding. The first screens should show the app's value before asking for anything: a rating, a permission or a payment. That's also what Apple checks: my second rejection on Solys (guideline 5.6.3) came from a rating request placed during onboarding.

The paywall. The subscription screen has to clearly show the price, the duration, any trial and a button to restore purchases. The classic mistakes are in iOS paywall: 7 beginner mistakes.

Subscriptions. Products are created in App Store Connect. I use RevenueCat to handle entitlements, restores and revenue tracking. The iOS in-app subscriptions page covers the whole job.

Analytics. Without analytics, you won't know where people drop off. I use PostHog to track the funnel (app open, onboarding completed, paywall shown, purchase) and Sentry for crashes.

Step 4: how do you publish your app and get found?

The App Store listing. Name, subtitle, keywords, screenshots, description. It's what decides whether someone downloads, and whether the App Store shows you in its search results. The App Store ASO page explains how to work on it.

Privacy. Your data collection disclosures have to match what the app actually does, and your online privacy policy has to be up to date. That's exactly what got Clic a 5.1.1 rejection.

Submitting for review. Provide a demo account if the app requires sign-in, and explain what the reviewer should test. Apple says it reviews 90% of submissions in under 48 hours; it's rejections that really stretch the timeline. Review times are covered in App Store review time, and the full process on the publishing an app on the App Store page.

What about Google Play? The path is the same, with one extra step. For a personal account created after November 13, 2023, Google requires a closed test with at least 12 opted-in testers for 14 days in a row before going to production.

Your first users. A published app isn't a discovered app. Talk about your app where your audience already hangs out, and look at your listing's numbers from the very first week.

How much does it cost to make an app?

If you build it yourself, the mandatory costs are low. Here are the prices listed on the official pages on October 2, 2026. These plans change: check them before you start.

Item	Listed price	When you pay it
Apple Developer account	$99 per year	For TestFlight and to publish
Google Play account	$25, one time	When you create the account
Building and submitting to the stores (Expo EAS)	$0 up to 15 iOS builds and 15 Android builds per month, then $19 per month	When you build often
Database and accounts (Supabase)	$0 up to 500 MB and 50,000 monthly active users, then from $25 per month	When the app grows
Subscriptions (RevenueCat)	$0 up to $2,500 in tracked revenue per month, then 1%	When the app sells
Apple's commission	15% with the Small Business Program, 30% otherwise	On every sale made through the App Store

Two things to note. The $99 Apple account isn't needed to start coding, only for TestFlight and publishing: the steps are in Apple developer account: price and sign-up. And enrollment in the Small Business Program isn't automatic: you have to apply.

If you have the app built for you, you pay for developer time: a day rate multiplied by a number of days. No serious figure can be given without knowing the scope. The costs, the free tiers and the expenses almost nobody mentions are detailed in how much does an app cost.

The biggest cost doesn't show up on any invoice: your time.

How long does it take to go from idea to App Store?

There's no honest timeline without knowing the app and where you're starting from. What's certain is that every step needs a visible finish line:

1. Idea: one sentence, one audience, one revenue model, the technical base set up.
2. Build: the core feature used by testers through TestFlight.
3. Payments: a successful test purchase, restore included.
4. Publishing: the app submitted to Apple, complete listing, age rating included.

If a step has no visible finish line, that's a sign the first version is too big.

One real benchmark, which is neither an average nor full-time work: on TradaZen, 26 calendar days passed between the first commit and the App Store release. The details are in how long does it take to make an app.

What happens after you publish?

A published app is a beginning. The first usage numbers almost always tell you something nobody saw coming: a screen where everyone drops off, a paywall nobody sees, a feature people use differently. The next version gets decided on those numbers, not on your initial hunches.

Frequently asked questions

Can you make an app for free?

Mostly, yes. You can code, test on your phone and build your app without paying anything, thanks to the tools' free plans. Publishing, though, costs money: $99 per year with Apple, $25 one time with Google. The details are in making an app for free.

How much does it cost to make an app?

If you build it yourself, the mandatory costs come down to the developer accounts: $99 per year for Apple, $25 one time for Google. The tools have free plans to get started. If you have it built, you pay for developer time, and the price depends on the scope.

How do you make an app easily?

The easiest thing isn't a tool, it's a tiny first version: one feature, finished. For a catalog or a form, a no-code tool is enough. For an app you want to publish and sell, AI writes the code, as long as you test every step on a real phone.

What's the best software to make a mobile app?

There's no best software in absolute terms. To build without code, Bubble or FlutterFlow can publish to the stores. To have AI write the code, Claude Code, Codex or Cursor work with React Native and Expo. The right choice depends on two things: whether the app needs to be on the stores, and whether it needs to sell a subscription. The comparison of app generators is in Lovable, Rork, FlutterFlow.

Can you make an app on your own, without knowing how to code?

Yes. I publish my own apps with React Native, Expo and AI, and every step in this guide can be done solo. What you need to know: AI writes the code, but you're the one who checks it. There always comes a point where you need to understand a bit of what it wrote, especially for payments and Apple's review.

Is making an app profitable?

Nobody can guarantee that. Revenue doesn't depend on the number of downloads, but on the number of people who pay and what's left after Apple's commission. What makes the outcome vary is explained in how much does an app make.

How long does it take to make an app?

There's no universal timeline: it all depends on the size of the first version and how much time you put in each week. My real benchmark: 26 calendar days between the first commit and TradaZen's release on the App Store.

How do you make an iPhone app?

The 4 steps are the same, with three Apple-specific tools: the Apple Developer account, TestFlight for testers and App Store Connect for the listing and submitting for review. The full path is on the making an iPhone app page.

Follow this method with the iOS Kit

These 4 steps are exactly the ones in the iOS Kit roadmap: pick the app that can make money, build its core, wire up the money, publish and get found. You follow them at your own pace, with the starter code from my apps and the Claude Code skills for each step.

You can also follow this method on your own, with the guides linked in this article. Not sure which step you're at? The free diagnostic tells you where you stand, which step to tackle first, and sends you my checklist for avoiding Apple rejections. Nobody can guarantee Apple's approval or any revenue; what the method guarantees is that you always know what's left to do.