App Store Submission Kit

Changelog

• 1.0.0, 21 October 2026: first release

App Store Submission Kit

Version 1.0.0

Getting an app through review is mostly about preparation: the right assets at the right sizes, accurate privacy answers, a working demo account and metadata that matches the app. This kit puts all of that in one place for both the Apple App Store and Google Play.

Who it's for

• Developers submitting their first app to either store
• Teams who've been rejected and want to avoid it next time
• Anyone who releases often and wants a repeatable checklist

How to use it in 5 minutes

1. Open the checklist for your store: apple-submission-checklist.md or google-play-submission-checklist.md. Skim it to see what you'll need.
2. Read rejection-reasons.md. Most rejections come from a short list of avoidable problems.
3. Start privacy-worksheet.md and data-inventory.csv early. They take longest because you need to check every SDK in your app.
4. Draft your listing in store-listing-templates.md, which shows every character limit.
5. Before you press submit, fill in review-notes-template.md and work through release-checklist.md.

File map

A note on accuracy

Store requirements change often: screenshot sizes, SDK versions, policy wording and form questions. Everything in this kit was checked against the official documentation in October 2026, and the places most likely to change are marked. Always confirm with the store's current pages before you submit. Following this kit lowers the chance of rejection, but approval is always the store's decision.

Licence

MIT License. See LICENSE.txt.

Apple App Store submission checklist

Work through this from top to bottom. Items follow roughly the order App Store Connect asks for them. Requirements change, so confirm anything marked (check current) on Apple's developer site before you submit, especially the Upcoming Requirements page and the App Review Guidelines.

App: ______________________ Version: ________ Build: ________ Target date: ____________

---

1. Account and agreements

• Apple Developer Program membership is active (individual or organisation).
• The Account Holder has accepted the latest Apple Developer Program License Agreement. Submissions are blocked until they do.
• For paid apps or in-app purchases: the Paid Apps Agreement is signed, and banking and tax details are complete in App Store Connect.
• If you distribute in the EU: your trader status under the Digital Services Act is declared and verified. Apps without it are not available on EU storefronts.
• Team roles are set so the right people can upload builds and submit.

2. Build

• Built with the minimum Xcode and SDK version Apple currently requires. Since 28 April 2026 that's Xcode 26 with the iOS 26 SDK or later (check current).
• Bundle ID matches the App ID in your developer account.
• Version number (CFBundleShortVersionString) and build number (CFBundleVersion) are higher than any previous upload.
• Signed with a distribution certificate and an App Store provisioning profile (or automatic signing).
• App icon included in the asset catalogue (1024 x 1024 px, no transparency). Dark and tinted variants are optional.
• Every permission your app requests has a clear purpose string in Info.plist (for example NSCameraUsageDescription) that explains why, in plain language.
• Privacy manifest (PrivacyInfo.xcprivacy) included, declaring any required-reason APIs you use. Third-party SDKs on Apple's list include their own signed manifests.
• Export compliance answered. If your app only uses standard encryption such as HTTPS, setting ITSAppUsesNonExemptEncryption to NO in Info.plist skips the question on each upload. If you use other encryption, check whether you need documentation.
• No debug menus, test endpoints, placeholder content or staging URLs.
• Tested on real devices, on the oldest and newest iOS versions you support, and on iPad if the app runs there.
• Uploaded through Xcode or Transporter and finished processing in App Store Connect.
• Tested through TestFlight by at least one person outside the development team.

3. App information

• Name (up to 30 characters). Unique on the App Store.
• Subtitle (up to 30 characters).
• Primary category, and an optional secondary category.
• Age rating questionnaire answered truthfully. Apple updated its age rating system and questions in 2025 to 2026, so review your answers even for existing apps (check current).
• Content rights: you confirm you have rights to any third-party content in the app.
• Privacy policy URL that opens a working page (required for all apps).
• License agreement: Apple's standard EULA, or your own.

4. App privacy

• Privacy details ("nutrition label") completed for every data type collected by you and by third-party SDKs. Use privacy-worksheet.md.
• Answers match your privacy policy and what the app actually does.
• If you track users across apps and websites owned by other companies, the app asks permission through App Tracking Transparency before any tracking happens.

