If you maintain more than one mobile app, you probably know how quickly release management becomes messy.
Your source code is in GitHub.
Screenshots are somewhere in Google Drive.
Store descriptions are in a document.
Different language versions are in spreadsheets.
App icons are in folders with names like:
final.png
final-v2.png
final-new.png
final-new-final.png 😅
And then someone asks:
“Which one is the latest version?”
That was one of the reasons I started building AppOps.
What is AppOps?
AppOps is a workspace for managing the operational side of shipping mobile apps.
The goal isn't to replace GitHub, Xcode, Android Studio, App Store Connect or Google Play Console.
Instead, it's meant to sit around those tools and keep the information that gets scattered between them organized.
You can think of it as a central source of truth for your app portfolio.
What I'm working on
📱 App catalogue
Keep all your applications organized in one place instead of maintaining separate spreadsheets.
🖼️ Versioned assets
Manage app icons, screenshots, banners and other store assets with version history.
🌍 Store copy & localization
Keep descriptions and store metadata organized by language/locale.
📐 Device screenshots
Track screenshots for different device types and make it easier to see what is actually ready for release.
👥 Team roles
Give team members appropriate access instead of sharing everything with everyone.
📜 Release history
Keep a record of what changed and when.
Why build another developer tool?
There are already excellent tools for writing and building apps.
GitHub handles source control.
CI/CD platforms handle builds and deployments.
App Store Connect and Google Play Console handle publishing.
But the operational information around those systems often ends up spread across multiple places.
For an indie developer with one app, that's probably manageable.
For someone maintaining 5, 10, 20 or more apps, it becomes much harder.
That's the problem I'm interested in solving.
The bigger idea
I'm thinking about AppOps less as an “asset manager” and more as an operating layer for an app portfolio.
Imagine opening one dashboard and seeing:
My Apps
│
├── App A
│ ├── Versions
│ ├── Screenshots
│ ├── Store Copy
│ ├── Localizations
│ └── Releases
│
├── App B
│ ├── Versions
│ ├── Screenshots
│ ├── Store Copy
│ ├── Localizations
│ └── Releases
│
└── App C
├── Versions
├── Screenshots
├── Store Copy
├── Localizations
└── Releases
The long-term goal is to make the process of taking an app from “ready to ship” → “ready for the stores” much more organized.
I'm still building it
This is an early product, so I'm particularly interested in hearing from developers who maintain multiple mobile apps.
I'd love to know:
- How do you currently manage screenshots?
- Where do you keep localized store descriptions?
- How do you track which assets belong to which version?
- Do you use spreadsheets, Notion, Drive, custom tools, or something else?
- What part of preparing a release takes more time than it should?
If you manage multiple apps, I'd genuinely like to hear how you handle this today.
Top comments (0)