Sinabi ng App Store na Oo
Dalawang linggo ang nakaraan, sumulat ako ng "Nagtatayo pa rin. Hindi pa tapos." Ngayon, live na ang DIALØGUE sa App Store. Ito ang hitsura ng huling 40%.
Dalawang linggo lang ang nakaraan, nagtapos ako ng blog post sa ganito: "Nagtatayo pa rin. Hindi pa tapos. Iniisip pa rin kung ano ang sasabihin sa anak ko."
Nangako akong mag-follow up kapag nakapasok ang app sa App Store. O kapag na-reject. Sabi ko pa nga na baka mas interesting ang rejection story.
DIALØGUE - AI Podcast Studio — live na sa App Store. Native SwiftUI iOS app na ginagawang fully produced podcast episode ang kahit anong topic o PDF, binuo gamit ang Claude Code ng isang taong hindi pa nakakaalam ng Swift noon. I-download mo na.
Pero hindi naman sa unang try. Aaminin ko — tama nga ang hula ko na mas interesting ang rejection story kaysa sa approval story.
Ano ang Nangyari Nang I-reject ng Apple ang Unang Submission?
Na-reject ang unang submission ko. Guideline 2.1 — Performance: App Completeness. Sira ang in-app purchases.
Magalang ang review message ng Apple — napansin nila na first submission ko, binati nila ako sa pag-join ng developer program, at malinaw na ipinaliwanag ang issue. Error ang lumabas sa IAP products nang subukan ng reviewer nila na bumili.
Ito ang nakakatawa kasi: gumagana naman nang perpekto ang purchase flow sa testing ko. Ang problema pala ay nasa sandbox environment ng Apple, na ibang-iba ang behavior kumpara sa development at production. Kailangan kasi ng StoreKit configuration na exact sync sa App Store Connect — at hindi ganoon ang sa akin. Nag-test ako sa local StoreKit configuration file habang ang reviewer naman ay naka-hit sa tunay na sandbox.
Inayos ko rin naman noong parehong araw, nag-resubmit, at pumasa. Nag-ship din ako ng v1.0.1 bug fix update pagkatapos, at dumaan din nang walang problema.
Tatlong submissions lahat. Isang rejection. Mas marami akong natutunan sa rejection na iyon kaysa sa dalawang approval combined. Ganyan talaga ang pattern naman, 'di ba? Ang mga failure ay laging mas educational kaysa sa mga success.
Ano Ba Talaga ang Hitsura ng "Huling 40%"?
Sa original post, sabi ko na dinadala ka ng AI sa 60% ng daan at ang natitirang 40% ay puro human work. Gusto kong maging mas specific ngayon, kasi meron akong git log para patunayan.
16 commits. 57 files ang nagbago. 4,886 linya ang nadagdag. Lumaki ang app mula sa 69 Swift files hanggang 88, mula 7,568 linya hanggang 11,459. Halos 4,000 linya ng "polish" iyon.
Ito ang nilalaman ng 16 commits na iyon — sa halos pagkakasunod-sunod ng nangyari:
Ang Test Suite na Dapat Nandoon Mula Simula
Zero tests ang original scaffold. Zero talaga. Gumawa si Claude ng 69 files ng production code at wala kahit isang test. Sa unang tunay na commit ko pagkatapos ng original post, nagdagdag ako ng 176 unit tests at 19 integration tests na tumatakbo sa local Supabase instance.
Agad nakahuli ng totoong bugs ang pagsulat ng tests: Show model decode failures dahil sa non-existent database columns, AudioPlayer na hindi nagre-reset sa dulo ng track, isang library reload race condition, isang nawawalang nil UUID guard sa creation wizard. Lahat ng iyon ay magiging crash sa production.
Sa tingin ko ito ay isang pattern na worth naming: Nag-generate ang AI ng code na walang test infrastructure. Hindi naman dahil hindi nito kayang sumulat ng tests — magaling naman si Claude sa tests kapag hiniling mo — pero ang initial scaffold prompt kasi ay laging "build the app," hindi "build the app na may comprehensive tests." Galing sa akin ang tests — desisyon ko na hindi ako komportable mag-ship nang wala.
Studio: Ang Feature na Halos Stub Lang Noon
Ang orihinal na "Studio" feature para sa recurring shows ay isang placeholder. Pagkatapos ng dalawang commits, naging tunay na produkto na ito: show creation na may template grids, episode management na may status badges at action buttons, edit/delete workflows, schedule configuration na may timezone pickers, at voice customization sheets.
Tapos dumating ang Studio Phase 2: show detail redesign, per-episode retry/delete, manual episode generation na may credit checks. Plus 8 bagong XCUITests para masiguro na gumagana ang lahat end-to-end.
Ito ang ibig kong sabihin sa "nagbuo ang AI ng codebase, hindi product." Nag-compile ang Studio feature. Nag-render ng screen. Pero hindi ka talaga makakapag-manage ng recurring podcast show gamit nito.
Ang Audio Player, Reimagined
Nabanggit ko sa original post na binura ko ang mini-player. Mali pala ako — gumawa rin naman ako ng mas magandang mini-player sa huli. Ang final design ay may persistent mini-player bar sa itaas ng tab bar na may progress, skip controls, at play/pause. I-tap mo lang at lalabas ang expanded "Now Playing" sheet na may seekable slider, speed selector (0.5x hanggang 2x), transport controls, at sound-rings artwork animation.
Ang nakakatuwang part ay ang isSeeking state — kapag wala nito, nag-aaway ang position ng slider at ang audio observer, kaya jittery na gulo ang resulta. Isang linya lang ng state iyon pero isang oras ang inabot ko para ma-diagnose.
Nagdagdag din ako ng offline downloads na may ambient UX: green icon sa mga na-download na episode sa library, completion toast, "Downloaded" label sa Now Playing, at swipe-to-remove-download. May temp file race condition pala ang DownloadManager sa URLSession delegate na nagdudulot ng silent failures — ang fix ay synchronous file move sa loob ng callback. Hindi ito ang klaseng bug na makikita sa code review.
Security Hardening sa Bawat Layer
Sobering talaga ito. Isang security audit ng full stack — hindi lang ng iOS app — ang nagbunyag ng vulnerabilities sa maraming layer: over-permissioned database functions, authentication edge cases, token verification gaps, at input validation issues sa ilang backend services.
Wala naman sa mga ito sa iOS Swift code. Nasa backend lahat — yung kinakausap ng iOS app. Pero kapag nag-ship ka ng iOS app, nasa bulsa na ng users mo ang buong stack mo. Tumaas ang stakes sa lahat. Yung code na "gumagana naman" para sa web app ay biglang hindi na acceptable kapag dumadaan ito sa review process ng Apple at napupunta sa native app na dala-dala ng mga tao.
StoreKit: Ang Submission Killer
Ang StoreKit sandbox testing ay sarili nitong universe, at iyon mismo ang pumatay sa unang submission ko. Ibang-iba ang behavior ng sandbox environment kumpara sa production. Minsan nananatiling "pending" forever ang mga transactions. Kailangan ng manual sync ang Xcode StoreKit configuration file. Gumugol ako ng isang buong gabi nagde-debug ng purchase flow na perpektong gumagana sa code pero tahimik na nagfe-fail sa sandbox — may trailing space pala ang product IDs sa App Store Connect. Isang space lang.
Na-hit ng Apple reviewer ang sandbox error kasi out of sync ang StoreKit configuration ko sa App Store Connect. Gumagana naman sa local testing ko — pero ang reviewer pala ay naka-hit sa tunay na sandbox, hindi sa local StoreKit config file ko. Inayos ko naman noong parehong araw, pero perfect example ito ng gap between "gumagana sa machine ko" at "gumagana sa environment ng Apple."
Sariling project na rin ang purchase verification chain: nagpapadala ang iOS app ng JWS (JSON Web Signature) representation ng transaction sa server-side function, na gumagawa ng full cryptographic chain verification ng signed receipt ng Apple. Hindi lang basta decoding — actual signature validation. Dalawang dedicated commits ang inabot para magawa nang tama.
Privacy at App Store Compliance
Ang privacy at compliance ay puro forms, decisions, at checkboxes na may legal implications — at walang AI ang pupuno nito para sa iyo. App Tracking Transparency declarations, privacy nutrition labels, export compliance para sa encryption (oo, kasama ang HTTPS), content rights, Turnstile captcha integration. Marunong sumulat ng Swift si Claude Code, pero hindi niya masasabi sa iyo kung ang data collection practices mo ay kailangan ng "Data Used to Track You" label.
Full MFA at Localization
Ang original MFA implementation ay broken stub — empty factor IDs, verify-only flow. Sinulat ko ulit bilang complete TOTP lifecycle: enroll, scan QR code (native CoreImage generation), verify, view status, disable. Isang 394-line na MFAView.swift na hindi pa umiiral noon.
Localization sa 7 wika — ibig sabihin 253 UI strings na isinalin sa English, Spanish, French, Japanese, Korean, Vietnamese, at Chinese. Si Claude ang nag-translate, at maganda naman karamihan. Pero ang "maganda naman karamihan" sa Japanese ay pwedeng may button label na grammatically correct pero parang robot ang sumulat. Nahuli ko ang ilan sa mga iyon sa pagpapalit ng wika ng phone ko at aktwal na paggamit ng app. Ganoon ang klaseng testing na hindi pa kaya ng AI — hindi pa.
Ano ang Magagawa Mo sa DIALØGUE iOS App?
Para sa sinumang hindi nakabasa ng original build story, ito ang ginagawa ng DIALØGUE:
Bigyan mo lang ng topic — o mag-upload ng PDF — at gagawa ito ng fully researched, scripted, voiced podcast episode. Dalawang AI hosts ang mag-uusap nang natural tungkol sa topic mo, backed by real research. Walang microphone na kailangan.
Kasama sa iOS app:
- 5-step creation wizard — topic, format, customization, outline review, script review
- 30 AI voices sa 7 wika — English, Spanish, French, Japanese, Korean, Vietnamese, Chinese
- 9 podcast formats — mula sa Tech News Analysis hanggang Investigative Comedy
- Audio playback na may lock screen controls — background playback na gumagana agad
- Apple Sign-In, Google OAuth, at email auth
- In-app purchases — credit-based, walang subscription: 4 credits para sa $4.99, 9 para sa $9.99, 18 para sa $19.99
- Studio — mag-set up ng recurring shows na awtomatikong nag-ge-generate ng mga bagong episode
- PDF upload — research papers, reports, aklat bilang source material
Tunay na native SwiftUI app ito. Hindi web wrapper. Hindi React Native. Yung nagsimula sa 69 Swift files ay 88 files na ngayon at 11,459 linya ng code, backed by 195 tests. Totoo lang, proud na proud ako na na-ship ito.
Gaano Kalayo ang "Polish Phase" Estimate Ko?
Sinulat ko na ang app ay "nasa development pa rin, nasa final polish phase." Technically totoo naman, pero hindi ko inasahan kung gaano karami ng "polish phase" ang bagong trabaho talaga.
Tingnan mo ang git log — 16 commits hindi naman mukhang "polish." Mukhang second phase ng development. Ang test suite lang — 176 unit tests at 19 integration tests — buong project na iyon. Lumago ang Studio mula stub hanggang full feature. Na-reimagine ang audio player dalawang beses. Umabot ang security hardening sa 40+ backend functions. Na-rewrite ang MFA mula sa simula.
Sabi ko rin na binura ko ang mini-player. Mali rin pala ako doon — gumawa rin ako ng mas magandang version sa huli, na may Now Playing sheet, speed controls, at download indicators. Tama naman ang original instinct na "burahin" — ang unang mini-player ay pangit talaga. Pero tama ang concept. Kailangan lang buuin nang maayos.
Sa tingin ko ang honest na split, ngayong nakikita ko na ang buong picture, ay: nagtatayo ang AI ng foundation (60%), nagtatayo ang tao ng product (30%), at itinuturo ng App Store submission process ang natitirang 10%.
Available ba ang DIALØGUE sa EU?
Available ang DIALØGUE worldwide, pero pinoproseso pa ng Apple ang EU availability. Kasi ang EU's Digital Markets Act ay may karagdagang compliance steps — alternative payment disclosures, specific privacy documentation, business registration details. Na-submit ko na lahat, at nire-review na ng Apple ngayon. Dapat available na sa EU countries soon.
Kung nasa EU ka at ayaw mong maghintay, gumagana naman ang web app kahit saan at pareho lang ang features.
Gaano Kabilis ang AI-Assisted iOS Development?
Halos dalawang linggo lang ang DIALØGUE iOS app mula first commit hanggang App Store — isang gabi ng AI scaffolding at dalawang linggo ng human product work. Pinapanatili ko ang table na ito kasi lagi akong natututo dito:
| Proyekto | Complexity | Oras ng Pagbuo |
|---|---|---|
| DIALØGUE v1 | MVP podcast generator | ~6 na buwan |
| STRAŦUM | 10 AI agents, 11 frameworks, multi-tenant | 75 araw |
| Site redesign | WordPress frontend overhaul | 3 araw |
| DIALØGUE v2 | Buong web app rebuild | 14 na araw |
| Blog migration | WordPress → Next.js, 490 posts, Sydney RAG | 4 na araw |
| DIALØGUE iOS | Native iOS app, unang beses gumamit ng Swift | ~2 linggo (scaffold: isang gabi lang) |
Halos dalawang linggo ang scaffold-to-ship gap ng DIALØGUE iOS. Isang gabi lang ang scaffold. Yung ratio na iyon — isang gabi ng AI work, dalawang linggo ng human work — sinasabi nito lahat kung nasaan tayo sa AI-assisted development ngayon.
Pabilis nang pabilis ang AI part. Ang human part, halos pareho pa rin. Sinulat ko iyon dalawang linggo ang nakaraan at totoo pa rin.
Anong Skills ang Mahalaga Kapag AI na ang Nagco-Code?
Sa original post, naghahanap pa rin ako ng tamang payo. "Matutong maging yung taong nagbubukas ng Simulator" ang pinakamahusay na nasabi ko noon.
Ngayong talagang na-ship ko na, sa tingin ko kaya ko nang maging mas specific.
Umiiral ang app dahil sa tatlong bagay na hindi kaya ng AI:
-
Ginamit ko ang product. Hindi lang sinubukan. Ginamit talaga. Gumawa ng podcasts. Pinakinggan sa commute. Napansin ko na ang outline review screen ay kailangang magpakita ng research sources kasi gusto kong malaman kung saan galing ang mga facts.
-
Gumawa ako ng judgment calls na walang tamang sagot. Burahin ang mini-player o panatilihin? Gaano karaming customization ang sobra na sa creation wizard? Dapat ba tab o section ang Studio feature? Hindi engineering decisions ang mga iyon. Taste decisions. At ang taste ay galing sa paggamit ng maraming products — magaganda at pangit — at pagbuo ng instinct para sa kung ano ang tamang pakiramdam.
-
Nag-navigate ako ng sistema na designed para sa tao. App Store Connect, privacy declarations, export compliance, screenshot requirements — wala sa mga ito ang pwedeng i-automate. Kailangan ng pagbabasa, pag-unawa ng context, at judgment calls tungkol sa legal at business implications. Ang skill na iyon — pag-navigate ng complex human systems — hindi mawawala yan.
Kaya siguro ang updated advice ay: matutong gamitin ang mga bagay nang malalim, bumuo ng taste sa pag-aalaga sa quality, at masanay sa pag-navigate ng mga sistema na hindi designed para maging simple.
Mas concrete iyon kaysa "matutong mag-isip nang kritikal." Sa tingin ko mas malapit ito sa katotohanan. Pero hindi pa rin ako sigurado kung sapat iyon.
Paano I-download ang DIALØGUE?
Libre ang app na may in-app credit purchases. Walang subscription.
Available worldwide — pinoproseso pa ng Apple ang EU availability at malapit na maging live. Ang web app ay available kahit saan.
Mga Madalas Itanong
Available na ba ang DIALØGUE sa App Store?
Oo! DIALØGUE - AI Podcast Studio — live na sa App Store simula March 2026. Libre ang download na may in-app credit purchases (4 credits for $4.99, 9 for $9.99, 18 for $19.99). Available worldwide — na-submit na ang EU availability at pinoproseso pa ng Apple.
Available ba ito sa EU?
Na-submit na at pinoproseso ng Apple. Kasi ang EU's Digital Markets Act ay may karagdagang compliance steps, at natapos ko na ang paperwork — hinihintay na lang ang review ng Apple. Dapat available na soon. Sa ngayon, gumagana ang web app kahit saan, kasama ang EU.
Na-reject ba ito ng Apple?
Oo — na-reject ang unang submission dahil sa sirang in-app purchases (Guideline 2.1: App Completeness). Hindi naka-sync ang StoreKit sandbox configuration sa App Store Connect, kaya nag-error ang purchases habang nire-review. Inayos ko noong parehong araw, nag-resubmit, at pumasa. Pumasa rin ang v1.0.1. Tatlong submissions lahat, isang rejection. Mas marami akong natutunan sa rejection kaysa sa dalawang approval.
Gaano katagal ang buong proseso?
Halos dalawang linggo mula original blog post hanggang App Store approval. In-scaffold ni Claude Code ang 69 Swift files sa isang gabi lang. Ang natitirang 16 commits ay nagdagdag ng 4,886 lines sa 57 files — tests, Studio features, audio player redesign, MFA rewrite, security hardening, StoreKit verification, localization, at App Store submission process. Na-ship ang app sa 88 files at 11,459 lines na may 195 tests.
Ano ang pinakamahirap na bahagi ng huling 40%?
StoreKit sandbox testing. Napakalaki ng gap between "gumagana ito sa code" at "gumagana ito sa transaction system ng Apple." Ibang-iba ang behavior ng sandbox transactions kumpara sa production, kailangang exact match ang product IDs (pati mga trailing spaces), at mabagal ang feedback loop — hindi ka basta pwedeng mag-run ng unit test.
Pwede pa rin ba gamitin ang web app?
Oo naman! Ang podcast.chandlernguyen.com ay may parehong features at gumagana sa kahit anong device. Nagdadagdag lang ang iOS app ng native conveniences — Apple Sign-In, lock screen controls, offline downloads — pero ang core podcast generation experience ay pareho lang.
Iniisip pa rin kung ano ang sasabihin sa anak ko. Pero at least ngayon may na-ship na akong app na maituturo kapag sinabi kong "ang human work ang mahirap na part."
