Finished code does not mean an application is ready for release. A store release also includes a signed artifact, available backend services, privacy declarations, permissions, store metadata, reviewer access, and an Arabic experience that works outside the developer’s device.
This checklist is informed by public releases through my Apple Developer profile and Google Play Developer profile. A live listing proves publication. It does not predict how long a future review will take or what it will decide.
Freeze the release identity
Before opening App Store Connect or Play Console, write down:
Public app name:
Bundle ID or package ID:
User-visible version:
Build number:
Backend environment:
Privacy and support URLs:
Reviewer access method:
Features included in this release:Confusing a test build with the production candidate creates failures in APIs, notifications, privacy links, and analytics.
1. Test the signed artifact
Do not rely only on Debug or a build connected to a development server. Test the artifact you intend to upload:
- Clean installation and cold start.
- Sign-in and sign-out.
- Slow and missing network.
- Notifications and deep links.
- Denied and later accepted permissions.
- Upgrade from the previous version when one exists.
- Account or data deletion when required by the product.
2. Keep reviewer dependencies available
Apple asks developers to provide complete review access, including a demo account or a fully featured demo mode for account-based apps, and to keep backend services available during review. A correct binary can look broken when access instructions are incomplete or the API is offline.
Use a reviewer account that contains no real customer data and exposes the features that need review. Keep credentials in the store’s protected review fields, never in a public repository or note.
3. Trace privacy from code to declaration
Do not complete App Privacy or Data Safety from memory. Review:
- Registration and profile fields.
- Analytics, crash, and advertising SDKs.
- System permissions.
- Images, files, and location uploads.
- Backend logs and retention.
- Third parties receiving data.
Google states that the developer is responsible for complete Data Safety declarations, including collection by third-party libraries. Apple requires privacy information that accurately describes collection, use, sharing, retention, and deletion paths.
4. Minimize permissions
Every permission creates technical and policy questions. If a photo picker can complete the task without broad library access, do not request more. If a feature does not need background location, do not ask for it.
Test denial. The app should explain what is unavailable and how the user can change the decision without becoming trapped in an empty state.
5. Review Arabic store content
Check:
- App name and subtitle without truncation.
- A description focused on user outcome.
- Screenshots from the current build with real copy.
- Screenshot order matching the user journey.
- Mixed Arabic, English, numbers, and links.
- Support and privacy URLs available without sign-in.
6. Keep screenshots honest
Do not present a missing feature or an old interface. The reviewer and user should be able to find what the description and screenshots show.
On Google Play, prepare categorization, contact details, the store listing, screenshots, and the required testing path for the account. “Submitted” is not “published.” Keep accepted artifact, review status, track availability, and public release as separate facts.
7. Write review notes as a test path
Useful review notes are specific:
1. Open the app and select Arabic.
2. Use the reviewer account in the protected access field.
3. Open the sample request from the home screen.
4. The camera permission appears under Attach document.
5. This account does not create a real purchase.Do not say “everything is clear in the app” when a feature is unusual or access is restricted.
8. Prepare support after submission
Before submitting, know:
- Who watches crashes and backend health?
- Who can disable a failing feature?
- What is the rollback plan?
- Where do support messages arrive?
- Who answers a rejection or policy question?
- Can the previous app version use the new API safely?
Use this checklist when
- The application is Arabic or bilingual.
- Accounts, APIs, notifications, or permissions are involved.
- Data collection needs store declarations.
- More than one person manages release work.
Do not treat it as an approval guarantee
Store policies are living documents. Review requirements depend on the product, market, data, and features. Check the official sources on the day of each submission.
Conclusion
A reliable release is a complete chain: signed artifact, available environment, accurate metadata, matching privacy declarations, useful review instructions, and post-release monitoring.
Run the Arabic app and RTL testing checklist against the signed build before submission.