I have just read the following on a forum "In less than a working day, I got Claude Code to help me build an iOS app in SwiftUI and the same app for Android in Kotlin/Compose. End result: good looking, extremely functional, completely native apps, no half-way Motif houses.Yes, you need a Claude subscription that comes to the same as say LCC, but the tooling is completely free. I’ve never built a polished app so quickly, let alone using platforms I’m not familiar with."
20:56
That tracks with what a lot of people are reporting with Claude Code lately — building genuinely native apps from scratch on platforms you don't know well, in hours rather than weeks.
A few honest notes on the claim, since forum posts like this tend to compress a lot:
"Good looking, extremely functional, completely native" is plausible for v1 of an app with a clear, bounded scope (a few screens, standard UI patterns, maybe local storage or a simple API). It gets much harder once you add things like complex animations, background processing, push notifications, App Store/Play Store compliance edge cases, or anything requiring deep platform-specific tuning.
"Less than a working day" for two full native apps (SwiftUI + Kotlin/Compose) is fast even by enthusiastic-early-adopter standards. Possible if the apps are relatively simple, or if "less than a working day" means "the AI-assisted coding part," excluding things like setting up dev environments, signing certificates, provisioning profiles, App Store accounts, etc., which often eat real time independent of how good the AI is.
The "no half-way Motif houses" line is a nice way of saying it's not some hybrid/cross-platform compromise — it's two genuinely separate native codebases. That's a real and meaningful claim if true, since cross-platform tooling (React Native, Flutter, etc.) is the usual shortcut people take specifically to avoid maintaining two codebases.
If you're thinking about trying something similar — want me to walk through what a realistic first project and time budget would look like, or anything about how Claude Code works in practice?
Yes please. For example how would I create an Android application to keep a journal? I don't need to see code but would like to know what I would have to install on my mac to use with Claude Code.
20:59
Synthesized installation requirements for Android development with Claude
Synthesized installation requirements for Android development with Claude
Good — building an Android journal app is a great first project: well-scoped, no complicated platform restrictions like iOS has, and you can see it running on an emulator without needing a physical device or any App Store approval process to test it.
What you'd need to install on your Mac
1. Claude Code itself
The recommended way now is the native installer — it's self-contained and doesn't require Node.js at all:
curl -fsSL
https://claude.ai/install.sh | bash
(You can also install via Homebrew with brew install --cask claude-code if you prefer, or via npm if you already have Node.js — but the native installer is the simplest path and what Anthropic now recommends.)
2. Android development tools
This is the Android-specific part, separate from Claude Code:
Android Studio — free, from Google. This gives you the Android SDK, build tools, and the emulator (a virtual Android phone that runs on your Mac so you can test the app without an actual device).
That's really it on the Android side — Android Studio bundles everything else you need (Kotlin compiler, Gradle build system, etc.).
3. A Claude subscription
Pro tier ($20/month) includes Claude Code access and is plenty for a project like this.
4. Git (optional but recommended)
Usually already on a Mac, or installable via Homebrew. Lets Claude Code track changes and gives you version history/undo as it works.
How the actual build would go
You open Terminal, create a project folder, run claude inside it.
You describe the app in plain English — "a journal app where I can write daily entries with a date, optional photo, and tags, store them locally, and search past entries."
Claude Code writes the Kotlin/Compose project structure, builds the UI screens, sets up local storage (likely a small on-device database), and can run the build itself to catch errors.
You open Android Studio just to launch the emulator and see/tap through the app as it's built — Claude Code can often trigger builds itself, but you'll want eyes on the actual running app.
Iterate: "make the entry list show newest first," "add a dark mode," etc.
A journal app like this is realistically a same-day project — it's a bounded, well-understood app pattern (list + detail + local storage), which is exactly where Claude Code tends to perform best.
Want me to sketch out what a sensible feature scope for v1 would look like, so you're not starting from a blank page when you sit down with it?
Yes
21:02
Architected foundational feature set for mobile journaling platform
Architected foundational feature set for mobile journaling platform
Here's a v1 scope that's realistic for a day's work and gives you something genuinely useful, not just a tech demo:
Core (worth building first)
Entry list — chronological feed of journal entries, newest first, showing date and a preview snippet
New entry screen — a text field for writing, auto-saves the date/time
Edit/delete existing entries
Local storage — entries saved on the device (survives closing the app, no internet needed, no account required)
Entry detail view — tap an entry to see it full-screen
Worth adding once core works (still same-day)
Search — find entries by text content
Tags or mood tag — e.g. a simple emoji or one-word mood per entry, filterable
Photo attachment — attach one photo per entry from the camera or gallery
Basic stats — "12 entries this month," a simple streak counter
Nice-to-have, but I'd defer these
Cloud backup/sync — adds real complexity (accounts, server, conflict handling) for little day-one value
Reminders/notifications — easy in theory, fiddly with Android's permission model, easy to push to v2
Rich text formatting (bold/italic) — plain text covers 90% of journaling use cases
Biometric lock on the app — nice for privacy, but a clean add-on once the core app works
A decision worth making upfront
Do you want one entry per day (like a classic diary — open today, write, done) or unlimited entries any time (more like notes, several a day if you want)? This shapes the data model and the home screen, so worth deciding before Claude Code starts building rather than retrofitting it later.
Want me to put this into a short brief you could literally hand to Claude Code as your first prompt?
Yes
21:03
Thought for 2s
Thought for 2s
Q: One entry per day, or unlimited entries any time?
A: One per day (classic diary)
21:04
Deliberated format choice between file and inline code block
Deliberated format choice between file and inline code block
Here's a brief you can paste straight into Claude Code as your first prompt:
Project: Android journal app ("Daybook")
Build a native Android app in Kotlin using Jetpack Compose. This is a personal daily journal — one entry per day, classic diary style.
Core features:
Home screen shows today's entry (empty state with a prompt to write if nothing saved yet)
A calendar or list view to browse past entries by date
Tapping a past date opens that day's entry (read-only if it's not today, or editable — your call, but flag the tradeoff)
Only one entry allowed per calendar day — if the user already wrote today, opening "new entry" should open the existing one for editing, not create a duplicate
Entries are plain text, no rich formatting needed for v1
Local storage only — entries persist on-device, no account, no internet required, no cloud sync
Nice-to-haves if time allows, in this order:
Search entries by text content
A simple mood tag (emoji or single word) per entry, visible in the list/calendar view
One photo attachment per entry
A streak counter ("X days in a row")
Explicitly out of scope for v1: cloud backup, notifications/reminders, biometric app lock, rich text formatting.
Before writing code: propose a simple data model (what fields an entry has) and a basic screen flow, and check in with me before building.
That last line matters — it gets Claude Code to show you its plan before it starts generating files, so you can catch any misunderstanding early rather than after it's built something.
One practical note: have Android Studio installed and the emulator set up before you start this session, so you can actually launch and tap through the app as it gets built rather than just reading code.
Excellent, I will give it a try.
21:05
Good luck with it — sounds like a fun first project. If you hit snags with the install or the emulator setup, or want a second opinion on something Claude Code builds along the way, feel free to come back.
Will do.
21:06
Sounds good — enjoy building it.
Claude is AI and can make mistakes. Please double-check responses.
), the app was already built as a web app using Xojo. The API was already built, and all the design had been done. I wanted some mobile companion apps that connected to the same database (MySQL) using the existing API. 