How Publishing an App in Microsoft Store, Apple App Store, and Google Play Store Looks in 2024 (From a Developer's Perspective)

Introduction

Hi, there. If you've been curious recently about how does publishing an app in the Microsoft Store, Apple App Store, and Google Play Store looks like —you're in the right place. More specifically, if you're a developer and you're curious how does it all look like from a developer's point of view in 2024 - the story I'm about to tell is going to be, hopefully, useful for you.

So, for starters, this text will tell a story from a perspective of 2 developers - (mostly) myself and my colleague. We're both developers with a a regular software development day job. My main expertise lies in Embedded software (and some Desktop). An my colleague has an even greater expertise in both Embedded and Desktop. But, as you're about to read - our dev experience is not limited to just that. As such, in our free time we run this startup that develops mostly audio-oriented apps (mostly for Desktop & Mobile). And although we've previously published some of the apps on some of the platforms (some of it successfully, some of it less so). In 2024 it was finally time for a new round of attempting to publish app(s) on 3 platforms that we were interested in - Microsoft Store, Apple App Store and Google Play Store.

This article will recount our journey through the publishing process (mostly my experience). A bit about our combined experience developing for each platform. As well as what our expectations were, what went well and what didn't. How much time and effort each publication took. And some additional notes about the process.

Disclaimer: This isn't supposed to be a comprehensive guide on how to publish your apps on these platforms. Instead, it aims to highlight how such an attempt went for us, plus some additional notes and insights.

About the Apps We Intended to Publish (and Some General Context)

To start things off, for better understanding I should probably tell some backstory first. So, there's this startup that I'm a part of. This startup is a project of just 2 developer s- me and my colleague. Where both of us are software developers with pretty much regular jobs. And in our off hours we run this startup that developer apps. Most of it are audio-oriented cross-platform apps for various platforms.

This startup has existed for quite some time now (10+ years) in various form. Some of the Apps are in active development, some are essentially put on hold. It is worth mentioning that at least few of the Apps were previously published at different times and stages on Apple App Store, Google Play Store and 3rd-party e-commerce platform (back when this was still a thing on Windows). Some of these were quite successful, some of it less so.

Still, last active round of publishing took place a few years back already. Our experience has changed since then. The whole market has changed since then. So it was finally decided that I should try publish our apps again.

So, the big plan for 2024 was: - Find out what can we actually publish in the Microsoft Store, Apple App Store, and Google Play Store. And if we can, how much time and effort will publication and support take? - How to potentially monetize these applications on these platforms (or just 'sell' in simpler terms), and later use that as an additional source of income ?

Taking all this into account, the initial thought was to publishing some kind of "Hello World" app as a pilot project. So we could try out the entire publishing process all the way through. It quickly turned out though that none of the 3 platform would allow a "Hello World" . For the simple reason that quite understandable this would be considered a spam from a platform's point of view.

And so, we had to change tactics and chose 1 of our existing old apps instead. The app itself was rather old. At that point it had existed for 10+ years, and was frankly in need of an major update. It was (and still is) a cross-platform Desktop App (Windows and macOS) Audio-oriented App that had been earlier published on Apple App Store. So a refresh and an update would do it some good.

After a while, however, it did turn out that this old existing App needs a substantial rework. And it didn't support all the platforms that were of interest to us. So we had to change tactics again.

This time we were looking a pilot project that we'll be able to develop and later publish to all 3 platforms (Microsoft Store, Apple App Store, Google Play Store). And after some deliberation we've decided to risk it all and create a brand new App that would fit these requirements. So we've used some of our own quite old code (Win, Qt) and veeery old code (WinAPI) and make a brand new app out of it/ An app that will do like1 thing but do it very well.

As a result, this was quite an interesting experience, experimental even (neither of the 2 of us were entirely sure that this will work). And in the end it turned to be as follows: - a cross-platform app that has its Core part in C++ (all in one .cpp file btw) - all the platform/OS specific integration is explicit and placed in a separate source files (for each platform) - this integration is implemented using mostly native API only of the respective platform - Only the default project templates (i.e. Hello World) are used for builds and configuration, using the default dev environment provided by platform's manufacturer.

All and all, this new approach was a success and the new app was created. Frankly, this new experimental approach to writing cross-platform apps is quite interesting on its own. And would definitely be a good topic for a separate article. But I digress.

So to sum it all up, the plan was to publish :

  1. Existing Cross-Platform Desktop App
    • Platforms: Windows, macOS.
    • History: The app has been around for over 10 years.
    • Previous Publications: Previously published in Apple App Store and a third-party e-commerce platform.
    • Domain: Audio processing.
    • Technology Stack: C++, Qt.
  2. New Cross-Platform App
    • Platforms: Desktop (Windows 10/11, macOS), Android (phones, tablets, Chrome OS), Wear OS, iOS, watchOS.
    • History: New app developed in 2024.
    • Previous Publications: None.
    • Domain: Audio processing.
    • Technology Stack: C++ for the core part, Java (Android and Wear OS specific parts), Objective-C (iOS, macOS, watchOS specific parts).

Additional Note: As non-U.S. residents based in Europe, some notes regarding tax forms and banking will be posted in that context, and therefore applicable only to someone in a situation similar to ours.

Microsoft Store

The Microsoft Store happened to be the first platform we tried to publish apps on in 2024. Neither of us had any prior experience with publishing anything on it. But either way, we did decide to give it a go.

The entire publishing process can be roughly divided into four major stages: registration/recovery of developer account, product setup, upload/testing/certification, and the actual (production) release in the Microsoft Store.

Registration or Recovery of Developer Account in Microsoft Partner Center

So, step one is registering or recovering a developer account in the Microsoft Partner Center.

Microsoft offers two types of accounts: Individual or Company. The differences lie in whether it's your main type of activity and income, the cost of registration, the set of features the portal offers, including how Microsoft as a legal entity will interact with you. Creating a new account implies paying a registration fee, which depends on the type of account you're about to open and your country of residence. More details can be found here.

Note: Throughout the entire registration process, the Microsoft Partner Center is quite sensitive to how many and what type of accounts are currently logged in, especially if there are two or more Microsoft accounts. Therefore, it is recommended to complete the entire registration process, for example, in Incognito mode.

Since neither of us had an existing developer account on the platform, I've opened a new one. Details can be found in Steps to open a Windows developer account in Partner Center.

When creating a new account, you'll need to:

  • Choose the type—Individual or Company.
  • Select the relevant Partner Programs you wish to enroll into (for publishing desktop apps in the Microsoft Store, select the Windows and Xbox program).
  • Pay a one-time registration fee.
  • Verify your contact email via an OTP verification code.

If everything went OK—you've just got yourself a brand new developer account. And the next step is to set it up. Account setup can be roughly divided into sections with developer information, sections with tax and bank account data, and setting up all necessary Partner Programs.

Developer information is filled out in the Organization profile section under Account Settings. Specifically, in the Legal info section, you fill in the official legal information about yourself as a developer. Your contact information (Contact info) is also entered there.

Partner Programs. Ensure that your account is enrolled into all the necessary Partner Programs (for example, the Windows and Xbox app developer program) in the Programs section of the main Account Settings. You can add a new Partner Program in the + My access section on the main dashboard.

Bank Account and Tax Forms. These details can be filled out in the Payment and Tax profile section:

  • Payout Profile
    • This one is quite straightforward—fill in all the required bank account information for payouts. This one is highly dependent on your country of residence and bank.
  • Tax Profile
    • In our case as non-U.S. residents, Microsoft acts as your tax agent in the United States. Therefore, to pay taxes on your behalf and file documents with the IRS, you need to fill out the IRS W-8BEN Certificate of Foreign Status of Beneficial Owner for United States Tax Withholding and Reporting (Individuals).
    • In the Tax profile section, you need to fill out and submit this W-8BEN form. For example, in our case, when filling out the form, we selected:
      • Non-U.S. resident.
      • Permanent residence address (according to instructions choosing a P.O. box or "in-care-of address" is not allowed).
      • Without U.S. Tax Identifier Number (TIN), but with Foreign TIN.
      • Include Tax Withholding treaty, choose appropriate percentage.
    • Not Legal Advice: It's highly likely that there's a double taxation avoidance agreement (or something similar) between your country of residence and the United States. According to most materials I've read, the Tax Withholding Rate should be chosen based on this treaty.
  • Do not forget to link the Payout Profile to your Tax Profile.

Product Setup in Microsoft Partner Center

Technically, you can start creating a new product in Partner Center as soon as you create your developer account and enroll into one of the Partner Programs. That is, you don't need to fill out all the banking and tax details from the previous section to start creating a new product. However, to submit your newly created product for review for publication and get paid, the Tax and Payment Profile need to be filled in.

To create a new product, follow Main dashboard → Apps and Games → New Product. For Win32 apps, Microsoft offers two product types—'MSIX' or 'MSI or EXE'. It is important to choose carefully because once the product is created, the type cannot be changed (at least manually without Microsoft's support).

To sum it all up very briefly:

Feature Packaged (MSIX) Unpackaged (Win32)
Hosting Complimentary, provided by Microsoft Publishers are responsible for hosting and costs
Commerce Platform (payment, in-apps, subscriptions, licensing) Use Microsoft Store commerce platform or your own or third-party platform Use your own or third-party commerce platform
Code signing Complimentary, provided by Microsoft Publishers must sign with a certificate from a CA in the Microsoft Trusted Root Program and cover costs

More details about the types and their differences can be found at How to distribute your Win32 application through Microsoft Store.

Note: We had chosen 'Packaged (MSIX)', mostly because it was just easier for our situation.

The next step is to create and fill out the App Submission:

  • Reserving the product name.
  • Pricing and availability section (price and regions your app will be available in).
  • Properties section (selecting a category for your app and providing various support information).
    • In case your app collects any personal data, you'll also need to provide a Privacy Policy for your app (provided as a URL).
    • It is also recommended to fill in the System requirements subsection, such as necessary hardware features required or recommended for your app.
  • Age ratings section—complete a questionnaire to set the recommended age rating for your app.
  • For the 'Packaged (MSIX)' type of app—the Packages section (.msix, .msixbundle, .msixupload, .appx, .appxbundle, .appxupload, .xap) lists packages associated with this App Submission (more on that later).
  • Store listing section—all the data for your app's page in the Microsoft Store.
    • List of languages supported by the app and additional languages for Store listing. For each language in Store listing, you'll need to provide: - Logos for the app (9:16 Poster art 720×1080, 1440×2160; 1:1 Box art 1080×1080, 2160×2160; 1:1 App tile icon 300×300). - Screenshots for Desktop, Mobile, Xbox, Holographic. - Optionally—Trailer Video, Windows 10 and Xbox images, Xbox images, Holographic image, Windows 8.x and/or Windows Phone 8.x images.
  • Submission Options section—choose whether to publish immediately after certification or according to a set schedule.

Read more at Create an app submission for your MSIX app.

Upload, Testing, and Certification

Upload: As mentioned earlier, depending on the type of product (App Record) selected in App Submission, uploading means:

  1. Unpackaged (Win32)—upload the signed .EXE or .MSI installer to your website and provide a valid HTTPS link to it.
  2. Packaged (MSIX)—upload the package (.msix, .msixbundle, .msixupload, .appx, .appxbundle, .appxupload, .xap) either directly in the Packages section of App Submission or select one of the packages already uploaded to Package flights (discussed later).

More details on Win32 app distribution options here: How to distribute your Win32 application through Microsoft Store.

More details on MSIX package requirements here: App package requirements for MSIX app.

Package Flights

For app testing, specifically for distribution to a limited group of testers, Microsoft offers Package flights. For testers, a Package flight looks almost like a regular app release in the Microsoft Store. For developers, it also looks like a near-full-fledged App Submission release. For example, Package flights also undergo the Certification procedure (more details later) but with somewhat relaxed requirements.

Additional Notes

If you plan to create an MSIX package from an existing .EXE or .MSI using MSIX Packaging Tool:

  1. Fill out Publisher Name as CN=<id>, where <id> must match the ID in the developer account.
  2. Publisher Display Name must also match the developer account.
  3. Package Name should be specified as <Publisher Display Name>.<Product Name>, which must also match the developer account.
  4. Package Display Name must match at least one of the Reserved Product Names.

Certification and Release to Production

App Certification for Submission to Microsoft Store:

After the App Submission is filled out and ready for publication, and you have clicked the Submit to the Store button, the certification process (or review) begins.

  1. The first stage is Validation —a set of automated tests and various checks.
  2. The second stage is In certification —this is the review conducted by a person (or it seems so), checking your app for compliance with Microsoft's internal guidelines. A few notes on common issues at this stage:
    • The app name (App Title in the title bar) must match exactly at least one of the reserved product names.
    • Installed components visible to the user must also have names that match exactly at least one of the reserved product names.
    • The About section in the app must contain information that matches what is specified in the developer account.
    • There is a public version of the Microsoft Store Policy, and an internal version of the same Microsoft Store Policy. The report after Certification will reference the internal version.
      • For example, such text in the report with a link to the internal version:

Technical requirement policies Notes to publisher
10.1.4.6 App Quality - Misleading Content
Information within the product or metadata does not accurately represent the product. Products need to have unique functionality and value in the Store. For more information see Microsoft Store Policy 10.1 at
http://go.microsoft.com/fwlink/?LinkId=620446.

Solution: Write to support at reportapp@microsoft.com.

Once Certification is passed, the product can be published in the Microsoft Store. Or it will be published automatically if you select the appropriate option in App Submission.

If you've reached this point—congratulations, your product is officially published!

Post-Release Notes (Releasing New Versions, Payments, etc.)

Releasing a New Version

Releasing a new version is essentially the same process of filling out App Submission, with the difference that data from the previous App Submission is retained. A more detailed overview can be found here: Publish update to your app on the Store.

About Payments

In addition to the one-time registration fee for the developer program (mentioned in earlier sections), there is an additional commission if Microsoft acts as the payment processor. That is, for the Packaged (MSIX) option, the commission is 15% for apps and 12% for games. For the Unpackaged (Win32) option, there is no such commission. More details can be read here.

About Payments to Your Account:

All payments follow a payment schedule (monthly) and have a minimum limit ($50). The transaction itself takes 7–10 business days. In our case (non-U.S. resident, non-U.S. bank) - bank's compliance department had requested a proof of income in a form of official contract. We were lucky, and a copy of 'Development Agreement' with Microsoft and a report about the payout did the job. But your mileage may vary.

Additional Tools

Microsoft offers several tools for monitoring app's performance once its released. Including but not limited to Downloads stats, Page Views count (page in the Microsoft Store), and Purchases or as Microsoft calls Acquisitions. There's also a Health Report—various stats on crashes, hangs, and other failures. Not that all those stats would give you some deeply unique understanding of your app's performance (both in the Microsoft Store and once installed on end user's device). But its certainly better than nothing.

Additionally, there are several tools for Advertising and Marketing, such as Targeted Offers and Promo Codes and so on. But Marketing an app is most certainly out of scope of this text. On simpler note though, there's a quite solid guide from Microsoft on how to create a Badge that links to your App's page in the Microsoft Store Link to your app. The guide does include a section about how to specifically create a badge, the "Download from Microsoft Store" one, with all the correct links and assets: Microsoft Store badges.

Summary

Excluding development time, from the start to finish publishing a new app in the Microsoft Store took about 2–3 weeks. And that's assuming working in off ours, creating an account, reading various documents on correctly accounting for taxes, and several iterations of Uploading and Certification. So, a fairly decent result.

Apple App Store

Next platform we decided to publish on was Apple App Store. As mentioned earlier, this platform isn't exactly new to us . Namely, Existing Cross-Platform Desktop App have been already published there for macOS. Nonetheless, that app did not receive a proper major update in years. So, at the very least - a major update was in order. Additionally, there now was a plan to also publish New Cross-Platform App. And that new app implied publishing for new (for us) Apple platforms. So even given prior experience, publishing to Apple App Store presented somewhat of a challenge,

Registration or Recovery of Developer Account in App Store Connect

For starters, given that we'd previously published apps with Apple - we already had a developer account (though inactive for couple of years at that point). So the hope was that we'll be able to recover this old developer account if needed. More so, we'd much rather prefer to actually recover an old account than creating a brand new one. And thankfully, our old account still existed thought in a deactivated state. A such, to recover it all we had to do was:

  • Pay the fee for the developer account.
  • Accept the updated Developer Agreement.

Additionally, from 2024 onwards, to publish new apps or updates in Apple App Store within the European Union, you 'd need to confirm Trader Status (fill out additional data in a special form in App Store Connect) according to the Digital Services Act. Read the details here.

Bank, Tax, Compliance, and Other Information

In our case, there was no need to update any of banking or tax information (except for the Digital Services Act). But generally speaking, Apple Developer Account admin page contains sections:

  • Agreements (Paid Apps Agreement, Free Apps Agreement)
  • Bank Accounts - Your bank account(s) for payouts.
  • Tax Forms The same U.S. Form W-8BEN, just like in the Microsoft Partner Center.
  • Compliance The already mentioned form for the Digital Services Act.

Creating a New App in App Store Connect

To publish your app in the Apple App Store, you first need to create a corresponding App Record for the app (typically one App Record per app). A comprehensive guide on creating a new app can be found here Create an app record — Add a new app

if very briefly, each App Record includes:

  1. Apple platforms the app will support (macOS, iOS (watchOS-only apps are included in the iOS platform), tvOS, visionOS)
  2. General section - info about the app and its developer, contact details, etc.
  3. Trust & Safety section - the very same Privacy Policy and other declaration about what personal data the app collects (or not).
  4. Growth & Marketing section - settings for sales, promo codes, etc.
  5. Monetization section - settings for pricing and market availability.

For each platform that the app supports (which can be added or updated even after creating an App Record), there is a separate section with a list of App Submissions for that platform. Where an App Submission is a set of data about the app version you plan to publish in the App Store, such as:

  • App version (also used to identify App Submissions ).
  • Data for the App's page in the App Store (app description, screenshots, banners, logos, etc.).
  • A Build - one of those already uploaded to App Store Connect (more details on uploading later).
  • Additional metadata (e.g., list of entitlements for macOS).

Actual data that you'll need to to prepare and fill out differs slightly for each platform. OS it's better to Apple's own documentation on the matter. But as of 2024, a macOS App Submission included:

  • Previews and screenshots.
  • Promotional text & App description.
  • Keywords, Support URL, marketing URL (promotional).
  • Version & Copyright text.
  • a Build (from those uploaded to App Store Connect).
  • App icon.
  • Sign-in account data, i.e., login and password for the account with which you can log into your app.
  • Developer's contact info.
  • Sandbox Information (a.k.a macOS Entitlements).
  • Release schedule (planned date or immediately upon approval).

Additional Notes:

  • When creating an App Record, carefully choose the Bundle ID. You can review and edit all this in the Certificates, Identifiers & Profiles section.
  • Carefully fill out and verify metadata in the App Record (for platforms that require it). For example, macOS Entitlements. This will be needed later in the app review process.

Apple watchOS

As of 2024, there are two types of watchOS apps:

  • standalone - the one that can operate independently of the iPhone.
  • bundled - the ones installed alongside companion iOS app.

Regardless of the type - a watchOS app is supposed to be added in the App Submission for iOS platform. So the situation becomes a bit confusing rather quickly. Anyway, at the time of development (mid 2024), the situation was as follows:

  • Apple Watch is not a standalone device, but is paired with an iPhone.
  • standalone watchOS app option is intended for cases when the app can function completely independently of the iOS app, including cases where the iOS app is not installed at all. However, even in this case, watchOS app's content is embedded into iOS app for deployment, uploading to App Store Connect, and App Submission.
  • bundled option is for cases when the watchOS app is a companion app to the iOS app. That is, the deployment and operation of the iOS and watchOS parts are interconnected. Confusingly so, Xcode watchOS bundled project has a checkbox Supports Running Without iOS App Installation (which effectively appears to make it an independent standalone app, but packaged with an iOS one...).-
  • If a public release was made as a standalone watchOS app, you cannot revert to bundled, at least according to support. So, choosing the type should be done carefully.

Additionally, depending on the chosen option (standalone vs. bundled), the deployment and update of the app will differ slightly, even during development. This applies to both Apple Watch simulators and real watchOS devices. But development & debugging of watchOS apps are way beyond scope of this text anyway..

Upload, Testing, and Review

Upload: One of the main stages in App Submission is selecting a Build. To do this, you'll need to upload the Build to App Store Connect. This can be done using one of the methods described in Upload Builds. (In our case, we simply used Xcode.)

Additionally, there is an option to use TestFlight and Xcode Cloud. Where to put a long story short - TestFlight is a tool for distribution and testing, both internally within companies and externally. And Xcode Cloud is for CI/CD workflows.

Technically speaking, to create and submit an App Submission for review you don't have to use neither TestFlight nor Xcode Cloud (although using at least TestFlight is considered a best practice). So, the minimally necessary and sufficient step is to upload your Build to App Store Connect, as in:

  • During Upload choose the "App Store Connect" scope
  • Make sure that basic validation process during upload went smoothly.

Note: It typically takes somewhere between few minutes to few hours for an uploaded build to properly show up in App Store Connect dashboard.

Review and Release of the App to Production

Review: After the App Submission is filled out (including at least one Build that is 'Ready for review' chosen for the App Submission) . Then you can submit your App Submission for review. The review process can take several business days. Typical focus areas during review include:

  • Basic functionality
  • Does the app launches without fail on a given platform ?
  • Does the basic functionality match the declared category ?
  • For iOS and watchOS—screenshots and previews must be accurate and provided for all supported form factors.
  • Metadata in App Submission should match the one in the app
  • App name in App Submission must match the one shown to the user.
  • If there's an About section - information in there must match what is specified in the App Submission.
  • If user data collection is declared —you might be asked why the app needs this data.
  • If access to devices is declared (e.g. macOS Entitlements)—you might be asked the reason why your app needs such access.

Once the review is successfully completed, the product will be published according to the schedule chosen in App Submission.

Post-Release Notes (Releasing New Versions, Payments, etc.)

Releasing New Versions. Releasing new versions is the same as creating a corresponding App Submission. Just fill out the updated data in App Submission, upload the corresponding Build, and submit thi submission for review.

Post-Release Analytics & marketing. Although marketing an App is way beyond the scope of this text. It is still worth mentioning some very basic tools Apple offers such as App Store Marketing Tools. You can create badges like "Download on the App Store" with a link to your app in the App Store, or a QR code with a link to your app. Additionally, there are promotional materials for social networks.

Monetization. Payments are made at the end of each month to the account specified in your account. More details can be read here. You can view payment reports in Payments and Financial Reports section in App Store Connect. Depending on your bank and country of residence - your bank may require a contract or some document (that'll confirm origin of payments). In some cases payment report and a copy of a Developer's agreement may suffice,

Summary

Overall it took about 12- weeks to release an update for the Existing Cross-Platform Desktop App app. That is excluding development time and working mostly just in off hours. As for the release of 1st version of New Cross-Platform App - that one took a bit longer, about 3–4 weeks (mainly due to extensive testing of the version for watchOS).

Google Play Store

And last but not least - Google Play Store. As it was already mentioned - this will not be my first attempt to release an App on Google Play Store. Last time either of us had tried to publish our app - it did not end in successful release. Back then, both of us unfortunately lacked the necessary experience and capacity to make a production-ready app And actually publish it in the Store. And all of it in off hours, also developing in parallel for other platforms. Hence, we decided to postpone development for Android entirely. This time however, a few years have passed and things were quite different. There was a lot more actual development experience under our belts this time around. And a lot better cross-platform support in all of our apps. So we decided to give Android another go. And this time it was a success. Therefore, we postponed it to better times. However, from those times, we still had a developer account in the Google Play Console (or at least we thought so).

Over this time, our experience in Android development significantly increased, so this time, when developing our relatively new second app, we aimed at Android as well.

Registration or Recovery of Developer Account

Now, last time I've tried to publish our App in Google Play Store I've already created a developer account. And was quite honestly hoping that this account was still intact. Or that I'd at the very least be able to recover it by emailing support. But no - it wasn't the case here. After just a few years of inactivity Google decided to simply close and delete the account. Along with all our products in it. Emailing support did not yield much (other than frustration). And after browsing some forums and reading what developer community has to write on the topic I've learned 2 things:

  1. That this is not an isolated incident (it was happening quite regularly actually)
  2. In the end, all what was left to do to was just simply create a new account.

So that's exactly what I did.

Creating a Developer Account To create a new account, I first followed used pretty standard guide: How to get started with Play Console. The procedure is generally similar to Microsoft and Apple:

  • Sign up for a developer account in the Google Play Store.
  • Accept 'Google Play Developer Distribution Agreement'
  • Pay one-time registration fee.
  • Choose the account type (Personal or Organization):

Do note that for Personal accounts that were created after November 2023, there are some additional requirements:

  1. You'll need to verify that the developer has access to a real Android device.
  2. Before publishing to production, you'll need to conduct a testing round with at least 20 testers (individual accounts that must explicitly opt-in for testing). More on that later.. And last but not least - complete developer (or Company) verification procedure. As you might have guessed - I chose Personal account. For the simple reason that it was I that primarily handled everything related to publish for Android. But I digress.

Setting Up the Developer Account Around 2022, Google tightened its requirements for creating new accounts, particularly Personal ones. So now, to verify a developer account, besides the usual you'll need to fill out the following:

  • Full name (official) and address.
  • Contact email (will require verification).
  • Contact phone number (will require verification.
  • Official government identity document, i.e. an official document that proves identity.
  • Additionally, verify the you've got a real Android device. More details: Device verification requirements for new developer accounts.

Creating a Google Merchant Account If you ever plan to sell anything via Google Play Store - your next will be creating a merchant account. That includes:

Additional Note on Tax Forms. In our case (non U.S. resident) - it is also required to submit a U.S. Form W-8BEN. The very same one one mentioned in the Microsoft Store and Apple App Store sections. It was also required to submit an official document that proves Tax Residency. Or in a simpler terms - a document that proves that I indeed am a tax resident of country that I claim I am. Thankfully, my local Tax Office was able to supply me with one. And it was successfully accepted by Google.

Product Setup in Google Play Console

This step is pretty straightforward. Create a new product in main dashboard. Chose either App or Game, free or paid (can change that later in settings) and you're good to go. Next, you'll need to fill out a fairly standard set of info and questionnaires:

  • Set Privacy Policy—the very same privacy policy already mentioned in the previous sections
  • App Access—whether some functionality is restricted by login, location, etc.
  • Ads—whether the app uses Advertising ID.
  • Content Rating—a standard content rating questionnaire.
  • Target Audience— app's target audience questionnaire (children, teenagers, adults).
  • News Apps—whether the app is a News app (yes or no).
  • Data Safety—whether the app collects user data and which data ("collecting" means transferring data from the app off the user's device).
  • Government Apps—whether the app is government-related (yes or no).
  • Financial Features—whether the app offers any financial services/features.
  • Health—whether the app offers any health-related functionality.

Store Listing

Next up is creating and setting up a Store Listing. You'll need to prepare and fill out:

  • App name, short description, detailed description.
  • Graphics:
  • App Icon (PNG or JPEG, up to 1 MB, 512×512 pixels).
  • Feature Graphic (PNG or JPEG, up to 15 MB, 1024×500 pixels)— this one is basically app's main main poster. Its expected that it'll showcase all of the app's main features (sort of like an Ad).
  • Video (optional)—video uploaded to YouTube, public.
  • Screenshots:
  • Phones—up to 8 pieces , PNG or JPEG, up to 8 MB each, aspect ratio 16:9 or 9:16, each side between 320 pixels and 3840 px.
  • Tablets:
    • 7-inch tablets—up to 8 pieces, PNG or JPEG, up to 8 MB each, aspect ratio 16:9 or 9:16, each side between 320 pixels and 3840 pixels.
    • 10-inch tablets—up to 8 pieces, PNG or JPEG, up to 8 MB each, aspect ratio 16:9 or 9:16, each side between 1080 pixels and 7680 pixels.
  • Chromebooks —4–8 pieces, PNG or JPEG, up to 8 MB each, aspect ratio 16:9 or 9:16, each side between 1080 pixels and 7680 pixels.

Google's Store Listing is quite particular about the dimensions and number of screenshots provided. So it is worth to spend some time and double check all of the graphics submitted.

Pricing (for Paid Apps)

Next up is setting up th Pricing section (for paid apps):

  • Create a Merchant Account if you haven't already.
  • Set up either a paid app or a subscription:
    • Set the price(s) (can customize for specific regions).
    • Specify regions where the app will be available.
    • Link to your Merchant Account.

Upload, Testing, and Release

Upload: Since 2021, all new apps must be uploaded as Android App Bundles . To upload a bundle to the Google Play Console - it needs to be signed. Read more here. Additionally, you can configure which key will be used to sign the app in the release. For the vast majority, this will be Play App Signing.

Testing Tracks

So, when it comes to app publishing Google Play Console operates in terms of Releases and Testing Tracks:

  • Internal Testing—release for testing, well, internally within your team during development..
  • Closed Testing—release for a limited group of testers that may or may not include external testers.
  • Open Testing—release of an open beta.
  • Production—successful, main public release.

All 4 are supposed to go in Stages and in that Order. And, well, you're supposed to go through all 4 in order to publish an App to main Google Play Store. At least for your newly created App\Product. Once your 1st Release is all out and about however - then you can skip some of those stages. And if you're bold enough - just creating Production Release could do. But, as you might have guessed - that goes against all the advice bo th from Google's own documentation and pretty much all the articles with best practices on the topic. But I digress.

Internal Testing track is available as soon as the App\Product is created. That means that to start using Internal Testing track you don't event have to configure your App and its Store Listing all the way through. A quite typical scenario would actually be something like you'd create an App first, then upload your builds to Internal Testing track. And while that's in testing, you'd continue to fill out all the data, questionnaire and prepare assets for your Store Listing. Internal Testing track is kind of meant for internal testing within your own team during development. So the number of testers is limited (to about a 100 as of early 2024), and the number of Releases that are out at the same time is also limited (to 1 as of early 2024).

After the Internal Stage is done and over - next up is Closed Testing . This one is about involving a broader group of testers, including external testers. And now there can more than 1 Release out at the same time. To, well, test a few versions of a pre-release app before going forward. Closed Testing track becomes available after completing all the App settings mentioned previously.

Next in line is supposed to be Open Testing track. And this one requires a so-called Production Access, which you have to explicitly apply for. NOTE For personal accounts created after November 2023, there's an additional requirement—in order to apply for Production Access, app must have complete a Closed Testing round with at least 20 unique testers, over no less than 14 days.

This new requirement also applied to me (since I had to create an entirely new account). And as such, I've got some experience to share.

Opinion piece side-note According to Google, the new requirement was introduced to improve the quality of the apps available in the Google Play Store. Basically implying that a mandatory round of Closed Testing will somehow magically improve the overall Quality of the Apps. In reality though, these requirements basically look like a yet another raising of an already high cost of Android development. Especially for Indie Developers (which includes me as well). And especially Indies Solo Developers with limited resources (lime Time). In the end, this mandatory round of Closed Testing will not actually Improve overall quality of the Apps. But would rather make it even worse. And the reason is quite simple. All the efforts and resources that could have been spent on actual quality improvements - would now be spent on tackling this new requirement instead. Be it Indie Solo Developers, or a small teams. And at the same time for those Do want to hack it, and release an app regardless of its quality (yes, scammers, I'm looking at you) - this new requirement won't make much of a difference. End of Opinion piece side-note

So. If you're an Indie Developer like us. And you don't actually have 20 QAs ready to test you new Android App. Here's a couple of options for you to try and get yourselves a group for Closed Testing:

  1. Ask 20 family members, friends or acquaintances to join
    • They must have an Android device and an active Google account linked to that device.
    • To start testing, they need to give active consent (opt-in). So, be prepared to write detailed instructions on how to join testing, considering that not all your friends and relatives will be technically savvy.
    • You will also need to provide some technical support for this group because even if the instructions are sufficient and everyone in the group can join testing, during the 14-day testing round, questions about the app will arise.
  2. Buy or find 20 Android devices (and 20 Google accounts)
    • At first glance this might seem like an overkill (Like who the Hell just buys 20 Android devices just to overcome Google Play Console requirement ?). BUT. Practical experience shows that if you're developing professionally for Android (And judging by the fact that you're trying to publish something in the Google Play Store - you most likely are). It is quite likely that you App supports 3-4 different Vendors, at least 3-4 versions of Android. And a couple of popular form-factors (let's say Phones and Tablets). This combo alone is 24 devices already. And as such, it wouldn't be a stretch to say that actually owning this many device is Not an overkill after all. Especially if you look at the device support list of even the mid-sized Apps (and those have a waaay longer list than this).
  3. Find 20 testers on Social Media
    • For example, there's a subreddit AndroidClosedTesting created precisely for finding willing testers to test each other's apps.

As for me, I've used all 3 options in one way or another. Most of the group was formed by our own devices. With addition of some friends and family members. As well as kind people of Reddit to make a group of testers a little more diverse. It all ended up being quite an interesting experience. But to sum it up - vast majority of actual major issues were found by ourselves during either manual review or running tests on or own device. Friends and family did help us find a couple more major issues. And lastly, kind people of Reddit did do some testing, but that ended up bringing the least amount of useful feedback (meaning the one we could use to trace issues back). Which is more than understandable. And regardless, I'm still quite thankful to the kind people of Reddit for testing it at all.

Now, if you work for a company or a team that has QA;s on hand - none of the above is that applicable to you. But still, I hope that Solo developers did find at least some of the info useful.

So, Once the Closed Testing is done, and your Application to Production Access has been reviewed and approved. Then you can start a round of Open Testing. Which is none other than plain old public Beta Release. Now, Application to Production Access itself is not too complicated, and includes:

  • Filling out a form about the results of the Closed Testing round.
  • Pass Google's Internal review. This internal review pays attention to things like the results of the pre-launch report . Your Store Listing will also be scrutinized for compliance with Google's guidelines for a Store Listing. For instance, correctness of screenshots provided. As in do screenshots actually reflect the App's interface or not.

Internal App Sharing. In addition to the aforementioned Internal Testing track, there's also one more option for testing within your team - Internal App Sharing. This one is not a full-blown Release, bur rather a quicker way to upload and share a Build with testers via a link.

WearOS Releasing an App for WearOS is a bit special. Mostly because WearOS counts as a separate form-factor, and is not counted along with main 'Phone\Tablet\Chromebook' combo form-factor. As such, there's a more or less separate Releases for WearOS under each of the Testing tracks. So there would be 2 Releases in a Closed Testing track if your app supports both phones & tablets and WearOS -1 per each form-factor. In all other regards its pretty much the same as a regular Release. Developing & deployment for Wear OS is a whole different story though. But that would be beyond the scope of this article.

Release of the App to Production

One might have guessed already that a final Release to Production in Google Play Console means creating yet another Release, but in Production track. That is given that all the required conditions are met:

  • At least one release in Closed Testing is completed.
  • Production Access is already granted (i.e., Store Listing has passed review).
  • Optionally, all banking and tax information is already entered (for paid apps).

If the answer is Yes then all you'd have to do is to:

  • Create a release in the Production track.
  • Fill out all Release Notes.
  • Wait for this Release to pass Review.

Typically, review process takes anywhere between a few hours an 2–3 business days. And if everything's good then congratulation! You've an App released in the Google Play Store!

Post-Release Notes (Releasing New Versions, Payments, etc.)

Releasing New Versions Releasing new versions of an App looks more or less the same as releasing the 1st one. Except that, of coarse, your account has already been setup, your product has been configured and a Store Listing have already been mostly put together. So you can re-use basically all of that when releasing a new version. Hence, the bulk of the work will be to create, test and publish a new Release in a Production track

Technically speaking, you can skip all the other testing tracks when posting a new version of your App. But that is considered to be rather a bold choice. More so, most if not all docs on the topic advise to actually create those intermediate Releases for if nothing else then for running bunch of automated tests in Firebase. But, of coarse, you do you. (And creating and running auto tests to run in Firebase is quite beyond the scope of this text)

App's Performance once released Google Play Console's dashboard in fact offers a whole separate subsection to monitor App's performance once its Released. Both for App itself and for Store Listing conversions. These metrics include but not limited to things like Apps' Crash & ANR rate, App's Vitals, average frame rate, number on installations, distribution of devices that App is installed on, and so on. There's also a section for setting up Store Listing experiments, sales and things like that. Yet again though, Marketing an App is way beyond the scope of this text, so I digress.

Payments Payments are usually a fairly straightforward process. Although it is to be Noted that the exact conditions and requirements change over time, and Are highly dependent on your Payment profile setup (i.e. country of Residence and Bank) More about that here. In my case, yet again, a copy of Developer's Agreement and a payments report was enough for my Bank to proceed with the funds.

Summary on publishing in Google Play Store

As you might have guessed - publishing in the Google Play Store was the most lengthy one so far. All and all, creating new dev account, setting up a product and Releasing the 1st version of the App to Production took almost 2 month of my time. Again, this does not account for development time, and assumes working mostly in my off hours (aside from the day job). The longest stage unsurprisingly was the mandatory Closed Testing round— this one took a bit over a month to setup and run. Including finding and\or buying devices and setting those up. And also finding and convincing friends and family members to take part in the testing. Writing quite a comprehensive guide for them how it all works (and Yes, that meant playing a Role of their Tech Support for a month). And last but not least - asking kind people of Reddit to do some testing, and testing their Apps back. So, all and all about 2 month.

Releasing a new version, quite unsurprisingly, took way less time - about a week, same conditions (does not include dev time, working mostly in off hours).

Summary

To sum it all up - across all 3 platforms, releasing the very 1st version (+ a major update in the App Store) took about 3 months of work of just 1 person. Yet again, not accounting for dev time, working mostly in off hours. The most time (and bureaucracy) was spent on the 1st Release in the Google Play Store. Publishing a new App in the Microsoft Store took about as much as publishing a new App n Apple App Store - 1-3 weeks.

Would I recommend Microsoft Store, Apple App Store, and Google Play Store to Indie/Solo developers in 2024? Heavily depends on your circumstances and experience. if compared to similar experiences from just about 5 years ago - releasing an app for the very 1st time has undoubtedly become more complicated (in terms of time and effort). Is it still possible to do it all for Solo developers? Definitely, Yes.

And lastly, here's the links to Apps discussed here: