DEV Community: TheIOn-Project

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?

The One-Command Android Release That Actually Worked For Me

TheIOn-Project — Tue, 14 Apr 2026 17:21:43 +0000

I've shipped a handful of Android apps over the last couple of years and the part that always slowed me down wasn't the code. It was the last mile. Signing, bundling, filling in the same store metadata I've filled in twenty times before, staring at the Play Console wondering which tab the language translations hide behind this week.

This is a short write up of the release flow I actually settled on. Nothing fancy. No CI pipeline. Just a sane local setup that lets me push a new version without losing half a day.

Step 1: stop relying on memory for keystore stuff

The thing that bit me the most was signing config drift. I'd set up signing once, forget about it, come back three months later and have no idea which variant was actually signed for release.

Fix: keep a single keystore.properties file (not in git) and reference it in build.gradle. Then pin it to the release variant only. Once this is set once, it's set forever.

signingConfigs {
    release {
        def props = new Properties()
        props.load(new FileInputStream(rootProject.file("keystore.properties")))
        storeFile file(props['storeFile'])
        storePassword props['storePassword']
        keyAlias props['keyAlias']
        keyPassword props['keyPassword']
    }
}

Simple. But I kept forgetting to pin it to buildTypes.release.signingConfig. If your upload to Play ever silently fails or shows a weird "invalid signature" error, check that first.

Step 2: build an AAB, not an APK

I know this sounds obvious in 2026 but I still see people trying to upload APKs. Play wants the App Bundle. One command:

./gradlew bundleRelease

Output lives in app/build/outputs/bundle/release/. That's the file you want.

Step 3: the metadata problem

This is the part nobody warns you about. The Play Console asks you for the same 30 fields every time. Screenshots, feature graphic, short description, full description, content rating, target audience, ads, data safety form, translations, etc. Each release.

If you change literally one screenshot dimension, expect an email the next morning saying your release is held for review.

My current solution is to template the whole thing. I keep a folder for each app with:

metadata/en-US/short_description.txt
metadata/en-US/full_description.txt
metadata/en-US/images/phone/*.png
metadata/en-US/changelogs/default.txt

Then I either upload manually in a fixed order (my printed checklist is a lifesaver) or use a tool to push it.

Step 4: the tool I actually use now

Full disclosure, I built a desktop app for this because the manual loop was eating my Saturdays. It's called IOn Emit. It reads the metadata folder, handles the AAB upload, and pushes translations. If that sounds useful: https://theionproject.com/ionemit. It's freemium.

If you'd rather stay manual, I honestly understand. The command line plus a good checklist gets you 80 percent of the way there. The one thing I'd push for either way is that your release process lives in version control, not in your head.

Step 5: the boring stuff that matters

A few habits that saved me from shipping bugs to prod:

Always bump versionCode by at least 1, never reuse.
Tag the commit as v1.4.2 the second you upload. If you ever need to reproduce that exact build, you'll thank yourself.
Keep a RELEASE_NOTES.md with what's different in each version. This is what goes into the Play Store changelog. No rewriting it on the fly.
Do a dry run on internal testing track before production. Yes every time.

Wrapping up

The goal isn't to automate everything. The goal is to make the release feel boring. If pushing a new version feels dramatic, something is wrong with your process, not your willpower.

If this was useful, I write more about solo dev stuff over at https://theionproject.com. Happy to answer questions on signing config gotchas, I've hit most of them.

The Google Play Console Is Still a Time Sink in 2026

TheIOn-Project — Fri, 10 Apr 2026 22:39:50 +0000

I've been publishing Android apps for a few years now. The actual coding part is usually the fun part. What isn't fun is the Google Play Console.

Every time I go to upload a new build or update a listing, I end up spending way more time than I planned. Between the screenshot requirements, the content rating questionnaires, the store listing details, and whatever new compliance form they've added since last time, it's a whole thing.

And I'm not even talking about complicated apps. Even for a simple utility app, you're looking at a solid chunk of your afternoon just getting everything formatted and submitted correctly.

The stuff that eats the most time

If you've done this more than once, you know the drill:

Screenshots need to be specific dimensions for each device type. You need phone screenshots, tablet screenshots, and if you're feeling ambitious, Chromebook screenshots. Each set has its own size requirements.
The content rating questionnaire asks you the same questions every time, and you still second-guess your answers because getting it wrong can get your app flagged.
Store listing copy has character limits that don't quite match what you want to say, so you end up rewriting your description three times.
Privacy policy links, data safety forms, target audience declarations. It all adds up.

None of this is hard exactly. It's just tedious. And if you're a solo dev shipping multiple apps, you're doing this whole dance repeatedly.

Why I built something to speed it up

After going through this process enough times, I decided to build a tool that handles most of the repetitive parts. It's called IOn Emit, and it's basically a desktop app that simplifies the whole publishing workflow.

The idea is pretty straightforward: instead of clicking through dozens of console screens, you configure your app details once and let the tool handle the submission. It cuts what used to take me an hour or more down to about five minutes.

It's freemium, so you can try the core features without paying anything. I built it for myself originally, but figured other Android devs might find it useful too.

Not everything needs to be painful

There's this weird acceptance in the Android dev community that publishing is just supposed to be annoying. Like it's the price you pay for being on the platform. But it really doesn't have to be that way.

If you're spending more time in the Play Console than you are actually building your app, something's off. That's time you could spend on features, testing, or honestly just not staring at Google's UI.

If you've felt this pain before, I'd love to hear how you deal with it. And if you want to try Emit, the link is above. Happy to answer any questions about it.

Building The IOn Project as a solo dev. Follow along on X @TheIOnProject_.

I Published My Android App in Under 5 Minutes. Here's Exactly How.

TheIOn-Project — Thu, 09 Apr 2026 18:09:45 +0000

I spent weeks the first time I tried to get an app on Google Play. The console is a maze of forms, policy checkboxes, and requirements that look optional but aren't. Privacy policy URLs, data safety declarations, content ratings. Miss one thing and you're stuck in review limbo.

After going through that pain enough times, I built a desktop tool called IOn Emit that handles the entire publishing flow. You point it at your APK or AAB, fill in the basics, and it walks you through every step the Play Console requires. No browser tabs, no guessing what's missing. It's freemium, so the core stuff is free to use.

Here's the thing though. Even if you don't use a tool, the biggest time saver is just knowing what Google actually requires upfront. So I wrote a quick walkthrough covering the whole process from start to finish.

Full guide: Publish Your Android App in Under 5 Minutes

If you've ever rage-closed the Play Console tab, this might save you some headaches. Happy to answer questions about the process.