DEV Community: TheIOn-Project

Google Play runs your app on real devices before launch, and most first-time publishers never look

TheIOn-Project — Sat, 06 Jun 2026 18:31:00 +0000

Most people publishing their first Android app think the Play Console is basically an upload form. You push your build, fill out some forms, hit publish. What a lot of them miss is that Google quietly runs your app on a rack of real, physical devices the moment you upload to a testing track, and then hands you a report. It is called the pre-launch report, and it sits in a menu most people never open.

Here is what it actually does. Google installs your app on a spread of real devices, different screen sizes, different Android versions, and crawls through it automatically. It taps around, fills in fields, moves between screens. Then it tells you where the app crashed, which screens have accessibility problems, whether you are leaking anything over the network, and if any of your dependencies have known security issues.

That last part catches people off guard. You can ship an app that runs perfectly on your own phone and still get flagged because a library you pulled in three versions ago has a vulnerability Google now knows about. The pre-launch report surfaces that before your users ever see it.

The crash data alone is worth the look. Testing on your own device tells you the app works on your device. The pre-launch report tells you whether it works on a Pixel running an older OS, on a low-memory phone, on a tablet. Those are the failures that quietly show up in your one-star reviews later if you skip this step.

The catch is that the report only generates after you upload to a track, so by the time most first-time publishers find it, they have already promoted the build to production. The better move is to upload to internal testing first, wait for the report to populate, read it, fix what it flags, then promote. It adds maybe a day. It saves you a bad launch.

This is one of those steps that is easy to know about in theory and easy to forget under deadline pressure. That is part of why I built IOn Emit, a freemium desktop app that walks you through the Google Play publishing flow and makes sure things like the pre-launch report get checked before you ship, not after. You can find it here: https://theionproject.com/ionemit

If you take one thing from this, let it be this: do not promote a build to production that you have not seen a pre-launch report for. The data is already sitting there. You just have to open the menu.

Google Play turns on every country by default, and it can quietly cost you a week

TheIOn-Project — Wed, 03 Jun 2026 22:12:02 +0000

There's a Play Console setting almost nobody checks on their first release: country and region availability. It defaults to every country switched on. All of them. And that default feels generous right up until it bites you.

Here's the problem. Your store listing, your privacy policy, your content rating, and even your screenshots get evaluated against the rules of every region you ship to. If your app is live in 170+ countries, you've opted into the strictest interpretation of all of them at once.

Where this actually bites

A few real failure modes I've seen:

Store listing rejections from markets you never thought about. Some regions have stricter rules on health claims, gambling references, or financial language. A sleep app that says "treats insomnia" can sail through in one market and get flagged in another. Your release sits in review while you figure out which market triggered it.

Untranslated listings doing quiet damage. Google doesn't block you for shipping an English-only listing to non-English markets, but users in those markets see an obviously foreign app, bounce fast, and that engagement signal drags your ranking down everywhere.

Tax and legal exposure you didn't sign up for. Selling a paid app or in-app purchases in some countries creates tax obligations. Most solo devs have no idea they've technically opted into this.

Reviews you can't read. Your first one-star review in a language you don't speak, about a payment method you didn't know existed, is a rite of passage nobody asks for.

The fix is boring and takes five minutes

Start narrow. Pick the markets you actually understand: your home country plus a handful where you speak the language or know the rules. Ship there first. Watch your crash rates and reviews. Then expand deliberately, a region at a time, translating the listing as you go.

You can always add countries later. Removing one after users have installed your app is much messier.

This is one of those defaults that exists because it's good for the platform, not for you. Treat country availability as a launch decision, not a checkbox you never open.

I build IOn Emit, a freemium desktop tool that handles the Google Play publishing flow and flags traps like this before they cost you a release cycle. If you're sitting on an app you keep meaning to ship, it might save you a weekend: https://theionproject.com/ionemit

Curious how others handle this. Did you launch worldwide on day one, or start with a few markets?

The 12-tester rule that quietly adds two weeks to your first Google Play launch

TheIOn-Project — Mon, 01 Jun 2026 22:08:00 +0000

If you are about to ship your first Android app, here is the rule that catches almost everyone off guard.

Google Play now requires new personal developer accounts to run a closed test with at least 12 testers, and those testers have to stay opted in for 14 days straight, before you are allowed to promote the app to production. Not 12 installs. Twelve actual accounts that join your closed track and keep it for two full weeks.

