Producing an application for both desktop and mobile

Benefits for LWN subscribers The primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!

These days applications are generally moving away from the desktop and toward the mobile space. But taking a multi-platform desktop application and adding two mobile platforms into the mix is difficult to do, as Dirk Hohndel described in his linux.conf.au 2019 talk. Hohndel maintains the Subsurface dive log application, which has added mobile support over the past few years; he wanted to explain the process that the project went through to support all of those platforms. As the subtitle of the talk, "Developing for multiple platforms without losing your mind", indicates, it is a hard problem to solve sanely.

Hohndel noted that he rarely has slides for his talks but that he makes an exception for Subsurface talks. He has spoken about Subsurface at LCA several times along the way and uses photos from his most recent dives in the slides. He is "like the grandparent who invites you for dinner and then forces you to look at their vacation pictures"; this year's photos were from dives in Fiji the previous week.

Linus Torvalds (who attended the talk) started the Subsurface project in 2011 when he was unable to work on the kernel for a few weeks due to the kernel.org breakin. A year or so later, Hohndel took over as the maintainer. He has chronicled the project in LCA talks in 2013 through 2015, but only returned to the conference in 2019. Things have changed quite a bit in that interval.

There is a generational change among divers (along with many of the rest of us) regarding the use of laptops; younger divers do not want to bring a laptop along on their trips. Instead, they want to use their phones. Even a tablet is too big to bring along for many. That means they are looking for a mobile app. Most new users of Subsurface come in via the mobile app and only later start using the desktop version because it makes some operations (e.g. editing) much easier.

Adding mobile

So when it became apparent that a mobile version of Subsurface was needed, the first idea was to take the desktop application and put it on the mobile device. That is a "really bad plan", Hohndel said. A mouse is a high-precision pointer, and touch is quite coarse, so there is a mismatch there. In addition, when you touch a user interface (UI) element, you are covering it with your finger, which is something about touch interfaces that drives him crazy, he said. Using the same UI on the desktop and mobile device will not work, he said; Subsurface tried that and failed.

So he looked at Android and iOS, since those are the only two mobile platforms that matter. The two have different development philosophies and recommended languages (Objective C, or maybe Swift, for iOS and Java for Android). But Subsurface has a lot of native C/C++ code for various tasks (e.g. talking to dive computers or the cloud, managing the different kinds of data that it handles); the project does not want to redevelop all of that twice. Furthermore, Hohndel "speak[s] neither Java nor Objective C", which would make it difficult for him to continue maintaining the code.

In order to talk to most recent dive computers, Subsurface must be able to talk Bluetooth Low Energy (BLE). It is good that many newer dive computers use BLE, since that is really the only way to communicate with iOS, he said. Older computers and even some of the newer ones use serial over USB to communicate, which "kinda sorta sometimes works" on Android, but not for iOS. Much of that is a work in progress for Subsurface; the mobile apps have been out for three years, but they are not all that good yet, he said.

Subsurface is based on the Qt toolkit, which has a UI markup language: Qt Modeling Language (QML). It is the obvious route for a Qt-based desktop application to move to the mobile space. When you first look at QML, he said, it looks fairly straightforward; you describe the UI elements that should appear on the screen and what kind of actions should happen when those elements are clicked and so on. But, when you try to actually use it, it turns out to be "really hard".

QML has no widgets or UI libraries; it simply has boxes that can be filled in various ways, text fields for input, and support for mouse and touch input. "It is as bare bones as you can get", he said. Beyond that, it requires you to wrap your mind around the difference between declarative and procedural programming. Once again, that sounds simple but a declarative program describes the outcomes rather than the process—and the process magically happens with callbacks and signals behind the scenes. It was "an insane learning curve" for him and the other developers.

Kirigami

