Unpublish a published app
The current help path is Test and release → Setup → Advanced settings → App Availability → Unpublish. Review any prerequisites or blocking issues displayed for the app before confirming.
Google's guidance states that existing users can continue using an unpublished app and can receive updates. Unpublishing therefore does not revoke all installations, delete user accounts or erase data on your servers.
Match the action to the goal
| Goal | Appropriate investigation |
|---|---|
| Stop new users finding the app | Unpublish the store availability |
| Remove an accidentally prepared update | Discard or edit the draft release |
| Remove one uploaded bundle from a release | Edit that release's artifact selection |
| Stop a faulty update spreading | Review halt/staged-rollout controls and corrective release |
| Close user accounts and retained data | Implement the separate deletion process |
Do not change a package name as a substitute for an orderly retirement. That creates a different Android app and does not clean up the original users' state.
Plan product retirement beyond the Console
Communicate support dates, export options and server shutdown behavior. Verify that authentication failures or subscription flows do not leave users trapped after the app is no longer discoverable.
Keep the signing material and release records needed to publish an important fix for existing users. Store removal is not a reason to discard keys immediately.
Check whether deletion is actually available
Console options depend on publication history, account permissions and app state. Do not promise that every published app can be permanently deleted through the same menu. Read the current controls for the specific record, and preserve business or compliance records independently.
APKLint's policy checklist can organize retirement tasks, but it does not change app availability. Use Google's update and unpublish instructions and release-state guidance to distinguish a reversible distribution choice from deletion of data elsewhere.
Separate store availability from service retirement
For an illustrative subscription app being retired, identify three independent states: whether new users can obtain it, whether existing installations can reach the service and whether customer subscriptions or retained data remain active. Unpublishing addresses distribution availability; it does not perform every operational step in the retirement plan.
The update and unpublish guidance explains the store action and continued access for existing users. Use that distinction when writing user-facing notices. Avoid promising that uninstalling or removing a listing automatically deletes cloud records or cancels an external billing arrangement.
Test the remaining path as an existing user
Keep a supported test installation with synthetic account data. After the planned service changes in a controlled environment, verify sign-in, data export, deletion requests and access to support instructions. Confirm that the app does not trap users behind a login screen when the announced export path requires an active session.
Review links embedded in older supported versions. A new retirement page helps only if those installations can reach it. Preserve required policy and support destinations, or maintain suitable redirects, so the installed product still provides the promised information.
Keep the authorized signing and release capability available for necessary corrections. A severe compatibility or export problem may require an update for existing users even after new distribution stops. Record who can produce that update and where the matching release artifacts are retained.
If Console offers deletion for the particular app record, read the displayed conditions and consequences before choosing it. Distinguish deletion of the Console record from deletion of customer data in systems operated by the business. Do not use a generic instruction as evidence that a state-dependent control will be available for every app.
Close the retirement checklist with observations from the actual user paths and the responsible service owners. Keep dates and support commitments consistent across the app, website and customer communication. This prevents a reversible store-availability change from being mistaken for completion of a much broader shutdown process.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
