DEV Community: shyam manek

I Built a Tool to Make iOS and Android App Releases Less Painful

shyam manek — Wed, 28 Oct 2026 18:16:03 +0000

Hey DEV Community! 👋

I'm an independent mobile app developer, and I've spent years building and publishing applications.

One thing I've learned is that building an app is only part of the challenge. Getting it ready for release is another.

Every release comes with repetitive tasks:

Preparing screenshots for different device sizes
Managing App Store and Google Play listings
Updating descriptions across languages
Maintaining release notes and version history
Reviewing permissions and submission requirements
Dealing with unexpected app review rejections

I've faced these challenges while publishing my own applications.

So I started building ReleaseYour.App.

🚀 What is ReleaseYour.App?

ReleaseYour.App is a workspace designed to simplify release preparation for iOS and Android developers.

Instead of managing screenshots, descriptions, release notes, and checklists across different tools, the goal is to bring everything into one place.

🛠️ What I've Built

📱 Screenshot Management

Organize App Store and Google Play screenshots for different devices and releases.

🌍 Localized Store Listings

Manage app descriptions and metadata across multiple languages.

✅ Pre-Release Checklists

Track important tasks before submitting your application.

🔍 Rejection Risk Checker

Identify potential App Store submission issues before sending your app for review.

This checker doesn't guarantee approval, but it can help developers spot potential problems earlier.

📝 Release Notes and History

Keep track of release notes, assets, and changes across app versions.

🎯 Looking for My First 10 Developers

The platform is live, and I'm looking for 10 developers willing to test it during a real app release.

I'm especially interested in feedback from:

Independent iOS and Android developers
React Native and Flutter developers
Mobile app development agencies
Developers who frequently publish app updates

I'll personally help early users get started.

💬 I'd Love Your Feedback

I'm curious about three things:

What's the most frustrating part of preparing your app for release?
Have you experienced App Store or Google Play rejections?
What would make your release workflow easier?

You can explore the platform here:

👉 https://releaseyour.app/

I'm building this independently, and feedback from other developers would mean a lot.

Thanks for reading! 🙌

I built a release management tool after dealing with App Store rejections. Looking for my first 10 users.

shyam manek — Wed, 28 Oct 2026 18:09:31 +0000

Hey I'm an independent mobile app developer, and I've spent years building and publishing iOS and Android applications.

One frustrating part of shipping apps isn't always the coding. It's everything that comes afterward.

Preparing screenshots for different devices, managing App Store descriptions, handling permissions, writing release notes, and dealing with unexpected app review rejections.

I've experienced these challenges while publishing my own apps, so I decided to build something to simplify the process.

🚀 Introducing ReleaseYour.App

A release preparation and management workspace for iOS and Android developers.

Here's what it offers:

📱 App Store and Google Play screenshot management
🌍 Localized store listings and descriptions
✅ Pre-release checklists
🔍 Rejection Risk Checker to identify potential submission issues
📝 Release notes and version history
📂 Centralized release assets

Where I am today:

The platform is live, and I'm looking for my first 10 developers who regularly publish mobile apps.

I'm not looking for hundreds of signups right now. I want real feedback from developers preparing actual releases.

If you're willing to try it, I'll personally help you get started and listen to what needs improvement.

I'd especially love to know:

What's the most frustrating part of publishing your mobile app?
Have you experienced App Store or Google Play rejections?
Would a centralized release preparation workspace help your workflow?

🔗 https://releaseyour.app/

I'm building this independently and would genuinely appreciate your feedback.

Thanks for reading!

Mobile app screenshot management

shyam manek — Sun, 25 Oct 2026 18:40:29 +0000

Maestro and Fastlane can both help automate screenshot capture.

The next challenge is organizing the resulting assets by app and device class. That's one workflow we're working on at https://www.releaseyour.app

App Store Screenshots Are a Release Task, Not Just a Design Task

shyam manek — Sun, 25 Oct 2026 18:37:22 +0000

When preparing a mobile app update, screenshots are often one of the last things developers think about.

The code is ready. Tests are passing. The build is uploaded.

Then someone realizes that the App Store screenshots are outdated, the tablet screenshots are missing, or the latest feature isn't represented in the store listing.

The release gets delayed—not because of a coding problem, but because the release assets weren't ready.

Why screenshots become a bottleneck

For teams maintaining multiple mobile apps, screenshot management can quickly become repetitive.

Common problems include:

Capturing the same screens manually for every release.
Maintaining screenshots for different device classes.
Updating screenshots when the UI changes.
Keeping localized screenshots consistent with store descriptions.
Finding the latest approved version of each asset.
Coordinating between developers, designers, and marketing teams.

These tasks seem small individually, but they add friction to the release process.

1. Treat screenshots as part of release planning

Don't wait until submission day to check your screenshots.

Include asset readiness in your release checklist:

Are the screenshots representative of the current app?
Are the required device classes covered?
Are important features visible?
Are localized assets available where needed?
Are the final files organized and easy to identify?

The goal isn't to create more process. It's to avoid discovering missing assets at the last minute.

2. Automate screenshot capture where possible

