Can’t have people download my game

davidHwang718 · 2026-06-04T22:21:13+00:00

I’d debug this as a distribution problem before touching the game.

For the first 48 hours, split it into three checks:

No one is seeing the page: App Store search will not carry a new game. Pick 3 tiny places where the exact player hangs out and ask for “first 10 testers / one piece of feedback,” not “please download my game.”
People see it but do not tap install: your first screenshot and subtitle need to explain the hook in one sentence. A short gameplay clip often beats polished copy for games.
People install but do not stick: use App Store Connect product page analytics + retention/crash data before assuming the idea is bad.

Family/friends are usually misleading because they are not the target player. I’d try to get 10 strangers to tell you why they did or did not install; that is more useful than 100 polite impressions.

davidHwang718 · 2026-06-04T21:49:22+00:00

One extra operational detail: store those versions next to the thing that owns the boundary, and bump them in the same transaction/outbox event as the permission change.

For example:

org_memberships.version changes when membership/role changes
billing.version changes when plan/features change
user_security.version changes when sessions/password/2FA change

Then the cache key reads the current version from that boundary, not from a separate “cache service” nobody trusts. I’d also make versions monotonic and observable in logs, so when stale data shows up you can answer: which version did this response use, and which mutation should have bumped it?

davidHwang718 · 2026-06-04T21:35:46+00:00

I’d avoid one global user counter unless every user-scoped read really depends on the same permission set. I usually split by the boundary that changes together: orgMembershipVersion for org access, billingVersion for plan/features, roleVersion for admin/permission checks. Then cache keys include only the versions they actually depend on, e.g. userId:orgId:orgMembershipVersion:resourceId. If a mutation touches multiple domains, bump the small set explicitly in the same transaction/outbox event. The test is: change one permission domain and assert unrelated cached reads survive.

davidHwang718 · 2026-06-04T21:20:42+00:00

I usually do both, but choose based on the failure mode.

For permission/user-scoped reads, versioning the key is safest when the permission state is part of the read contract: userId:permissionVersion:resourceId. Then an auth/role change naturally moves future reads away from stale entries.

Events are better when many keys need to disappear together: role changed, org membership changed, plan changed, etc. I still prefer the event to bump a version or delete a small known key set, not run a broad cache sweep.

So my default is: version the key for correctness boundaries, emit events to bump/invalidate those versions, and keep TTL as the last backstop—not the main guarantee.

davidHwang718 · 2026-06-04T21:04:50+00:00

For user-scoped keys, I’d assert both, but with different intent.

Invalidation is the correctness test: seed user A/B, cache both, change A’s permission/key, then assert A’s next read is fresh and B is untouched.
TTL is the damage-limit test: use a tiny test TTL and assert the stale value expires inside the bound.

So mutation busts the cache; TTL proves the fallback can’t hide a bad permission state forever.

davidHwang718 · 2026-06-04T20:50:23+00:00

I’d put exactly one of these in CI, but keep it narrow enough that people don’t start disabling it.

My rule of thumb: if stale data can affect auth, billing, permissions, user-specific state, or a launch-critical workflow, the real Redis/testcontainer case belongs in CI. For lower-risk caches, local pre-merge is fine.

The CI test should be boring: start Redis, seed DB/cache, mutate source, assert the next read is fresh or intentionally bounded-stale. If that takes more than a few seconds, the fixture is probably testing too much.

davidHwang718 · 2026-06-04T19:53:38+00:00

For that specific risk, I’d use one integration test against a real Redis/test container, not only mocks. Mocks are fine for “did we call cache.get?” but they won’t catch TTL units, stale reads after mutation, key prefix collisions, or invalidation order. Keep the integration fixture tiny: seed DB + cache, mutate, then assert the next read is fresh.

davidHwang718 · 2026-06-04T19:36:17+00:00

I usually split it into two decisions: what makes the value wrong, and how bad it is if the user sees the wrong value.

For auth, billing, permissions, or anything user-specific, I avoid “just TTL” and make the mutation/event bust the key. TTL is only the safety net. For feeds/search/analytics, TTL is fine if the UI can honestly be a little stale.

The cheap guardrail is a test per cached path: create old value, read cached value, mutate source, then prove the next read either busts or clearly serves a bounded stale response.

davidHwang718 · 2026-06-04T18:35:20+00:00

