Your Guide to the App Store Submission Process in 2026

Friday afternoon is a common time for teams to discover that a release-ready app is not submission-ready.

The build works. QA is mostly quiet. Marketing wants the date locked. Then App Store Connect or Google Play Console turns the launch into something else entirely. The app store submission process is part packaging, part compliance check, and part reviewer handoff. Teams that treat it like a final admin step usually pay for it in review delays.

The delays are rarely caused by one dramatic failure. They come from smaller misses that signal avoidable friction to a reviewer: missing login steps, placeholder copy left in a secondary screen, privacy answers that do not match the SDKs in the build, or reviewer notes that say nothing useful. Reviewers are not judging only the product. They are checking whether they can access key flows, verify claims, and clear the app without having to guess.

That last point gets underestimated. A well-built app can still stall if the reviewer has to reverse-engineer how to test it.

Store volume makes that practical reality even harsher. Review teams process an enormous number of submissions and updates, so clarity matters. The teams that get first-pass approval more often usually do one thing better than everyone else: they anticipate reviewer questions before review starts. The Notes for Reviewer field is where that work shows up, and it is one of the least-used advantages in the whole process.

A clean submission is not clerical polish. It is launch execution.

Table of Contents

• From Code Complete to Live on the Stores
• Pre-Launch Groundwork Your Essential Checklist
  • Start with release ownership and reviewer access
  • Build a submission packet, not just an app
  • Plan around store-side constraints before they become blockers
• Building and Signing Your App for Release
  • What signing accomplishes
  • Release build checks that catch review-time failures
• Preparing Your Store Listing and Metadata
  • Your listing sells the app and explains it to review
  • The Notes for Reviewer field decides more submissions than teams expect
  • What strong reviewer notes look like
• Navigating Privacy Compliance and Data Safety
  • Map your data before you touch the forms
  • The EU Trader Status Requirement Many Teams Miss
• The Submission and Review Gauntlet
  • What happens after you submit
  • The unwritten rule that saves approvals
  • What the statuses usually mean
  • How to handle the review window without creating new problems
• Common Rejections and How to Fix Them
  • Common App Store Rejections and Fixes
• App Store Submission FAQ
  • What should you do right after approval
  • How are updates different from first submissions
  • What if you think the rejection was wrong

From Code Complete to Live on the Stores

The last bug fix rarely marks the end of the project. It marks the handoff into a different discipline.

A finished app can still fail the app store submission process because stores review more than code quality. They review business model clarity, privacy declarations, metadata accuracy, account access, and whether the app feels complete. An app with polished features but weak submission prep often launches later than a simpler app with better reviewer support.

The practical shift is this: stop thinking like a developer shipping a build, and start thinking like an operator preparing a release. That means asking a different set of questions. Can a reviewer log in without guessing? Does the store listing match the actual product? If the app uses unusual hardware, time-gated content, or a backend flag, have you explained that clearly?

Practical rule: Reviewers don't debug your app for you, and they don't chase missing context. If they can't verify a feature fast, they usually move toward rejection instead of investigation.

There's also a launch timing reality. Apple's review flow is usually predictable for straightforward submissions, but predictability only helps if your own prep is clean. Teams get into trouble when they promise a release date before they've validated metadata, privacy paperwork, screenshots, and reviewer access.

That's why experienced teams treat submission as part of product delivery, not a final click. The stores are the gatekeepers, but they're also the first external operators who touch your app in a structured way. If you make their job easy, first-pass approval gets much more realistic.

Pre-Launch Groundwork Your Essential Checklist

Friday afternoon, the build is ready, QA has signed off, and the team wants to submit before the weekend. Then the release stalls on problems that had nothing to do with code. The company account still sits under a former contractor. The privacy policy URL points to a draft page. Reviewer login needs a one-time code that nobody documented. That is how launch dates slip.

The teams that get first-pass approval usually do one thing well. They prepare the review package before they prepare the upload. Stores are checking whether the app is understandable, testable, and accurately represented. Your groundwork should answer those questions before a reviewer has to ask them.

Start with release ownership and reviewer access

Account control causes more launch friction than many product teams expect. If the Apple Developer account or Play Console is tied to a personal email, fix that before release week. The same goes for banking, tax, legal agreements, and admin roles. A build can be perfect and still sit idle because the wrong person owns the console.

