App Review banned our core mechanic. Notarization let it through - and caught something else

In an earlier post I described how we distribute our iOS app outside the App Store through AltStore PAL. The most common follow-up question was "what about review?". We now have numbers: two App Review rounds and six notarization rounds, two of which ended in rejection. Here is what that looked like.

The app is Rate Me: people upload their photos and get 1-10 ratings from other people. That mechanic matters for the rest of the story.

What notarization is, briefly

If you distribute through an alternative marketplace (EU, Japan, Brazil), your build does not go to App Review - it goes to Notarization. Apple describes it as a baseline review focused on platform security, privacy and device integrity: automated checks plus human review confirm that the app is free of known malware, functions as promised and does not expose users to egregious fraud (Notarization for iOS apps).

People usually read that as "notarization is a virus scan, guidelines do not apply there". In our experience that is exactly half true.

Timeline: eight review rounds

All timestamps come from App Store Connect, the History section (which also holds your alternative distribution package IDs).

Lesson 1: content really is not reviewed

The rejection that closed the App Store for us was Guideline 1.2: rating people on their appearance, objectification. No amount of copy rewriting fixes that - it is what the app does. The same rejection also cited 5.1.1(v): no full in-app account deletion.

Then the interesting part: the same mechanic, unchanged, passed notarization - four times. Neither notarization rejection mentioned 1.2 or anything about content. For apps that the App Store rejects on content grounds, that is the practical takeaway: alternative distribution is not a loophole, it is a different kind of review.

Lesson 2: formal guidelines still apply

This is where "notarization is just a virus scan" breaks.

Rejection on 2026-09-08, Guideline 2.1: "app uses the AppTrackingTransparency framework, but we are unable to locate the ATT permission request". The review ran on an iPad Pro 11", iPadOS 26.6.1 - a human opened the app and looked for the prompt.

The cause is instructive. We had removed ATT back in July: there is no ATTrackingManager in the code and ads are non-personalized. But NSUserTrackingUsageDescription came back into the build - copied from an old working copy on another machine without checking history. To Apple that is a declared tracking intent with no prompt, so: rejected.

The rule is simple: do not ship NSUserTrackingUsageDescription unless the code actually calls ATTrackingManager.requestTrackingAuthorization. We had been caught by the mirror image of this two months earlier in App Review: the key was there, the wrapper was there, and nothing ever called it.

Lesson 3: the reviewer opens your web pages

Rejection on 2026-09-10, same submission, Guideline 4.8 Login Services. The reviewer (a different device this time, iPad Air M3) opened our sign-in page at auth.rateme.lv, saw Google and Facebook buttons, and asked for an equivalent login service that does not collect data without consent.

Note that those buttons are not in the app - they are on a web page the app opens. For review purposes that is still part of the product.

The fix gave us the single most useful observation of the whole story: we never rebuilt the binary. We added Sign in with Apple on the identity service side (App ID plus capability, Services ID, key, return URL), verified that the sign-in page now offers three providers, and resubmitted the same build (8) with a reply to the reviewer. Approved a bit over a day later. If a rejection is about your server side, you do not need another archive, upload and wait - fix it and reply.

Turnaround: a week at first, hours now

The nicest finding of these two months is that our notarization queue got an order of magnitude faster:

• first version, 1.0.3: a week end to end (review started within three hours, the verdict took seven days);
• 1.0.4: 33 hours;
• the 1.0.5 rounds: 8 to 42 hours;
• latest version, 1.1.0: 3 hours 46 minutes, and the review itself took one minute.

I cannot tell whether that is Apple's queue warming up or the account building a track record, but you can now plan a release in days rather than weeks. Two rejections in a row still cost us three days on 1.0.5 - a rejection is far more expensive than the review itself.

A checklist before your first notarization submission

Collected the hard way:

1. Info.plist: no keys for frameworks that are not in the code. ATT is the classic case, but the rule is general.
2. Keep usage strings in English. Review runs on an English system; a localized string reads as an unexplained prompt.
3. Actually open every web page your app shows: sign-in, password reset, legal pages. They get looked at.
4. If your sign-in page offers social logins, you need an equivalent option that satisfies 4.8.
5. Fill in the reviewer notes. In both of our cases an explanation there shortened the next round.
6. Be ready to use "Reply to reviewer": some rejections close with a server-side fix and no new build.

Caveat

This is one app and eight review rounds, not a sample. Notarization may have caught us on 2.1 and 4.8 by chance and may catch something else in your app. But the direction looks stable: content is not reviewed, the technical honesty of your declarations is - and it is checked by a human on a real device.

Rate Me lives at rateme.lv; the distribution setup itself is in the previous article. Happy to answer questions in the comments.