# App Quality: Broken Functionality (Crashes, Won't Install, Unresponsive)

**Guideline:** app-quality/broken-functionality · **Store:** Google Play · **Risk:** high · **Difficulty:** medium · **Typical turnaround:** 1-3 days

Canonical URL: https://appstorereject.com/rejections/google/app-quality%2Fbroken-functionality/app-quality-broken-functionality-crashes-wont-install-unresponsive

## Description

Google rejects apps that crash, force close, freeze, or otherwise function abnormally under its Broken Functionality policy, which explicitly bars apps that don't install, install but don't load, or load but are not responsive. 

This is Play's rough equivalent to Apple's App Completeness guideline, and it's frequently triggered by the automated Pre-launch report (powered by Firebase Test Lab) catching crashes or ANRs on specific device models, or by a reviewer hitting a broken in-app purchase flow, dead link, or unresponsive core feature during manual testing. 

A common blind spot is IAP/paywall failures caused by geo-availability misconfiguration — the reviewer's test region can't fetch your product listing, which reads as broken functionality even though the app works fine for real users elsewhere.

## Common variations

- Violation of Broken Functionality policy
- Apps that don't install
- Apps that install, but don't load
- Apps that load, but are not responsive
- The item that you were attempting to purchase could not be found

## Example rejection email

```
Google Play Console — Policy status

Issue found: Violation of Broken Functionality policy

We don't allow apps that crash, force close, freeze, or otherwise function abnormally.

During review, we found that your app:
- Crashed or became unresponsive during normal use, OR
- Failed to complete a core advertised feature

Details: "The item that you were attempting to purchase could not be found." This may indicate your in-app product configuration is not available in the region used for review, or a broken payment flow.

Action required:
- Reproduce and fix the crash, ANR, or broken feature
- Verify all in-app purchase products are configured and available in every country where your app is distributed
- Test your app end-to-end using the Pre-launch report before resubmitting
- Resubmit your app for review once verified

Learn more: https://support.google.com/googleplay/android-developer/answer/9898783
```

## Resolution steps

## How to Fix a Broken Functionality Rejection

1. **Pull the Pre-launch report**
   In Play Console go to Test and release > Testing > Pre-launch report. It runs Firebase Test Lab's Robo test across a range of devices and surfaces crash logs, ANRs, and screenshots at the point of failure — start here before guessing.
2. **Check Android vitals for crash/ANR spikes**
   Quality > Android vitals shows your User-perceived crash rate and ANR rate. Google's "bad behavior" thresholds are ≥1.09% crash rate (or ≥8% on a single device model) and ≥0.47% ANR rate (or ≥8% on a single device model) — exceeding these can trigger reduced discoverability independent of a manual rejection.
3. **Reproduce on the flagged device/OS combination**
   Pre-launch reports list the specific device model and Android version where the failure occurred. Test on that exact configuration (physical device or matching emulator image) rather than only your primary dev device.
4. **Verify every advertised feature end-to-end, including IAP**
   If the rejection cites a purchase flow ("item could not be found"), confirm your in-app products/subscriptions are published and available in every country your store listing targets — a product missing in the reviewer's test region reads as broken functionality.
5. **Check for unhandled exceptions and network-failure states**
   Wrap network calls and config fetches (especially anything gating your paywall or core screen) in proper error handling so a timeout or empty response doesn't crash or freeze the UI.
6. **Use the pre-review automated check before submitting**
   On the Publishing overview page, under "Changes not yet sent for review," Google now runs a fast automated check (~15 minutes) that can catch some Broken Functionality issues before you submit for full review.
7. **Test through a closed or internal testing track**
   Distribute a release candidate via Internal testing or Closed testing and have real testers exercise every core flow (install, first launch, primary feature, IAP if applicable) on varied devices before promoting to production.
8. **Resubmit only after confirming the fix**
   Re-run the Pre-launch report on the new build and confirm crash-free/ANR-free behavior on the previously flagged device before resubmitting for review.

## Appeal guidance

Appeal only if you have evidence the crash was environment-specific to the reviewer's test conditions (e.g., a region-locked IAP product that works correctly for your actual user base, or a Pre-launch report showing no reproducible crash on the cited device after investigation). Include your Android vitals crash/ANR rate for the affected device, Pre-launch report screenshots showing a clean run, and a changelog of what you fixed. If you can reproduce the crash yourself, don't appeal — fix it and resubmit, since Google's review notices rarely include full stack traces and repeated appeals without a code fix don't change the outcome.

## Before / after examples

**Before:** A subscription app's paywall screen calls a remote config endpoint to fetch pricing; when that call times out or the reviewer's test region has no matching product ID, the screen throws an unhandled exception and the app force-closes.
**After:** The developer adds a timeout + fallback UI state ("Pricing unavailable, try again") instead of crashing, and confirms all subscription products are published in every country listed in the store listing's distribution settings.
**Why it works:** Handling the failure state gracefully and matching product availability to actual distribution countries eliminates both the crash and the region-specific 'item could not be found' error that Google's reviewers read as Broken Functionality.

## Common questions

**Can you appeal a app-quality/broken-functionality rejection?**

Appeal only if you have evidence the crash was environment-specific to the reviewer's test conditions (e.g., a region-locked IAP product that works correctly for your actual user base, or a Pre-launch report showing no reproducible crash on the cited device after investigation). Include your Android vitals crash/ANR rate for the affected device, Pre-launch report screenshots showing a clean run, and a changelog of what you fixed. If you can reproduce the crash yourself, don't appeal — fix it and resubmit, since Google's review notices rarely include full stack traces and repeated appeals without a code fix don't change the outcome.

**How long does this typically take to fix?**

Typical turnaround is 1-3 days (difficulty: medium). After resubmission, most re-reviews complete within 24-48 hours.

---
*Machine-readable source: https://api.appstorereject.com/api/rejections/detail?slug=app-quality-broken-functionality-crashes-wont-install-unresponsive*