Along the way, Subsurface developers encountered Kirigami, which is a part of the KDE project. It is a UI framework that has more structure, adds widgets, and provides other more complex UI elements. Most crucially, though, the KDE community provided a great deal of help with using it. As he has mentioned several times in his talks along the way, the Qt and KDE/Plasma communities have been amazingly helpful. One Plasma developer, who happens to also be a diver, reached out to the project and was able to put together a rough overall framework for the mobile app in about a month.

To this day, when Subsurface has questions about how to make something work, it can get answers from KDE developers fairly quickly. Distressingly often, however, those answers are about "some magic thing you just have to know". Part of that may be because Subsurface is the first project outside of KDE to use Kirigami, so the only other users are quite familiar with it and how it should work. The documentation leaves something to be desired, he said, and Googling "Kirigami" will mostly teach you about a particular style of paper cutting and folding.

Hohndel put up an example of a button in Kirigami and noted that it is "very verbose". It is not immediately obvious that you are looking at the code for a button. It is also difficult to encapsulate the Kirigami code so that parts and pieces can be reused elsewhere. He noted that the code he was showing might not be particularly good code, but it does work.

The example also showed how QML interfaces with the existing Subsurface C++ code, which is simply to make function calls. That is both the major strength and the biggest weakness of Kirigami (and QML, which underlies it). There are three different ways to interface to C++ from QML, but the other two ways are fraught with oddities in object lifetimes and such. So calling functions is the way to go in his mind, but doing things that way makes for "horrible code". When the QML folks show up, usually in response to some call for help, they always say "you're doing it wrong", but it is the only way that works reliably for Subsurface.

He showed some screen shots of the mobile app on Android that looked reasonable from a functional standpoint but perhaps lacked some visual appeal. In part, that is because Kirigami "is its own thing"; it does not follow the Android or iOS UI design philosophy, so the app does not look like other apps geared for those platforms. Because Kirigami has one look and feel, only one manual is needed for the app, but all of the reviews on the iOS and Android stores complain about it. "Everyone thinks that we suck", Hohndel said.

Kirigami apps can run natively on the desktop, rather than in a simulator, which makes it great for debugging, however. It is relatively easy to take an existing desktop application and add mobile support using Kirigami. But, in the end, you may not be entirely happy with the UI that you get. Kirigami is also lacking a UI design tool, which is the biggest missing feature in his mind.

Another problem is that it is difficult to find experienced QML developers. In response to his query about QML development knowledge, one attendee raised their hand, so Hohndel joked that Torvalds should tackle that person at the end of the talk so that they couldn't leave the room. There is roughly four orders of magnitude difference between the numbers of iOS or Android developers and those with QML experience. On the flip side, though, he tried to make a Java app that called into the Subsurface native code and "it's a nightmare". There are around a million lines of code that the project already has; making that work with Objective C and Java was not really in the cards. It is a matter of which battle you want to fight, he said.

Connecting to the Subsurface C++ code is rather tricky. The documentation is lacking, there are all sorts of magic rules that you need to know, and there are object creation heartaches that need to be worked through. Hohndel noted that he had been complaining a lot, "I'm German by birth, it is the national pastime", but once those problems are all resolved, and a pull request comes in making things work, "it is beautiful". Once it is all hooked up correctly, the bugs can all be fixed in one place. There is no need to fix them five different times, once for each desktop (Linux, Windows, macOS) and mobile platform (iOS, Android).

The mobile app now has access to all of the infrastructure that the desktop application has built up over the years. That infrastructure understands the data that Subsurface uses and how it all works together. It is "really wonderful" that complex features from the desktop can easily be added to the mobile app (e.g. filtering) because most of the work has already been done. Even with all the "bitching and moaning" he did about the complications and his complaints about the UI not being quite what he wanted, taking this path did make it "really really easy to make progress" on a mobile app.

Packaging frustration

Over the years, he has given talks on Linux packaging, which he finds to be "really frustrating". But packaging for iOS and Android is "so much more frustrating that I have thought about stopping this several times", Hohndel said. Packaging for the mobile platforms is geared toward using the IDEs and packaging tools that go with the platforms; Subsurface is built using GCC or Clang with scripts and CMake, "all kinds of things that no one expects you to do". It is worse on iOS than Android, he said; you essentially cannot package an iOS app without using Xcode.

