How we keep 17 apps of our own alive on both stores

We are MyQuietSpot Inc., a small software studio in Ontario, Canada. We keep 17 apps of our own live on the App Store and Google Play, 13 of them on both stores, all built with Flutter from one codebase and one toolchain. Nobody pays us to keep them alive, so the upkeep had to become cheap and boring: one release pipeline that builds, captures screenshots, uploads store listings, and runs a pre-release check before every submission; a support desk that reads both stores' reviews and our support mail; and a calendar built around the two platforms' deadlines. Here is the checklist we use, the store requirements that matter, and the things that bit us.

The calendar drives everything

Google Play, target API. By August 31, 2026, new apps and app updates must target Android 16 (API level 36). Existing apps must target at least Android 15 (API level 35), or they stop being available to new users on devices running a newer Android version. An extension to November 1, 2026 can be requested from Play Console. Source: Google Play target API level requirements. The same page lists August 31, 2025 for the previous round, so plan on late August.

Google Play, billing and 16 KB page sizes. Two more requirements ride on the same summer date. By August 31, 2026, new apps and updates must use Play Billing Library 8 or later (Billing deprecation FAQ). And since November 1, 2025, new apps and updates targeting Android 15 or higher must support 16 KB memory page sizes (Android Developers Blog); Google's documentation adds that from February 1, 2027, updates without 16 KB support can't be released (Support 16 KB page sizes). Native libraries make this real work. Check Google's current dates; they have moved before.

Apple, build tools. Since April 28, 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later using the iOS 26 SDK. Since September 9, 2026, iOS and iPadOS apps must target iOS 13 or later (Apple: Upcoming requirements). Apple's page shows a late-April cutoff in 2023 and 2024 too. In practice: every spring, update Xcode, rebuild, fix what broke.

Apple, the quiet one. Apps that haven't been updated in three years and have very few downloads over a rolling 12-month period get an email and 90 days to submit an update, or they are removed from the App Store (App Store Improvements). Apps that crash on launch are removed immediately.

Membership and accounts. If the Apple Developer Program membership expires, your apps are no longer available for download; Apple says renewal must be done by the Account Holder (Membership renewal). Google closes developer accounts it considers inactive, after emailing the owner (Closure of inactive developer accounts).

Spring is Apple, summer is Google, the rest is watching the inbox. Every app in our portfolio inherits its Android target level and its Xcode from one shared toolchain (today Xcode 26.6 and Flutter 3.41.6, which sets API level 36 for all of them), so a deadline is one upgrade and a rebuild per app, not 17 separate edits. Fourteen of our 17 live apps have shipped an update since Apple's April 28 cutoff, and the Play Billing 8 upgrade went in workspace-wide in July.

The things that only break in release builds

Rebuilding is the easy part. The traps never show up on a developer's machine. These happened to us.

The notification icon that vanished. One version of our kombucha app shipped on Android looking completely fine: it installed, it opened, every screen worked. But no notifications ever fired. The release build's resource shrinker had stripped the notification icon, because only Dart code referenced it, so the notification plugin never initialized and channels, the permission prompt, and scheduled reminders silently didn't happen. We found it by pulling the release APK and AAB apart. The fix that mattered was one small file, res/raw/keep.xml, pinning the drawable.

"Missing type parameter." Two of our apps were stable in debug and on the emulator, then crashed on real devices in release builds only: missing ProGuard rules had let code shrinking remove type information a notification library needed. Our pre-release check now refuses a build without those rules.

The build that ran "fully local." One of our apps went to both stores with its backend addresses missing, because those values lived in a developer's run script, not the release lane. The app started, said nothing, and had no sign-in, no sync, no backup. Our pre-release check now refuses a release lane without those values, and one without the production flag that keeps test ads out of store builds.

Store metadata. App Store Connect refused one app's release notes over a single emoji (Play accepts them, though Google's metadata policy bans emojis and repeated special characters in the app title, icon, and developer name: Google Play Metadata policy). Another build bounced at upload for a missing photo-library purpose string (ITMS-90683) that a sharing library had pulled in. Our tablet screenshot captures had a gray system status bar until we fixed the capture. Apple limits app names to 30 characters and expects screenshots to show the app in use (App Review Guidelines, 2.3).

Features that need signing. An iOS feature built on App Intents did not register at all in unsigned simulator builds. Not a code bug; it must be tested on a signed build, and we lost time learning that.

The lesson: only a release build on a real device counts.

Our checklist, per app, per cycle

1. Update Xcode and the Android build tools; rebuild.
2. Raise the target API / SDK, and read the platform notes for behavior changes on the new OS version.
3. Run the pre-release check. Ours has about 95 conditions that stop a build, from missing ProGuard rules and a billing library below version 8 to an emoji in the iOS release notes.
4. Build a release build and install it on a real device. Check notifications, sign-in, purchases, and deep links.
5. Inspect the release artifact for resources that must be present (icons, fonts, native libraries).
6. Refresh store metadata: screenshots that match the current UI, release notes written, in every language the listing has (ours go up to five).
7. Submit early. A rejection two days before a deadline is a bad week.
8. Confirm the membership renewal date and who holds the Account Holder and account owner roles.

What to do this week

• List every app you own on both stores, its current target API level, and when it was last updated.
• Check the Policy status page in Play Console for target API warnings.
• Confirm who holds the Apple Account Holder role and the Google Play account owner role, and when the Apple membership renews.
• Install the current release build on a real phone and trigger a notification.
• Put August 31 (Google) and late April (Apple) on next year's calendar.

If you'd rather someone else run this checklist, that's what App Care is: the pipeline and calendar we use on our own 17 apps, pointed at yours.

Sources

• Google Play target API level requirements: https://support.google.com/googleplay/android-developer/answer/11926878
• Google Play Billing Library deprecation FAQ: https://developer.android.com/google/play/billing/deprecation-faq
• Android Developers Blog, 16 KB page size requirement: https://android-developers.googleblog.com/2025/05/prepare-play-apps-for-devices-with-16kb-page-size.html
• Android Developers, Support 16 KB page sizes: https://developer.android.com/guide/practices/page-sizes
• Apple, Upcoming requirements: https://developer.apple.com/news/upcoming-requirements/
• Apple, App Store Improvements: https://developer.apple.com/support/app-store-improvements/
• Apple, Membership renewal: https://developer.apple.com/support/renewal/
• Google Play, Closure of inactive developer accounts: https://support.google.com/googleplay/android-developer/answer/11605267
• Google Play Metadata policy: https://support.google.com/googleplay/android-developer/answer/9898842
• Apple App Review Guidelines: https://developer.apple.com/app-store/review/guidelines/