Why this trips people up

The code is usually done long before you hit this wall. You build the release, you sign it, you fill out the forms, and then you reach the production step and Play tells you that you need a completed closed test first. So the clock you thought started today actually starts whenever you can round up 12 people. For a solo dev that is the hard part, not the build.

What actually counts

A few things that are easy to get wrong:

The testers have to opt in through the testing link and install from Play, not sideload your APK.
They need to stay in the program for the full 14 days. If people drop out and your count dips below 12, the timer can stall.
The 14 days are continuous, so a gap can reset your progress.

How to not lose two weeks

Start the closed test the day your build is stable, not the day you want to launch. Line up your 12 testers in advance, friends, a small Discord, a subreddit, whatever you have. Send them the opt-in link early and confirm they actually installed. Then let the two weeks run in the background while you finish your store listing and screenshots.

The mistake is treating publishing as the last 30 minutes of the project. On Play it is more like a two week tail you have to plan around.

A shortcut

This is one of the reasons I built IOn Emit, a freemium desktop tool that walks you through Google Play publishing step by step and flags requirements like the closed testing track before they cost you time. It will not magically skip the 14 days, but it makes sure you start the clock on day one instead of finding out about it on launch day.

More on it here: https://theionproject.com/ionemit

Play App Signing: the one Android publishing decision you cannot undo

TheIOn-Project — Fri, 29 May 2026 22:08:57 +0000

If you are about to publish your first Android app, there is one screen in the Play Console that deserves more attention than it usually gets. It is the app signing setup, and unlike almost everything else in the publishing flow, the choice you make here is permanent.

What app signing actually is

Every Android app has to be signed before Google Play will accept it. The signature is what proves future updates came from the same source as the original. If the signature does not match, Play rejects the update. No override, no support ticket that fixes it.

There are two keys in play. The upload key is what you use to sign builds before sending them to Play. The app signing key is what Google uses to re-sign your app before delivering it to users. With Play App Signing turned on, Google holds the app signing key and you only manage the upload key.

Why the permanent part matters

When you enroll in Play App Signing, the app signing key lives with Google for the life of that app. You cannot rotate it out later the way you might rotate the upload key if it leaks. That sounds scary, but it is actually the safer default for most people. If you lose your upload key, you can request a reset and keep shipping. If you were managing the app signing key yourself and lost it, your app would be stuck forever, unable to ship a single update.

The mistake first-time publishers make is treating this as a throwaway step. They generate a keystore, forget where they saved it, and only find out months later when an update gets blocked.

A few habits that save you

Back up your keystore somewhere you will still have access to in two years. Not just your laptop.

Write down the key alias and passwords in your password manager the moment you create them. These are not recoverable.

Turn on Play App Signing unless you have a very specific reason not to. For a solo dev or small team, the tradeoff almost always favors letting Google hold the signing key.

Where this fits in the bigger picture

App signing is one of those steps that is easy to get right and very expensive to get wrong. It sits alongside a handful of other Play Console gotchas that quietly decide whether your launch goes smoothly or stalls for two weeks.

I got tired of re-learning these details on every release, so I built IOn Emit, a freemium desktop app that walks you through the publishing flow and flags the irreversible steps like signing before you commit to them. If you want to see how it handles the signing setup, it is over at https://theionproject.com/ionemit.

The short version though: whatever tool you use, treat your keys like they are irreplaceable. Because they are.

The Play Console questionnaire that quietly decides your app's distribution

TheIOn-Project — Wed, 27 May 2026 22:13:22 +0000

There's a step in the Google Play publishing flow that doesn't get talked about much, but it quietly controls where your app can be installed and who can see it.

It's the content rating questionnaire.

Google requires every app to go through an IARC rating before it can go live. The questionnaire itself only takes about five minutes. But the answers you give determine whether your app gets rated Everyone, Teen, or Mature 17+, and that rating directly affects distribution. Some countries restrict apps with higher ratings. The Designed for Families program is locked behind an Everyone rating. And once your rating is set, changing it means resubmitting and waiting for a new review.

Here's where it gets tricky.

The questionnaire asks about things like violence, language, sexual content, controlled substances, gambling, user-generated content, and location sharing. Most of those are straightforward if your app is simple. But the user-generated content question catches a lot of people off guard. If your app has a WebView that loads external pages, Google may consider that UGC. If you say yes to UGC, your rating jumps, and you might lose access to distribution in certain markets.