Lock down the permanent identifiers early. Bundle ID and package name choices spread into environments, analytics, deep links, OAuth settings, and marketing tools. Changing them late is possible in some cases, but it creates cleanup work that rarely pays off.

Reviewer access belongs in pre-launch planning, not in the last hour before submission. If login is required, create a stable test account, seed it with realistic data, and confirm it works on the release environment. If the app depends on hardware, location, paid entitlements, feature flags, or an admin-side setup step, document that now.

This is also the right time to draft the Notes for Reviewer field, even if you will finalize it later. Strong notes shorten review because they remove guesswork. Weak notes say, "Log in with this account." Useful notes explain how to reach the feature under review, what state the account is in, and anything that might look broken without context.

Build a submission packet, not just an app

Teams lose time when they treat metadata and support material as admin work. Reviewers and store systems use that material to decide whether the app is complete and whether the listing matches reality.

Prepare these items before you cut the release candidate:

• Company-controlled developer accounts: Confirm the business owns Apple and Google access, with backup admins in place.
• App record details: Set the app name, primary language, SKU or internal naming convention, and identifiers carefully so operations stay clean later.
• Working public URLs: Support, privacy, and marketing URLs should load correctly and reflect the current product.
• Accurate store copy: Titles, descriptions, and feature bullets must match what a reviewer can see in the app.
• Release-ready screenshots: Capture them from the current build, with the current UI, on the device classes the store requires.
• Permission and SDK inventory: List what the app requests, what third-party SDKs collect, and which answers you will need for privacy forms.
• Reviewer test path: Provide credentials, sample content, and any setup steps needed to verify gated flows.

One detail gets overlooked a lot. Reviewers are often testing under time pressure, and they rarely hunt for hidden setup instructions. If your app has a special path, such as waiting for an approval email, connecting a device, switching regions, or entering a code from another system, spell it out in the reviewer notes with numbered steps.

Plan around store-side constraints before they become blockers

Google Play's closed testing requirement for certain new personal developer accounts changes launch timing. It affects tester coordination, feedback collection, and the point when production release becomes available. Teams that discover this late end up shifting launch dates for operational reasons, not product reasons.

Apple has its own version of the same problem. App Store Connect fields can look routine, but they influence review readiness early. If screenshots, age rating inputs, app privacy details, or contact information are incomplete, submission slows down before the reviewer even gets to the product.

The trade-off is simple. You can submit fast with half-finished assets and fill gaps after rejection, or you can prepare the full package once and give review a clean path. The second approach feels slower for a day or two. It is usually faster by the end of the week.

Building and Signing Your App for Release

A surprising number of launches stall after the app is "done" because the release build is the first time anyone tests the exact package the stores will review. That is when signing mistakes, missing entitlements, and production-only config issues show up.

What signing accomplishes

Signing ties the binary to the developer account that is allowed to publish updates for that app identifier. On iOS, that means certificates, provisioning profiles, entitlements, the Apple team, and the Bundle ID all have to match. On Android, the release artifact has to be signed with the same keystore lineage you will use for future updates.

For React Native and Expo teams, EAS Build and EAS Submit remove a lot of manual certificate handling. They do not protect you from configuration errors. I regularly see builds succeed in CI and still fail review because production signing exposes an entitlement mismatch, such as a missing iCloud container, an incorrect Associated Domains entry for universal links, the wrong push notification environment, or a capability enabled in App Store Connect but missing from the final profile.

Native iOS teams usually do best with Xcode automatic signing unless there is a clear compliance or multi-team reason to manage profiles by hand. On Android, keystore discipline matters more than many teams expect. If the keystore or Play App Signing access is poorly documented, the app can ship once and become painful to update later.

A few habits prevent that:

• Use release configuration early: Build signed release candidates well before launch week so production-only entitlement and environment issues surface while there is still time to fix them.
• Separate environments cleanly: Dev, staging, and production should have distinct bundle IDs or package names, endpoints, and signing paths.
• Archive the exact release candidate: Keep the signed binary that passed QA identifiable and reproducible.
• Document credential ownership: More than one person should know where certificates, keystores, and recovery access are stored.

Release build checks that catch review-time failures

The submitted build should be tested on physical devices in its release form, not just as a debug build in simulators or emulators. Reviewers interact with the signed production package. That version can behave differently.