Manual capture can work for a small app, but automation becomes more valuable when the same screens must be captured repeatedly.

Tools such as Maestro and Fastlane can help automate screenshot capture in your own development environment.

A practical workflow looks like this:

Define the screens you need to capture.
Configure the automation for your app.
Run the capture workflow on a simulator, emulator, or CI environment.
Review the generated images.
Import and organize the final screenshots for store use.

Automation doesn't remove the need for review. You still need to verify that the correct screen, data, language, and device layout appear in each image.

3. Keep the resulting assets organized

Capturing screenshots is only part of the job.

Teams also need to know which images belong to which app, release, language, and device class.

A consistent naming convention and central asset location can help prevent outdated images from being submitted accidentally.

For example, separate assets by:

App and release version.
Platform and device class.
Language or storefront.
Draft, reviewed, and approved status.

The exact structure depends on your team, but consistency matters more than complexity.

4. Connect screenshots to the wider release workflow

Screenshots don't exist in isolation.

A new feature may require updated store descriptions, localized copy, and new screenshots. A UI redesign may affect several device sizes. A new release may also introduce configuration changes that deserve review.

A release checklist should bring these tasks together so that teams can see what's ready and what's still missing.

How ReleaseYour.app fits into this workflow

We're building ReleaseYour.app to help mobile teams manage the operational work around app releases.

You can generate a screenshot capture kit for up to 10 named screens using Maestro, run the automation in your own environment, and import the resulting PNG files. Existing Fastlane screenshot workflows can also be used, with their captured images imported into the platform.

ReleaseYour.app also helps teams organize store assets, manage metadata and localization, review potential store-listing and configuration issues, and maintain release history.

These checks can help identify potential problems before submission, although they cannot guarantee approval by Apple or Google.

Final thoughts

A mobile release involves more than shipping a working build.

Store assets, localized content, permissions, configuration, and release coordination all deserve attention before submission.

Automating repetitive tasks and keeping release information organized can make the process easier to manage as your app portfolio grows.

Question for mobile developers: How do you currently manage App Store and Google Play screenshots—manual captures, Fastlane, Maestro, or another workflow?

Your App Builds Successfully. But Is It Ready for App Store Submission?

shyam manek — Sun, 25 Oct 2026 18:30:47 +0000

A successful CI/CD pipeline doesn't guarantee a successful mobile app release.

Before submitting an update to Apple App Store or Google Play, there are several things worth checking:

✅ Store metadata — Are descriptions, titles, and promotional text valid?

🌍 Localization — Are translations complete for every supported language?

📱 Screenshots and assets — Are the correct screenshots available for each required device size?

🔐 Permissions and configuration — Have you introduced new permissions, entitlements, or manifest changes?

📋 Release readiness — Have you reviewed the changes and checked everything required before submission?

Missing these details can lead to avoidable rework, delays, or potential store review issues.

Make pre-release checks part of your workflow

Instead of relying entirely on manual reviews and scattered checklists, make these checks a regular part of your release process.

We're building ReleaseYour.app to help mobile teams organize release assets, manage store metadata and localization, review potential configuration issues, and keep release history in one place.

It won't guarantee store approval, but it can help teams catch potential issues before submission.

What's the most frustrating part of your mobile release process: store reviews, screenshots, localization, or release coordination?

Mobile App Releases Are More Than Code: How to Organize Your Release Assets

shyam manek — Sat, 24 Oct 2026 18:57:09 +0000

Shipping a new version of an Android or iOS app involves much more than merging a pull request and uploading a build.

There are app icons, screenshots for different device sizes, store descriptions, localized metadata, release notes, and approvals to coordinate.

When an app grows, these small tasks can become a workflow of their own.

Here are five ways to make mobile app releases easier to manage.

1. Create a single source of truth

Avoid keeping the latest screenshots in one shared folder, descriptions in a document, and release notes in a spreadsheet.

Organize assets and metadata around each app and platform. Give every asset a clear version and make it easy to identify the currently approved version.

2. Track screenshots by device requirements

A screenshot that works for a phone may not meet a tablet's requirements.

Keep track of device classes, image dimensions, and which assets are required for each release. Check completeness before submission rather than discovering missing assets during the release process.

3. Treat localization as part of release readiness

If your app supports multiple languages, store metadata should be managed per locale.

Track translated titles, descriptions, keywords, and other required fields. An explicit checklist makes missing translations visible before a release goes live.

4. Keep a history of changes

When a screenshot or description changes, it should be possible to identify the previous version and understand what changed.

Version history is especially useful when several people manage the same app or when a release needs to be reviewed after publication.

5. Define ownership and approvals

Make responsibilities clear. Who can upload assets? Who reviews store copy? Who approves the release?

Role-based access and clear ownership help prevent accidental changes and reduce confusion as a team grows.

Bringing the workflow together

These practices are easier to maintain when app assets, store metadata, localization, and version history live in a structured system rather than disconnected folders.

That's one of the problems we're working on with ReleaseYour.app, our AppOps platform for organizing mobile app release operations.

We're building it around a simple idea: less release chaos, more time building.

A question for mobile developers: How does your team manage store screenshots, localized metadata, and release history today? I'd love to hear what works and what still feels unnecessarily manual.

