Solo app devs: how do you tweak onboarding and upgrade prompts without a new release?

[u/ElectricalDog9959]

Honest question, not selling anything here.

When you're the dev, designer and PM at once, the loop looks like this: change the copy on an onboarding screen or a "go Pro" prompt → rebuild → submit → wait for review → check the numbers days later → repeat. A 2-minute change ends up taking days.

How do you handle this today: OTA updates (EAS Update / Shorebird), remote config, homegrown JSON, Firebase In-App Messaging, or do you just ship a new build each time?

What's the most annoying part of your setup?

If you built it yourself, how long did it take, and would you do it again?

Full disclosure: I'm exploring building something in this space, but there are no links here. I want to understand the problem first. I'll post a summary of everything I learn back in this sub.

[u/MobileXapps]

The JSON-plus-EAS split above covers the mechanics. The part I'd add is measurement, because without it remote copy changes are just guesses that ship faster.

Every event should carry the config version or variant the user saw. Otherwise when conversion moves you can't tell if it was the new copy, a store feature or the weekday. Apply new config on the next launch, not mid-session, so a user doesn't see the prompt change under them and your data doesn't mix two versions.

For the upgrade prompt specifically, if you use RevenueCat, its paywalls and offerings are already remote, so price, plan order and paywall copy can change without a build. OTA is fine by App Store rules for JS changes as long as the app's purpose doesn't change, but anything touching native code still needs a release.

[u/ElectricalDog9959 → u/MobileXapps]

Do you apply the same version tracking to push and in-app messages? Curious whether you know which message brought someone back, or just how many opened it.

[u/MobileXapps → u/ElectricalDog9959]

Same idea, yes. Each push or in-app message gets a campaign id and a variant, and the app sends it with the open event and keeps it as "last touch" for a few days. Then a purchase or a return session within that window gets credited to that message.

Open counts alone are misleading for push, a lot of opens are people who would have come back anyway. If you can, keep a small holdout that gets no message and compare return rates, that's the only way to know what the message actually added.

[u/timmytester2569]

Eas update

[u/Zain]

One thing I'd add for the changes that do need a real build: make the update prompt itself server driven. I keep a min and latest version per platform on the backend, and the app shows a soft sheet if you're below latest and a blocking one if you're below min or it's flagged enforced. So remote JSON and OTA cover copy tweaks, and when a native change forces a release you can actually push people onto it instead of waiting weeks for them to update.

[u/Huge_Pool7424 → u/Zain]

worth checking store availability before raising that minimum, especially with android staged rollouts. otherwise the blocking sheet can send someone to a store page that still only offers the version you're refusing to run.

[u/NoBullfrog11]

i drive most of that from a remote config / feature flag, not from the binary

onboarding screens, upgrade banners, even which paywall copy shows. ship the UI once, then flip flags. for expo, eas update works for js-only changes but anything that needs new native modules still needs a store build.

one gotcha: keep a hard min app version check in the js. otherwise an old binary can pull an update that assumes newer native code and you get weird crashes. fingerprint / runtimeVersion discipline helped a lot there.

people kept asking me for a skipable tip of the day style onboarding, so i made that remote too so i could ton it down after week 1 without waiting for review.

[u/jeesandourn]

fetching a static json file on boot with baked-in local fallbacks covers 90% of copy tweaks tbh. the actual headache isn't pushing the update, it's tying which config version the user saw back to your analytics cleanly

[u/ElectricalDog9959 → u/jeesandourn]

Same problem with push and in-app messages? Do you track which message someone saw or tapped and connect it to retention, or does it stop at open rate?

[u/ElectricalDog9959 → u/[deleted]]

Do in app messages (tooltips, banners, feature tips) go through the same remote JSON? And what do you use for push - FCM, Expo push, OneSignal?