nativeforks

I've been using 1.1.1.1 for performance rather than privacy. Maybe I should revisit that decision after reading this.

The browser-first approach is a bigger deal than it sounds. Every time I've looked at reverse engineering, I got stuck somewhere between "install this ancient compiler" and "patch this SDK". Being able to just open a tab and start experimenting removes a huge amount of friction.

Exactly, you got it

>Maybe look into dual licensing.

No, no, not at all as a FOSS developer.

> I’m planning a non-intrusive in-app prompt to remind users about donations something subtle, because many users forget once they start using the app, rather than only seeing the donation info in the README.

As I mentioned previously, the above approach seems to be well enough and good.

Thanks! I feel the same there’s a lot of room for small, focused utility apps that do one thing well without ads, trackers, or dark patterns. That’s largely the motivation behind this project too. Competing on care, simplicity, and respect for users really feels like a worthwhile direction.

Thanks for the suggestion, that’s a fair point. I currently rely on a couple of mainstream platforms mainly to keep things simple, but I do see the value in more open and permissionless options like Bitcoin/Lightning or Monero.

I’ll definitely consider adding at least one of them going forward. Really appreciate the willingness to support.

>Have you had any luck using vector maps?

I already done much research about it (the same as you've mentioned here) related to OSM vector maps. See:(https://github.com/CompassMB/MBCompass/releases/tag/v1.1.4), for Android, the available map rendering libs like Maplibre-Native are an excellent choice, but obviously, it is a high-level library that adds a huge binary to the APK itself, its usecase doesn't fit for MBCompass at least as of now. But thanks for your valuable suggestion :)

Yep, if it were close to the power line, it might cause accuracy loss, but you can obviously easily find the compass accuracy in the top app bar, and if it goes 'very low', the alert dialog automatically popsup to notify you to recalibrate it.

The reason I included that note is that, as an open-source developer, I’ve seen many projects that weren’t actively maintained get picked up by bad actors as they modify the code and publish it on Google Play with ads or IAPs. I wanted to discourage that.

Other than this notice, MBCompass is fully licensed under GPLv3 or later.

Yep, I’m aware that many FOSS projects use in-app payments, but for MBCompass, I want to keep it free on every platform, regardless of the audience. Without funding or community contributions, it’s hard to maintain a FOSS project with meaningful features and improvements, rather than just vague “bug fixes/version bumps.”

As a FOSS advocate, I started this project as a community contribution to address the gap between user needs and available apps.

I can maintain it long-term without major contributions, but support really helps (especially maintaining in different apps stores). I’m planning a non-intrusive in-app prompt to remind users about donations something subtle, because many users forget once they start using the app, rather than only seeing the donation info in the README.

> but I wonder how accurate the compass is

MBCompass uses sensor fusion for accuracy, combining sensor data from the accelerometer, gyroscope, and magnetometer.

It is one of the most accurate compass apps. Don't trust my words, try it with different apps on Google Play and with some FOSS options like Compass by Philip Bobek: https://f-droid.org/en/packages/com.bobek.compass

