Enter fullscreen mode

I quit learning to code three times.

Not because I wasn't motivated. I had app ideas I genuinely wanted to build. I bought courses, watched tutorials, followed roadmaps. Every single time, I hit the same wall: the resources assumed I already understood something I didn't, and by the time I'd filled that gap, three more gaps had appeared behind it.

Then I stopped trying to learn to code first and started trying to build first — using Claude Code as my development partner.

Six weeks later I had a working habit tracker and an AI-powered calorie tracker on the App Store.

This is the workflow I used, documented chapter by chapter. I've since turned it into a complete book for anyone who's been in the same place I was.

The Problem With "Learn First, Build Later"

Mobile app development has been evolving for thirty years. In the 1990s and early 2000s, building software required deep technical expertise — compilers, memory management, hardware constraints. In the 2000s through 2020s, frameworks like React Native and tools like Expo dramatically lowered the barrier. But it was still a barrier measured in months of learning before you could ship anything real.

We are now in a third era. AI partners like Claude Code understand your entire project at once — not just the file you're editing, but the relationship between your components, your database schema, your API calls, and your navigation structure simultaneously.

The implication is significant: the bottleneck is no longer technical knowledge. It's the ability to describe what you want clearly.

That is a learnable skill, and it's the core skill this workflow develops.

Setting Up: The Environment That Actually Works

The setup stack is deliberately minimal:

Node.js — the runtime everything runs on
Claude Code — your AI development partner (CLI)
Expo — the framework that handles iOS/Android complexity
A code editor — VS Code works perfectly alongside Claude Code

The key insight here is that you are not setting up a traditional development environment where you write code in files. You are setting up a conversation interface where you describe screens, features, and behaviours — and Claude Code builds them.

The first project you build in this environment is not an app. It is a "Hello World" screen you get running on your physical phone in under 20 minutes. This matters psychologically: seeing your name on a real phone screen, the first time, breaks the mental model that this is hard.

Your First Real Test: The App Running on Your Phone

Before writing a single line of app logic, you prove the pipeline works end to end:

Claude Code scaffolds a new Expo project
You run it on your computer
You scan a QR code with Expo Go on your phone
Your app appears on your screen — live, updating in real time as you make changes

This is called the Three-Stage Testing Protocol: Computer → Mirror (screen mirroring on your laptop) → Physical Phone. Every feature you build gets tested through all three stages before you move on. It catches 90% of layout bugs that only appear on real hardware.

This protocol sounds simple. It saves enormous amounts of frustration later.

The Framework That Changes How You Think About Apps

Before building anything complex, it is worth understanding what makes an app work — not technically, but structurally.

The Five-Element Framework breaks every successful app into five layers:

Layer 1 — Core Function
The one thing your app does brilliantly. Not ten things. One. A calorie tracker counts calories. A habit tracker tracks habits. If you cannot state your app's core function in five words, the app is not ready to build.

Layer 2 — Core Loop
The repeatable cycle that drives daily engagement. For a habit tracker: open app → check habits → mark done → see streak. The loop must be completable in under 60 seconds or users will not return.

Layer 3 — Accessory Features
Enhancements that orbit the core without changing it. Statistics. History. Reminders. These are built after the core loop works perfectly — never before.

Layer 4 — Surface Area
Every screen and interaction the user touches. The fewer screens, the better. Every additional screen is a navigation decision the user has to make.

Layer 5 — Retention Hook
The reason users come back tomorrow. Streaks. Progress indicators. Completion percentages. This is what separates apps people use once from apps people use every day.

This framework is the difference between building something that works technically and building something people actually use.

Project 1: The Local Habit Tracker

The first real project is a habit tracker that stores everything locally on the device using AsyncStorage.

Why start local? Because local storage is instant. There is no network, no authentication, no database to configure. You can see the full app working on your phone within a few hours and the workflow is pure: describe the feature, Claude Code builds it, test it on your phone, iterate.

The app includes:

Adding and removing habits
Marking habits complete each day
A streak counter
A simple statistics view

The prompting workflow that works:

"Build a habit tracker screen. It should show a list of habits,
each with a checkbox. When I check a habit it should mark it
as done for today. Show a streak counter at the top that
increments each day all habits are completed."

