How to Build an App with Claude Code

1. Why Claude Code for Building Apps

There are plenty of ways to "build an app with AI". Most of them are chat windows that hand you snippets to copy and paste, or no-code builders that lock you into their platform. Claude Code is different in one way that matters: it works inside your actual project.

It reads your files, writes new ones, runs the build, reads the error messages, and fixes them itself. You describe what you want in plain English, it does the typing, and you stay in charge of the decisions: what the app does, how it looks, and what gets shipped. That loop, describe, build, run, fix, is what makes a real app possible for someone who is not a full-time developer.

It also removes the old reason people avoided native apps. Writing an app twice, once in Kotlin for Android and once in Swift for iOS, used to mean two specialist teams. With Claude Code, rebuilding a working app for the other platform is a matter of days, not months. If you have already built a site this way, this is the natural next step after my guide to building a website with Claude, and my Claude ecosystem guide covers where Claude Code fits among the other Claude tools.

2. The Whole Path, at a Glance

Before the detail, here is the full journey from idea to a live, promoted app. Every step below gets its own section, but seeing the whole path first stops you from making the most expensive mistake: building for weeks before thinking about the store or the ads. Tap through each step:

3. Step 1: Pick Your Platform

Your first decision is where the app will live: Android, iOS, or both.

Android is the large majority of phones in India, which makes it the default starting point for most Indian audiences. You can build it on any computer using Android Studio, and publishing costs a one-time fee.

iOS reaches a smaller but typically higher-spending audience. The practical catch: building an iOS app requires a Mac with Xcode, because Apple's build and signing tools only run there. Claude Code writes the Swift, but Xcode compiles and ships it.

You do not have to launch on both at once. Starting with one platform, proving people actually use the app, and then building the second version is usually the smarter path. That is exactly what we did with Intel, which launched on Android first.

4. Step 2: Pick the Language (My Take: Go Native)

This is the decision people overthink, so here is my straight recommendation: build native.

• Android: Kotlin, with Jetpack Compose for the screens.
• iOS: Swift, with SwiftUI for the screens.

Why native, and why now? Native apps are faster, feel right on each platform, and get full access to the phone: notifications, camera, biometrics, widgets, and whatever Apple and Google release next. The only real argument against native was cost, because you needed two separate skill sets. AI has quietly removed that argument. Claude Code writes idiomatic Kotlin and Swift, and can rebuild a finished app for the other platform far faster than a team could.

What about wrappers like Capacitor? A wrapper puts your website inside an app shell. It is tempting because you already have the website. But a thin wrapper is exactly what Apple rejects under its minimum-functionality rule (guideline 4.2): an app has to offer more than a repackaged website. A wrapper with genuine native features can pass, but at that point you are doing most of the native work anyway.

And React Native or Flutter? They are still solid, widely used choices, and plenty of good apps are built with them. They make most sense when you already have a team that knows them. If you are starting fresh with AI doing the coding, native removes a whole layer between your app and the phone, and that is the direction I would bet on.

5. Step 3: Local App or Server App?

Ask yourself one question: does the app need data that lives outside the phone?

A local app keeps everything on the device. A calculator, a habit tracker, a notes app or a personal budget tool can store all its data on the phone using built-in storage (Room on Android, SwiftData on iOS). No server, no monthly server bill, no backend to maintain. If your idea fits this model, keep it this way.

A server app is needed the moment you want any of these: user logins, data that syncs across devices, payments, content shared between users, or fresh content delivered every day. Intel is a good example. Because it delivers new stories daily and sends alerts, it needs a backend behind it. A to-do list would not.

For the server, you have three broad options:
• Firebase: Google's ready-made backend, with login, database, storage and push notifications. Easy to start, and it also powers your Google Ads measurement later.
• Supabase: an open-source alternative built on Postgres, popular for its simplicity.
• Your own server: full control, but you own the maintenance and security.

Make this decision before you build. Adding a server to an app designed to be local, or ripping one out later, is painful. And do not add a server "just in case": every server is something you have to secure, pay for and keep running.

6. Step 4: Build It with Claude Code

The single biggest mistake is asking Claude Code to build the entire app in one go. Here is the loop that actually works, with a free tool for every step. Claude Code itself is the only paid piece. Design the screens in Google Stitch, write a short brief, build one feature at a time, run it, fix it with the exact error, and test on real phones before anything goes near a store. Treat Claude Code like a very fast developer on your team: clear brief, one task at a time, and you review the result. The quality of the app tracks the quality of your instructions far more than the quality of the AI. (Need somewhere to host your privacy policy? Here is how to host any website for free.)

7. Step 5: Store Accounts and What They Require

Before anyone can download your app, you need a developer account on each store you publish to. Here is what each one actually asks for in 2026:

8. How All the Pieces Connect

Once the app is built and the store accounts exist, it helps to see the whole system in one place, because promotion depends on pieces you add inside the app. Your app sits at the top. A server only exists if you need one. The stores are how people get the app. The measurement SDKs are what let the ad platforms see installs and in-app actions. And the ad platforms sit at the bottom, learning from those signals.

9. Step 6: Promoting Your App

Launching an app and hoping people find it is not a plan. The stores are crowded, and most apps are discovered through ads, search and word of mouth. For most apps, the two workhorses are Meta (Facebook and Instagram) for discovery through short video, and Google for reaching people across Search, the Play Store and YouTube. If you are on iOS, Apple Ads (formerly Apple Search Ads) puts your app at the top of App Store search results.

The rule that saves the most money: set up measurement before you spend anything. Each platform needs its own accounts, its own SDK or link, and its own events verified before a campaign can learn anything. Skip this and you are paying for installs you cannot see, from campaigns that cannot improve.

One honest warning before the setup: every ad platform reports its own results and claims credit generously. Meta, Google and Apple can each count the same install. Your store console and your own backend are the reality check. The next two sections walk through exactly what each platform needs, step by step. If you want the fundamentals of the two platforms themselves, start with my Meta vs Google Ads comparison.

10. Meta Ads: App Promotion Setup

Meta is often the fastest way to get your first installs, especially with short videos showing the app in use. But Meta cannot promote or measure an app it does not know about. Here is everything it needs, in order, before your first app ad. Tap through each step:

11. Google Ads: App Promotion Setup

Google App campaigns work differently from normal Google Ads: you do not write individual ads or pick keywords. You give Google your app, your assets and your goal, and it builds ads across Search, the Play Store, YouTube and more. For that to work, Google needs to see inside your app through Firebase. Here is the full setup, in order. Tap through each step:

12. Mistakes to Avoid

The mistakes that cost the most time and money, most of which only show up at the very end:

• Wrapping your website and calling it an app. A thin web wrapper is one of the most common reasons Apple rejects apps. If it is just your site in a shell, build it properly.
• Building everything before testing anything. Build and test one feature at a time. Ten untested features make one very confusing bug hunt.
• Adding a server you do not need. If the app works with data on the phone, keep it local. Every server is a monthly cost and a security responsibility.
• Leaving store requirements for the last day. Privacy policy, data disclosures, account deletion and, on Play, 14 days of closed testing all take time. Plan them from the start.
• Running ads before measurement works. Verify that a test install and a test event show up in Meta and Google before spending a rupee.
• Double counting with two measurement setups. If you add both the Meta SDK and a measurement partner, decide which one reports to Meta, or every install gets counted twice.
• Judging campaigns on day three. App campaigns need time and conversions to learn. Cross-check against the store console, then decide.