Surviving App Store review, part two — and how Google Play compares

Apple rejected us, we fixed the App Store rejection, and a few days later we were live. The short version: read the reviewer's note carefully, explain exactly what your app does in plain words, fix only what they flagged, and resubmit fast. This is part two. Here's the honest version of the second round — and how Google Play compared.

If you missed the first round, start with part one. This post picks up after that: a fresh rejection, a better Apple review response, and the moment Trott finally cleared both stores.

What Apple flagged the second time

The first rejection was about the basics. The second one was sharper. The reviewer couldn't see what the app actually did. They opened Trott, saw a clean screen waiting for content, and had no saved reels to test with. To them it looked empty. Not broken — just unclear.

That's the trap with a share-to-save app. The magic only happens after you've shared something in. A reviewer on a fresh install has nothing to share and nowhere obvious to start. So the rejection wasn't really "your app is wrong." It was "we don't understand it yet."

How we explained the app to the review team

We stopped arguing and started demonstrating. The Apple review response that worked had three parts:

• A plain-language summary. Two sentences. What you share, what you get back. No features list, no buzzwords.
• A step-by-step path to the core feature. "Open Instagram, share a reel to Trott, wait for it to read the video, then search for it." Exact taps.
• A short screen recording. One real save, one real search, start to finish. Reviewers test in minutes; we handed them the minute that mattered.

The lesson under all of this: a reviewer is a first-time user with a stopwatch. If your value lands in the first thirty seconds, you pass. If it needs setup, you fail — no matter how good the app is.

Resubmission turnaround, and what to prioritize

Turnaround surprised us. After we replied through Resolution Center with the notes and the recording, the next review came back inside a day. Fixing the actual issue was faster than the waiting had been.

If you're staring at a rejection, here's where to spend your hours — the things that actually moved the needle for us:

• Fix exactly what they cited. Nothing else. Don't ship a redesign mid-review. Address the line item, resubmit, keep the diff small.
• Make the first run obvious. We added a clearer empty state that tells you what to do, so a cold open isn't a dead end.
• Reply in writing, every time. A calm, specific note in Resolution Center does more than a resubmit with no explanation.

Google Play vs Apple submission

Then we did it all again on the other side. Google Play vs Apple submission is a real difference in feel, not just paperwork. Apple read our app like a person. Google checked it like a machine.

Play's review leaned faster and more automated. The first submissions cleared without a human writing us a note about empty screens. But the criteria sit in different places. Google cares hard about policy declarations up front — data safety, permissions, content rating, what you collect and why. Get those forms wrong and you're stuck before anyone even opens the app.

iOS vs Android, the differences that bit us

• Who's judging. Apple weighs the experience and whether the app earns its place. Google weighs policy compliance and declarations. Build for both audiences.
• Speed and predictability. Play tended to be quicker; Apple was slower but gave clearer human feedback when it said no.
• Where the work lives. On iOS the effort was the demo and the review notes. On Android it was filling out the data and permissions forms accurately the first time.
• The share sheet. Both stores expect a clean share-to-app flow, and both will notice if it's flaky. Because Trott is Flutter, the app shipped from one codebase, but each store's submission process was its own separate climb.

The part nobody warns you about

Rejection stings more than it should. You read the email, your stomach drops, you reread it three times convinced it's personal. It isn't. A reviewer spent a few minutes and couldn't find the point of the thing you spent months on. That gap is the feedback.

The cycle goes: rejection, a bad evening, then the slow realization that the fix is small and obvious. Resubmit. Wait. Refresh App Store Connect more than any adult should. Then the status flips to Ready for Sale and the whole bad evening evaporates. We've now felt that on both stores. It does not get less satisfying.

A pre-submission checklist we wish we'd had

Before you hit submit on either store, run through this. It would've saved us a round on each side:

• Install a fresh build on a device that has never seen the app. Reach the core value in under a minute.
• Write the two-sentence "what it does" summary and paste it into the review notes.
• Record a thirty-to-sixty second clip of the main flow, start to finish.
• Give the reviewer a real path: which other app to share from, what to type, what they'll see.
• Make sure the empty state explains the next step, so a cold open never looks like a dead end.
• For Google Play: finish the data safety, permissions, and content rating forms honestly and completely.
• Test the share sheet itself — the most reviewer-facing feature is the one most likely to break.

That's the whole second act. Two stores, two rejections, two approvals, and a lot of refreshing. If you want to see what survived all that review, the best test is to share one reel to it and search for it later.