Mobile App Growth Blog

Most Firebase event plans are a list of screens somebody walked through, which is why nobody opens the dashboard six months later. A plan that survives contact with a real product starts from the decision each event is meant to settle, not from the interface. Here is the four-column template we use, and the documented limits that quietly decide what you are allowed to put in it.

You changed a value in the Firebase console, the console says published, and a large share of your users are still on the old behaviour. Nothing is broken. Remote Config has a value priority order, a client cache and an activation step, and each of them is doing exactly what it is documented to do. This is how to read the mechanism, and why a config change still deserves the discipline of a release.

You shipped a bad build, hit halt rollout, and the number of affected users did not fall. That is not a bug — halting a staged rollout and halting a fully rolled-out release are two different operations with two different outcomes, and neither one is a rollback. Here is what each control actually does, why a track’s first release cannot be halted, and how managed publishing changes the shape of the problem before it starts.

Both stores report something that looks like uninstalls, and neither reports the thing most teams think they are asking for. Apple counts Deletions from opted-in devices and hides small numbers on purpose; Google Play counts a user as lost after thirty days of silence, whether or not anything was uninstalled. This is what each number actually counts, and how far you can get towards identifying an individual leaver.

You call the review API, the code path runs, and no dialog appears. On both stores that is a documented outcome rather than a bug: Play enforces a quota it will not disclose, Apple caps the prompt and lets users switch it off entirely, and neither API reports back whether anything was shown. Here is the fault tree, in the order worth checking.

Your build is finished, uploaded and going nowhere. Most Play Console blocks are not code problems at all — they are unanswered declarations, and each one has a different owner, a different review queue and a different penalty for getting it wrong. This is the fault tree, taken from Google's own documentation.

Your retention curve is falling and none of your product experiments move it. That is often because the churn is not a product problem at all — it is a crash concentrated on one handset, an ANR nobody reports, a cold start over five seconds, or a download too large to finish. Google documents thresholds for all four, and they are stricter than most teams assume.

Most teams shut an app down by simply stopping work on it, which is the one option neither store lets you take quietly. Apple states plainly that an app you no longer actively support will be removed, and Google Play will not let you delete a monetised app at all once it has installs. This is the sequence that ends an app without stranding the people still paying you.

Two questions get merged into one decision and both get answered wrong. Apple will not let you gate a first launch behind a login unless your app genuinely has account-based features, and Google Play tells you outright that its purchase notifications do not carry complete information about the purchase. One of these questions is a policy constraint; the other is an architecture constraint, and they resolve separately.

You budgeted for 15% and your Play Console statement says 30%. The lower tier is not automatic — it requires an enrolment most teams never completed, enrolment most teams never completed, and within an account group the threshold is pooled across every developer account you own. Alternative billing in India reduces the fee by four percentage points, but only for developers who build and certify a second payment stack.

Every paywall review turns into an argument about whether to add a third plan, and nobody in the room has evidence either way. The store documentation will not tell you the optimal number, but it does define what a plan is, how many you may create, and what each extra one costs you in price-change flexibility. That is enough to decide.

Every MVP guide tells you to cut scope until only one feature survives. Neither store has read that guide. Apple and Google both publish a floor below which an app is not a product, and version one has to clear it before a single user sees the listing.

Every stack comparison you have read is a benchmark argument, and benchmarks do not survive contact with your build flags. The decision that actually matters is which documented store constraints your app will run into: download size caps, the startup thresholds Android vitals treats as excessive, how a crash gets attributed, and whether the SDKs your growth stack depends on exist for your framework. Those are all published, and they decide more than framework speed does.

Your cancellation count and your churn count disagree, and both stores are technically right. Google Play fires one notification for voluntary and involuntary cancellation alike, while Apple splits the same event across a renewal-status change and a later expiry with a subtype attached. Until you read the payloads the way the documentation defines them, every win-back campaign you build is aimed at the wrong cohort.

Your active subscriber count fell but almost nobody pressed cancel. That gap is involuntary churn — cards that expired, banks that declined, wallets that ran dry — and both stores run a long, documented recovery machine to win those payments back. Most of the revenue is lost not by the store giving up but by the app revoking access at the wrong moment.

Most idea validation tests whether people want the thing and whether you can build it. It rarely tests the third condition, which is whether the stores will distribute it at all. Apple and Google both publish the rules that decide that, and reading them before you write code is the cheapest validation step available.

Half the app SEO advice online describes a system Google no longer runs. Firebase App Indexing is no longer the recommended way of indexing content for Google Search App, and the Search App on Android no longer uses locally indexed content. What replaced it is narrower, better documented, and mostly a web problem with an app-shaped destination.

Most expansion decisions are made on market size, which is the one input that tells you nothing about whether the market will pay you back. The store mechanics make it worse: Google Play targets releases by the country a user registered their account in, not where they are standing, while your ad platform targets something else entirely. This is the sequencing framework we apply to a client's own numbers, with no invented benchmarks in it.

Someone typing your competitor name plus the word "alternative" has already decided to switch. That search cannot be answered by your store listing, because store metadata policy restricts what you may say about other brands. It can be answered by a page on your own site — and Google publishes enough documentation to tell you which version of that page survives and which one gets classified as spam.

Most founders ask this as a marketing question and get a marketing answer. The useful answer is mechanical: a developer website is a documented precondition for AdMob to verify your app-ads.txt file, and a domain you control is the only place the two stores will look for the files that make deep links open your app. Neither store makes a website mandatory to publish, which is exactly why the requirement gets discovered late.

Someone in Jakarta sees your listing in Indonesian and you never wrote a word of Indonesian. That is Google Play doing two different things under one word, and knowing which one is running on your listing decides whether you have a localisation problem or not. The text is the easy part; the screenshots, the in-app strings and the support inbox are where the money leaks.

Most teams find custom store listings after they have already built a workaround for the problem custom listings solve. The feature lets you show a different name, icon, description and screenshots to a targeted slice of Play traffic, and Google documents both the ceiling and the constraints. The constraints are where the plans usually break.

Localisation is sold as one decision and priced as one invoice, but the stores treat the listing and the binary as two entirely separate systems with two separate fallbacks. Google Play will now translate your app strings at no cost while charging for listing translation; Apple charges for neither and supplies neither. Knowing which half of the work each store does for you is what decides where the money goes.

You have picked the market. What breaks next is almost never the choice — it is the order. Pricing that was set before the tax position was settled, a listing translated before anyone checked the store supports the language, availability flipped on before a local payment method existed. Some of those steps are reversible and some are not, and the store documentation tells you which.