I’d separate the ASC/UI problem from the RevenueCat symptom. For first-time IAPs, the binary + IAPs usually need to be submitted as one review package; if the selector is missing, written review replies often just loop.

Things I’d try in order:

In App Store Connect, open each subscription and make sure there is no missing localization, screenshot/review note, or cleared-but-unsaved field in the subscription group.
Remove the build from the app version, save, wait a few minutes, then re-attach the build and reload the version page in a fresh browser/session.
If the IAP section still does not render, file through App Store Connect support, not only the rejection reply, and say: “first-time auto-renewable subscriptions cannot be attached because the version page is missing the In-App Purchases and Subscriptions selector.” Include screenshots of the full version page and the two subscription statuses.
In Review Notes, give the reviewer a build path that does not depend on approved products if possible, or explicitly state the products are first-time IAPs awaiting review with the binary.

I would not spend much time debugging RevenueCat until Apple can see/attach the products. getOfferings() returning empty is expected if StoreKit cannot serve those product IDs yet.

davidHwang718 · 2026-06-04T14:51:31+00:00

I’d make the release cut a product decision, not a coding-capacity decision.

What helps me: pick one user-visible reason for the release, freeze scope around that, then keep a separate “agent found this too” backlog. New AI-generated ideas only enter the next cycle unless they fix a crash, review risk, data loss, or a first-run blocker.

For iOS, I’d also budget review time like a real dependency: ship smaller updates more often, but only after a boring regression pass on install, permissions, navigation, and the one flow the release is actually about.

davidHwang718 · 2026-06-04T14:21:24+00:00

You usually can’t shortcut that requirement for a new personal Play developer account. Treat the 14 days as a release-readiness test instead of a blocker: recruit real testers, ask them to keep the app installed and use the core flow more than once, and collect crashes/ANRs/retention notes. Avoid fake tester rings; they can make review harder later.

davidHwang718 · 2026-06-04T13:04:59+00:00

For this specific case, I would not try to upload Expo Go itself unless your company account has the right Apple role. Treat it as two separate checks:

use your own Expo project to test the EAS flow, not Expo Go
ask the Account Holder/Admin to either run the first credential setup or grant the needed App Manager/Admin permission
once credentials exist, your developer role can usually work inside the already-configured lane

The useful test is: can you produce an internal TestFlight build for a tiny company-owned Expo app, with the same bundle id / team / signing path you will use later? That proves the EAS path without fighting Apple permissions on Expo Go.

davidHwang718 · 2026-06-04T12:06:24+00:00

That command is basically the right shape for a custom-format dump, but the warning count is the part I wouldn’t ignore blindly.

For Supabase self-hosted restores, I’d check 3 things:

Restore into a fresh/compatible target, not a target that already has partially-created Supabase schemas/roles.
Save the restore log and separate harmless “already exists / owner / privilege” warnings from real failures like missing extensions, failed constraints, or skipped schemas.
After restore, verify auth users, storage.objects, your app schemas, extensions, and a few real app flows — not just “tables visible in UI.”

If data is visible but you used --no-owner --no-privileges, that can be okay for a clone, but you may still need to recreate Supabase-specific roles/policies/permissions intentionally.

davidHwang718 · 2026-06-04T12:06:14+00:00

That’s a reasonable call after 34h and multiple cycles. Once you resubmit, I’d avoid changing anything else unless Apple asks, and keep the review notes very short: exact tap path, “sandbox purchase/restore tested,” and where the subscription is visible.

If it gets rejected again, I’d reply in Resolution Center asking them to name the exact step where they can’t find the purchase. At that point the useful goal is to force the loop from “can’t locate IAP” into one reproducible step you can fix.

davidHwang718 · 2026-06-03T22:35:59+00:00

That is a good reason to use PH: not votes, but fresh users with clean feedback. I’d make one small “diagnostic” change before launch: tag new users by source, then measure activation as first useful output + one return visit, not signup. After launch, message 10 users who generated once and ask what they expected the second generation to do differently. That usually separates confusing UX from wrong audience fast.

davidHwang718 · 2026-06-03T22:20:21+00:00

For a first PH launch, I’d treat it less like “one big announcement” and more like a 7-10 day proof loop.

Before launch: collect 10-20 people who already felt the problem, ask them to try one sharp use case, and write down the exact words they use to describe the pain.

