The best way to build mobile apps in 2026

Timestamps

• 00:00 - Intro
• 04:01 - Which Stack to Choose
• 07:41 - How I Built My App
• 08:26 - Keep V1 Thin
• 09:55 - Example Spec
• 12:02 - Subagents
• 13:55 - Auditing Your App
• 15:45 - Plugins and Skills

I'm building a mobile app for Course Catalyst, and agents wrote most of it. The trick was anchoring it against the web app that already exists, so the AI could look at how the backend and the browser version work and translate that to mobile.

The app itself is a learning platform. You can watch lessons from me and other instructors, each lesson has notes, a library keeps track of what you're working through, and a marketplace aggregates courses from every instructor on Course Catalyst with a product in the marketplace. V1 is pretty simple, and that's on purpose.

💡 Tip[!tip]
This video was sponsored by GoLogin. I don't own any Android phones, so I test on Cloud Android, virtual Android devices you run from the browser, with different configurations and proxies for testing from other regions. There's also an official GoLogin MCP server if you want Claude Code driving the device. Promo code CALEBCURRY40.

Which Stack to Choose

There are about five realistic options, and the right one comes down to what infrastructure you already have and what devices you want to deploy to:

• Swift - native iPhone
• Kotlin - native Android
• Kotlin Multiplatform - cross-platform. Promising if you're starting from scratch, though I haven't tried it myself
• Flutter - popular cross-platform option
• Expo (React Native) - cross-platform, builds off React

All of these compile natively, and that matters. Sometimes you'll see an "app" that's really just a web page viewed through the phone, that's not what you want for a new app.

Going native with Swift or Kotlin makes sense if you're only ever going to be on one platform, or if you need some very specific capability you can't get cross-platform. If you don't know what those specific capabilities are, it's probably not an issue for you, so I wouldn't worry about it. Even then, you can still write small bits of Swift or Kotlin specific code from a cross-platform app, so it's not necessarily a dealbreaker.

It's worth noting that going native doesn't mean the whole system is written in that language. Keep the app layer thin and put most of the logic in a centralized backend that the iPhone app, the Android app, and the web app all call.

How I Built My App

That thin app layer is the architecture I went for. My backend and my web frontend are both JavaScript, and as a single developer I wanted as little language switching as possible, so React Native gave me the most bang for my buck. One JavaScript backend, three frontends (web, iPhone, Android), and the mobile apps still compile natively to the devices.

Even things you don't think about upfront get shared, like types. I don't have to define a course object or a lesson object in three different languages and do data conversions between them.

Most of the capabilities I needed already existed in the backend and the web app, so the mobile version was not a huge lift. I spent a lot of time writing a spec, then had the LLM implement it by looking at the existing backend and how interactions work on the web app. It wasn't snap-my-fingers done, there was still back and forth, but way simpler than maintaining Swift plus Kotlin plus my JavaScript web stack.

Keep V1 Thin

There were a ton of features I wanted in V1, and I removed most of them. Not just for technical complexity, but for compliance and app store approval. The fewer features you have, the easier it is to get through that door, and you can keep adding things after.

Two things I deferred:

• Payment processing. My marketplace only has free products for now. In-app payments bring app fees and extra scrutiny, and my app is really a gateway that can lead to purchases on the desktop later
• Admin controls. No course editing, no seeing students in your course. It's a student-facing app in V1, less features means less bugs and an easier approval

Example Spec

Saying "write a spec" can feel a bit vague, so here's what mine looks like. I don't write it from scratch, I describe the features and have the AI build the spec out: what students need (search, the marketplace, and so on), plus a separate file for V2 ideas so they don't get lost or interrupt what we're currently working on.

There's also a running list of decisions made along the way. A few from mine: the app is pure client with no mobile backend, React Query for the data layer, and types generated from the OpenAPI spec off my backend. Most of these details I don't need to memorize, the AI uses them to keep its understanding of the app up to date.

One important thing: any spec that's a living document describing how the app currently works needs updated as the code changes. Put that instruction at the top of your CLAUDE.md (or whatever your agent reads) so the specs don't drift from the actual code.

Subagents

The spec is really there so I can delegate. Do the research and spec writing with a higher cost model, then hand implementation to a cheaper model, and confirm the work with tests and by checking it against the spec. Done properly, you can build very large portions of your app without running out of credits or sitting there answering questions as they pop up.

Things still come up mid-run, so I triage decisions by how reversible they are. If a choice is easy to reverse, the agent just makes it. If it's a little risky, take a note of it. If it's genuinely hard to undo (a framework choice, for example), don't implement it, stop and get an answer from me. With that in place the agents run for quite a long time, implement pretty much the entire spec, and then I go test things myself.

Auditing Your App

The hard part for me wasn't really the building, it was getting the app in to the stores in good standing. I had agents do deep research on the Apple review guidelines and the Play Store requirements, and extract only what's relevant to my app in to a concise checklist. Then, once the app is almost ready, an agent audits the app against that list.

One example from mine: account deletion. Deleting an account has to actually remove it from your records along with the associated data (anything you're not legally required to keep). A soft delete flag that keeps the account row and its email fails this. Google also lets you offer deleting some data without deleting the whole account, but that's an additional option, not a replacement. Then there's a bunch more on privacy policies and packaging, the app icon, the description, all of that.

Plugins and Skills

I built my auditing checklist myself with AI help, but before you do that for everything, search for what already exists in your ecosystem. Expo publishes a set of skills you can pull in locally so your agent already knows how to do a bunch of things, like bringing an existing React web app to iOS and Android, and there's even a store submission workflow for releasing through EAS. Your agent being informed up front beats it doing research or trying outdated methods mid-build.

My app is most of the way there, not 100%, but I hope to have it out very soon, and there will be some course content on it you can view for free.