A mobile app rarely dies in one moment. Updates stop, the store warns you, a new OS version breaks something, and one day it is gone for new users. The code does not disappear with the listing. Your iOS and Android projects, the backend they talked to and the design files behind every screen still describe a working product, and Odys AI Labs, the research and development arm of Odys, buys that kind of code for cash to use for AI training and R&D.
Why so many apps end up here
Stores remove inactive apps on purpose. Apple says it can pull an app that has not been updated in three years and barely downloaded, after a 90 day warning, and Apple removed about 167,000 apps from the App Store in 2025 for all reasons combined. On Android, an app must target a recent API level to stay visible to new users on newer phones; Google Play’s current rule requires Android 15 (API level 35) or higher by August 31, 2026. An app nobody maintains drops out within about a year.
None of that says anything about the quality of the code. It means nobody was paying for upkeep.
What your code is likely still worth
App code is useful for AI training and R&D because it covers a full stack in a compact space: native or cross-platform UI, local storage, offline sync, networking, push notifications, in-app purchases and the server code behind them. Swift, Kotlin, Dart and TypeScript projects written by a real team, with real bug fixes in the history, show how mobile software is actually built and maintained.
Value goes up with completeness and history. An iOS app, an Android app and the backend together, with git history, beat a single client exported as a zip. Screens in Figma, a test suite and a ticket export add more; our guide on docs, tests, tickets and designs explains why. We do not publish price figures: the offer comes after review, and how we value a codebase is explained on the call.
What a buyer will check
- Both clients and the server. Is the backend still in a repository, or was it lost when the hosting was cancelled?
- Original share. How much is your code versus SDKs, CocoaPods or Gradle dependencies, and generated files (build outputs, generated API clients).
- Rights. Who wrote it: you, staff, freelancers or an agency.
- Credentials and user data. Signing material, config files and anything copied from production.
- Status. The app makes no money today. An app still earning from subscriptions or ads is not something we buy.
Three risks specific to this situation
1. Signing keys and config files in the repo. Mobile repos collect credentials that web projects do not: the Android keystore and its password in gradle.properties, iOS .p12 certificates and provisioning profiles, APNs push keys, google-services.json and GoogleService-Info.plist for Firebase, and API keys for maps, analytics and crash reporting. Some of these still work years later. One caution before you clean: if the Android app was not enrolled in Play App Signing, losing the keystore means you can never publish an update to that listing again, so back it up somewhere safe first. Then revoke what you can, move the rest out of the repository, then clean the history with git-filter-repo; our guide to removing secrets from old code covers the order of steps.
2. User data in the backend and test fixtures. Apps tend to carry real user data in places people forget: Firebase exports, test accounts with real phone numbers, crash logs with emails, screenshots in the repo, analytics dumps. We never take databases, user records or chat logs, and personal data is removed before transfer. Our guide to personal data in old code lists where to look. This is not legal advice; if users were in the EU, UK or California, ask a privacy lawyer what you still need to do.
3. The agency or freelancer who built it. Many apps are built by an outside studio. Unless the contract assigned the code to you in writing, you may not own it outright. Find the agreement now, while the agency still exists and can sign a confirmatory assignment if one is missing. Our guide on who owns the code explains the usual fixes. This is not legal advice; a lawyer can check your contract.
What to do this month
- Find every repository: iOS, Android, any shared Flutter or React Native project, the backend, cloud functions and admin tools.
- Check that full git history is there, not only the last release.
- Move signing keys, keystores and certificates out of the repos and into safe storage, and revoke push and API keys you no longer need.
- Search for exported user data, real phone numbers and emails in fixtures, seed files and logs.
- Keep your Apple and Google developer accounts accessible, even if the app is unlisted, so you can prove you were the publisher.
- Locate the agency or freelancer contracts and the Figma files.
Your options
| Option | For a dead mobile app |
|---|---|
| Sell the code | Cash for the clients, backend and designs; store listing and users are not part of it |
| Update and relaunch | Possible if you have a fresh reason for people to install it; expect real work on SDK and OS updates first |
| Open source | Helps other developers, but public code cannot later be sold exclusively, and committed keys become public |
| Archive | Keep it read-only on GitHub, which is cheap and reversible |
| Delete | Removes every future option, including a sale |
If the app also had a landing site that still gets search traffic, TheBlueOceanWebsites.com buys websites of former businesses on its own terms, separate from the code.
Our process never asks you to install or run anything, and no code changes hands before a signed written agreement. Payment is cash, one agreed price, paid on transfer. That is a useful benchmark for any approach you get: a fair buyer does not need your code, or a script on your machine, before a contract exists.
What to do next
- Gather every app, backend and design repo in one place and confirm history is intact.
- Take signing keys and user data out before anyone else sees the code.
- Send us a few details for a free code valuation, or try the code value check first.
Frequently asked questions
Apple removed my app. Can I still sell the code?
Yes. Removal from a store ends distribution, not ownership. If your team wrote the app, it is a complete product, it makes no money today and you own the rights, the source code typically qualifies. Odys AI Labs buys the code itself, plus history, docs and design files, never the store listing, the user base or any user data.
Do I need the backend too, or just the app code?
Send what you have, but a mobile client without its backend is half a product. Many apps lose their server code when the hosting is shut down, so look for the API repository, cloud functions and database schema files. A complete set of app, backend and admin tools is usually worth more than the client alone.
What do I do with signing keys and the keystore?
Keep them out of any sale. Android keystores, iOS certificates, provisioning profiles and push notification keys are credentials, not code. Remove them from the repository and its history, store them somewhere safe, and revoke any you no longer need. We help with this cleaning step before transfer, and nothing moves before a signed agreement.
An agency built my app. Do I own the code?
Only if your contract assigned it to you in writing. In the US, code from an outside contractor is usually not work made for hire by default, so you generally need a signed assignment. Find the original agreement and check its IP clause. This is not legal advice; a lawyer can read your contract and confirm.
Find out what your old code is worth right now.
Tell us about the product in about a minute. No code needed. We review the details and come back with a cash offer or a plain no.
Get my free code valuation →