I made a native Android app

[Simon Rumble]

Hi there folks.

I recently got a Shearwater Peregrine and wanted to log all my dives in an accessible way so I thought I'd try out Subsurface. Amazing what's been achieved here. It's really solid and the breadth of device support is incredible. However the Android app was pretty clunky. Random freezes, not great navigation and UI.

So I thought I'd see what I could knock out to improve things a bit. Some back and forth with AI agents and I've got a pretty good Android app that scratches my particular itches.

https://github.com/shermozle/subsurface/tree/master/android-ng

And there's builds available if you'd like to try it out:

https://github.com/shermozle/subsurface/releases/tag/android-ng-dev

I'm not really sure what to do from this point. I'm pretty happy with what's come out after half a weekend. It fixes the issues I encountered for me.

I could make this a real release and get it into the Play Store. I could probably even make an iOS version of the same. Is there interest in that? A different approach? The hardest part would be making sure all the dive computer imports work which I can't really test as I only have one.

Feedback from the group? You have much more experience with all this obviously. I'm all ears.

[Jason Bramwell]

What about fixing the issues you encountered with the Subsurface mobile app? That way others could benefit too.

Jason

Sent from my iPhone

On 23 Aug 2026, at 08:46, Simon Rumble <si...@simonrumble.com> wrote:



--
You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-dive...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/subsurface-divelog/6891057d-5984-46cc-a10d-71a0059d3a26n%40googlegroups.com.

[Michael Keller]

Hi Simon.

On 23/8/26 19:37, Simon Rumble wrote:

So I thought I'd see what I could knock out to improve things a bit. Some back and forth with AI agents and I've got a pretty good Android app that scratches my particular itches.

Thanks for sharing this. The UX problems you identified are useful, concrete feedback, and the prototype gives us something tangible to discuss.

I need to clarify an important distinction: this is not a modified version of Subsurface with a native Android UI. It is an entirely new implementation that independently reimplements parts of Subsurface, including the data model, git storage format, cloud synchronisation, dive-computer protocol and parser, and dive-planning calculations.

That makes its use of the production Subsurface cloud storage particularly concerning. Compatibility with the cloud is not established by producing byte-identical output for one fixture or by passing simulated synchronisation tests. It also requires compatibility across the complete data grammar, existing logs, concurrent edits, merge behaviour, malformed or unexpected data, and future changes made by Subsurface. A subtle incompatibility could damage or lose users’ cloud-stored dive data, while the resulting recovery and support requests would fall on the Subsurface project.

Please remove support for the Subsurface cloud service immediately and do not offer test builds that can connect to it. This includes removing or replacing the currently published development APKs that provide this capability. Testing against the production service with users’ real logs and credentials is not an acceptable way to establish compatibility.

The same architectural concern applies to dive-computer imports. The current Subsurface applications reuse libdivecomputer and the shared Subsurface backend rather than independently porting individual protocols and parsers. That provides broad device support and avoids maintaining multiple implementations of critical data-handling code.

The Subsurface project is not interested in investing resources in maintaining a separate implementation that cannot reuse the existing backend logic, particularly for cloud storage and libdivecomputer-based imports.
If you want to continue with this approach, please treat it as a separate product fork:
- choose a name that clearly distinguishes it from Subsurface and identifies it as a fork;
- describe builds as independent and unsupported by the Subsurface project;
- develop, operate, maintain and fund your own cloud storage service if cloud synchronisation is required;
- take responsibility for compatibility, device testing, data recovery and user support;
- avoid presenting its releases as Subsurface test builds or as a prospective official replacement.

The original reports about freezes, startup behaviour, navigation and location handling remain useful. Please report those separately, with the Subsurface version, Android version, device model and application log where available, so they can be investigated in the existing application.

Ngā mihi

  Michael Keller

[João Ventura]

Hi Simon,

I understand the urge to just ask AI to create something better from scratch. The problem is that someone needs to maintain that code, and not simply ask AI to re-create it again without a specific bug, but possibly with all other bugs. Until AI learns how to maintain open-source projects, this is the way that AI can work with us - simple humans - in order that everyone can contribute.

Yes, the Android version is indeed clunky, and it does take some time to start-up, which is annoying but I'll keep using that I know will be maintained for the next 10 years, and not something that AI whipped up for you over a weekend, where you probably never reviewed every line of code it generated, nor will the AI be able to maintain it without changing it completely. Being open-source is not simply being in GitHub....

It's OK to ask AI to create a patch to fix a specific thing (like the auto-filling of GPS coordinates when creating a new dive site), but you should then be able to review that patch and defend all the changes that it does. And the patch should not do random changes unrelated to the problem being addressed.

Cheers,

João

[Simon Rumble]

Hi there folks. All good and sensible feedback! I've removed the build so we can discuss without the data risk you mention. I'm not ridiculously invested in this: it was a fun little activity over a day or so. But I'd still love to improve the subsurface experience.

Michael, you gave a very detailed reply so I'll go through your comments in particular.

I need to clarify an important distinction: this is not a modified version of Subsurface with a native Android UI. It is an entirely new implementation that independently reimplements parts of Subsurface, including the data model, git storage format, cloud synchronisation, dive-computer protocol and parser, and dive-planning calculations.