The other common mistake is over-disclosing. If you're building a health app and one screen mentions nicotine or alcohol in an educational context, you might be tempted to flag it. But doing so can push your rating higher than it needs to be. The questionnaire is about what your app enables or depicts, not what it references in passing.

A few things worth knowing before you start:

The rating applies globally, but each store interprets the IARC rating slightly differently. Google Play tends to be stricter on UGC and gambling triggers.

If your app changes significantly, like adding a chat feature or in-app purchases tied to chance, you're supposed to redo the questionnaire. Google doesn't always catch this right away, but when they do, your app can get suspended until the rating is updated.

The questionnaire is also one of the gates you have to pass before your first production release. If you skip it or leave it incomplete, the Publish button stays grayed out and Google gives you almost no feedback about why.

I built IOn Emit to walk through this step as part of the publishing flow, so you don't have to guess at the answers or realize three weeks later that your rating is limiting installs. It's freemium and handles the content rating alongside the rest of the Play Console checklist.

theionproject.com/ionemit

Anyone else run into a situation where their content rating unexpectedly changed their app's reach?

The App Bundle switch most first-time Android publishers still skip

TheIOn-Project — Thu, 21 May 2026 17:57:04 +0000

Most first-time Android publishers learn the App Bundle thing the hard way. They upload an APK, the install fails on some user's phone with a missing native lib error, and somewhere in the Play Console support page they finally read that Google has been requiring App Bundle for new apps since August 2021.

If you've never made the switch, here is the short version of what changes.

What App Bundle actually does

An APK is one big file with every resource, every native lib, and every language file packed in. When a phone installs it, the phone gets all of that, even the parts it will never use. A Pixel 8 running in English does not need the arm64 native libs alongside the armv7 ones, does not need every screen density asset, and does not need 80 language files.

App Bundle (.aab) flips this around. You upload one bundle, Play generates per-device split APKs at install time. The phone only downloads the slices it needs.

The practical effect on a real app:

Install size shrinks. On apps with native code, this is often 30 to 50 percent smaller.
Crash reports for missing libs basically stop. The wrong-ABI install path doesn't exist anymore.
Updates are smaller because Play patches the slice, not the whole binary.

The mistakes people make on the switch

A few things bite people who are coming from APK uploads.

Forgetting to sign with Play App Signing. App Bundle requires Play to do the final signing. You upload your bundle signed with an upload key, Play signs the artifact that goes to users. If you skip enrolling, the upload just fails.

Confusion about which keystore matters. Your upload keystore signs the bundle on upload. Play's signing key signs the artifact that ships. If you lose your upload key, you can reset it. Lose the Play signing key and there is no recovery path, but you don't hold that one in the first place once enrolled.

The 200MB initial download limit. App Bundle install slices have a cap. If yours blows past it, you need asset packs or Play Asset Delivery to push large assets separately. APK didn't have this exact split-and-cap rule, so it catches people off guard.

Skipping the install audit. It's worth checking the per-device install sizes in Play Console under App Bundle Explorer once the bundle is live. The size variance across device classes is often bigger than expected, and a few unintentional resources usually get caught here.

How to verify the switch is doing its job

Few quick checks once you're live:

App Bundle Explorer in Play Console shows the per-device APK sizes. Spot-check a couple of common devices to see what users actually download.
Pre-launch report should show fewer install-time errors on the device matrix.
Crash reports filtered to UnsatisfiedLinkError or similar native lib errors should trend toward zero.

If you want the switch handled automatically as part of the publishing flow alongside the rest of the Play Console paperwork (data safety form, content rating, signing setup, asset specs), IOn Emit is a freemium desktop tool I built specifically for that. It sets up App Bundle by default and walks through the bits that usually catch first-time publishers.

The upgrade from APK to App Bundle is one of the rare changes where you get smaller installs, fewer crashes, and smaller updates all at once. If you're still uploading APKs and shipping to Play, it's worth an hour of your weekend to make the swap.

The August deadline that quietly knocks Android apps off Google Play

TheIOn-Project — Fri, 15 May 2026 22:07:03 +0000