I'm looking for 10 app teams to try Appavio-AppOps for free. 🙌

shyam manek — Tue, 06 Oct 2026 10:21:50 +0000

I'm looking for 10 app teams to try Appavio-AppOps for free. 🙌

Who it's for:

Indie developers and small teams shipping iOS and/or Android apps
Agencies managing apps for multiple clients
Anyone who's been burned by outdated store listings or missing assets

What you get:

Free early access
Direct setup help from me
A say in what I build next

What I ask:

Honest feedback after you've used it

Interested? Comment "Appavio-AppOps" or send me a DM, and I'll get you set up.

Know someone who ships apps? Tag them 👇

🔗 swtly.co/appavio

mobiledevelopment #appstore #indiehackers #buildinpublic

Story of mobile app release managemant

shyam manek — Tue, 06 Oct 2026 10:20:45 +0000

A few years ago I was [shipping a release / updating an app listing], and found out the iPad screenshots were missing. Again.

I'm a mobile developer ([React Native / Swift]), and I kept running into the same things:

→ Hunting for the latest screenshots
→ Copy-pasting store descriptions between locales
→ Digging through Slack to remember what changed in the last release

None of it is hard. It's just scattered, and it wastes time that should go into building.

So I'm building AppOps: one place to manage app assets, store copy, locales, and release history.

Less release chaos. More time building.

It's early, and I'm building it in public. I'll share what I learn along the way.

🔗 swtly.co/appavio

buildinpublic #indiedev #mobiledevelopment #appstore

Shipping the app is the easy part.

shyam manek — Tue, 06 Oct 2026 10:19:43 +0000

The real headaches come after:

📵 Missing tablet screenshots
📝 App Store description still mentions a feature you removed
📁 Assets scattered across Drive, Slack, and someone's laptop
❓ Nobody's sure which version is the current one
🕰️ Release history lives in 5 different places

I've seen this on [every / many] app I've worked on.

Curious: how does your team keep store assets and release info organised?

👇 Tell me what's worked (or what's been a mess).

mobiledevelopment #appstore #iOS #android #reactnative

Appavio AppOps

shyam manek — Thu, 01 Oct 2026 05:10:52 +0000

Shipping an app is easy compared to everything around it.

11 locales.
20 screenshots.
Multiple device sizes.
Different app versions.
Store metadata.
Team access.
Release history.

Soon you have folders, spreadsheets and docs everywhere.

We're building AppOps to bring those boring parts of shipping into one place.

Register → Upload → Localize → Release.

• Versioned assets
• Device-aware screenshots
• Per-locale store copy
• Team roles
• Release history
• Direct-to-storage uploads

Built for developers who ship more than one app.

Try it → Appavio

buildinpublic #indiedev #mobiledev #appdevelopment

I’m building AppOps to make shipping multiple mobile apps less painful

shyam manek — Thu, 01 Oct 2026 04:45:44 +0000

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.

Try appavio AppOps

👉 https://swtly.co/appavio

I Tried Cluely and Sidekick for a Week — Here's My Honest Experience

shyam manek — Sat, 27 Jun 2026 08:57:29 +0000

AI assistants have become part of my daily workflow. Whether it's meetings, coding, debugging, or taking notes, I wanted to see which tool actually saved me more time.

Over the past week, I spent time using both Cluely and Sidekick by Squiwo.

Both are impressive products, but I noticed they shine in different areas.

My Workflow

I'm a software developer, so my typical day includes:

Team meetings
Reading documentation
Debugging issues
Writing code
Reviewing pull requests
Taking meeting notes
Researching unfamiliar technologies

I wanted an AI assistant that could stay useful throughout the day—not just during meetings.

Cluely

Cluely performed well for meeting-related tasks.

I liked how quickly it could assist during conversations and help capture information while I was in calls.

If your primary use case is AI assistance during meetings, it's worth trying.

Sidekick

What stood out to me about Sidekick was that it continued to be useful after the meeting ended.

Instead of switching to another AI tool, I could continue asking technical questions, get help understanding code, and work through development tasks in the same workflow.

That reduced the amount of context switching I usually deal with.

What I Liked

Cluely

Good meeting assistance
Helpful during live conversations
Easy to get started

Sidekick

Helpful during meetings
Continued to assist after meetings
Useful for technical questions
Better fit for my developer workflow
Reduced the need to switch between multiple AI tools

Which One Would I Choose?

I don't think there's a single "best" AI assistant for everyone.

If your work mainly revolves around meetings, Cluely may be a good fit.

As a developer, I personally found myself spending more time in Sidekick because it fit better into the rest of my day—not just the meetings.

Being able to continue from meeting notes into coding, debugging, and technical discussions without changing tools made my workflow feel smoother.

Download Sidekick

Final Thoughts

AI assistants are evolving quickly, and competition is great for users.

For my daily development workflow, Sidekick felt more like an AI companion than just a meeting assistant.

I'm interested to see how both products evolve, but based on my experience, Sidekick has become the one I keep open throughout my workday.

Have you tried either of these tools? I'd be interested to hear which one fits your workflow better.