01 / The issue
Why this decision deserves attention.
The social app was first rejected under Guideline 4.3(b) as too similar to apps in a saturated category. The team appealed using its core mechanic, business model and pilot data, and rewrote the listing to make the differentiation clearer.
Later reviews found an onboarding bug, tested an unsupported iPad path, and flagged vague location and photo permission strings plus an incorrect age-assurance answer.
The founder reports that direct clarification in Resolution Center sometimes worked better than resubmitting. Apple’s own guidance also asks developers to provide review access and explain non-obvious features and purchases in review notes.
02 / The principle
What the evidence tells us.
Submission is not just uploading a binary. Reviewers must be able to access the complete product, understand why it belongs in the store and see specific reasons for every sensitive permission.
03 / The decision
What to change in the way you work.
- 01
Support differentiation with user evidence and precise store metadata.
- 02
Test the exact devices, accounts and states a reviewer can encounter.
- 03
Write permission copy with a concrete in-app example rather than a generic benefit.
04 / How Ten Million helps
Submission & review
For a product at this stage, we turn the lesson into concrete working material:
- A preflight review against the relevant Apple guidelines
- Store description, keywords, screenshots and review notes
- Reviewer account, demo path and edge-case checklist
- A response or appeal structure for specific rejection reasons
05 / Builder playbook
What to do this week.
- 01
Map every login, purchase, permission and external dependency in the review path.
- 02
Give the reviewer working credentials and explain every non-obvious feature.
- 03
Check metadata and privacy strings against what the app actually does.
- 04
When rejected, separate clarification from a code or asset change before resubmitting.