Every August, Google Play raises the minimum target API level for apps in the store. If you have not updated your app to that new target SDK by the deadline, any new release you try to push gets rejected. Existing builds stay live for a window, but you cannot ship updates, fixes, or new features until you catch up.

For solo devs this one is brutal because it does not announce itself in your dashboard. The Play Console just starts refusing your release with a message that almost looks like a normal validation error.

Here is what usually breaks first.

Your build.gradle is locked to an older target

Most Android Studio templates write a targetSdk value into the app module build.gradle the day you create the project. Nobody touches it after that. Two years later it is still pointing at the same number, and now Play wants something higher.

The fix is one line:

defaultConfig {
    targetSdk 34
}

The trap is that bumping targetSdk usually breaks behavior. Background work, scoped storage, notification permission prompts, exact alarms, all of these change with API level. You bump the number, you also need to do the migration work.

You also need to update compileSdk

Google Play checks targetSdk, but you will run into runtime crashes if compileSdk is older than the libraries you depend on. AndroidX, Compose, and a lot of Google Play services updates pin newer compileSdk values. Update both at the same time.

App Bundle uploads do not auto-rebuild

If you uploaded an .aab and then bumped target SDK in code, the .aab on Play is still the old one. You have to upload a fresh build. Sounds obvious until you spend an afternoon wondering why the warning is not going away.

Beta and internal tracks have the same rule

The deadline is not just for production. Internal testing, closed testing, and open testing tracks all enforce it once the cutoff hits. So you cannot work around it by demoting your app to a test track.

How to spot it before it bites

Set a recurring reminder in May or June every year. Google announces the new target SDK requirement months ahead. Read the Android Developers blog post when it lands. Bump your project before July, push a test build, leave a couple of weeks to fix migration issues.

If you are juggling several apps, this becomes a real chore. Built IOn Emit to flag the target SDK gap before you hit the Play Console, alongside the data safety form, signing key checks, and the rest of the release checklist. Freemium so you can try the core checklist for free. https://theionproject.com/ionemit

Anyone else been caught by the August cutoff? Curious how others batch the target SDK migration across multiple apps.

The privacy policy URL is the quiet blocker on your first Google Play release

TheIOn-Project — Tue, 12 May 2026 21:29:26 +0000

Most of the Google Play submission gotchas you read about are loud. The screenshot dimensions are wrong, the data safety form keeps failing, the closed testing track wants 14 days. Those at least show up as red error banners.

The privacy policy URL is different. It is the quiet one. You do not notice it until you have already filled out everything else and your release sits there refusing to roll out.

Here is what Google actually expects:

A live, public URL that anyone can open without a login
A policy that names your app specifically
Disclosure of every type of data your app collects, including SDK data you may not realize is in there (ads, analytics, crash reporting)
A contact method

Things that quietly get you flagged:

Hosting the privacy policy as a Google Doc set to view-only. The URL works in your browser but the Google bot reads it as locked.
Linking to a generator template you forgot to fill in. Saying "This app collects [data type]" instead of actually naming what it collects.
Forgetting to list the SDKs you are pulling in. If you added Firebase Analytics, AdMob, or Crashlytics, those need to be in there.
Pointing to a 404. This happens more than you would think when devs rename their marketing site late in the cycle.

The trap is that Play often accepts the upload anyway. You see the build move to review. You think you are done. Then a day or two later you get the rejection or the soft hold and you are back to editing a URL field in the console.

How to get this out of the way on day one:

Host the policy on your actual product domain, not on Notion or a Google Doc.
Use a generator only as a starting draft. Read it through and replace every placeholder with your app's real data flow.
Audit the SDKs in your build.gradle and make sure each one shows up.
Open the URL in an incognito window before pasting it into the console.

If you are about to ship your first Android release, this is one of those small steps that is much cheaper to get right before you hit the upload button than to fix after.

IOn Emit catches this kind of thing up front so you do not lose a launch weekend to a hosting issue. Freemium to try. https://theionproject.com/ionemit

The hidden 14 day wait before your first Android app goes live on Google Play

TheIOn-Project — Mon, 04 May 2026 22:07:11 +0000

Most first time Android publishers don't find out about this rule until they're staring at it in the Play Console at 11pm.

If you're shipping a brand new app to Google Play and the app or your developer account was created after November 13, 2023, you have to run a closed testing track for at least 14 days with at least 12 active testers before you can request production access. No exception form, no expedited path. Just the wait.

