Submitting a Wrapped Game to the App Stores

Set Up Developer Accounts

Apple's Developer Program costs $99 per year and requires identity verification. You can register as an individual or as an organization. Individual accounts are simpler to set up, but organization accounts display your company name on the store listing instead of your personal name. The enrollment process takes one to three days for individuals and up to two weeks for organizations that need D-U-N-S number verification.

Google's Play Developer Console has a one-time $25 registration fee. Google also requires identity verification, including a government-issued ID and a payment profile for receiving revenue. The verification process has become more thorough in recent years and can take several days. You must complete verification before you can publish any apps.

Both accounts need payment and tax information configured before you can sell paid apps or offer in-app purchases. For free games with advertising, you can skip the payment setup initially, but you will need it eventually if you add any paid content. Set up these details early to avoid delays when you are ready to launch.

Prepare Required Assets

App icons are required at multiple sizes for each platform. iOS needs a 1024x1024 pixel icon for the store listing, and Xcode generates all smaller sizes from it. Android needs adaptive icons with separate foreground and background layers at multiple densities (mdpi through xxxhdpi). Your game icon should be distinctive, recognizable at small sizes, and consistent with your game's visual identity.

Screenshots are critical for store listing conversion. Apple requires screenshots for each device size you support: iPhone 6.7-inch, iPhone 6.1-inch, and iPad 12.9-inch at minimum. Google Play requires a minimum of two screenshots and supports up to eight per device type. For games, screenshots should show actual gameplay, not loading screens or menus. Capture your game at its most visually compelling moments, and consider adding minimal text overlays that highlight key features.

Write a compelling store description that explains what makes your game interesting without using generic marketing language. The first three lines are the most important because they appear in search results before the "read more" fold. Include your target keywords naturally in the description, and highlight gameplay features, content variety, and any unique mechanics. Apple allows up to 4000 characters, and Google Play allows up to 4000 characters for the full description plus a separate 80-character short description.

You need a privacy policy URL, even if your game collects no user data. Host the privacy policy on your game's website or any publicly accessible URL. The policy must accurately describe what data your app collects, how it is used, and whether it shares data with third parties. If your game uses advertising SDKs like AdMob, they collect device identifiers and usage data that must be disclosed in your privacy policy.

Ensure App Store Guideline Compliance

Apple's App Store Review Guideline 4.2 is the section that specifically affects wrapped web games. It states that applications should not simply be repackaged websites. To meet this requirement, your wrapped game should demonstrate that it provides a better experience as a native app than it would as a web page. Offline functionality, native API integration (haptics, push notifications, Game Center), and a polished native presentation all help satisfy this guideline.

Games have an inherent advantage over utility apps when it comes to guideline 4.2 because they provide interactive entertainment that clearly benefits from an app format. A game with touch controls, full-screen gameplay, and local save data is obviously more than a website bookmark. However, if your game simply loads a remote URL and renders a responsive web page with no native features, Apple may reject it. Bundle your assets locally and integrate at least one or two native capabilities.

Google Play's policies are more permissive regarding WebView-based apps. The primary concerns are that the app functions properly, does not deceive users, and complies with content policies. Games that load content from remote URLs are generally accepted as long as the app provides a meaningful experience. Google's main focus areas for game review are content ratings accuracy, advertising behavior (ads must not be deceptive or interfere with gameplay excessively), and data collection disclosures.

Both platforms require proper handling of user-generated content if your game includes multiplayer chat, level sharing, or player-created content. You need moderation mechanisms and clear reporting tools. For many single-player wrapped games, this is not applicable, but if your game connects to any social features, plan for content moderation from the start.

Configure Code Signing

iOS apps must be signed with a distribution certificate and a provisioning profile linked to your Developer Program account. In Xcode, go to your project's Signing and Capabilities tab, select your team, and choose "Automatic" for signing management. Xcode creates and manages the certificates and profiles for you. If you use a CI/CD pipeline for builds, you will need to export these certificates and install them on the build machine manually.

