What binary requirements must your app meet for approval

App Store approval feels, from the outside, like a quality check. Submit something well-built and it goes through. Submit something broken and it comes back. That is the theory. The reality is considerably more complicated, and the gap between the two has cost real products real money.

The requirements that cost real products money are the ones that only surface after your first rejection.

The requirements that matter most are buried inside the logic of your product category, surfacing only after your first rejection, and shifting depending on what Apple happens to be building in the background. We have learned this the hard way across multiple projects, and the currency exchange app we worked on is the clearest illustration of how badly it can go when compliance requirements are not mapped out before a line of code is written.

Binary requirements are those where there is no negotiation. Either your app meets them or it does not ship. Understanding which requirements fall into that category, and which are matters of degree, is the first thing any product team building for the App Store should work out. This article walks through the main categories, what each one actually demands, and where teams tend to get caught out.

How the App Store review process actually works

Apple reviews every app submission against its App Store Review Guidelines, a document that covers everything from privacy and data collection to content, payments, and legal compliance. According to Apple's published data, around 90% of submissions are reviewed within 24 hours. The speed is real. The consistency is not.

In practice, the review process works in passes. A reviewer looks at the binary, checks it against the guidelines, and either approves it or raises a rejection reason. If you resolve that reason and resubmit, a different reviewer may pick up the app, and they may find something the first reviewer missed, or choose to interpret the same guideline differently. This is the system working as designed.

What this means for teams is that passing review once does not guarantee passing it again after an update, and resolving one rejection does not mean no further rejections will follow. On the currency exchange project, Apple raised a new objection every time we resolved the previous one. The stated reasons changed. The underlying objection did not. That kind of rejection loop has no formal resolution path, and teams rarely discover it exists until they are already inside it.

Read the rejection reason carefully before resubmitting. Apple's stated objection and the underlying concern are not always the same thing, and fixing only the stated issue can leave you in a loop.

Financial app requirements: AML, KYC, and transfer limits

Financial products face the most extensive binary requirements of any app category. This is a regulatory reality that Apple enforces at the review stage, often more stringently than the underlying law technically requires.

On the peer-to-peer currency exchange product we built, users could swap leftover foreign currency with other travellers at interbank rates, cutting out commission entirely. We built the core transfer mechanism well. What we did not factor in was anti-money laundering compliance. Apple flagged the product as a potential vehicle for laundering because the transfer capability was unlimited. We had to retrofit several layers of compliance after the fact, including more stringent Know Your Customer checks, enhanced transfer security, and hard limits on the number of transfers permitted between any two parties.

Following a later pivot to an in-person exchange model, Apple raised further money laundering concerns. To satisfy those, we imposed a transaction cap of approximately €100 to €150, intended to prevent the platform being used to move large sums. The compliance work came after the build, which meant it cost more and took longer than it would have done if we had mapped these requirements before writing the first line of code.

The lesson is direct. If your product touches money movement in any form, map your AML and KYC requirements at the discovery stage. Any app that allows value to transfer between users will be scrutinised for laundering risk, regardless of how small or well-intentioned the transactions are.

When the review process stops being about compliance

There is a version of the App Store rejection loop where the guidelines are being applied in good faith, and your product has a genuine gap to close. And there is another version where something else is happening entirely.

On the currency exchange app, the client spent significant money on legal counsel and compliance work to satisfy each successive rejection. Every time we resolved Apple's stated objection, Apple raised a new one. Eventually, the client ran out of budget and abandoned the product. It later became apparent that the repeated rejections coincided with the build-up to the launch of Apple Pay and related payment services. The rejections, in retrospect, looked strategic rather than compliance-based.

The App Store review process has no effective mechanism to challenge what looks like strategically motivated rejection.

The App Store review process has no effective mechanism for a developer to challenge this behaviour. Apple does not publish the criteria by which iterative rejections are evaluated, and there is no appeal process that meaningfully addresses a pattern of shifting objections. A well-funded incumbent can use this to block a compliant competitor from reaching the market, and the developer has very limited recourse.

