How to Publish an App to Google Play and the App Store

Finishing the app is only part of the work. Before anyone can install it, the app has to pass through two stores with their own accounts, signing rules, privacy forms, and review processes. Teams that leave this to the last week usually lose two or three weeks to it, often on things that have nothing to do with code: a missing privacy policy, a reviewer who cannot log in, or a new Google Play account that has not finished its mandatory testing period. This guide walks through both stores in the order the work actually happens.

Decide Who Owns the Developer Accounts

Register the accounts under the company that owns the app, not under a freelancer or an agency. The account holder controls the listing, the signing keys on Google Play, the payouts, and every future update. Moving an app between accounts later is possible but slow. Company accounts on both stores need a D-U-N-S number, which is free but can take a few days to a couple of weeks to issue, so request it at the start of the project. Add the developers as users with limited roles instead of sharing the owner login.

Prepare Signing Keys and Version Numbers

On Android, enrol in Play App Signing. Google keeps the key that signs the app delivered to users, and your team keeps an upload key. If the upload key is lost, the account owner can ask Google to reset it. Without Play App Signing a lost key means you can never update the app again. Store the upload keystore and its passwords in a password manager or your CI secrets, never in the repository.

On iOS, let Xcode manage certificates and provisioning profiles for a small team, or keep them in your CI system when several people release builds. Both stores reject a build whose version code or build number is not higher than the last one uploaded, including builds that only went to testers. In Flutter both numbers come from the version line in pubspec.yaml, for example 1.4.0+27, so increase the number after the plus sign on every upload.

Fill In the Store Listing and Privacy Forms

• A privacy policy at a public URL that matches what the app really collects. Both stores require it, and Indonesian users are also covered by the Personal Data Protection Law (UU PDP).
• The Data safety form on Google Play and the App Privacy details on App Store Connect. Include data collected by SDKs such as analytics, crash reporting, and ads.
• Screenshots for the required device sizes, an app icon, a short description, and a full description written for users rather than for keywords.
• A content rating questionnaire on Google Play and an age rating on the App Store.
• A demo account with sample data if the app needs a login. Reviewers who cannot get past the login screen reject the build.
• An in-app way to delete the account if users can create one in the app. Both stores now ask for this.

Google Play: Plan for the Closed Test

Personal developer accounts created after November 2023 cannot publish straight to production. The app first has to run a closed test with at least 12 testers who stay opted in for 14 days in a row, and only then can you apply for production access. Organization accounts are exempt, which is one more reason to register the company. If you do use a personal account, recruit testers early and ask them to keep the app installed, because the 14 days start again if the count drops below the minimum.

Google Play also raises the minimum target API level every year, usually with an August deadline for new apps and updates. An app that targets an old API level can no longer be updated until it is rebuilt against the newer one, so check the requirement before planning a release.

App Store: Use TestFlight and Expect Review Questions

Upload builds to TestFlight first. Internal testers in your team can install them within minutes. External testers, up to 10,000 people, need a short beta review on the first build. Apple review for the store itself usually finishes within one or two days, but a rejection adds another round, so leave room in the schedule for at least one.

• Crashes or broken features on the device the reviewer uses. Test on a real iPhone with the latest iOS version.
• An app that is only a website inside a web view, which falls under the minimum functionality guideline.
• Selling digital content or subscriptions with a payment method other than in-app purchase. Physical goods and services delivered outside the app may use a regular payment gateway.
• Missing permission explanations. Every request for camera, location, or contacts needs a clear purpose string.
• Metadata that mentions other platforms, placeholder text, or screenshots that do not match the app.

Building the Release

1. 1Turn off debug logging and point the app at the production API and production keys for maps, push notifications, and payments.
2. 2Build the release artifact, for example flutter build appbundle for Android and flutter build ipa for iOS, or the release variant in Android Studio and an archive in Xcode.
3. 3Upload to the internal testing track and to TestFlight, then install from the store on real devices, including a low-end Android phone.
4. 4Check sign-up, login, payments, push notifications, and deep links on the store build. Debug builds hide problems with signing and configuration.
5. 5Submit for review with release notes, the demo account, and notes for the reviewer that explain anything unusual.
6. 6Release to a small share of users first with a staged rollout on Google Play or a phased release on the App Store, watch crash reports, then widen it.

After the First Release

Keep a release checklist in the repository and automate the build and upload with Fastlane or your CI system once releases become regular. Watch the Android vitals and Xcode Organizer crash reports for the first days after every update. Plan one maintenance release a year for each platform, because both stores require newer SDK versions and an app that is never rebuilt eventually cannot be updated at all.

Companies that serve users in Indonesia should also check whether they need to register as a private electronic system operator (PSE) with Komdigi. Requests from the stores and from regulators often arrive after launch, so it is easier to prepare the documents together with the store listing.