Push notification marketing and App Review
Push review risk is not only the system permission prompt. It is the relationship between consent, message purpose, opt-out controls, payload data, and what the app promised users.
Separate transactional, product, and marketing notifications before writing copy. Apple guidance requires user permission for notifications, and App Review rules restrict using push for advertising or direct marketing unless users explicitly opt in and can opt out. AppReviewReady interpretation: keep a message taxonomy and consent record that a reviewer can verify from inside the app.
Classify every notification before requesting permission
Transactional notifications help a user complete or monitor an action they already asked for: delivery updates, security alerts, reminders, booking changes, account events, or collaboration messages. Marketing notifications try to increase engagement, sell something, announce promotions, or bring the user back without a user-specific transaction.
Put each message template in a taxonomy with owner, purpose, trigger, payload fields, opt-out route, and whether it is required for the app's core function. This stops product, lifecycle, and growth messages from all hiding behind one generic notification permission screen.
Ask for system permission after the value is visible
- Show the feature or workflow that benefits from notifications before presenting a pre-prompt.
- Explain the specific message types the user will receive, not a vague promise to 'stay updated'.
- Trigger the system prompt after the user chooses a notification-related action.
- Handle denial with in-app settings, email fallback, or manual status checks where appropriate.
- Confirm notification settings are reachable later without deleting the account or reinstalling the app.
Add explicit opt-in for promotional pushes
Marketing messages should not be silently bundled with operational notifications. A user who agrees to security alerts has not necessarily agreed to sale announcements. Keep promotional opt-in separate, name the category plainly, and provide an opt-out path inside the app.
AppReviewReady interpretation: screenshot the marketing toggle in both off and on states. If the app sends remote configuration or server-triggered campaigns, the backend should respect the same consent flag the app displays.
Keep payloads minimal and safe
- Avoid sensitive health, financial, child, location, or private-message content in lock-screen text unless the user controls that exposure.
- Do not include secrets, tokens, Apple IDs, bundle IDs, or unnecessary personal data in notification payloads.
- Verify deep links land on the promised screen and respect the user's current auth state.
- Test revoked tokens, deleted accounts, opted-out users, and expired subscriptions before submission.
Prepare a notification review route
If a notification is hard to trigger during review, include a server-side sample path or a test account state that can generate it. Do not rely on the reviewer waiting for a scheduled campaign.
Notification review path: Message categories: [transactional, reminders, marketing] Where permission is requested: [screen] Marketing opt-in location: [settings path] Opt-out behavior: [what stops] Sample trigger: [how reviewer can generate one] Sensitive payload policy: [what is omitted]
Freeze campaigns before review
A compliant build can still fail if a live campaign sends aggressive or misleading text during review. Pause experimental promotional campaigns for review accounts and verify that production campaign tooling cannot override the consent categories shown in the app.
Primary references checked for this guide
Policy statements above are grounded in the linked Apple documentation. Operational recommendations are AppReviewReady's interpretation and should be tested against your app and the current guideline text.
Audit notification readiness
Check permission timing, consent, payloads, and review evidence before submission.
Open the tool