This matters for any product operating in a category Apple competes in or plans to compete in. Payments, currency, financial tools, and productivity apps that overlap with Apple's native functionality are all more exposed to this risk than apps in categories Apple has no stake in. Understanding that risk before committing significant build budget is a reasonable precaution.

If your product competes with or overlaps Apple's own native services, model the review risk into your project plan before you start building. Budget for legal counsel early rather than treating it as a contingency.

Authentication and user identification requirements

Apple's guidelines do not mandate a single authentication approach, but your product's legal context often will. The binary question is whether your app requires verified user identification before granting access, and the answer depends almost entirely on what your product does with the data it collects.

The general principle we follow is to defer authentication as long as possible, letting users experience enough of the product to understand its value before asking them to commit to registration. Asking for sign-up on the first screen loses a meaningful share of potential users before they understand what they are registering for.

On the anonymous messaging app we worked on, that principle did not apply. We had to put authentication right at the front because the nature of the product meant we could not allow users to send messages without being able to tie those messages to a specific account on the back end. The messaging was anonymous to other users within the product, but we needed the ability to identify senders for legal reasons, specifically to handle cases of abuse or harassment. The authentication requirement was not a product choice. It was a legal one, and it shaped every subsequent decision about how the app was structured.

The consequence of front-loading authentication is real. Users who have not yet seen the product's value are being asked to hand over their details, and many will not. That trade-off is sometimes unavoidable, but teams should understand exactly why they are making it before they build the onboarding flow around it.

Data handling, storage, and privacy requirements

Apple's App Store requires a privacy nutrition label for every app, disclosing what data is collected, whether it is linked to a user's identity, and whether it is used for tracking. This is not a formality. Apple reviews the declared data practices against the app's actual behaviour, and a mismatch between the two is a binary rejection criterion.

Beyond the label itself, the question of where data is stored and how it is accessed determines whether an app can be approved in certain jurisdictions. Apps handling health data, financial data, or communications data are subject to additional scrutiny, and the standards are stricter than developers typically anticipate.

On the performance coaching survey app we built, the requirement was to ensure survey responses could not be collected outside of the designated session window and that the QR codes used to access surveys were not stored externally. We used iOS's built-in libraries to generate the QR codes entirely within the presenter's native app. None of the code was stored outside the app. Once the presenter marked a survey as finished, no further responses could be recorded. The design made the data handling both secure and demonstrably bounded, which simplified the privacy declaration considerably because the data collection had a clear start and end point rather than being open-ended.

The broader point is that data architecture decisions made early in a project directly affect what the privacy label can legitimately say. Designing with that in mind from the start is considerably easier than retrofitting privacy compliance after the product is built.

In-app content and messaging requirements

Apple's content guidelines cover user-generated content, messaging, in-app communications, and any mechanism that allows one user to send information to another. The binary requirement is that any app enabling user-to-user communication must include a mechanism to report and filter abusive content, block specific users, and prevent the platform from being used to send content that violates Apple's guidelines.

This extends to automated messages. If your app can generate or permit messages that are not produced by a verified human user, Apple expects you to demonstrate that your content moderation system accounts for that. A generic messaging implementation that does not reflect the product's actual use case is a common source of rejections that teams do not anticipate until they are deep into the build.

• User-to-user messaging must include block and report functionality
• Automated or bot-generated messages require explicit moderation controls
• Content filters must be active, not optional
• Any mechanism for sending media must be covered by the same safeguards as text

The practical implication is that the content requirements for a messaging feature are not separable from the product's core premise. An app built around verified, human-to-human interaction needs a messaging system that enforces that. An app that applies a generic messaging component without designing it to reflect the product's actual rules is building something that will either get rejected or undermine the product it sits inside.

When a feature contradicts your own app's premise

Some rejections are purely about internal coherence. Apple's reviewers look at whether a feature is consistent with what the app claims to be doing, and a product that contradicts its own premise creates problems that the guidelines do not neatly resolve.

