Demo rescue
A web app that the App Store kept refusing
Packaging a web app for the stores is the easy half. The compliance surface behind it is what costs review cycles, and each cycle is days.
Built with Lovable, wrapped for iOS and Android
A demonstration build, not a client engagement. We built this app, broke it, and repaired it to show the method. No client is named or implied, and the figures below are measurements from this build alone.
- Stack
-
- Lovable
- Expo
- React Native
- App Store Connect
- Google Play
- Duration
- [n] days
01Before
What was broken
- S1
Rejected for minimum functionality
The first submission was a web view with no native capability, which Apple refuses under its minimum functionality guideline. Resubmitting the same build with a better description does not change the outcome.
- S2
Missing privacy manifest and required-reason declarations
The build used APIs that require a declared reason, and bundled third-party SDKs that require their own manifests. The submission stalled without a clear statement of which dependency was at fault.
- S3
Android target SDK below the current floor
The build targeted an API level Google no longer accepts for new releases, so it was refused at upload rather than at review.
- S4
Data safety answers did not match the app
The Play data safety form declared no data collection while the app sent analytics and account data. That mismatch is itself a policy violation, independent of the collection.
02After
What we changed
- C1
Genuine native capability, not a wrapper
Push notifications, biometric unlock, offline caching and native share implemented against the real platform APIs — so the app does things a browser tab cannot, which is what the guideline actually asks for.
- C2
Privacy manifests completed for the app and its dependencies
Required-reason API usage declared, third-party SDK manifests collected and verified, and tracking domains listed accurately. Each declaration checked against what the build actually does rather than what it intends to do.
- C3
Target API 36 and the changes it forces
Upgraded to the current Android target, and fixed what that surfaced: edge-to-edge layout with proper insets, and large-screen orientation behavior that no longer assumes portrait.
- C4
Declarations reconciled with the build
Data safety and privacy answers rewritten from an audit of actual network calls, plus in-app account deletion, which both stores now require for apps that allow account creation.
03Measured
What it measured
| Measure | Before | After |
|---|---|---|
| App Store review cycles before approval | [n] | [n] |
| Android target API level | [n] | 36 |
| Undeclared required-reason APIs | [n] | 0 |
| Days from first submission to live on both stores | — | [n] |
| Time to rescue | — | [n] days |
Figures are measurements from this demonstration build. All demo rescues
Your app probably fails in one of these ways.
The audit tells you which, with evidence and a fix estimate, in two business days. If it finds nothing material you do not pay for it.
Prefer to write? Send your requirements