Mobile app packaging is also poorly documented and there is a "ton of magic" required. Beyond that, when it doesn't work, it is nearly impossible to figure out what went wrong. There is no real way to debug the install process. Google and Apple regularly break things as well. As far as he knows, Subsurface is the only Kirigami app with a version in both the iOS and Android stores, which is part of why he has struggled with it so much—no one else is doing it. He would like to see more projects do so but, as someone in the audience pointed out, he doesn't really make it sound like much fun.

There is also the question of putting GPL-licensed code onto the iOS store, which has been deemed impossible by the FSF. Subsurface is under GPLv2 but the project has decided that it owns the copyrights and doesn't care that Apple distributing the app from its store might violate the license. The libraries Subsurface uses are all open source and available and the scripts and tools are packaged up in various ways (e.g. container images) such that people can easily build the packages themselves if they want. "So we're pretty sure that we actually are sort of, mostly, kind of compliant with the licenses", though he is not a lawyer, he cautioned. For projects that have members with strong views on open-source compliance, that could be an issue to keep in mind. Subsurface has declared the license to both Apple and Google and has not been challenged on it.

In summary

The Subsurface project knew exactly what it wanted, which was to reuse as much of its existing code as possible, but it still doesn't know how to get that. In the end, the developers ended up with something fairly close. The apps are not as beautiful and intuitive as he would like.

There is an "incredibly hard tradeoff" between the sunk costs of a particular path and the cost of change. Subsurface came down on the side of change back in the days of the switch from GTK+ to Qt; Hohndel has been tempted to simply switch to starting over with a Java app, but hasn't ever quite gotten there. The ease of being able to reuse all of the existing program infrastructure in the mobile app is what keeps the project headed down this path. When that all works, the benefits outweigh the downsides even though he is not entirely happy with the result.

For Subsurface, it is "cross-platform development squared"; not only does it support five operating systems, it also supports two very different hardware platform types (desktop and mobile). That is "incredibly hard" to do. He did some searching to see if he could find another project that does what Subsurface does; he could find no other project that supports all of those environments from a single code base with a relatively small UI layer to handle the differences between desktop and mobile platforms. That means Subsurface is really unusual, but he thinks that will change; more projects will head down this path as mobile apps become ever more important.

There are definitely frustrations, but there are also huge successes. Using the app on the phone to download from the dive computer while sitting on the dive boat, pushing the data up to the cloud, then being able to retrieve it later on a laptop is quite an accomplishment. "I look forward to that day", he deadpanned to laughter. In truth it usually works today. He recommended that projects and developers considering this path should understand the tradeoffs: you can make amazing things happen but it takes a fair amount of effort to get there.

In the Q&A session, Hohndel said that he did not think Flutter was the solution for Subsurface. QML is clearly designed to do what Subsurface needs; it is the extension of Qt into the mobile space. The fact that he has been unable to get it to do what the project needs is a different problem. Another question was what he might recommend to a new project just starting out. If you want a cross-desktop application, Qt is probably what you want as there is little else in the open-source realm that has good support for Windows, macOS, and Linux.

Another attendee said that Subsurface is better than any other dive log application that he has used, which, as Torvalds pointed out, is a pretty low bar. Hohndel said that the proprietary dive computer applications are "a disaster, they are so bad". Some of them are starting to get better, but they are always tied to a specific vendor's dive computers. There are also two single-OS proprietary applications (one for macOS, one for Windows) that handle multiple dive computers, but their phone apps are not well integrated and do not share code with the desktop. As far as he can tell, no one else is doing what Subsurface does.

Interested readers can view a WebM-format video or a YouTube video of the talk.

[I would like to thank LWN's travel sponsor, the Linux Foundation, for travel assistance to Christchurch for linux.conf.au.]

