Managing a Portfolio of 10 to 50 Apps: A Checklist

Running two apps is a hobby. Running ten to fifty is an operation, with all the usual problems: things get forgotten, deadlines arrive from two stores at once, and one outdated library can affect a dozen products. This checklist covers the systems that keep a portfolio manageable. It is deliberately tool-neutral; a spreadsheet and a calendar will take you a long way.

Store rules change, so wherever this article touches policy or deadlines, check the current policy in Play Console and App Store Connect.

1. Build an inventory spreadsheet

One row per app, one source of truth. Suggested columns:

• Internal name and public name.
• Platform and store account it belongs to.
• Package name or bundle identifier.
• Store listing URLs and developer website.
• Owner (the person responsible) and backup owner.
• Current version and the date of the last release.
• Target SDK level or minimum OS version.
• List of third-party SDKs and their versions.
• Ad networks and analytics used, with account IDs stored in a safe place rather than a public sheet.
• Privacy policy URL and the date the store privacy forms were last reviewed.
• Status: active, maintenance only, scheduled for retirement, or retired.
• Notes on anything unusual.

Keep access to the sheet limited, because it contains sensitive details. Make updating it part of the release checklist, not a separate chore. An out-of-date inventory is worse than none because people trust it.

2. Agree naming and package conventions

Conventions prevent confusion and make bulk work possible.

• Package names and bundle identifiers: choose a consistent pattern based on a domain you control, and never change one after publishing, since it identifies the app permanently in the store.
• Internal names: a short, unique code per app that appears in repositories, build jobs, and the inventory.
• Repository and branch names: the same pattern everywhere, so a script can loop over them.
• Store names and descriptions: distinct enough that your own apps do not compete in search or look like duplicates. Stores have policies on repetitive or low-value content, so read the current spam and minimum functionality rules before you publish near-identical apps.
• Signing keys: document where each key lives and who can use it, and keep backups. Losing a signing key can block updates.

3. Standardise versioning

Decide on one scheme and apply it to all apps. A common choice is a human-readable version name plus a monotonically increasing build number. Rules to write down:

• The build number always increases, never repeats.
• Every release is tagged in source control with the version.
• Release notes are written for users, not developers.
• Hotfixes follow the same path as ordinary releases, only faster.

Record the version of every shipped build in the inventory, so you can answer “which apps use version X of this library?” in seconds.

4. Keep a store-deadlines calendar

Both stores announce requirements that apply to all apps, such as minimum target API levels, new privacy disclosures, and changes to account verification. With dozens of apps, a missed announcement becomes dozens of problems at once.

• Subscribe to policy emails in each console and read the announcements page regularly.
• Put every date you learn into a shared calendar, with reminders well before the deadline, and link to the source.
• When a deadline appears, add a column to the inventory for that requirement and mark each app compliant or not.
• Do not trust secondhand dates, including ours. Verify in the console.

For examples of the type of change to track, see our notes on the Android 16 target API deadline.

5. Monitor uptime and store listings

Your apps live on someone else’s platform, and the platform can change their status without asking.

• Store pages: check every listing URL on a schedule with a simple script or monitor. A page that starts returning a not found response often means the app was removed, suspended, or unpublished, so alert a person immediately and open the console to see the reason.
• Developer website and policy pages: monitor each privacy policy URL and your app-ads.txt file for availability, as described in the app-ads.txt guide.
• Backend services: if the apps use your servers or APIs, monitor them and set up alerts for errors and expiry of certificates and domains.
• Console notifications: route email from the stores to a shared mailbox that several people watch, not to one person’s inbox.
• Crash rates and ratings: review console vitals for each app on a rhythm, such as weekly. Investigate sudden changes after releases.

6. Plan shared SDK updates

Many of your apps likely use the same ad, analytics, and crash-reporting libraries. That is efficient, and it is also a single point of failure.

1. Keep the SDK list in the inventory with exact versions.
2. When a vendor announces a breaking change or a deprecation, search the inventory to find every affected app.
3. Update one pilot app first, test, then roll out in batches.
4. Wrap SDKs behind your own thin interface where practical, so replacing one touches one module.
5. After every update, re-check data disclosures. The Data safety guide and the matching App Store privacy labels explain how an SDK change can alter your answers.
6. Subscribe to vendor changelogs and security advisories.

7. Run a recurring policy compliance review

Put a review on the calendar, for instance every quarter, and cover each app:

• Are the store privacy forms accurate and in step with the privacy policy? See what to include in a privacy policy.
• Does the target API level meet current requirements?
• Do permissions still match actual features, with nothing left over?
• Are ads configured appropriately for the declared audience?
• Is the content rating still correct?
• Are contact details valid?
• Does the listing make any claims the app cannot support?

Sensitive categories need more frequent attention. If any app handles health or cycle data, apply extra scrutiny to what is collected. Apps with unusual mechanics, such as simulators that look like financial products, need especially careful wording.

8. Decide when and how to retire apps

Not every app deserves ongoing maintenance. Set explicit criteria, such as no meaningful usage, unsustainable maintenance, or an unfixable policy conflict. Then follow a defined path:

1. Mark the app as scheduled for retirement in the inventory.
2. Stop new feature work; keep security and policy fixes going until the end date.
3. Tell users in advance through an update and, where appropriate, the listing text, and suggest alternatives if you have them.
4. Plan data handling: export options for users, deletion of stored data according to your policy.
5. Unpublish through the console rather than just abandoning it. Read the current console help to understand the consequences, such as whether existing users keep the app and whether the package name can be reused.
6. Keep a record of the decision and the date, along with the signing keys and sources, for as long as you might need them.
7. Remove dead apps from your ad configuration and app-ads.txt, and shut down servers that served them.

9. Separate client accounts

If you build or publish apps for clients, avoid mixing them with your own.

• Use separate developer accounts, or arrange ownership so each client owns their listing, depending on the agreement. Confirm the current account type and transfer rules in each store.
• Keep each client’s ad accounts, analytics projects, keys, and credentials separate.
• Mark client apps in the inventory and restrict who can see their details.
• Put responsibilities in writing: who answers policy notices, who pays fees, who holds the signing key, and what happens at the end of the contract.

10. Document everything that would hurt to lose

Documentation is cheap insurance against absences, departures, and your own memory.

• A runbook for building, signing, and releasing an app.
• A list of accounts, with owners and recovery methods, stored in a proper password manager rather than in a spreadsheet.
• An incident checklist: what to do if an app is removed, a key is lost, or a library is found vulnerable.
• Short per-app notes covering architecture quirks and external services.
• A weekly and quarterly routine listing every recurring check in this article.

Review the documentation after each incident and update it.

Starting from zero

If your portfolio is already messy, do not try to fix it all at once. First, create the inventory. Second, set up store listing and policy page monitoring. Third, build the calendar. Then work through apps in batches by risk. For discoverability work across the portfolio, see the organic installs checklist, and for more material aimed at publishers visit the publishers hub.