Shipped my first iOS app entirely with Codex — what worked, what surprised me

hoosber neo — Wed, 06 May 2026 19:52:41 +0000

Just shipped Rushi — my first iOS app, built solo with Codex over the past 4 months. Wanted to share what I learned, especially for anyone considering Codex as their primary coding partner for an iOS project.

Background

I'd never written Swift before. Started with Codex as my pair-programmer, learning Swift by doing as I built. The app is a Buddhist toolkit — sutra reader + 108-bead mala counter + sutra calligraphy practice. Free for the first week, then $1.99 — early users keep it free forever via App Store purchase history.

What worked surprisingly well with Codex

SwiftUI scaffolding from natural-language descriptions — first iteration was usable; ~80% of layouts hit on first generation
Localizing 17 languages — Codex generated all the .strings files from English seeds with cultural awareness (e.g. it correctly chose Vietnamese honorifics for Buddhist terms; same for Tibetan transliteration)
SwiftData migration code when I changed schemas mid-project
CoreText fallback chain for CJK fonts — UIFont in iOS 17 has bugs with Chinese serif fonts, and Codex correctly recommended bypassing it with CTFontDescriptor explicit fallback
Apple Search Ads keyword research — Codex generated competitive keyword lists that matched what ASA actually showed as high-volume

Where I had to take over

Apple-specific UX nuances (haptic timing, large title behavior, dynamic type quirks) — needed multiple rounds with screenshots
Audio concurrency — Codex tended to over-engineer with actors when AVAudioPlayer would do
App Store metadata (privacy labels, age rating) — Codex would sometimes suggest things that didn't match actual data flow ("data collection: false" while suggesting analytics SDK in another file)

Codex-specific tips for iOS solo devs

Show Codex the entire SwiftUI view file when iterating — partial context leads to half-broken layouts
When testing, paste the exact Xcode error text including line numbers — Codex maps stack traces well
For App Store review, ask Codex to write your privacy label statements based on your actual data flow, not your intent — it catches "I think we don't collect X" mistakes
Don't let Codex pick your dependency list — it prefers "popular" libraries over "minimal" ones; for a solo iOS app you want the latter

Outcome

Apple review: 2 days, no rejections
17 UI languages, 9 full-text languages
0 crashes in TestFlight beta
Open-sourced everything: sutra texts CC0 1.0, app source on GitHub
Codex token usage during development: ~50M input tokens, ~3M output tokens

Repo (with the open-source sutra texts): github.com/hooosberg/Rushi

Vibe coding made me anxious; building this calmed me down. Happy to answer specific Codex/SwiftUI/CoreText questions in the comments.

DOMPrompter: The hardest part of AI UI coding is pointing at the right element

hoosber neo — Sat, 18 Apr 2026 17:26:00 +0000

When people talk about AI coding, they usually talk about generating whole components, pages, or features.

But in real front-end work, the painful part is often much smaller.

It is the last 10%:

move this button a little to the right
increase the gap between these two cards
make this tag less cramped
tighten the spacing between a heading and the supporting copy

That sounds simple, but the communication overhead is brutal. You know what you want to change. The AI does not know exactly which element you mean, what context matters, or what "a little" means in this layout.

Why screenshots and vague prompts still fail

Screenshots help, but they are still missing structure.

A screenshot does not tell the model:

which DOM node you are referring to
what the surrounding hierarchy looks like
whether the spacing problem is margin, padding, gap, or alignment
how the target element relates to its siblings and container

Natural language alone is even worse.

"Move the tag down a bit" quickly turns into a guessing game. And once the AI guesses wrong, you burn both time and tokens correcting the correction.

The part I wanted to improve

So I built DOMPrompter.

It is a macOS tool specifically for interface micro-tuning in DOM-based UIs.

Instead of trying to describe the target from memory, I can:

click the exact element I want to change
inspect the DOM context around it
see the tag, spacing, position, and hierarchy information that actually matters
write the specific change I want
generate a more structured prompt for Cursor, Claude Code, Copilot, or any other AI coding tool

That shift matters because the workflow stops being "describe and hope" and becomes much closer to "point, explain, generate."

Not just for browser pages

One thing I wanted to get right is that this workflow should not be limited to a normal website.

If the interface is DOM-based, the same micro-tuning problem shows up in:

localhost front-end projects
static HTML prototypes
desktop apps built with web technology

So the product is a macOS app, but the adjustment workflow is useful anywhere the UI itself is DOM-driven.

Why I still think this is worth building

This week I noticed that tools like Codex and Claude Code are also adding pieces of this experience.

That makes sense. The problem is real.

But my own feeling is that UI micro-adjustments still deserve a more complete workflow than "the model kind of knows what you clicked."

What helps in practice is not just selecting an element. It is carrying over the context around that element:

tags
gap
spacing
position
hierarchy

Then turning that into a prompt that is tailored to the exact edit you want.

That is the core idea behind DOMPrompter.

The principle

The principle I keep coming back to is simple:

click the element, stop guessing

If AI is going to be part of front-end iteration, the handoff between "what I see" and "what the model edits" has to get more precise.

DEV Community: hoosber neo