The failures are usually mundane. Push notifications work in development but not with production entitlements. A subscription screen points at the wrong backend. Universal links fail because the Associated Domains list is incomplete. The iOS permission prompt references old functionality because the release target still contains placeholder usage text.

Before upload, run the release candidate through the paths a reviewer is likely to hit first:

Release check	What to verify
Authentication	Login, logout, password reset, session expiry, account lock states
Payments	Sandbox purchase flow, failed purchase handling, restore purchases
Permissions	Camera, microphone, location, photos, notifications, denied-state behavior
Environment	Production API base URLs, feature flags, analytics, crash reporting, logging level
Deep links	Universal links, Android app links, referral URLs, invite flows, redirect handling

One more unwritten rule matters here. If your app depends on a capability that can look broken in a reviewer environment, explain it in Notes for Reviewer before they have to guess. Call out device pairing requirements, region limits, test account roles, third-party login setup, or any feature that only works with a production entitlement. That field gets ignored by inexperienced teams and used heavily by teams that pass on the first round.

A build that is stable in the happy path is not enough. The stores review edge cases, mismatched environments, and partially configured states. Your signing and release process should assume that from day one.

Preparing Your Store Listing and Metadata

A reviewer opens your app expecting the screenshots, positioning, and first-run experience to match. If the listing promises one product and the build shows another, the submission starts with doubt.

Your listing sells the app and explains it to review

Store metadata does two jobs at once. It has to convince a user to download, and it has to help a reviewer understand what they are looking at without guessing.

That starts with alignment. The app name, subtitle, screenshots, promo text, and description should describe the release build that is under review. Screenshots need to reflect the current UI, not a design file from three sprints ago. Feature claims need to match what is enabled in production. If a user needs an account, an approval step, a paired device, or a specific location context, say so clearly in the listing instead of presenting the app as friction-free.

I see the same avoidable mistakes in delayed launches. Placeholder copy survives in account settings. Screenshots still show a retired onboarding flow. Support URLs load a half-finished help center. Marketing claims go beyond the current build's features. None of those issues is dramatic on its own, but together they make the app look unfinished.

A practical review pass for metadata looks like this:

• Set the launch story first: Define the problem the app solves and the features that are ready for public use.
• Write with proof in mind: Every claim should be visible in the app or easy for a reviewer to verify.
• Capture screenshots from the release candidate: If the UI changed, recapture them.
• Open every public URL by hand: Privacy policy, support page, marketing page, and account deletion instructions all need to load and make sense.
• Check field-to-field consistency: Categories, age rating, descriptions, screenshots, and privacy answers should describe the same product.

The Notes for Reviewer field decides more submissions than teams expect

This field is underused, and that is a mistake.

Apple's App Review team says in its review guidance that apps should include complete demo account information and detailed explanations for features that are hard to access or require special setup, as outlined on the App Store Review page in App Store Connect Help. In practice, that advice carries real weight. A clear reviewer note often prevents the exact kind of confusion that turns into a rejection for “app incomplete,” “feature not found,” or “unable to review.”

Use Notes for Reviewer whenever the app has behavior that is not obvious from the first launch:

• login-required flows
• account roles with different permissions
• hardware pairing
• region-specific features
• moderation or approval delays
• time-based content availability
• feature flags
• payment states tied to a preconfigured account
• external web steps that change in-app behavior

A good reviewer note removes guesswork.

If the app needs a demo account, provide one that works on the day of review. If the main feature sits behind three taps that are easy to miss, list the path. If the test account has a specific role or preloaded data, state that. If a feature depends on a device, entitlement, or backend approval, explain the dependency before the reviewer runs into it.

Later in the submission flow, it often helps to include a short walkthrough for anything unusual.

What strong reviewer notes look like

Weak notes are vague, and vague notes create work for the reviewer. “Use test account below” is incomplete. “Backend configuration required” tells them almost nothing.

Strong notes read like operator instructions. They are short, specific, and written for someone seeing the app cold for the first time.

Include these elements:

1. App purpose in one sentence
   Tell the reviewer what the app does and what part matters most in this build.

2. Exact access details
   Add username, password, test code method if needed, and whether the account is preloaded with sample data.

3. Direct navigation steps
   Show the shortest path to the feature under review.

4. Special setup or limits
   Mention device dependencies, region restrictions, approval states, or external steps.

5. Expected result
   Tell the reviewer what they should see so they know the feature is working as intended.

