Rescue a mobile app that won't ship.

The hardest part of inheriting a mobile app is that it fails on hardware you don't have in front of you. A crash that never happens on your test device happens on a specific phone, a specific OS version, under a specific amount of memory pressure — and without crash reporting wired in (Sentry, Crashlytics or an equivalent), nothing records what state the app was in or what the user had just done when it went down. You're left trying to reproduce a fault you can't see, across a range of devices and OS versions far too large to test by hand.

The stores' own dashboards help less than you'd hope. They cluster crashes and hand you a stack trace, but without the surrounding context — the user's path, the data on screen, the device conditions — a trace tells you where the app fell over without telling you how it got there. What should be a quick read becomes a long stretch of educated guessing, which is exactly why the first move on an inherited app is to instrument it properly before changing anything.

Store rejections tend to get treated with the same misplaced mystery, and usually don't deserve it. Apple's and Google's review guidelines are public, and rejections cluster around a short, well-known list: permissions not requested or explained the way the platform requires, incomplete store metadata, a crash during the reviewer's own launch, demo credentials that don't work, or an in-app purchase flow that doesn't follow store rules. These are specific, previously-seen, fixable causes. Teams stay stuck not because the reason is exotic, but because they patch a guess and resubmit without first pinning down which exact clause the rejection points to.