On a dating app project focused on verified profiles and bot prevention, the client chose to skip discovery for the messaging component and focus purely on the onboarding process. The onboarding was rigorous. The messaging feature, built without a discovery phase, was generic. It allowed automated messages and had no mechanism to enforce the verification standards the onboarding had established. The mismatch between a carefully verified entry process and a permissive messaging system meant the entire messaging section had to be rewritten, at a cost of approximately £15,000 and two additional months of work.

The problem was not that the messaging feature was technically deficient. It was that the feature contradicted the product's stated purpose. A platform built on the premise that every profile is real and every interaction is genuine cannot include a messaging layer that permits the opposite without undermining the whole product.

Run a consistency check across every feature before it goes into the build. If a feature would be fine in any generic app but conflicts with your specific product's rules, it will create problems that cost more to fix after the fact than they would have done in discovery.

App Store listing requirements and pre-download communication

The App Store listing is subject to its own set of binary requirements, distinct from the binary review of the app itself. Screenshots must accurately represent the app's current functionality. The description cannot claim features that do not exist. The metadata, including the app's name, subtitle, and keywords, must not include content that could mislead users or inflate rankings artificially.

These are not just editorial standards. A listing that misrepresents the product is a rejection criterion at the binary stage, and Apple cross-checks listing claims against the actual app during review. An app that promises a feature the reviewer cannot find in the binary will be rejected on those grounds.

The listing also does substantive product work in situations where the app itself cannot communicate the product's value before registration. On the anonymous messaging app, because authentication was required upfront, we could not drip-feed value to users as they moved through the product. Everything that would normally unfold through early use had to be communicated before the user downloaded the app at all. That meant the App Store listing, the screenshots, and the preview video carried the entire weight of the first impression. The listing was not marketing. It was onboarding for users who had not yet agreed to onboard.

Teams who treat the listing as an afterthought and the binary as the real product tend to find out at launch that the two need to work together. Getting users to download an app that then asks them to register before showing them anything requires the listing to have done enough work that the registration feels worth it.

How to audit for binary requirements before you build

The most effective way to handle binary requirements is to treat them as a constraint to design around, not a checklist to complete after the build. An audit at the discovery stage costs a fraction of what a retrofit costs at the submission stage.

The audit has four components. First, identify your product category and any adjacent categories that Apple applies stricter requirements to, particularly finance, health, communications, and children's content. Second, map every feature that involves user data, user-to-user interaction, or value transfer, and check it against the current guidelines for that feature type. Third, identify any overlap between your product and Apple's own native services, and model the review risk that creates. Fourth, confirm that every claim in the listing is demonstrable in the binary before submission.

1. Identify your product category and its specific guideline requirements
2. Map every feature that touches data, messaging, or money against the relevant rules
3. Check for overlap with Apple's native services and assess the review risk
4. Verify that the listing, the screenshots, and the binary all describe the same product

The table below shows where different product types tend to carry the most binary risk, to help teams prioritise which areas to audit first.

Conclusion

Binary requirements are the ones that end a product's chances of reaching the market if they are not met. They are not guidelines in the loose sense. They are gates, and unlike most of the decisions in a product build, they are not negotiable at the point of submission.

The currency exchange project is the most direct illustration of what happens when these requirements are not mapped at the start. The AML and KYC gaps were not the fault of the guidelines being unclear. They were the result of compliance being treated as something to sort out after the product was built, and that sequencing cost the client money that a discovery audit would not have. The dating app's messaging rewrite tells the same story from a different angle. The feature was built without reference to the product's own rules, and the mismatch cost £15,000 and two months.

The pattern across both projects, and across the anonymous messaging app's authentication requirements and the survey app's data boundaries, is the same. The teams that move fastest through App Store review are the ones that understand their binary requirements before the build starts, design around them rather than retrofitting them, and treat the listing as part of the product rather than a separate task at the end.

If you are building an app and want to map the binary requirements that apply to your specific product before you commit significant budget, let's talk about your App Store strategy.

Frequently Asked Questions