What Apple checks in App Review: lessons from three apps
Apple's reviewers open your build, try to reach every screen, and check payments, sign-in, permissions and metadata against the App Review Guidelines.
Apple's App Review team installs your build, tries to reach every screen, and checks payments, sign-in, permissions and your store listing against the App Review Guidelines. You can prevent most of the problems yourself. They come from three places: the reviewer can't get into the app, the payment model doesn't match the rules, or the app asks for data without explaining why.
This article draws on three apps I built. IMPERIA THE1 is a fitness app with a mentor, live in the App Store. Prosto Pushka is a guest app for a lounge in Dubai; I submitted it to App Review on 27 October 2026 and it was still waiting as I wrote this. Lucent is a renter app for a supercar rental, finished and not published in the App Store. Pushka and Lucent have no review outcome, so for them I describe how I prepared the build and claim no result. If you need the account side first (company developer account, D-U-N-S number, Apple versus Google), read publishing an app as a UAE company in the Savage Media journal. This piece covers what happens to the build itself.
What a reviewer does with your build
A reviewer gets your binary, your App Store listing and your review notes. They open the app on a device, sign in if they can, tap through the main flows, try any purchase, and compare what they see with your screenshots and description. Guideline 2.1 (App Completeness) covers the basics: no crashes, no placeholder content, no broken links, and working demo access for anything behind a login.
This matters for UAE business apps because many of them are built around a physical place. The reviewer is not in your lounge, your clinic or your showroom. Everything that depends on being there has to work for someone who isn't.
Pushka: the reviewer can't scan your QR code
In Pushka, a guest's first sign-in happens at the venue. A staff member shows a QR code, the guest scans it and lands in their own card. The venue creates the card, so there is never a second empty one. After that, the guest signs in with Apple, Telegram or a code sent by email, with no password.
That design suits the lounge. For App Review it creates a gap, because the reviewer has no staff member and no QR code. An app like this needs a written path for the reviewer, which usually means one of these:
- A demo account with a pre-filled card, with the credentials in the review notes.
- A test code that opens a sample card without a venue scan.
Write the review notes in plain English, step by step: where to tap, what to enter, what the reviewer should see. If your interface is in Russian or Arabic, name the screens in the notes so the reviewer can find them.
Payments decide which rules apply
Guideline 3.1.1 requires Apple's in-app purchase for digital content and features unlocked inside the app. Guideline 3.1.3(e) covers physical goods and services consumed outside the app, and those must use other payment methods.
The three apps fall on different sides of that line:
| App | What the user pays for | How payment works | Rule that applies |
|---|---|---|---|
| IMPERIA THE1 | Basic and Pro tiers, 3 days free | Subscription inside the app | 3.1.1 and 3.1.2 (subscriptions) |
| Prosto Pushka | Food, drinks, time at a table | No payments in the app; the guest picks a payment method, pays at the venue, the cashier closes the bill | Physical service, outside the app |
| Lucent | Car rental | Payment screen for a real-world rental | 3.1.3(e), physical service |
In Pushka, an order from the table is a request to the staff on shift. Nothing is sold through the app and nothing is shipped. The live bill shows what has been served, the total, and how much cashback will cover. Keeping money out of the app keeps the review question simple.
Ask one question about every item a user can pay for: is it consumed inside the app or in the real world? A paid recipe pack or a premium video lesson is digital. A massage, a table or a rental car is physical. Mixed apps need both payment mechanisms, and the reviewer will check each one.
Subscriptions and trials: what a paywall like Imperia's must show
IMPERIA THE1 sells two tiers, Basic and Pro, with three days free. Pro includes a chat with a mentor. Auto-renewing subscriptions fall under guideline 3.1.2, and the reviewer looks at the paywall closely:
- What each tier includes, in words the user understands before paying.
- The price and billing period, visible next to the buy button.
- What happens when the free trial ends.
- A way to restore purchases.
The store listing has to match the paywall. Imperia's audience is Russian-speaking around the world. The interface is in Russian, and one Russian storefront text covers all locales. Because the app and the listing share a language, the description and screenshots tell the same story as the paywall. If you translate your listing into English for reach while the app stays in Russian, say so in the description so users and reviewers know what they will get.
Permissions and background modes
Every permission prompt needs a purpose string that explains why the app wants the data. The app may use the data for that reason only.
In Imperia, lessons and podcasts keep playing in the background. Heart-rate zone running uses voice cues that tell you when to run and when to walk. Guideline 2.5.4 allows background services only for their intended purposes, such as audio playback. A reviewer may lock the phone during a lesson to check that audio continues and that the app uses background mode for nothing else.
The water tracker I built for Imperia (currently in TestFlight) reads and writes Apple Health in both directions. Health data has its own section, 5.1.3, with its own rules. You can't use it for advertising, and the prompt has to say plainly what the app reads and writes.
Pushka POS is the staff app for the same lounge. It has a working geofence: alerts and the "guest is on the way" card go only to cashiers and waiters within about 1 km of the venue. That feature needs a location prompt. Write the purpose string in staff terms, for example "to send you alerts only while you are at work near the lounge".
Sign-in: what guideline 4.8 changes
Guideline 4.8 covers login services. If the main account uses a third-party login such as Google or Telegram, Apple generally expects an equivalent privacy-focused option next to it, and Sign in with Apple meets that. Pushka offers Apple, Telegram and an email code. Lucent offers Sign in with Apple in the profile.
Owners often miss a second account rule, 5.1.1(v). If users can create an account in the app, they must be able to start deleting it from inside the app. Ask your developer whether a card the venue creates for a guest counts as an account under this rule, and where the delete option sits.
Age rating and content for a lounge
Pushka is rated 18+. The age rating questionnaire in App Store Connect asks about content and context, and your answers have to match what the reviewer sees. A lounge app shows a menu with kitchen, bar, tea and house flavour combinations, with photos, ingredients and prices in AED. Answer the questionnaire for that content, and write the listing around the guest, the table and the bill.
Apple's rules and UAE advertising rules are separate. If your venue serves age-restricted products, check with a lawyer or the media regulator what you may show in a store listing. Apple's approval does not settle local compliance.
Lucent: a rental app with real-world safety screens
Lucent, the renter app, has these parts:
- a garage of cars by category and brand;
- a car page with a 360° view and engine sound with haptics;
- booking in a sheet, with the car brought to an address, a hotel or an airport (terminal and flight);
- payment, and "My rental" with extension and documents;
- a map of drop-off zones and a Live Activity that follows the car on its way to the renter;
- chat, and a help screen with SOS and the UAE emergency numbers 999, 998 and 997.
Before you submit an app like this, check two things. If you collect client documents, the privacy policy and the App Privacy labels in App Store Connect must list that data and say what happens to it. Apple's guidance says a Live Activity should show the live status of something the user started, here the car on its way, and should not carry advertising.
TestFlight is a different gate
Two of my apps are in TestFlight. Pushka POS is in an internal group. Lucent Staff, the rental's staff app, is ready for release. Internal testers get builds without App Review. External testers need Beta App Review. A public release needs full App Review.
So "it's in TestFlight" tells you the build runs on real phones. It does not tell you Apple has approved it. If a developer shows you a TestFlight build as proof the app is "approved", ask which group it is in. For how staff apps change daily operations, see staff apps for venues.
What not to do
- Submit an app that only works on site, with no demo path in the review notes.
- Put a physical service behind in-app purchase, or a digital feature behind a card form.
- Leave the paywall vague about what Pro includes or when the trial converts.
- Ask for location, Health or camera access "for future features".
- Use screenshots of screens the build does not have. If a feature sits behind a flag, leave it out of the listing.
- Show placeholder reviews, sample data or stock photos in the build.
- Treat Apple approval as UAE legal approval for your advertising.
Questions to ask your app developer
- How will the reviewer get past sign-in? Show me the review notes.
- For each paid item, which guideline applies, and why?
- Which permissions does the app request, and what does each prompt say?
- Where in the app can a user delete their account?
- Which background modes are on, and which feature uses each one?
- Do the screenshots match the build we are submitting?
- Is this build in internal TestFlight, external TestFlight, or submitted to App Review?
If you are planning a venue app, the full path from idea to submission is in a venue app from idea to App Store. The first-run experience is covered in an onboarding people finish. Project details are in the Pushka, Imperia and Lucent Rental cases. App development work is on the apps service page.
Checklist before you press Submit
| Check | Guideline | Done when |
|---|---|---|
| Demo access works without being on site | 2.1 | Review notes list steps and credentials |
| Each paid item uses the right payment method | 3.1.1, 3.1.3(e) | Digital = in-app purchase, physical = outside |
| Paywall shows tiers, price, period, trial end, restore | 3.1.2 | A stranger can explain the offer from one screen |
| Third-party login has a privacy-focused equivalent | 4.8 | Sign in with Apple offered where needed |
| Account deletion starts inside the app | 5.1.1(v) | Path tested on a fresh account |
| Background modes match real features | 2.5.4 | Each mode tied to one named feature |
| Health data used only as described | 5.1.3 | Prompt text lists what is read and written |
| Age rating answers match the menu and content | Age rating questionnaire | Answers checked against live screens |
| Screenshots and description match the build | 2.3 (Accurate Metadata) | No flagged or unfinished features shown |
Questions and answers
Does my venue app need Apple's in-app purchase if guests pay for food and drinks?
Apple requires in-app purchase for digital content and features used inside the app. Physical goods and services consumed outside the app, such as a meal, a table or a car rental, use other payment methods. Your developer should be able to name the guideline section that applies to each paid item.
My app only works after a QR scan at the venue. How will Apple test it?
The reviewer is not at your venue, so you give them a way in: a demo account, a test code or a review mode, described in the review notes. If the reviewer cannot get past the first screen, the review stops there.
Is TestFlight the same as being approved by Apple?
No. Internal TestFlight testers get builds without App Review. External testers need Beta App Review, and a public App Store release goes through full App Review.
Do I need Sign in with Apple?
If your app offers a third-party login such as Google or Telegram for the main account, guideline 4.8 generally requires an equivalent privacy-focused option, and Sign in with Apple is the usual answer. Email-only or your own account system follows different rules, so ask your developer to check before the build is submitted.