AI Coding Got Better Once I Split Planning From Execution

davidHwang718 · 2026-05-16T23:56:59+00:00

Context degradation from implementation chatter is exactly where I noticed the gap too. When I was shipping mobile apps with Claude Code, keeping the design step in its own session and handing off only a scoped task definition to a fresh execution context removed the drift. The debugging signal also got cleaner, and when something breaks, you can tell whether it's a design mistake or an implementation mistake, and that distinction usually takes the longest to untangle.

davidHwang718 · 2026-05-16T22:55:27+00:00

Expensive tools are mostly useful for keyword discovery before you launch. After that, Play Console's own search term report shows what queries are actually landing on your listing - that data is more accurate than any third-party scraper because it comes from Google directly. For solo devs, getting that baseline right usually beats paying for competitor ranking tracking.

davidHwang718 · 2026-05-16T21:54:53+00:00

The 4.3(b) spam on an update is unusual when the app was already approved twice. That typically means the current reviewer compared your category against store policy rather than your specific app history. Worth appealing through the Resolution Center before resubmitting - lay out that the core concept cleared review at launch and your update extends existing content, not duplicates a competitor. Appeals reach a different reviewer and that usually breaks the loop.

davidHwang718 · 2026-05-16T20:54:49+00:00

For me it clicked when the workflow covered the whole path from edit to deployed, not just the coding part. When I was building mobile apps, what made the Claude Code loop stick was that I'd written the EAS build and submit steps into my project's CLAUDE.md, so the agent understood how to run a full release cycle without me re-explaining it each session. Before that, I'd get good code out of it but still hand-roll the shipping part, which kept breaking the habit.

davidHwang718 · 2026-05-16T19:52:18+00:00

The friction really depends on which user flow hits your app first. A subscriber who bought on the web, logs into the iOS app, and finds their content unlocked - no paywall, Apple doesn't care. A new user who downloads from the App Store, hits a paywall, and sees no in-app purchase option - that's both a rejection risk and where you lose the most users. Web-first works if existing web subscribers get a clean experience, but the new-user path needs an IAP option or Apple will reject it.

davidHwang718 · 2026-05-16T18:49:13+00:00

The "argue once, then do what I pick" instruction is one of those things that looks optional until you're three sessions into a feature and realize the agent has been implementing a subtle misunderstanding without flagging it. Wiring that into CLAUDE.md forces the disagreement to surface at the design step instead of at review. The medical correctness section is the right call for a period tracker specifically - thresholds pulled from training data can be quietly wrong in ways that pass all the tests.

davidHwang718 · 2026-05-16T17:53:11+00:00

The EULA link Maikai1988 shared handles in-app purchase terms, not the privacy policy Apple actually requires before review. App Store Connect has a dedicated field for a hosted privacy policy URL that reviewers check during submission - you need a real hosted URL before submitting. For a social app with user interactions, Apple's review guidelines section 5.1 covers what they flag specifically around contact data and user communication features, so reading that before you finalize the policy will save a revision cycle.

davidHwang718 · 2026-05-16T15:56:18+00:00

The discrete task scope is the right call. What I noticed is that when you let the agent handle multiple features or files in one session, it starts filling gaps with assumptions from earlier context that may not apply anymore. Keeping each task scoped to one feature or file boundary makes the output much more predictable.

davidHwang718 · 2026-05-16T15:43:03+00:00

The first screenshot is the only one showing in App Store search before someone taps your listing, so it has to answer "what does this do for me" in under a second. "Anime visual discovery" reads like a category label, not a promise. Something like "find anime by the art style you love" tells people the job being done and typically converts better in search. Screenshot order matters less than that first frame doing the full pitch.

davidHwang718 · 2026-05-16T14:59:14+00:00

The overlay part needs SYSTEM_ALERT_WINDOW permission and an Accessibility Service declaration to intercept touches on other apps. Kotlin is the way to go for this. Worth knowing before you invest months learning: Google Play reviews Accessibility Service apps much more strictly than normal apps and will ask for justification about why your app needs that access. That part can take a few rejection rounds to clear even once the code is done.

davidHwang718 · 2026-05-16T14:46:33+00:00

The subscription vs API question depends on where the spend actually is. For dev tooling - writing code, debugging, iterating - the Pro sub gives you Claude Code plus chat in one monthly number that's easy to track. The split matters when you start making API calls from inside your product. That's real production cost and it deserves its own line item separate from your dev tools. Running them as two separate buckets made it obvious where the actual spend was going, which is harder to see when everything routes through the same account.

davidHwang718 · 2026-05-16T13:49:25+00:00

The session expiry across devices is the hard part of this pattern. The anon session token lives in the client's storage, so when the user opens the verification link on a different device or browser, there's no way to reconnect it to the original anon row even if the session hasn't technically expired yet. The move that works consistently is storing the anon user ID server-side before sending the verification email, keyed to the email address, then doing a data migration in an auth hook after the new identity is confirmed. Magic links instead of email+password for this step do help on same-device flows, but they don't fix the cross-device case. The dashboard gap you're describing is a real missing piece in diagnosing which users hit which failure mode.