Here is the difference in practice:

Weak reviewer note	Strong reviewer note
“Login required. Test account attached.”	“Use demo@company.com / Password123. After login, tap Devices, pair the pre-seeded demo device, then open History to review the synced data set already loaded on this account.”
“Some features depend on approval.”	“The test account is already approved for the seller flow. Tap Profile, then Seller Dashboard to review listing creation and payout settings.”

The best launch teams treat metadata as part of the review package, not a marketing task to finish at the end. That is how you reduce preventable questions and improve first-pass approval odds.

Navigating Privacy Compliance and Data Safety

A large share of preventable submission delays starts here. The build works, the listing is ready, and then the privacy answers do not line up with the app, the SDKs, or the policy.

The fix is operational, not legalistic. Put one owner in charge of the disclosure inventory. Legal, engineering, product, and growth can all supply inputs, but one person needs to reconcile them before anyone touches App Store Connect or Play Console. Teams that split this work across departments tend to answer platform questions from memory, and that is how mismatches slip in.

Map your data before you touch the forms

Start with a plain spreadsheet or doc. List every data type the app collects, accesses, transmits, stores, or shares. Then list every SDK and service in the build. Attribution, analytics, crash tools, support chat, auth, payments, maps, embedded web views, and push providers all affect what you may need to disclose.

Then pressure-test that inventory against the actual product.

A solid review pass covers:

• Permissions requested by the app: Camera, microphone, location, contacts, photos, notifications, health data, Bluetooth, motion, and anything else surfaced at runtime.
• Data touched by each SDK: Check vendor documentation and your implementation. Some SDKs collect identifiers, diagnostics, or usage data even when your team treats them as passive tooling.
• Privacy policy alignment: The policy, store disclosures, and in-app behavior need to say the same thing in plain terms.
• Purpose strings and prompts: If the app asks for access, the explanation should match the feature the reviewer sees.
• Release-by-release changes: A new feature flag, vendor update, or hidden dependency can change your disclosure obligations.

Apple privacy labels and Google Play Data Safety answers are metadata, but reviewers treat them like product truth. If the form says one thing and the build shows another, the app can stall even when the feature itself is fine.

I have seen teams lose days because of one unchecked SDK. I have also seen clean first-pass approvals on apps with complicated data flows because the disclosure sheet was built before submission week and reviewed like code.

Published Apple guidance also puts extra weight on privacy manifests and declared API use. If your build includes required manifests, make sure they are present and current. If your app uses APIs that require a stated reason, confirm the reason is properly declared. Placeholder entries and inherited SDK issues still trigger metadata problems during review, even when the app functions correctly.

The EU Trader Status Requirement Many Teams Miss

EU launches add one more failure point that sits outside the binary. Apps aimed at EU users may need trader information completed in App Store Connect, especially when the seller is offering paid apps, in-app purchases, or commercial services. Apple documents the requirement in its information for traders and non-traders in the EU or UK: https://developer.apple.com/help/app-store-connect/manage-compliance-information/manage-european-union-digital-services-act-trader-requirements/

This catches teams because nothing in QA points to it. The app can pass internal testing and still miss release timing because the seller account details, contact information, or declarations are incomplete.

Handle trader status like a launch dependency. Verify the legal business name, address, support contact path, and any required declarations well before you queue the release. If your submission serves multiple regions, check this early instead of discovering it during final review prep.

One more unwritten rule matters here. If there is anything unusual about your privacy setup, say it in Notes for Reviewer. Call out demo data, limited data collection in the review build, region-specific payment behavior, or why a permission prompt appears only after a certain action. Reviewers do not want a policy essay. They want enough context to confirm that the disclosures match what they can test.

The Submission and Review Gauntlet

Friday, 4:40 p.m., the build is uploaded, metadata looks finished, and everyone assumes approval is a formality. Then review stalls because the reviewer cannot reach a paywalled feature, a permission prompt appears without context, or the app behaves differently on a fresh install than it did in QA. That is the gauntlet. The store is no longer checking whether the app works for your team. It is checking whether a stranger can verify it quickly.

What happens after you submit

On Apple, the sequence is simple on paper. Attach the build to the version, complete review details, submit, and wait for status changes in App Store Connect. In practice, approval speed depends on how easy you make the reviewer's job.