That single prompt, given to Claude Code in a properly scaffolded Expo project, produces a working screen. You then iterate:

"Add a way to create new habits. Show a text input at the
bottom with an Add button."

"The habit list is getting long. Add a scroll view."

"When I swipe left on a habit, show a delete option."

This is the workflow. Describe → Build → Test → Describe again.

Important: During development, Claude Code may add hidden panels for testing — data reset buttons, debug toggles. These must be removed before you submit to the App Store. Audit for these before every submission.

Project 2: Adding a Cloud Backend and User Authentication

Local storage works for a single device. The moment a user switches phones, or wants their data on a tablet, it breaks.

The solution is Supabase — an open-source Firebase alternative that gives you a PostgreSQL database, authentication, and real-time subscriptions with minimal configuration.

The upgraded habit tracker adds:

User sign-up and login — email + password, handled entirely by Supabase Auth
Cloud sync — habits stored in Supabase, accessible from any device
Row-Level Security — each user can only read and write their own data

The local cache + cloud sync pattern used here is worth understanding:

Writes go to AsyncStorage first (instant feedback), then sync to Supabase in the background. Reads come from AsyncStorage unless it is empty, in which case Supabase is the source of truth.

This gives the app the feel of a local app (instant response) with the durability of a cloud app (data survives phone changes).

The Supabase dashboard is entirely visual — you create tables, set up auth, and configure security policies through a browser interface. No SQL knowledge required for the basics.

Project 3: The AI Calorie Tracker

This is where things get genuinely impressive.

The third project adds the Anthropic vision API to the app. The user opens the camera, photographs their meal, and the app returns a nutritional breakdown: calories, protein, carbohydrates, fat. Automatically. From a photo.

The implementation:

The user takes a photo with their phone camera
The image is converted to base64 and sent to the Anthropic API
Claude analyses the image and returns structured nutritional data
The app displays the breakdown and logs it to the day's total

The prompt sent to Claude with each image:

Analyse this food image and return a JSON object with:
- calories (number)
- protein_g (number)
- carbs_g (number)
- fat_g (number)
- food_name (string)
- confidence (low/medium/high)

Return only valid JSON, no explanation.

Requesting JSON output is essential. Structured JSON responses can be directly consumed by the app without fragile text parsing.

The accuracy is genuinely useful for everyday logging — not clinical-grade, but good enough for the use case.

Project 4: Securing the API Key With a Supabase Edge Function

Here is a problem that most beginner tutorials skip entirely, and it causes real security vulnerabilities:

You must never put your Anthropic API key inside your mobile app.

A mobile app is a file that gets installed on millions of devices. Anyone can extract the binary and read hardcoded strings inside it — including your API key. If your key is exposed, anyone can run up unlimited API charges on your account.

The correct architecture:

Mobile App
    ↓  (sends image, no API key)
Supabase Edge Function
    ↓  (adds API key securely, forwards request)
Anthropic API
    ↑  (returns result)
Supabase Edge Function
    ↑  (forwards result)
Mobile App

The Edge Function lives on Supabase's servers. The API key is stored as an environment variable on the server. The mobile app never sees it.

Claude Code builds this Edge Function from a plain English description. You deploy it with a single command. The security model is correct from day one.

Shipping: App Store and Google Play

EAS (Expo Application Services) handles the build and submission process:

# Build for iOS
eas build --platform ios

# Submit to App Store
eas submit --platform ios

# Build for Android
eas build --platform android

# Submit to Google Play
eas submit --platform android

EAS compiles your Expo project into a native binary in the cloud. You do not need Xcode installed. You do not need a Mac to build for iOS (though you do need an Apple Developer account, $99/year).

The submission process for both stores requires app description and keywords, screenshots, a privacy policy URL, and an age rating questionnaire.

The Real Result

Six weeks from knowing nothing to apps on the App Store.

That timeline is real. It is not a marketing claim. The limiting factor was not technical difficulty — it was learning to describe what I wanted precisely enough, learning to test systematically, and learning to iterate without fear.

The most important shift is mental: you are not a programmer who doesn't know enough yet. You are a product person who uses AI as a development partner. Those are different roles with different skills, and the second role is available to you right now.