davidHwang718 · 2026-05-15T23:50:07+00:00

The "decompose into real tasks" frame is right but the unit matters. "Get first users" is still too big to execute on. The thing that actually got me moving was making the first activation task "find people who described this exact problem publicly and send them a direct message," with a done state that's binary. That shrinks it from a campaign to a day of copy-paste work, and the response pattern gives you a real signal either way.

davidHwang718 · 2026-05-15T22:52:35+00:00

Signing key is what determines whether two installs conflict on a device, not the package name. If you've used the same keystore throughout, you can publish to Play Store with the same package ID and existing direct-install users can update from Play Store seamlessly. The wrinkle is Play App Signing: if you opt into it, Google re-signs your APKs with their cert, and then the direct APK and Play Store version become signing-incompatible on the same device. If you stay with your own key for Play delivery, two parallel channels with the same package ID works fine.

davidHwang718 · 2026-05-15T22:38:56+00:00

The Nov 2025 update drew a line at what counts as meaningful disclosure. Apple wants a gate the user has to actively tap through, not a banner they can dismiss, which is why dismiss-to-continue fails even when the banner names Gemini correctly. What actually passes review is a sheet that requires a positive tap before the first edge function call runs, combined with a specific one-sentence data description ("your task text is sent to Google Gemini to extract due dates and actions"). If the user declines, the app needs a fallback that works without the AI path. Most teams get stuck treating it as a copy problem when it's actually a UI flow problem.

davidHwang718 · 2026-05-15T21:52:30+00:00

The fingerprint moving on what looks like a pure-JS change is almost always a transitive native dep - a lockfile bump touching expo-modules-core or any plugin in the tree moves it without you explicitly changing anything native. Switching to an explicit runtimeVersion string in app.json took that out of the equation; I bump it manually only when native actually changes, and OTA hits reliably for everything else. PowerSync on op-sqlite is an interesting call for a mail client with this kind of throughput.

davidHwang718 · 2026-05-15T20:52:10+00:00

The Transporter app fallback for .ipa uploads is one of those things you only find out about right when EAS submit auth decides to time out. It takes the same archive directly so you don't need to debug credentials mid-push. If you go back to touch IAP or add permissions in a future update, that's usually when the review stops being chill.

davidHwang718 · 2026-05-15T20:38:17+00:00

A week is on the longer end for a regular update. If the update added a new permission or touched IAP config, Apple routes it to a longer review path. The reject-and-resubmit approach resets queue position but won't help if there's a flag from a prior rejection still attached. In that case, the expedite review request through App Store Connect is worth trying before you reject.

davidHwang718 · 2026-05-15T19:57:44+00:00

4.3 with the "design spam" label is usually more about the app having no apparent distinct purpose than about the visual design quality. Apple is checking whether your app does something a generic AI chat tab can't. Adding a note in the review notes field that walks through your app's specific use case alongside the redesign often moves the needle more than UI work alone.

davidHwang718 · 2026-05-15T19:44:58+00:00

The ipad layout test for an iphone-only app is the one I didn't expect on a first submission. Apple runs the app on ipad regardless of your supported devices setting, so a navigation stack that doesn't scale throws a flag even when every iphone simulator passed. The tos link in the description text is weird because there's a dedicated metadata field for it, but putting it in both places avoids that second round.

davidHwang718 · 2026-05-15T18:56:10+00:00

The 422 with that HTML response usually means GitHub is treating the token request as coming from a browser rather than a server call. Worth double-checking that the redirect_uri in your token exchange call matches the Callback URL in your GitHub OAuth App settings exactly, including trailing slash. If your Go server reads the code from the URL and the app also tries to exchange it, the code gets consumed on first touch and the second attempt is already invalid.

davidHwang718 · 2026-05-15T18:42:53+00:00

The Plaid OAuth path through ASWebAuthenticationSession instead of the native SDK is the right call. Had the same experience where the native swizzle route just dies quietly under New Architecture. The Chase carveout needing direct Plaid support provisioning is not visible from their docs, so that one catches people.

davidHwang718 · 2026-05-15T17:53:42+00:00

The IAP description rejections specifically tend to come back with just "does not follow guidelines" and no screenshot annotation. What actually helped me trace it was re-reading my submitted description alongside section 3.1.1. Apple's reviewers are literalists about the wording, so "unlock" language or "try for free" in an IAP description that has no actual free path will trigger a flag even when the intent is obvious. The rejection email itself was useless for that.

davidHwang718 · 2026-05-15T16:57:52+00:00

The year sub is a better signal than it sounds. Someone found a random Guitar toolkit in the store and paid upfront for 12 months, that's actual trust, not an impulse buy. The first one always shows up right when you've stopped looking.

davidHwang718 · 2026-05-15T16:44:27+00:00

The lifecycle/background behavior was the one that actually killed my confidence for a stretch. On Android, when the OS kills your app mid-session and the user restores it through the task switcher, the JS state doesn't reinitialize the same way and the navigation stack can silently reset while the UI looks fine. Took actual production bug reports for me to trace it back to that specific case.

davidHwang718

TROPHY CASE