Apple runs automated checks first. Human review follows if the build clears those checks. The reviewer then tries to confirm four things: the app opens and functions as described, protected areas are accessible, permissions make sense in context, and the public listing matches the build they are testing.

That last point causes more trouble than teams expect.

A submission package is stronger when it includes:

• A final build: No test copy, broken links, hidden dead ends, or unfinished settings screens
• Reviewer access that works on the first try: Stable credentials, any required OTP workaround, and a realistic account state
• Clear review notes: Short instructions for anything a reviewer would not discover on their own
• A release choice that matches risk: Automatic release for low-risk updates, manual release when launch timing matters, phased rollout when post-approval caution matters

The unwritten rule that saves approvals

The most underused field in the entire process is Notes for Reviewer.

Teams often treat it like an optional comment box. It is closer to an operations handoff. If your app needs a specific test path, reviewer notes should spell it out in plain language: where to log in, which account to use, how to reach the feature under review, what hardware or permission flow to expect, and whether a capability is region-limited or triggered only after a certain action.

Good reviewer notes are brief and testable. Bad reviewer notes are vague, promotional, or overloaded with product background.

Use notes like this:

1. State the path. “Log in with the demo account below, tap Projects, open Sample Project, then tap Export.”
2. State the exception. “Camera permission appears only after selecting Scan Receipt.”
3. State any environment constraint. “Apple Pay is disabled in the review build. Please use the card flow.”
4. State anything that might look broken but is expected. “The dashboard is empty on first launch until sample data sync completes in 10 to 15 seconds.”

That context prevents avoidable back-and-forth. Reviewers are not trying to reverse-engineer your product.

What the statuses usually mean

Review statuses matter less than the reason behind them. I tell teams to sort outcomes into operational buckets:

Status outcome	What it usually means
Approved	The build, metadata, and review path were clear enough to validate
Rejected, Binary	The reviewer hit a functional, technical, or access problem in the app
Rejected, Metadata	The listing, disclosures, assets, or review details did not match the build or policy requirements

This framing helps during resubmission. A binary rejection needs a build fix. A metadata rejection often needs cleaner packaging, corrected declarations, or better reviewer instructions.

How to handle the review window without creating new problems

The biggest mistakes happen after submission. Product teams swap credentials, operations teams update backend flags, marketing edits store copy, and someone uploads a new build before confirming what failed.

Use a tighter process:

• Watch App Store Connect messages closely. Reviewer questions are usually specific. Reply with direct instructions, not long explanations.
• Change only what the rejection requires. Unrelated fixes create new review surface area.
• Keep the test environment stable. Do not expire demo accounts, rotate codes, or remove sample data mid-review.
• Decide release control before approval arrives. Manual release gives you timing control. Phased release is safer for larger updates when you want to limit exposure after approval.

Google Play follows the same operational logic even though the workflow looks different. Policy checks, metadata review, app access, and declaration accuracy still decide whether you get through on the first pass.

Teams that clear review consistently do not just submit complete apps. They submit easy-to-review apps. That is a different standard, and it is the one that protects launch dates.

Common Rejections and How to Fix Them

Friday afternoon, the build is in review, launch posts are scheduled, and then the rejection lands for something avoidable. A broken login. Placeholder copy in one screenshot. A privacy answer that does not match the SDKs in the binary. That is how launch dates slip.

The pattern is consistent across both stores. Reviewers reject apps for product issues, but they also reject apps that are hard to verify. The unwritten rule is simple: if a reviewer has to guess, dig, or wait, approval slows down.

Fast resubmissions are narrow. Fix the blocker, explain the fix clearly, and give the reviewer a short path to confirm it.

Common App Store Rejections and Fixes