And importantly, for true compass accuracy, I'd recommend you use the "true north" (magnetic declination) function, which requires location access. It takes some time to lock GNSS hold (the same goes for the current location button on the map view, default map location is Paris, France), but if you're moving, it locks pretty quickly and shows your current location with tracking (if you're moving.)

Thank you so much that really means a lot!

Beyond donating, the best way to support MBCompass is simply spreading the word. That helps more people discover it, contribute to it, and make it better for everyone.

Thank you, that really means a lot. Consistency has been important to me, whether it’s shipping regular releases with real improvements (https://github.com/CompassMB/MBCompass/releases) or writing about Android development and FOSS alongside the project. I really appreciate the encouragement and support.

TBH, that’s a great idea! It’s actually on my roadmap for MBCompass, something like waypoint tracking, where you can mark a location and get a directional arrow to it. Appreciate the suggestion!

Exactly! That’s exactly the philosophy behind MBCompass keeping the core functionality focused and lightweight, without unnecessary frameworks or bloat.

People are often surprised by how much you can do in under 2 MB.

That’s great to hear! Glad it’s helping with everyday use cases like that.

Thanks! MBCompass will stay fully FOSS and free. Donations are extremely rare (tbh, I've not received a single one), especially from the Foss Android community, but they’re still very helpful for long-term sustainability (given Google's non-sense Play monthly policies) and greatly appreciated, especially for users new to open source.

As part of the MBCompass v2 proposal, I’m working on:

- Waypoint tracking (with GPX import/export support)

- GPS speedometer

- Offline maps with offline POI search using GeoPackage (an OGC-compliant standard supporting spatial queries)

I’d love to hear your thoughts or suggestions your feedback is really appreciated!

Good question! “Offline-friendly” mainly refers to the core compass and sensor features, which work fully offline.

For maps, it’s a bit different users initially see an online basemap (requires internet). Instead of forcing them to download an entire map upfront like some libraries (e.g., MapsForge), they can crop or select specific areas to download.

This makes it convenient to get only the map they need. Of course, if they prefer online maps, the app will cache tiles automatically. In remote areas, offline maps can be used as planned.

Thanks! Currently, MBCompass can show both magnetic north using Android’s sensor fusion and true north (based on WGS84 geodetic coordinates).

Adding a magnetic compensation map sounds like a great fit for improving global accuracy without changing the app’s core goals. Thanks for the suggestion.

Thanks for the suggestion. I do plan to publish the app on Google Play as well. While much of the audience is FOSS-oriented, there are also users who aren’t familiar with open source or compiling apps themselves, like here: https://github.com/CompassMB/MBCompass/issues/48.

For them, donations are a simple way to support the project, and they’re definitely appreciated.

Currently, the app shows the user’s live location with real-time tracking on an OpenStreetMap-based map. It does not calculate routes or provide turn-by-turn navigation instead, it focuses on orientation and situational awareness.

I’m actively working on features like waypoint tracking, offline maps, and a GPS speedometer. The goal is to keep MBCompass a useful navigation utility, not a full routing app.

Routing isn’t planned at the moment (maybe with plugins later), since adding it would shift the app away from its core purpose and increase complexity. The main priority is to remain fully functional offline-friendly and extremely lightweight (currently under 1.5 MB).

A fellow developer started a petition to stop Google from limiting app installation on Android devices unless developers provide personal identity documents.

Even though Google has not revoked similar controversial policies in the past, we do our best as much as we can. This change particularly threatens the freedom to build, share, and use software without giving away sensitive personal information. It affects independent developers, FOSS contributors, and even regular users who want to install apps outside of Google Play.

"Just imagine giving sensitive personal, government-issued ID to a corporation to install an app outside Google Play"

Let’s stand together to protect our freedom to create and use software without handing over personal information to a corporation. Every signature, share, and voice counts here

Support the petition here: https://chng.it/tyHZjstxWQ

This GitHub issue tracks https://github.com/CompassMB/MBCompass/issues/52, new feature requests, improvements, and upcoming features. Feel free to suggest improvements.

There are even some "Unknown problem" on IzzyOnDroid repo for app publishing, even ensuring reproducible build, izzy says >>Not necessarily "your fault" – baseline often has such issues: https://github.com/CompassMB/MBCompass/issues/90

Seems like he is talking about the developer being responsible for that also!

This has now become a major issue for F-Droid, as well as for FOSS app developers. People are starting to complain about devs because they haven't been able to release the new version for their apps (at least it doesn't show up on F-Droid) as promised

Still haven't. Currently, most of the devs aren't aware of this underlying issue!

> Nice to see some public funding for projects like F-Droid

Definitely, SSE4.1 instruction set based CPU, for building apps in 2025, No way!!

Yes, SSE4.1 and SSSE3 have been introduced in ~2006. The F-Droid build server still uses that to build modern and some of the most popular FOSS apps.

References:

F-Droid admin issue: https://gitlab.com/fdroid/admin/-/issues/593

Catima example: https://github.com/CatimaLoyalty/Android/issues/2608

MBCompass case: https://github.com/CompassMB/MBCompass/issues/88