Android apps are signed with a Java keystore file that you create using the keytool command or through Android Studio's build process. The keystore contains a private key that identifies you as the app's developer. Keep this keystore backed up securely because losing it means you can never update your app (you would need to create a new listing with a new package name). Google Play also offers Play App Signing, which manages your signing key in Google's infrastructure and is recommended for new apps.

For both platforms, the app identifier (bundle ID on iOS, application ID on Android) must be unique across all apps on the store. Use a reverse-domain format like com.yourstudio.yourgame. This identifier is permanent and cannot be changed after your first submission, so choose it thoughtfully. It should match the identifier you configured in your Capacitor or Tauri project settings.

Build and Upload

For iOS, open your project in Xcode, select "Any iOS Device" as the build target, and choose Product > Archive. The archive process compiles your app, bundles all assets, and creates a distributable package. After archiving, Xcode opens the Organizer window where you can validate the archive against App Store requirements and then upload it to App Store Connect. Validation checks for common issues like missing icons, incorrect architecture support, and signing problems.

For Android, open your project in Android Studio and choose Build > Generate Signed Bundle / APK. Select Android App Bundle (AAB) format, which Google Play requires for new apps. Choose your keystore, enter the key password, select the release build variant, and let Android Studio compile the optimized bundle. Upload the resulting .aab file to the Google Play Console through the Production track (or Internal/Closed testing tracks if you want to test first).

Before uploading to the production track on Google Play, consider using the internal testing track first. Internal testing distributes the build immediately to up to 100 testers without review, letting you verify the published build works correctly on devices you do not own. Once validated, you can promote the same build to production, which triggers Google's review process.

Complete Store Listing Metadata

Both platforms require detailed metadata beyond screenshots and descriptions. The content rating questionnaire asks about violence, language, gambling, user interaction, and other content categories. Answer honestly because inaccurate ratings can lead to removal. Most casual web games receive an "Everyone" or "Everyone 10+" rating on Google Play and a 4+ or 9+ rating on iOS.

Apple's App Store Connect requires you to declare your app's privacy practices through the App Privacy section. For each type of data your app collects (identifiers, usage data, diagnostics), you must indicate whether it is linked to the user, used for tracking, or collected by third-party SDKs. If your game uses AdMob or other advertising SDKs, they typically collect device identifiers, usage data, and diagnostics, all of which must be declared.

Google Play's Data Safety section serves the same purpose. You declare what data your app collects, whether data is shared with third parties, and your data retention practices. Like Apple, advertising SDKs must be disclosed. Google provides specific guidance for common SDKs like AdMob, Firebase Analytics, and Crashlytics.

Select the appropriate app category (Games) and subcategory (Action, Puzzle, Strategy, etc.) on both platforms. The category affects where your game appears in store browse sections and which competitor games appear in "similar apps" suggestions. Choose the most accurate subcategory rather than the most popular one, because misclassification can hurt your visibility in search results.

Submit for Review

Apple's review process typically takes one to three days, though it can occasionally stretch longer during busy periods like the holidays. If your app is rejected, Apple provides specific feedback citing the guideline number and a description of the issue. Address the feedback, fix the problem, and resubmit. Common rejections for wrapped games include: app appears to be a web page (add native features), missing privacy policy, inaccurate content rating, and crashes during review (test thoroughly on the latest iOS version).

Google Play's review process is usually faster, often completing within a few hours to one day. Rejections come with a policy violation notice that identifies the specific issue. Google's most common rejections for games involve deceptive ads (interstitial ads that mimic system dialogs), missing privacy disclosures, and content rating inaccuracies. Address the stated issue, update your build or listing, and resubmit.

After approval, your game goes live on the store according to the release schedule you configure. Both platforms allow you to schedule a specific launch date or release immediately upon approval. For subsequent updates, the review process is the same but tends to be faster because the reviewer already has context on your app. Increment your version number and build number with each update submission.