Rejection Reason	Platform(s)	Why It Happens	How to Fix It
Incomplete demo account	Apple	Reviewer cannot log in, the account lacks the right permissions, or protected flows have no usable test data	Create a stable reviewer account, preload realistic sample data, confirm the account works on a clean device, and use the Notes for Reviewer field to list the exact login steps and any required navigation path
Placeholder metadata	Apple	Screenshots, descriptions, URLs, or in-app text still show temporary content from staging or pre-release builds	Replace all temporary text and images, capture screenshots from the final release candidate, and test every public-facing URL before resubmitting
Crash or technical instability	Apple	The release build fails on startup, breaks in a common flow, or behaves differently outside the dev environment	Reproduce the issue on physical devices, test the same binary through TestFlight, inspect crash logs, and resubmit only after verifying the specific failing path is stable
Missing privacy manifest or undeclared API usage	Apple	The binary includes SDK behavior or required reason API usage that is not reflected in the project files or disclosures	Audit third-party SDKs, add the required privacy manifest details, verify required reason APIs, and make sure declarations match the app's and SDK's data behavior
Non-functional URL	Apple and Google Play	Support, privacy, or marketing links fail to load, redirect poorly, or require internal access	Publish final public pages before submission, test links outside your company network, and check them again after any CMS update
Data Safety mismatch	Google Play	The Data Safety form does not match what the app or its SDKs collect, share, or process	Review runtime behavior, SDK documentation, and declared permissions together, then update the form so it matches the shipped build exactly

Some of these look minor. Review teams do not treat them as minor because they block verification.

The most effective fix is often the one teams underuse: reviewer notes. Apple gives you a field for context, and strong submissions use it to remove ambiguity before review starts. If the app needs a login, role selection, hardware pairing, region setting, subscription state, or a hidden gesture to reach the tested feature, spell it out. Apple's App Review Guidelines explain what must be reviewable. The Notes for Reviewer field is where you make that review practical.

Keep those notes operational. Good notes answer four questions fast: what account to use, what path to follow, what to expect, and what changed since the last submission.

A weak resubmission note says, “Fixed issues from previous review.”

A strong one says, “Updated reviewer credentials for admin access. Added sample patient record to demo account. Replaced placeholder onboarding text in screenshots 2 and 4. Corrected privacy policy URL in metadata.”

That difference matters. It shortens the reviewer's path from open question to verified fix.

If the rejection involves policy or privacy, check the build and the declarations side by side before you touch anything else. A lot of teams edit the form first, then discover the SDK still behaves differently from what they declared. That creates a second review loop instead of closing the first one.

App Store Submission FAQ

What should you do right after approval

Approval is the handoff to launch operations, not the finish line.

Choose your release method before the decision comes in. Apple supports automatic release, manual release, and phased release. Manual release fits launches tied to press, paid acquisition, support staffing, or backend switches. Phased release is the safer choice for larger changes because it limits exposure while you watch crash rates, payment events, and support tickets.

Confirm the basics are live before you publish to everyone: analytics, crash reporting, customer support coverage, and backend alerting. I have seen approved apps go public with a broken production API key or missing subscription event tracking. Store approval did not catch it, because that is not what review is testing.

How are updates different from first submissions

Updates move faster when the app record is already in place, but reviewers still assess the new build on its own merits. Treat every update as a fresh review, especially if it changes login, billing, permissions, account creation, or any feature behind a role-based path.

The biggest mistake is assuming Apple remembers your setup from the last submission. Reviewers change. Context gets lost. The Notes for Reviewer field should be rewritten whenever the tested path changes. Include current credentials, the exact steps to reach the updated feature, any required test state, and what changed since the prior version. That one field prevents a surprising number of avoidable rejections.

Large updates deserve the same release-candidate discipline as version one. New code, new metadata, and new privacy answers create new failure points.

What if you think the rejection was wrong

Start with your own evidence. Re-read the guideline cited in the rejection, install the exact build you submitted, and verify that the reviewer could reach the feature you expect them to test. In a lot of disputed rejections, the actual problem is access, missing context, or a reviewer path that breaks before the key screen appears.

If the guideline still looks misapplied, use Apple's formal appeal path through the App Review Board. Apple documents that process in its App Review appeals page. Keep the appeal short and factual. Point to the specific guideline, explain how the app complies, and give precise steps the reviewer can follow to confirm it.

For Google Play, review timing and policy scrutiny often vary more by account history and app category. New accounts and apps involving payments, health data, child-directed features, or sensitive permissions should assume longer review cycles and plan launch dates accordingly.

If you want the fastest path through the app store submission process without doing every screenshot, privacy form, reviewer note, tester run, and console step yourself, LetsDeployIt handles the launch end to end for React Native and Expo apps. They prepare the store listing, ASO copy, screenshots, privacy policy hosting, reviewer notes, Google Play Data Safety details, signing, EAS build and submit flow, reviewer responses, and resubmissions, with a senior reviewer on each project. It's built for teams that want approval handled properly and don't want launch week consumed by store ops.