Apple rejected our Flutter app update for one sentence in the paywall fine print

SENEKA App — Fri, 13 Nov 2026 04:57:37 +0000

Small one, but it cost us a full review cycle, so maybe it saves someone else a week.

Full disclosure: we make SENEKA, a game of everyday dilemmas, and this is about our own app. We build it in Flutter and ship one codebase to Google Play and the App Store. An iOS update came back from App Review with three issues. None of them was a crash.

1. Guideline 2.3.10: "remove Google Play references"

Our subscription fine print under the paywall said:

Payment is charged to your Apple ID or Google Play account at confirmation.

One shared string for both platforms. It's accurate, and Apple doesn't care. An iOS binary can't mention another store, even in legal small print.

The fix is boring: a separate iOS string, picked at runtime.

import 'dart:io' show Platform;

Text(tr(Platform.isIOS ? 'paywall.legalIos' : 'paywall.legal'))

The annoying part was doing it in all 16 languages we ship. Before you submit, grep your localisation files:

grep -rniE "google|play store|android" assets/l10n lib

Every hit that can reach an iOS screen is a possible 2.3.10.

2. Guideline 2.1(b): "we couldn't complete the purchase"

The screenshot attached to the rejection showed Apple's own system alert, "Account Not In This Store". The reviewer device was on the Singapore storefront and the sandbox account was from the US. Nothing in our code was involved.

What we did:

Replied in App Store Connect explaining the storefront mismatch, politely, without arguing.
Attached a screen recording of the full purchase flow running in Xcode's StoreKit test mode, from the paywall to the unlocked content.

If your app is available in many storefronts, it's worth saying in the review notes that purchases were tested with a sandbox account of the same storefront as the device.

3. Guideline 2.1(b): "we can't find the in-app purchases"

Our paywall only shows up in a few places: a locked pack, the end of a free journey, and settings. "It's in settings" wasn't enough. They want exact steps:

1. Launch the app and finish onboarding (2 taps).
2. Tap the "Explore" tab.
3. Tap any pack with a lock icon.
4. The paywall opens with the yearly and monthly plans.

Write it like the reviewer has never seen your app, because they haven't.

Bonus bug we found on the way

While re-testing the paywall we noticed the yearly plan's "per month" price didn't always match the store's own price formatting (currency symbol position, decimals). We were using a ready-made per-month string from our purchases SDK. Now we divide the yearly price by 12 ourselves and write it in the same format as the store's own yearly price string, with a small unit test so it can't drift again. Small, but a paywall that shows two price formats side by side looks broken.

Checklist before the next submission

[ ] No "Google", "Play" or "Android" in any string an iOS user can see, in every language
[ ] Review notes have tap-by-tap steps to each in-app purchase
[ ] A short recording of a sandbox purchase, ready to attach
[ ] Prices on the paywall all come from the store, in one format