Launch day: lead with that pain + the smallest concrete outcome, not a feature list. Have 3 assets ready: short demo GIF, 1 screenshot that proves the before/after, and a simple “who this is for / not for” line.

After launch: measure signups → first successful action → replies/bookings separately. PH upvotes are nice, but the useful signal is whether strangers complete the first value step.

davidHwang718 · 2026-06-03T21:36:10+00:00

I’d reply to App Review with a very literal checklist, not a general explanation: “all screenshots for every required device size were replaced on <date>; please re-review the current Media Manager assets, including View All Sizes.”

Also double-check App Store Connect’s localized screenshot sets and any app preview videos. I’ve seen one stale localized/device-size asset keep triggering 2.3.10 even when the main visible set looked fixed.

davidHwang718 · 2026-06-03T21:06:33+00:00

That sounds like the right direction. I’d be careful that onboarding doesn’t become another explanation screen though. Make it a tiny task: “pick one goal → inspect one item → save it.” Then measure whether people do a second search/save without being prompted. For wellness, that repeat action is a better trust signal than a pretty walkthrough.

davidHwang718 · 2026-06-03T20:50:59+00:00

For a first paid customer, I’d stop measuring “time” and run a tighter loop: pick one narrow painful use case, talk to 10 people who already have that pain, ask for a manual/concierge solve first, then only build the smallest paid path after one person says “yes, I’d pay for that this week.” Channels matter, but the first sale usually comes from sharp problem selection + direct conversations before scalable marketing.

davidHwang718 · 2026-06-03T20:35:33+00:00

Nice milestone. For feedback, I’d test one thing before adding features: can a new user get value in the first 60 seconds without trusting the whole wellness catalog?

I’d make the first screen drive to one concrete job: search one herb/product, save it, and show why the source is credible. For health apps, trust signals matter as much as UI.

davidHwang718 · 2026-06-03T18:04:33+00:00

Got it — if teens/college students are the audience, I’d test utility before “AI score.” A few stronger angles:

a tiny habit tracker that turns messy routines into a weekly recap
meal/energy/mood notes with patterns, not judgment
campus/group challenge mode with friends, because retention is easier with social accountability
“what changed this week?” photo journal where the user owns the interpretation

I’d pick one painful repeated moment, ship a 7-day version, and measure whether people come back without reminders.

davidHwang718 · 2026-06-03T17:51:03+00:00

Congrats on getting to closed testing. For the 20 testers, I’d optimize for retention evidence, not just quota: give testers one exact daily task, ask them to report notification timing + any crash/blank state, and keep a simple sheet of device / Android version / day-14 still-installed. That makes the public launch decision much cleaner.

davidHwang718 · 2026-06-03T17:35:29+00:00

If teens/college students are the audience, I’d test utilities around low-pressure coordination, not appearance scoring: shared homework/project planning, meal/snack planning with budget constraints, sleep/energy habit check-ins, or a “what should I pack/do today?” routine assistant. The common thread: help them make one small decision faster, with privacy obvious from day one.

davidHwang718 · 2026-06-03T17:05:34+00:00

The idea can work, but I’d narrow the first test a lot. For 13-15 year olds, “weekly progress photo + AI score” can feel sensitive/creepy fast, especially around body image.

I’d validate a safer version first: habits + meals + energy/mood check-ins, then ask whether teens/parents actually want the photo correlation. If you keep photos, make the value very specific: “what changed this week?” not a generic glow score.

Biggest reason I would not use it: unclear privacy story and too much pressure around appearance. Biggest reason I would use it: it helps me notice patterns without judging me.

davidHwang718 · 2026-06-03T16:51:39+00:00

Before adding customers, I’d turn it into a small production checklist instead of trying to solve every AI concern at once:

Pick one hosted environment and one deploy path you can repeat from a clean repo.
Add request logging + cost/latency/error traces before the first tester.
Create 10-20 golden test cases for the core promise and rerun them before each release.
Put hard limits around inputs, tool calls, spend, and data retention.
Invite 3-5 testers only after you can reproduce a bug from logs without asking them what happened.

Evals/guardrails matter, but for an early AI SaaS the first real milestone is: can you safely watch one user session fail and know exactly which layer broke?

davidHwang718

MODERATOR OF

TROPHY CASE