It catches people because the rest of the publishing flow doesn't really hint at it. You upload your bundle, fill in the store listing, finish the data safety form, and then hit a wall when you try to push to production. The app sits in review, then gets bounced back with a message about needing the closed test first.

What an active tester actually means

This is where it trips people up. Google's definition is narrower than you'd expect.

Your tester has to opt in by clicking the link you send them, then install the app from the Play Store.
The opt in has to happen on a unique Google account.
The tester needs to have used the app on at least one day during the 14 day window. Just installing it doesn't count.
You need 12 of these, not 12 install events. So if 8 testers install on day 1 and 4 more come in on day 13, you're not at 12 yet, because some of those late ones haven't completed a full day.

The console will show how many testers currently count toward the 14 day requirement. If the number suddenly drops, it's usually because someone uninstalled or never finished the opt in.

Mistakes that quietly reset the timer

Some changes restart the 14 day clock. The ones I've seen most often:

Removing and re-adding the same testers
Switching the closed track between two different versions of your app in a way Google considers structurally different
Adding a big batch of testers after the track is already running, then removing them

If you treat the closed track as a one time setup and resist the urge to keep tweaking the tester list halfway through, you'll usually be fine.

How to plan around it

The simplest move is to start the closed track the same week you start polishing your release build. Line up the 12 testers early. Friends, fellow devs, the indie hackers community, anyone with a real Google account who'll actually open the app once or twice over two weeks.

Set a calendar reminder for day 14 and request production review the day after. By then you've finished everything else in the Play Console, so you're really just waiting on the timer plus the regular review queue.

Why I built IOn Emit around this

The publishing flow has too many of these quiet rules. You shouldn't have to find out about the 14 day requirement by getting blocked at the finish line. IOn Emit walks through the whole submission process end to end, including the closed test setup, screenshot sizing, signing key handling, and the data safety form. Freemium, desktop app.

Link if you want to take a look: https://theionproject.com/ionemit

If you've shipped a first Android app since late 2023, what other rules surprised you?

The Google Play data safety form is the silent killer of release weekends

TheIOn-Project — Fri, 01 May 2026 22:06:37 +0000

Most write-ups about shipping an Android app focus on the build pipeline. The thing that actually eats your weekend is the Data Safety form in the Play Console.

If you have not filled it out before, here is what to expect.

Why it stalls so many releases

The form looks short on the surface. A few yes/no questions about data collection. But the rules behind those questions are dense, and Google quietly rejects drafts that have any of the following:

A question left blank, even if it does not apply
A declared SDK that handles user data without a matching disclosure
A deletion request toggle set to off when your app actually has account features
Conflicting answers between data collection and data sharing sections

None of those throw a clear error. You hit submit, the draft sits, then the email comes back hours later asking you to re-check section 4.2. Lose another day.

The settings I now check before opening the form

Pull a fresh dependency tree and note every third-party SDK in the release build. Firebase, AdMob, analytics tools, crash reporters all need to be declared.
Re-read the deletion request rules if your app has any account-style flow. If users can sign in, you almost certainly need a deletion path declared, even for a side project.
Map each data type your app touches to one of Google's predefined categories before opening the form. Doing this in a notepad first saves a lot of back and forth.
Check encryption in transit and at rest. The encryption questions trip up devs who use Firebase but never thought about how data flows to it.

Why I built around this

I got tired of losing release weekends to the same form. IOn Emit handles the Play Console submission flow end to end, including the data safety section, screenshot sizing, signing key setup, and the steps that the official docs gloss over. Freemium, runs locally on desktop.

Link: https://theionproject.com/ionemit

If you have your own data safety horror story, drop it in the comments. Half the value of these threads is comparing the weird rejection reasons everyone has hit.

The signing key mistake that cost me a week on my first Android release

TheIOn-Project — Fri, 17 Apr 2026 22:07:02 +0000

If you've never shipped an Android app to Google Play before, the signing key part is where a lot of people get quietly stuck. It's not a hard concept, but the way Google documents it makes it feel like you're juggling three different keys that could all brick your release if you mess up.

Here's what actually went wrong for me the first time.

What I thought I was doing

I generated a keystore the way most tutorials tell you. Ran keytool, set a password, saved the .jks file somewhere on my machine, and moved on. Then I signed my release APK with that key, uploaded it, and assumed I was done.

I was not done.

