Engineering · August 18, 2026

What We Learned Publishing an Open Source Android App

Practical lessons from developing, testing and publishing Water Reminder as an open source Android app on Google Play, covering architecture, testing, Play Store submission and community feedback.

Publishing an open source app on Google Play is different from publishing a closed-source commercial app. The code is public, the development process is visible and users have expectations about transparency, contribution and licensing. When we open-sourced Water Reminder, we learned several lessons about the intersection of open source development and consumer app distribution.

Why open source a consumer app?

Most open source mobile apps are developer tools, utilities or technical demonstrations. Consumer-facing apps — the kind that regular people download from the Play Store — are rarely open source. We chose to open source Water Reminder for specific reasons:

Privacy verification. Water Reminder handles health data (daily water intake). Making the code public means anyone can verify that the app does not secretly collect, transmit or store data in ways the privacy policy does not disclose. This is the strongest privacy guarantee available.

Learning resource. A complete, published Android app is a more useful learning resource than a toy example or tutorial project. Developers can see how a real app handles database migrations, notification scheduling, widget updates and Play Store requirements.

Trust building. For a new, independent studio, open source builds credibility faster than marketing claims. Users who care about privacy can verify our claims. Developers who care about code quality can inspect our architecture.

Architecture decisions for open source

Open sourcing an app requires thinking about code organisation differently:

Separation of concerns

We structured the codebase so that someone reading it for the first time could understand each module independently. Database logic, notification scheduling, UI components and widget providers are clearly separated with minimal coupling.

No secrets in the repository

API keys, signing certificates and analytics identifiers must never appear in the source code. We use environment variables and build configuration files (excluded from version control) for any sensitive values. The repository includes template files that show what configuration is expected without revealing actual values.

Clear documentation

The README includes build instructions, architecture overview, contribution guidelines and licensing information. A developer should be able to clone the repository, build the app and run it on an emulator within 15 minutes.

Play Store submission for open source apps

Google Play has specific requirements that apply regardless of whether your app is open source:

Content rating

The app must complete a content rating questionnaire. Health-related apps require careful answers about data collection, even when the app does not collect data — you need to explicitly state that no data is transmitted.

Privacy policy

A privacy policy URL is required for all apps that handle personal or health-related data. For open source apps, the privacy policy should align with what the source code actually does. Any discrepancy would be immediately visible to code reviewers.

App review

Google reviews every app submission for policy compliance. Open source apps go through the same review process as closed-source apps. The review typically takes 1–3 days for new submissions and 1–24 hours for updates.

Store listing optimisation

Open source status is worth mentioning in the app description if your target users value transparency. We include “Open source · MIT licence” in the listing and link to the GitHub repository.

Post-launch observations

Users do not read source code

The vast majority of users who download Water Reminder from the Play Store have no idea it is open source and would not read the source code if they did. Open source is a trust signal, not a daily interaction for most users.

Bug reports come through Play Store reviews

Despite having GitHub Issues available, most bug reports arrive as Play Store reviews. This is expected — most users are not developers and are more familiar with app store review forms than GitHub issue templates.

Community contributions are rare

For a small utility app, pull requests from the community are uncommon. We have received a few contributions (localisation strings, minor bug fixes), but most development continues to be internal. This is normal for niche consumer apps.

Forks happen and that is fine

The MIT licence allows anyone to fork, modify and redistribute the app. Some forks have appeared with minor modifications. This is the intended behaviour of open source licensing and does not negatively affect the original project.

Lessons for other developers

Open source is not a growth strategy. Do not expect open sourcing your app to generate downloads, press coverage or community contributions. Do it because it aligns with your values and product goals.

Keep the build process simple. The harder it is to build your app from source, the fewer people will try. Minimise custom build steps, undocumented dependencies and complex configuration requirements.

Choose your licence carefully. MIT and Apache 2.0 are the most common permissive licences for mobile apps. GPL and AGPL may discourage forks and contributions. Pick a licence that matches your goals.

Maintain the same quality standards. An open source app should be as well-maintained, well-documented and well-tested as a closed-source app. “It’s open source” is not an excuse for poor quality.

Water Reminder is available on Google Play and the source code is on GitHub. If you are considering open sourcing a consumer app, we hope these observations are useful.