Mobile App Growth Blog

Four store rules landing across 2026 catch exactly the app a coding agent builds by default. Each one blocks updates rather than launches, which is why teams meet them late. Here are the dates, what each blocks, and the order to handle them in.

An .ipa is a zip file, and anything you bundled into it ships to every device that installs your app. This is what actually leaks in vibecoded mobile apps, why the widely-blamed anon key is not the problem, and the eight things to fix.

Prompt-to-app builders are genuinely good at the first afternoon and consistently bad at the six weeks that follow. This is what each one does well, the wall every one of them hits, and why source export is the single feature that decides how the story ends.

Ask any coding agent for a landing page and you recognise the output before you finish scrolling. The fix is not a better prompt — it is persistent design context. This guide reviews every Claude Code design plugin, skill and MCP server worth your time, and ends with a skill file you can install in one command.

There is no universally correct weekly or monthly app update schedule. This guide gives founders a risk-based release system: how to separate hotfixes, maintenance and product releases, when to hold a build, and which signals should change the calendar.

AdMob mediation can improve competition for an impression, but more networks do not automatically create more profit. This indie-app guide covers architecture, partner selection, SDK risk, A/B testing, reporting and the operating controls that protect retention.

Deleting an app account does not automatically cancel an Apple or Google subscription. This implementation guide separates identity, personal data, billing and entitlement state so users receive a clear, compliant and testable deletion flow.

Low traffic does not prevent learning; it prevents small-effect A/B tests from resolving quickly. This guide shows indie teams how to select high-information tests, size decisions, combine behavioural and qualitative evidence, and report uncertainty honestly.

User-generated content turns moderation into a continuous product operation, not a policy page. This guide maps preventive controls, reporting, queues, severity tiers, enforcement, appeals, evidence retention, staffing and App Store or Play review readiness.

A healthy global crash rate can hide a severe defect on one popular device family. This runbook shows how to move from Play Console’s device breakdown to variant-aware reproduction, evidence-based mitigation, verified fixes and safe rollout.

A referral programme becomes a payment system the moment rewards have value. This guide shows founders how to model abuse, validate qualifying events, use device integrity safely, control reward release, investigate clusters and protect legitimate advocates.

Reviews are public product evidence; support tickets contain deeper diagnostic context. This playbook unifies both into a privacy-aware operating loop for incident detection, helpful replies, theme analysis, roadmap evidence and release verification.

The first 1,000 users require a bridge between hand-recruited learning and repeatable distribution. This guide gives founders a 12-week channel sequence, activation gates, weekly scorecard, ethical launch tactics and evidence-based transition to paid growth.

A founder-friendly control sheet for the app behaviours most likely to create privacy, billing, account-deletion, UGC, permission, SDK, and review problems on Apple and Google Play.

Play Console is more than the upload screen. This field guide shows founders how to use its overlooked acquisition, testing, quality, release, policy, and financial controls as one operating system.

App SEO is not a trick for indexing screens inside a binary. It is a web demand, content, technical-routing, store-conversion and measurement system that turns qualified searches into installs or app opens.

Most App campaign bid strategy arguments are really eligibility arguments. Google publishes a conversion-volume requirement for tROAS, a warning that small budgets on Maximize conversions may get no conversions at all, and an explicit caution against bidding on more than one in-app action. Read in order, those three rules decide the strategy for you.

Someone on your team wants to know whether shaving megabytes off the build will move installs, and every number they can find online is a vendor blog quoting another vendor blog. Google does document the relationship, in plain language, on pages that disagree with each other about the actual limit. Here is what the primary sources say, what they do not say, and which Play Console metrics tell you whether size is costing you anything.

Most App campaigns are lost in the setup screen, not in the auction. Google publishes the budget-to-bid ratios, the conversion-volume floor and the asset counts the system needs, and almost every failing launch has broken one of them before a single impression served. This is the launch sequence in the order the documentation supports it.

You changed the title, the screenshots and the description, and three weeks later nothing has obviously happened. Part of that is real: the stores publish two timing anchors worth planning around, a 28-day quality window on Google Play and a 90-day test length on the App Store. The rest of the timeline is undocumented, and most of the confident week-by-week figures circulating about ASO are invented.

You shipped an update, the crash rate moved, and now you are trying to work out what you can actually take back. The two stores answer that question very differently: Apple gives you a fixed seven-day ramp you can pause, Google gives you a percentage dial and a halt that works even after full rollout. Neither one removes a bad version from a phone that already has it.

Your ad platform claims one install number, Play Console shows another, and App Analytics shows a third. None of them are lying. Each store counts a different event, at a different moment, for a different population of users, and once you know which event each report is actually counting the three numbers stop contradicting each other.

Your app is live, the listing looks fine, and it appears nowhere. "Not ranking" is not one problem — it is at least six, and they fail in a fixed order. Work the fault tree from indexing upward and most teams find the answer two branches before they reach keyword strategy.

Your cost per install has drifted upward for three weeks and the campaign settings have not changed. That combination has a small number of documented causes, and most teams check them in the wrong order — starting with bids, which is the one lever most likely to make the problem worse. This is the fault tree we work through instead.