Developers report App Store rejections for missing real‑device screen recordings under Guideline 2.1

App Store review is supposed to check whether an app works. But for a growing number of developers, “works” now seems to mean “prove it on video, on a real device, with paperwork attached.” That is the thing to understand here. The news is not that Apple changed Guideline 2.1 on paper this week. It’s that developers are describing a tougher review posture around the same rule — more evidence, more attachments, more back-and-forth — while Apple’s upload pipeline is already stricter on privacy manifests before review even begins. (developer.apple.com) ### What is Guideline 2.1, exactly? Guideline 2.1 is Apple’s “App Completeness” rule. In plain English, the app has to be finished, functional, and reviewable when Apple opens it. Apple says over 40% of unresolved review issues fall under 2.1, and it explicitly warns that missing instructions, incomplete information, crashes, placeholder content, or blocked reviewer access can delay or fail review. (developer.apple.com) ### Why are screen recordings showing up? Because review teams need a fast way to verify flows they can’t reliably reproduce themselves. Apple’s tooling already supports “App Store review attachments” for “specific app documentation, demo videos, and other items” to help prevent delays, and App Review details let developers provide demo credentials, notes, and attachments in App Store Con(developer.apple.com)s, that lines up with infrastructure Apple already has in place — even if the public guideline text does not say “every app must upload a video.” (developer.apple.com) ### Why a real device, not Simulator? Basically, a Simulator can hide the exact thing review is worried about. Hardware permissions, camera behavior, biometrics, push flows, location prompts, payment handoffs, and performance edge cases often behave differently on actual iPhones and iPads. Apple’s review process is built around real-device testing an(developer.apple.com) in play, record the app running on real hardware so the reviewer can see the complete path. (developer.apple.com) ### Where do third-party SDK lists come in? Apple has been moving responsibility for bundled code onto the developer for a while. Its guidelines say you are responsible for making sure everything in your app complies — including ad networks, analytics services, and third-party SDKs. That makes SDK inventories relevant during review, especially if a reviewer is trying to understand login, (developer.apple.com)rivacy-manifest rules too. (developer.apple.com) ### What about ITMS-91053? That part is real, official, and older than this week’s complaints. Apple said submissions starting May 1, 2024 need required reasons for covered APIs, plus privacy manifests and signatures for certain third-party SDKs, and apps that fail those requirements “won’t be accepted.” Apple also says (developer.apple.com)o Guideline 2.1. (developer.apple.com) ### Why are developers talking about on-demand resources? Because reviewers worry about apps changing behavior after approval. Apple’s on-demand resources are tied to app submissions and hosted by the App Store for public distribution, and Apple forum guidance says asset packs are tied to a specific app version. That means version-linking remote resources is one way developers try to show that(developer.apple.com)s a new Apple rule than a defensive move against “you changed something after review” suspicion. (developer.apple.com) ### Is this a formal policy change? Not cleanly — at least not from the public documents surfaced here. The public rules and docs already give Apple room to ask for instructions, demo accounts, notes, and attachments. What seems to be changing is enforcement style. Developers are reading the same Guideline 2(developer.apple.com)eports. (developer.apple.com) ### Bottom line? The practical checklist is getting longer. A shippable app is no longer just a clean binary — it is a clean binary, valid privacy manifests, review credentials, and, increasingly, a package of proof that the app behaves on a real device exactly the way the listing says it does. (developer.apple.com)