5. Pricing and availability

• Price tier or free.
• Countries and regions selected. Some countries need extra information or licences for certain app types.
• Pre-order set up, if you want one.
• Availability on Apple silicon Macs and Apple Vision Pro reviewed (on by default for compatible iPhone and iPad apps; turn off if the app doesn't work well there).

6. In-app purchases and subscriptions (if any)

• Every product is created, has a reference name, display name, description, price and review screenshot, and is in "Ready to Submit".
• New products are attached to this app version for review.
• Digital goods and features unlocked inside the app use in-app purchase, unless your app qualifies for an exception or a regional programme (check current). Rules on linking to outside payment differ by country and have changed in recent years.
• Subscription screens show the price, billing period, what's included, and links to your terms and privacy policy before purchase.
• A "Restore Purchases" option is available for non-consumables and subscriptions.
• Tested with sandbox accounts, including purchase, cancel, renew and restore.

7. Version page

• Screenshots for every required device size. See asset-sizes.md.
• Optional app previews (videos), up to 3 per device size.
• Promotional text (up to 170 characters), editable any time without a new version.
• Description (up to 4,000 characters).
• Keywords (up to 100 characters).
• Support URL that opens a page with real contact information.
• Marketing URL (optional).
• What's New (for updates).
• Copyright line, for example 2026 Your Company Ltd.
• Build selected.

8. App Review information

• Contact name, phone and email for the reviewer. Someone must answer during review.
• Sign-in required? Provide a working demo account with full access, or turn on a demo mode. See review-notes-template.md.
• Notes explaining anything not obvious: hidden features, hardware needs, region-locked content, why you request each sensitive permission.
• Attachments (screen recording or document) if a feature is hard to reach.

9. Policy checks before submitting

• Account creation? Users can also delete their account from inside the app.
• Third-party or social login? You also offer an equivalent login option that meets Apple's privacy criteria (Sign in with Apple is one such option) (check current).
• User-generated content? You have content filtering, a way to report content, a way to block users and published contact details.
• Made for kids or in the Kids category? You follow Apple's extra rules on ads, analytics and links.
• Health, financial, gambling, VPN or other regulated features? You meet the specific guideline sections for them.
• Nothing in the app or metadata mentions other platforms, beta status or pricing that conflicts with the store.
• Read rejection-reasons.md once more.

10. Release

• Release option chosen: manual, automatic after approval, or scheduled.
• Phased release for automatic updates turned on if you want a gradual rollout (spread over seven days, can be paused).
• Submitted for review. Note the date: ____________

Review times vary. Many apps are reviewed within a day or two, but plan for longer, especially around holidays and major iOS releases.

Screenshot, icon and video sizes

These tables reflect Apple's and Google's published specifications as of October 2026. Both stores add new device sizes and adjust rules regularly. Check the store's current requirements before you export your final assets:

• Apple: App Store Connect Help, "Screenshot specifications" and "App preview specifications"
• Google: Play Console Help, "Add preview assets to showcase your app"

---

Apple App Store

App icon

Optional dark and tinted icon variants can be added in the asset catalogue.

iPhone screenshots

You need screenshots for at least one large iPhone size. If your interface is the same across devices, provide the largest size and App Store Connect scales it down for smaller devices.

Smaller iPhone sizes are optional and are scaled from the next size up if you don't provide them. App Store Connect may also list a 6.1" set; check which sets it asks for when you open your version page.

iPad screenshots

Mac screenshots

Screenshot rules

App previews (videos)

App previews have their own resolution table per device. Check Apple's "App preview specifications" page for the exact sizes, frame rates and file limits before exporting.

---

Google Play

Icon and feature graphic

Phone screenshots

Tablet and Chromebook screenshots

Wear OS, Android TV, Android Automotive and Android XR have their own screenshot rules. Check the Play Console Help page if you support them.

Preview video

---

Export checklist

• Every image is exactly the required pixel size, not just the right aspect ratio.
• Alpha channel removed where transparency isn't allowed (all Apple screenshots, Google screenshots and feature graphic).
• Colour profile is sRGB (or Display P3 for Apple, where supported).
• Status bars are clean: full battery, strong signal, a neutral time, no personal notifications.
• No real customer data, email addresses or phone numbers visible.
• Text on screenshots is large enough to read on a phone listing.
• Screenshots are localised for each language you list in, or at least the captions are.
• File names are ordered (01-home.png, 02-search.png) so upload order is easy.
• Metadata such as location removed from image files before upload.

Google Play submission checklist

Work through this from top to bottom. Items follow roughly the order Play Console asks for them. Google updates its requirements and policies regularly, so confirm anything marked (check current) in the Play Console Help Center and the Developer Program Policy before you submit.

App: ______________________ Version name: ________ Version code: ________ Target date: ____________

---

1. Developer account

• Google Play developer account registered (one-time registration fee) and identity verification complete.
• Account type is right for you: personal or organisation. Organisation accounts need a D-U-N-S number.
• Developer name, contact email and address are correct. Some of these are shown publicly on your store listing.
• For paid apps or in-app products: payments profile set up and linked.
• If you distribute in the EU: trader status under the Digital Services Act declared in Play Console (check current).

2. Testing requirement for new personal accounts

New personal developer accounts must run a closed test before they can publish to production.

• Closed test track set up.
• At least 12 testers opted in, and they stayed opted in for at least 14 days in a row (check current).
• Testers actually used the app, and you collected feedback.
• Production access applied for, with answers about your testing and readiness.

Organisation accounts and older personal accounts may not have this requirement, but a closed or internal test is still a good idea.

3. Build

• Uploaded as an Android App Bundle (.aab). Required for new apps.
• Play App Signing enabled, and your upload key stored safely, with a backup.
• Targets the API level Google currently requires. From 31 August 2026, new apps and updates for phones and tablets must target Android 16 (API level 36) or higher, with different levels for Wear OS, Android TV and Android Automotive (check current).
• versionCode is higher than any previous upload.
• Only the permissions the app really needs. Sensitive permissions (SMS, call log, all files access, background location, exact alarms, photo and video access, accessibility services, QUERY_ALL_PACKAGES) need a declaration form and a core-feature reason. Where a system picker can do the job, use it instead of a broad permission.
• Foreground services declare their type, and you've completed the foreground service declaration if asked.
• Tested on several screen sizes and Android versions, including the minimum you support.
• Pre-launch report reviewed after upload, with crashes and serious warnings fixed.

4. App content (Policy and programs section)

Every item here must be completed before you can publish.

• Privacy policy: a public, working URL (not a PDF) that names your app or developer name and matches your Data safety answers.
• App access: if any part of the app is behind a login or subscription, give working credentials and instructions. See review-notes-template.md.
• Ads: declare whether the app contains ads, including from third-party SDKs.
• Content rating: IARC questionnaire completed truthfully.
• Target audience and content: age groups chosen. Including children under 13 brings in the Families policy requirements.
• Data safety: form completed for you and all SDKs. Use privacy-worksheet.md. Required even if you collect no data.
• Advertising ID: declared if your app uses it. Apps targeting Android 13 or higher that use it need the AD_ID permission.
• Government apps, financial features, health apps, news apps: declarations completed if they apply (check current).
• Account deletion: if users can create an account, they can delete it from inside the app and you provide a web link where they can request deletion without reinstalling.
• Sensitive permission declarations: completed for every restricted permission in your manifest.

5. Store listing

• App name (up to 30 characters).
• Short description (up to 80 characters).
• Full description (up to 4,000 characters).
• App icon: 512 x 512 px, 32-bit PNG.
• Feature graphic: 1024 x 500 px, JPEG or 24-bit PNG.
• Phone screenshots, and tablet or Chromebook screenshots if supported. See asset-sizes.md.
• Optional preview video (YouTube link, public or unlisted, ads off).
• App category and tags.
• Contact email (required), plus website and phone if you want them shown.
• Translations for the languages you support.

6. Pricing and distribution

• Free or paid. You can change a paid app to free, but once an app is free it can't be changed to paid. Choose carefully.
• Countries and regions selected.
• Device types chosen (phone, tablet, Wear OS, TV, Automotive, Chromebook).
• In-app products and subscriptions created, priced and active.
• Digital goods and features use Google Play Billing, unless your app qualifies for a regional alternative billing programme (check current).

7. Policy checks before submitting

• Title, icon and screenshots contain no ranking claims ("#1", "best"), price or promotion text, or misleading badges.
• No other company's brand, characters or trademarks without permission.
• User-generated content? Reporting, blocking and moderation are in place.
• Ads don't appear unexpectedly, block the app, or imitate system dialogs.
• Subscriptions clearly show price, billing period and how to cancel before purchase.
• Read rejection-reasons.md once more.

8. Release

• Release created on the production track with release notes (up to 500 characters per language).
• Staged rollout percentage chosen, for example 10% first.
• Managed publishing turned on if you want to control exactly when an approved release goes live.
• Sent for review. Note the date: ____________

Review times vary. New apps and new developer accounts can take several days or longer. Plan for at least a week on your first submission.

Privacy worksheet: App Privacy and Data safety

Apple's App Privacy details (often called the privacy nutrition label) and Google Play's Data safety form ask similar questions in different ways. This worksheet helps you answer both from one set of facts.

Answers must cover data collected by your code and every third-party SDK in the app: analytics, crash reporting, ads, login, payments, chat, maps and so on. Wrong answers can lead to rejection or removal, and they affect user trust.

The categories below follow each store's forms as of October 2026. Both forms are updated from time to time, so check the current questions in App Store Connect and Play Console as you fill them in.

---

Step 1: build your inventory

Open data-inventory.csv in any spreadsheet app. The filled rows are examples: keep the ones that apply, correct them, delete the rest, and add one row for every type of data that leaves the device, whether it goes to your servers or to a third party. For each SDK, read its documentation for "data collection", "privacy" or "Data safety". Most large SDK providers publish a page listing exactly what they collect.

Things people often miss:

• Crash reports usually include device identifiers and diagnostic data.
• Analytics SDKs often collect a device or app instance ID.
• Login SDKs collect email and name.
• Ad SDKs often collect advertising ID, approximate location and usage data.
• Customer support chat widgets collect messages and contact details.
• Your own server logs collect IP addresses.

Step 2: key definitions

Read each store's full definitions before you answer. These summaries are a guide only.

Step 3: Apple App Privacy

For each data type you collect, answer: what it's used for, whether it's linked to the user's identity, and whether it's used for tracking.

Data types

Purposes

• Third-party advertising
• Developer's advertising or marketing
• Analytics
• Product personalisation
• App functionality
• Other purposes

Notes

• If you use a payment SDK and don't store card details yourself, check how Apple's guidance treats that data.
• Data collected only in rare, optional cases (for example, a user choosing to send a feedback form) may still need to be declared. Read Apple's guidance on optional disclosure.
• If you answer "used for tracking" for anything, you must also use App Tracking Transparency.

Step 4: Google Play Data safety

Google asks whether you collect or share each data type, then for each one: is it collected, shared or both; is it processed ephemerally; is it required or optional; and what purposes it's used for.

Data types

Purposes

• App functionality
• Analytics
• Developer communications
• Advertising or marketing
• Fraud prevention, security and compliance
• Personalisation
• Account management

Security practices

• Is all user data encrypted in transit? (HTTPS everywhere, including SDKs)
• Can users request that their data be deleted? Give the method.
• Have you committed to the Families policy, if your app targets children?
• Optional: has your app had an independent security review against a recognised standard? Only claim this if it's true and current.

Step 5: cross-check

• Every row in data-inventory.csv appears in both forms.
• Your privacy policy describes the same data, purposes and third parties.
• Permission prompts in the app match the data you declared.
• Account deletion works and matches what you said.
• You've set a reminder to review both forms whenever you add or update an SDK.

Completed by: ______________ Date: ____________ App version: ________

Common rejection reasons and how to avoid them

Most rejections aren't about clever policy edge cases. They come from a short list of avoidable problems: a crash, a missing login, privacy answers that don't match the app, or metadata that promises something the app doesn't do.

This guide summarises the most common ones in plain language. Section numbers refer to Apple's App Review Guidelines and the policy areas in Google Play's Developer Program Policy. Both documents change, so read the current versions for anything you're unsure about.

---

Both stores

1. The app crashes or doesn't work

Apple: 2.1 App Completeness. Google: broken functionality and minimum functionality.

Reviewers test on real devices, often on the newest OS version, sometimes on iPad even if you designed for iPhone, and often on a fresh install with no data.

Avoid it:

• Test a clean install on the newest OS release and the oldest version you support.
• Test with no network, slow network and airplane mode.
• If the app runs on iPad (iPhone apps can run on iPad by default), test it there.
• Check every link and button, including links to your website, support page and privacy policy.
• Make sure your backend is live and production-ready during review, not a test server that might be switched off.

2. Reviewer couldn't sign in

Apple: 2.1 (information needed). Google: App access.

If any part of the app needs an account, reviewers need one too. This is one of the most common reasons for a delay or rejection.

Avoid it:

• Give a demo account with full access, including paid features, in the review notes.
• Make sure it doesn't need two-factor codes sent to your phone, an invitation, or a specific location.
• Check it still works the day you submit, and don't change its password during review.
• If your app uses hardware or a QR code to log in, provide a demo mode or a video.

Use review-notes-template.md.

3. Privacy answers don't match the app

Apple: 5.1.1 Data Collection and Storage, 5.1.2 Data Use and Sharing. Google: User Data policy, Data safety.

Both stores compare your privacy declarations with what the app and its SDKs actually do. Analytics, crash reporting, ads and login SDKs often collect data you didn't think about.

Avoid it:

• List every SDK in data-inventory.csv and read each one's data disclosure documentation.
• Make your privacy policy, store declarations and in-app behaviour all say the same thing.
• Explain each permission request in plain words at the moment you ask for it.
• Don't make users grant permissions the feature doesn't need.

4. No in-app account deletion

Apple: 5.1.1(v). Google: account deletion requirement.

If users can create an account in your app, they must be able to delete it from inside the app. Google also requires a web page where users can request deletion without the app. Deactivating or hiding an account doesn't count.

Avoid it: Put "Delete account" somewhere easy to find, usually Settings > Account, and explain what gets deleted and what you keep for legal reasons.

5. Misleading or inaccurate metadata

Apple: 2.3 Accurate Metadata. Google: Metadata policy, Store listing and promotion.

Avoid it:

• Screenshots show the real app in use, not only marketing art or features that don't exist yet.
• The description doesn't promise features the app doesn't have.
• No keyword stuffing in the name, subtitle, keywords or description.
• No other app names, competitor brands or celebrity names unless you have rights.
• On Google Play, the title, icon and developer name contain no emoji, no ranking claims such as "#1" or "best", no price or promotion text such as "free" or "sale", and no all caps unless it's part of your brand.
• On Apple, metadata doesn't mention other mobile platforms or include pricing terms.

6. Too little functionality or a website in a wrapper

Apple: 4.2 Minimum Functionality. Google: minimum functionality and spam policies.

An app that only shows a website, or does very little, is often rejected.

Avoid it:

• Add real native value: offline use, notifications, device features, a better experience than the mobile site.
• Make sure the app is useful on its own, not just a link to somewhere else.

7. Copycat, template or spam apps

Apple: 4.3 Spam. Google: Spam and Impersonation policies.

Many near-identical apps from the same or different developers get rejected. Apps built from templates or generators that look like hundreds of others are at risk.

Avoid it: Make one strong app rather than many variations. Customise design and features meaningfully. Don't imitate another app's name, icon or look.

8. Payments outside the store's billing

Apple: 3.1.1 In-App Purchase. Google: Payments policy.

Digital content and features used inside the app generally have to use the store's in-app purchase system. Physical goods and real-world services (food delivery, taxis, physical shop orders) use normal payment methods.

Avoid it:

• Use in-app purchase or Play Billing for digital unlocks, subscriptions, coins and premium features.
• Rules on linking to outside payment and on alternative billing differ by country, and they've changed recently in the US, EU, South Korea, Japan and elsewhere. Check the current rules for each storefront you distribute in.
• Offer a way to restore purchases.

9. Subscription screens that aren't clear

Apple: 3.1.2 Subscriptions. Google: Subscriptions policy.

Avoid it:

• Show the price and billing period clearly, at least as prominent as any trial or discount.
• Say exactly what's included.
• Say how to cancel.
• Link to your terms and privacy policy from the purchase screen.
• Don't use dark patterns: hidden close buttons, confusing toggles, or pre-selected expensive plans.

10. User-generated content without moderation

Apple: 1.2 User-Generated Content. Google: User Generated Content policy.

Chat, comments, profiles, uploads and machine-made content shared between users all count.

Avoid it: Provide a filter for objectionable content, a way to report content, a way to block abusive users, timely responses to reports and published contact details.

11. Incomplete or placeholder content

Apple: 2.1 and 2.3. Google: minimum functionality.

"Coming soon" screens, filler text, empty states with no data, test content and "beta" labels lead to rejections.

Avoid it: Remove or hide unfinished features. Seed demo content for the reviewer if the app is empty on first launch.

---

Mostly Apple

Third-party login without an equivalent option

4.8 Login Services. If you use a third-party or social login service for the main account, you generally also need to offer another login option that meets Apple's privacy criteria. Sign in with Apple is one such option. There are exceptions, for example when the app only uses your own company's account system. Check the current wording.

Permission purpose strings

5.1.1. Every permission must come with a clear purpose string that explains what it's for. "This app needs your camera" isn't enough. Say what the user gets: "Scan receipts to add them to your expense report."

Tracking without permission

5.1.2. If you track users across other companies' apps and websites, including for targeted ads or sharing with data brokers, you must ask permission with App Tracking Transparency first, and respect the answer.

Using non-public APIs or downloading code

2.5 Software Requirements. Use only public APIs, don't download executable code that changes how the app works after review, and keep the app self-contained.

Kids category

1.3 Kids Category. Apps for children have strict limits on ads, third-party analytics and links out of the app, and need parental gates for purchases and external links.

---

Mostly Google

Restricted permissions without a core-feature reason

SMS, call log, all files access, background location, photos and videos, QUERY_ALL_PACKAGES, accessibility services and exact alarms all have restrictions. Each needs a declaration explaining why it's essential to your app's core feature. If a system picker or a less sensitive API can do the job, Google expects you to use it.

Families policy

If your target audience includes children, ads and SDKs must be from approved programmes, and data collection is restricted.

Target API level too low

Uploads targeting an API level below Google's current requirement are rejected automatically. Update your targetSdkVersion before each annual deadline.

Deceptive behaviour and ads

Apps must do what the listing says, must not imitate system notifications or other apps, and ads must not appear unexpectedly or be hard to close.

---

If you're rejected

1. Read the full message. Both stores say which guideline or policy applies, and often include screenshots.
2. Fix the real issue, not only the screen they mentioned. Reviewers may check more thoroughly next time.
3. Reply clearly. On Apple, reply in App Store Connect with what you changed. On Google, check the policy status page in Play Console.
4. Appeal only if you believe there's a misunderstanding. Be polite, specific and brief. Apple has an App Review Board appeal process. Google has an appeal form linked from the rejection.
5. Keep notes of every rejection and fix, so the next release doesn't repeat it.

Release checklist

Use this for every release after your first. Copy it into your issue tracker or notes for each version, so you have a record of what was checked.

Version: ________ Build / version code: ________ Release owner: ______________ Date: ____________

---

Before building

• Every change in this release is merged and listed: ____________________________________
• Version number and build number (Apple) or version name and version code (Google) increased.
• Build tools and SDK meet each store's current minimum (Apple Xcode and SDK version, Google target API level). Annual deadlines catch many teams out.
• Third-party SDKs updated where needed, and their changelogs checked for new data collection.
• Feature flags set correctly for production.
• Staging URLs, debug menus, test accounts and verbose logging switched off.

Testing

• Clean install tested on the newest OS release and the oldest version you support.
• Update from the previous store version tested, with existing data kept.
• Main flows tested: sign up, sign in, the core feature, purchase, restore, sign out, delete account.
• Tested offline and on a slow connection.
• Tested on a small phone, a large phone and a tablet (if supported).
• Accessibility checks: large text sizes, screen reader on main screens, enough contrast.
• Beta testers (TestFlight, internal or closed testing track) had the build for at least [2] days.
• No new crashes in beta crash reports.

Privacy and policy

• New permissions? Purpose strings written, and declarations completed in Play Console if restricted.
• New SDKs or data? privacy-worksheet.md updated, and App Privacy and Data safety answers changed before submitting.
• Privacy policy updated if data practices changed.
• New in-app purchases or subscriptions created and attached (Apple) or activated (Google).
• Any new user-generated content features have reporting and blocking.

Store listing

• What's New / release notes written for every language.
• Screenshots still match the app. Update them if the interface changed noticeably.
• Description still accurate. Remove features you've taken out.
• Promotional text (Apple) updated if useful.

Submission

• Demo account checked today. Review notes updated (review-notes-template.md).
• Apple: build selected, release option chosen (manual, automatic or scheduled), phased release decided.
• Google: release created, staged rollout percentage chosen, managed publishing decided.
• Submitted. Apple date: ____________ Google date: ____________

After approval

• Released, or scheduled. Live date: ____________
• Watch crash rate and reviews for the first 24 to 48 hours.
• Google: increase the staged rollout step by step if metrics are healthy (for example 10%, 25%, 50%, 100%).
• Apple: let phased release continue, or pause it if a problem appears.
• Reply to new reviews, especially about bugs.
• Tag the release in source control.

If something goes wrong

• Google: halt the staged rollout in Play Console.
• Apple: pause the phased release. To replace a live version, submit a fixed build and request an expedited review if the problem is serious.
• Server-side kill switch or feature flag turned off for the broken feature, if you have one.
• Users told what's happening, in the app or on your support page.

Neither store lets you roll users back to an older binary. The fix is always a new build, which is why staged rollouts and feature flags matter.

Notes for next time

____________________________________________________________

____________________________________________________________

Review notes template

Reviewers have limited time with your app. Clear notes help them see everything quickly and avoid rejections for "we couldn't access this feature". Paste the filled-in version into App Review Information > Notes in App Store Connect, and into App content > App access in Play Console (Google has separate fields for each set of credentials and instructions).

Keep it short, factual and easy to scan. Write it for someone who has never seen your app.

Never put real customer data, your personal password or production admin credentials in review notes. Create a dedicated review account.

---

Template

ABOUT THE APP
[App name] helps [who] [do what]. [One more sentence on the main feature.]

DEMO ACCOUNT
Username: [[email protected]]
Password: [password]
This account has [full access / an active premium subscription / sample data] so
you can test every feature. It does not need two-factor authentication.

HOW TO TEST THE MAIN FEATURES
1. Sign in with the demo account above.
2. [Tap X to see Y.]
3. [To test Z, go to Settings > ... and ...]
4. [To test in-app purchase, use a sandbox account. The demo account already has
   premium unlocked if you prefer to skip purchase.]

ACCOUNT DELETION
Settings > Account > Delete account. [What gets deleted, and how long it takes.]

PERMISSIONS
- Camera: used to [scan receipts]. Only requested when you tap [Scan].
- Location: used to [show nearby stores]. The app works without it.
- Notifications: used for [order updates]. Optional.

THINGS THAT MAY NOT BE OBVIOUS
- [Feature X only appears after you add at least one item.]
- [Content is limited to [region]. The demo account is set to [region] so you can see it.]
- [The app connects to [hardware]. A video showing this is attached / at [link].]
- [User-generated content: report via the ... menu on any post, block via the
   user's profile. Reports are reviewed within [24 hours].]

CHANGES IN THIS VERSION
- [Short list of what changed, especially anything related to a previous rejection.]

CONTACT DURING REVIEW
[Name], [phone], [email]. Available [hours and time zone].

---

Checklist before you submit

• Demo account signed in successfully today, on a fresh install.
• It doesn't need a code sent to a phone or email you control, or you've explained how to get past that step.
• It has access to paid features, or you've explained how to test purchases with a sandbox account.
• It contains realistic sample data, so screens aren't empty.
• It won't expire, be deleted by a clean-up job or be locked after failed attempts during review.
• If the app needs special hardware, a location or an invite, you've provided a demo mode or video.
• Every sensitive permission is explained.
• The contact person will answer the phone and email during review.
• If this is a resubmission after a rejection, you've said exactly what you changed.

If your app has no login

ABOUT THE APP
[App name] helps [who] [do what].

HOW TO TEST
No account is needed. [Steps to reach the main features.]

PERMISSIONS
[As above.]

CONTACT DURING REVIEW
[Name], [phone], [email].

Store listing templates

Fill in your listing copy here before you open App Store Connect or Play Console. Limits are shown for each field. Limits can change, so check the current figures in each console, which also counts characters as you type.

App: ______________________ Language: ______________

---

Character limits at a glance

---

Apple App Store

App name (30)

Your brand name, optionally with a short descriptor.

[Brand]: [what it does]

Draft: ________________________________ Count: ___ / 30

Subtitle (30)

The main benefit in a few words. Don't repeat words from the name, since both are already indexed for search.

[Benefit in plain words]

Draft: ________________________________ Count: ___ / 30

Promotional text (170)

Appears above the description. You can change it any time without submitting a new version, so use it for timely news.

[New this month: one sentence about a feature, event or improvement.]

Draft: ________________________________________________ Count: ___ / 170

Keywords (100)

Comma-separated, no spaces after commas. Don't repeat words already in your name or subtitle, don't use competitor names, and don't include plurals of words you've already used.

[keyword],[keyword],[keyword],[keyword],[keyword]

Draft: ________________________________________________ Count: ___ / 100

Description (4,000)

Only the first few lines show before "more", so lead with what matters.

[One or two sentences: what the app does and who it's for.]

[Short paragraph: the main problem it solves and how.]

WHAT YOU CAN DO
- [Feature, written as a benefit]
- [Feature]
- [Feature]
- [Feature]

[Optional short paragraph: what makes it different, privacy approach, offline use.]

[If subscriptions: plan names, what's included, price and billing period, auto-renewal terms, how to cancel.]

Terms of use: [URL]
Privacy policy: [URL]
Questions? [support email or URL]

What's New (4,000)

[Version number]
- [New: one line about the most useful change]
- [Improved: one line]
- [Fixed: one line]

---

Google Play

App name (30)

[Brand]: [what it does]

No emoji, no "#1" or "best", no "free" or price text, no all caps unless it's your brand.

Draft: ________________________________ Count: ___ / 30

Short description (80)

The first text people read on your listing. One clear sentence.

[Action verb] [what] [for whom or with what benefit].

Draft: ________________________________________________ Count: ___ / 80

Full description (4,000)

Google indexes this text for search, so use the words people search for naturally. Repeating keywords unnaturally breaks the Metadata policy.

[One or two sentences: what the app does and who it's for.]

[Short paragraph on the main problem it solves.]

Features
• [Feature, written as a benefit]
• [Feature]
• [Feature]
• [Feature]

[Optional: privacy approach, offline use, accessibility.]

[If subscriptions: plans, what's included, price and billing period, how to cancel.]

Support: [email or URL]
Privacy policy: [URL]

Google Play supports a limited set of HTML tags (such as bold and italic) in the full description. Check the current list before using formatting.

Release notes (500)

- [New: one line]
- [Improved: one line]
- [Fixed: one line]

Draft: ________________________________________________ Count: ___ / 500

---

Writing checklist

• The first sentence says what the app does in plain words.
• Every feature mentioned exists in this version.
• No competitor names, celebrity names or trademarks you don't own.
• No claims you can't back up ("most popular", "used by millions").
• Subscription terms match what the app shows at purchase.
• Support, terms and privacy links work.
• Spelling checked in every language.
• Translations checked by a fluent speaker where possible.