Case 03 / 09
Directing AI to build the same app natively on iOS and Android — a couple's auto-matching memory app
2026.05 – 2026.06 / Solo (AI as the team) / iOS · Android
Results
⚡ Idea→ship
~7–8 weeks
2026-03-21
First prompt
+45 days
2026-05-05
First working build
+45 days
2026-06-19
First release · Latest
Dev start (04-27) → TestFlight ~7–8 weeks (~23 active days). ~5-week gap between idea and start (other projects in parallel)
01
First instruction: "When a couple is in roughly the same place (within ~10m) and one of them takes a photo, auto-collect that photo with its date and location — can this be done?" Original (KO): "커플 둘이 비슷한 공간(오차 10m)에 같이 있을 때 한 명이 사진을 찍으면, 그 사진을 날짜·위치와 함께 자동으로 모아주기 — 할 수 있나?"
Logging every shared moment by hand is tedious. The idea came from everyday life: what if the app itself noticed when two people were in the same place at the same time, and bundled that into a memory?
02
03
Fig. momento-03
Directing AI
01 First instruction
for iOS and Android each, build the same features the platform's own way.
02 What I checked
I ran builds and screens and found where server dates broke and where the Android build stalled.
03 Correction
I instructed by pointing at the cause — "build a decoder that flexibly accepts the server's various date formats," "the Android DI tool doesn't fit, switch to manual singletons."
Actual instructions (excerpts)
04
Fig. momento-07
Moving location matching from devices to the server
Case 01
Symptom
Dates from the server failed to decode on iOS, breaking screens.
How I described it
the server's date format is inconsistent, so parsing fails," as fact.Original서버 날짜 형식이 일정치 않아 파싱이 실패한다"고 사실로 전달.
AI’s first try
A fix assuming a single format failed on other formats.
What I caught
A flexible decoder that accepts multiple formats was needed.
Fix
Directed a custom decoder (accepting multiple formats).
Prevention
I treat externally-sourced values as "format may vary" and parse defensively.
Case 02
Symptom
The Android build failed from a clash between the DI tool (Hilt) and the latest build setup.
How I described it
Shared the symptom with the build log.Original빌드 로그와 함께 증상 전달.
AI’s first try
Changing versions alone didn't resolve it.
What I caught
Working around it with manual singletons instead of Hilt was the right call.
Fix
Directed a switch to manual singletons, stabilizing the build.
Prevention
I don't force incompatible tools — I weigh alternatives first.
05
06
Instructing the same features two ways taught me it's not copy-paste — each platform has its own natural design, and I have to separate that out in how I direct AI. Next time I'd lock down the backend and shared rules first, then attach both clients.
(01) Review
If a developer had built it
Feature scope — 24 iOS feature modules, on TestFlight
Pairing, location matching, timeline, map, diary, anniversaries, in-app purchase, ads, widget, account recovery; TestFlight build 12.
Speed & cost — ~29K lines across two native apps in ~7 weeks
iOS (SwiftUI) and Android (Compose) built separately on one backend with 14 database migrations.
Localization — 4 languages, same ~220 keys on both platforms
English, Korean, Japanese, Thai, kept identical across iOS and Android.
Architecture — feature-based, platform-standard patterns
Feature folders, @Observable + 13 view models, most screens 300–500 lines; shared backend helpers.
Code hygiene — clean
Essentially no force-unwraps or crash-prone casts; no file over 1,000 lines.
Performance — battery-aware location
100m movement filter on iOS, 15-minute background work on Android, spatial indexes in the database.
Security basics — access rules on every table
Row-level access rules on all 22 tables (47 policies); keys kept server-side.
Testing & automation — only the matching engine has tests
8 backend tests for matching; none for the apps, no CI.
Plan → Tests for pairing, matching, and purchase flows, plus CI for both apps.
Release & ops — live database drifted from the repository
The backend repo stopped updating in early May while the live database kept changing.
Plan → Dump the live schema into migration files, commit them, and stop dashboard-only changes.
Security — hardening before store launch
An extra server-side check for purchases comes before the store release; errors will be surfaced instead of swallowed.
Plan → Server-side purchase verification and proper error reporting.
Android completeness — Android trails iOS
I finished iOS first; Android is in development.
Plan → Bring Android to parity using the iOS feature list — not copied code.
Accessibility — labels on key screens only
Screen-reader labels in 23 places on iOS, about 10 on Android.
Plan → Labels and font scaling become release-checklist items.
Next project →
AttenNFC
A planner's design, built with AI — NFC + GPS attendance with automatic payroll for small Thai businesses