What I missed

Google Play now uses something called Play App Signing. What that means in practice is that Google manages the actual app signing key on their side. The key you generate locally is called your upload key. Those are two different things.

The upload key is what you use to sign the AAB before uploading to Play. Play then strips that signature, re-signs the build with the actual app signing key, and ships it to users.

If you lose your upload key, you can reset it. Annoying, but not fatal.

If you lose your app signing key and Google doesn't have it, your app is done. You can't update it. Users who installed it will stay on that version forever. I didn't know this at the time.

The week I lost

Here's what ate up my week. I signed my first release build with a key. Uploaded the AAB. Rejected, because I hadn't enrolled in Play App Signing yet. Enrolled, re-uploaded. Accepted.

Then I made a small fix a few days later. Signed the new build with what I thought was the same key. Rejected again. The fingerprints didn't match.

Turned out I'd generated a second keystore by accident when I was testing something, and my build gradle was pointing at that one. I spent the better part of an evening trying to figure out which keystore was the real upload key. The one I'd used, the one that was in my backups, or the one gradle was actually loading.

Eventually got it sorted by comparing SHA1 fingerprints against what Play had on file. But that whole mess could have been avoided if I'd understood the upload key vs app signing key distinction from day one.

What I do now

Three things.

First, one keystore per app, named clearly, backed up in two places. I keep the .jks file in a password manager attachment slot and a second copy on an encrypted drive.

Second, I write down the SHA1 fingerprint of the upload key the moment I create it. That way if anything ever looks weird, I can compare against a known-good value instead of guessing.

Third, I let tools handle the signing config for me. This is partly why I ended up building IOn Emit. It handles the upload keystore generation, stores the fingerprint, and keeps the signing config consistent across builds so you don't end up pointing at the wrong file halfway through a release cycle.

Play App Signing is actually a good thing once you understand it. It's just that the docs treat it like you already know the upload key vs app signing key distinction, and nobody explains that clearly until after you've tripped over it.

If you're about to ship your first Android app and this is new to you, the short version is: generate one upload key, back it up, enroll in Play App Signing, and let Google handle the rest. Don't try to keep your own app signing key. That's the old workflow and it's not worth the risk.

Anyway, this is the stuff I wish someone had told me before I spent a week chasing my own tail.

IOn Emit is freemium and handles a lot of this friction for you: https://theionproject.com/ionemit

The Play Console steps that quietly kill momentum on Android side projects

TheIOn-Project — Wed, 15 Apr 2026 22:06:36 +0000

Most Android side projects don't die from bad code. They die in that weird last mile where your app works fine on your phone but getting it onto the Play Store feels like a part time job.

Here's the stretch I see devs lose steam on.

Signing keys

The first time you generate an upload key and a signing key you think it's fine. Six months later you forget which one is which, and the Play Console politely refuses your upload. If you lose the key entirely, you can't push updates to that app again without going through a reset. That alone has killed a few of my projects over the years.

Screenshot dimensions

Play wants specific aspect ratios for phone, 7 inch tablet, and 10 inch tablet. Not just "some screenshots." If you've never done it, you spend an hour in Figma trying to figure out safe areas and status bar heights before you get to the actual design.

The data safety form

This one is the silent killer. Every SDK you pulled in (analytics, crash reporting, ads, whatever) collects something, and you have to declare all of it. Miss one and your submission gets kicked back two days later. Nothing feels more demotivating.

Content rating questionnaire

Fine for most apps, but the wording is a landmine. Answer "yes" to one ambiguous question about user generated content and suddenly you need a moderation policy document.

Internal testing track before production

You technically need a closed or internal test first, with a minimum number of testers for a minimum number of days. If you don't know that going in, you'll set aside a Sunday to publish and end up two weeks out.

Why I cared enough to build a tool

I got tired of this loop. Ship a small app in two days, then spend five more on Play Console plumbing. That's the reason IOn Emit exists. It's a desktop app that walks you through the publish flow end to end. Screenshots, signing, data safety declarations, the test track setup, the lot. Freemium, so you can try it before deciding.

https://theionproject.com/ionemit

If you've got an Android app sitting on your machine that you've been meaning to publish, honestly the best thing you can do this week is just get through the Play Console stuff once. The second time is so much easier. And if you want to skip straight to easier, that's what the tool is for.

What's the step that slows you down most on Play?