I specifically chose native Android because my experience with cross-platform frameworks is that there are always major downsides: usually speed and the native feel of the port. But I'm not wedded to it. I got the agent to port my dive computer across but realised that's a poor idea and had the remaining computers implemented as a lift-and-shift. That makes a whole lot more sense given I have no way to test except one model.

I'm also wary of safety-adjacent components being ported this way, specifically the dive planner. I'd want to be very careful modifying a feature like that.

That makes its use of the production Subsurface cloud storage particularly concerning. Compatibility with the cloud is not established by producing byte-identical output for one fixture or by passing simulated synchronisation tests. It also requires compatibility across the complete data grammar, existing logs, concurrent edits, merge behaviour, malformed or unexpected data, and future changes made by Subsurface. A subtle incompatibility could damage or lose users’ cloud-stored dive data, while the resulting recovery and support requests would fall on the Subsurface project.

Solid points. Heard and understood, and why I've taken the build down. (I suspect you've disabled it from your end anyway as my login seems to be failing in my version now.)

There is an interesting thing that comes out of your explanation though: the cloud sync service is evidently fragile and could use some hardening to ensure integrity against any client that connects. Not a knock but perhaps a path forward to accepting an alternative app connecting to it? (As an aside, I'd love to be able to also do a one-way export sync out of the cloud service so I could for example have an online dive log on my personal web site.)

The same architectural concern applies to dive-computer imports. The current Subsurface applications reuse libdivecomputer and the shared Subsurface backend rather than independently porting individual protocols and parsers. That provides broad device support and avoids maintaining multiple implementations of critical data-handling code.

Yes this is spot on. Re-implementing this is a fool's errand that would end up with loads of weird bugs. I'd switch that to a lift and shift.

Part of my choice to port rather than improve the existing codebase is that I know many developers take a dim view of AI-generated code and I just didn't want to get into that argument. I get it, especially for those who've spent many years refining their craft. I respect these deep skills: my own dev skills are hard won but it's never come naturally for me. My skills are elsewhere, primarily in the analytics space. What I have experienced is that well-guided AI tools, combined with good architectural decisions, can produce solid, maintainable applications. I get that not everyone agrees.

So two potential ways forward and I'm keen to hear your thoughts.

1. Improve the existing code base. I attempt to improve the existing app directly to specifically scratch the itches I . Would you be willing to accept AI-produced patches for these kinds of improvements?

2. I build a separate app with its own UI component but use the underlying code for all the important logic: file format, sync system, dive planner, dive computer syncs etc. This would be more a UI skin wrapped around the existing app logic. Compatible but separate, still using the underlying cloud sync. Perhaps with the sync endpoint getting some data integrity checks.

(I suppose there is a third option: a hard fork, as you suggested. It's a possibility but not something I'd really consider. I'm not a wrecker.)

Back to you. Interested in your side.

--
You received this message because you are subscribed to a topic in the Google Groups "Subsurface Divelog" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/subsurface-divelog/QJElGN_vJng/unsubscribe.
To unsubscribe from this group and all its topics, send an email to subsurface-dive...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/subsurface-divelog/510ba7bc-7a59-43bb-a86d-d7e902c82b47%40042.ch.

--

-- 

Simon Rumble <si...@simonrumble.com> - VK2VSR

www.simonrumble.com

[Michael Keller]

Hi Simon.

On 24/8/26 23:00, Simon Rumble wrote:

So two potential ways forward and I'm keen to hear your thoughts.

1. Improve the existing code base. I attempt to improve the existing app directly to specifically scratch the itches I . Would you be willing to accept AI-produced patches for these kinds of improvements?

2. I build a separate app with its own UI component but use the underlying code for all the important logic: file format, sync system, dive planner, dive computer syncs etc. This would be more a UI skin wrapped around the existing app logic. Compatible but separate, still using the underlying cloud sync. Perhaps with the sync endpoint getting some data integrity checks.

Thank you for removing the test build.

The Subsurface cloud was designed specifically to fill a functional gap in Subsurface, not to create a broader ecosystem. Otherwise, we would probably have used something like files on Google Drive and left users to support that setup themselves when it broke. The cloud infrastructure is also funded by Subsurface supporters and maintainers.

I agree that a native application generally provides the best user experience. The practical problem is that this would require at least two independent implementations, and possibly three because native Android is not native iOS. Maintaining and testing those implementations is not realistic for a community-driven open-source project.

Both options 1 and 2 seem reasonable. Option 1 is probably better suited to Subsurface because the desktop application already uses Qt, making its APIs relatively straightforward to expose to QML on mobile. There is no architectural reason, however, why a native frontend could not communicate with the existing C++ backend.
Many of the UX problems you identified result from deliberate scope choices. The priority was to deliver useful mobile functionality without first investing substantial effort in perfecting every interaction. They are not necessarily inherent limitations. For example, the application could show the current local dives immediately at startup while synchronising with the cloud in the background.

As Jason suggested, the most effective way to move this forward would be to apply your experience and effort to improving the UX of the existing mobile application. The issues you have identified provide useful starting points, and contributions addressing them would benefit current users without creating another complete application that the community would then need to maintain.

Ngā mihi

  Michael Keller