Back to Blog

Lessons from Publishing 10+ Apps on Google Play

•Emmanouil Athanasopoulos•5 min read•1,042 words
Google PlayApp PublishingMobileBest Practices

The Motivation Behind the Project

Publishing an app to Google Play for the first time feels like a major milestone. Publishing your tenth feels routine — but the accumulated lessons from those ten releases are anything but trivial. Over the past three years, I have shipped more than a dozen apps to the Play Store, ranging from simple utility tools to complex platforms with native modules, background services, and cloud sync. This article collects the most important lessons I have learned about the publishing process, the review system, app store optimisation, crash reporting, and handling real user feedback. None of these lessons came from documentation or tutorials — they all came from making mistakes and fixing them.

Core Features and Design Goals

  • Understanding the review process: Google Play's automated review catches obvious policy violations (missing privacy policy, misleading screenshots), but the manual review is where things get interesting. Apps that use sensitive permissions like AccessibilityService, SYSTEM_ALERT_WINDOW, or QUERY_ALL_PACKAGES face intense scrutiny. For Doomscroll Detox, my initial submission was rejected because I did not provide a video demonstrating why the app needed accessibility permissions. After recording a detailed walkthrough showing the feed-blocking functionality, the app was approved on the second attempt. The lesson: if your app uses any sensitive permission, prepare a clear demonstration video before submitting.
  • App Store Optimisation (ASO) basics: the title, short description, and first three screenshots are the most important conversion factors. I have tested different screenshot layouts across several apps and found that showing real app screens with a brief text overlay consistently outperforms abstract marketing graphics. The app description should lead with the primary use case, not with technical details — users want to know what the app does for them, not what technology it uses.
  • Crash reporting setup: Firebase Crashlytics is non-negotiable for any production app. I integrate it from the first release and monitor the crash-free rate daily for the first two weeks. A crash-free rate below 99.5% is a red flag that usually indicates a null reference on a specific Android version or manufacturer. The most common crashes I have seen across my apps are related to background service lifecycle management on Samsung and Xiaomi devices, which handle process priorities differently from stock Android.
  • Handling negative reviews: the first one-star review stings, but it often contains the most actionable feedback. I respond to every review personally and try to understand the underlying issue. In several cases, what looked like a bug report turned out to be a UX problem — the user could not find a feature that existed but was poorly discoverable. Responding promptly and shipping a fix often leads the user to update their review.

Deep Dive: How It Works Under the Hood

One of the most counterintuitive lessons I learned is that a slow rollout strategy prevents more problems than rigorous pre-release testing. Google Play allows you to release an update to a percentage of users (staged rollout), and I now use this for every release. I start with 5% for 48 hours, check Crashlytics and reviews, then bump to 20%, then 50%, then 100%. On two occasions, this caught critical bugs that my testing missed — once, a database migration that failed on devices running Android 10 with a specific locale setting, and once, a native module crash that only occurred on 32-bit ARM devices. Without staged rollouts, these bugs would have affected every user simultaneously. The cost of a staged rollout is patience — it takes about a week to fully deploy an update instead of a day. But the cost of a broken release (one-star reviews, uninstalls, lost trust) is far higher. I have also learned that the Play Store's internal testing track is invaluable for validating in-app purchases and subscription flows. The production payment system behaves differently from sandbox mode in subtle ways (timing, receipt validation, refund handling), and the only way to catch these differences is to test on the internal track with real payment instruments.

Technical Implementation

  • Release checklist: I maintain a pre-release checklist that I run through for every submission: (1) increment version code, (2) run a production build and verify it installs cleanly on a physical device, (3) check that all deep links resolve correctly, (4) verify privacy policy and data safety section are current, (5) test the upgrade path from the current production version, (6) record a demo video for apps with sensitive permissions.
  • Data safety section: Google Play's data safety section requires you to declare exactly what data your app collects, how it is used, and whether it is shared with third parties. Getting this wrong can delay your review. I maintain a living document for each app that maps every API call, analytics event, and local storage write to a data safety category. When I add a new feature, I update this document first.
  • Multi-device testing: I test every release on at least three physical devices: a current-generation flagship (Samsung S24), a mid-range device (Xiaomi Redmi Note), and a lower-end device (Samsung A14). This catches performance issues and manufacturer-specific quirks that emulators miss. The mid-range and lower-end devices are where most of my users are, and they expose problems that the flagship hides behind raw performance.
  • Version naming convention: I use semantic versioning (major.minor.patch) with the version code auto-incremented on every build. The version name is human-readable and appears in the app's settings screen, making it easy for users to report which version they are on when submitting feedback.

The Technology Stack

These lessons apply to apps built with Expo (SDK 52–56), React Native, and TypeScript, deployed to Google Play via EAS Build and EAS Submit. Crash reporting uses Firebase Crashlytics, analytics uses Google Analytics for Firebase, and OTA updates use expo-updates for JavaScript-only changes between full releases.

Final Reflections

Publishing an app is not the end of the development process — it is the beginning of a different kind of work. The technical skills needed to build an app are different from the operational skills needed to maintain it in production, handle user feedback, navigate the review process, and keep the crash-free rate high. Both skill sets are equally important, and the only way to develop the operational skills is to ship real products and deal with the consequences.