Multiplatform target (Flutter and/or Kotlin CMP)

Applications Others
22

What would be the benefit of putting the development effort on flutter over just focusing on Android emulation?

Sure there probably is some, but would that make significant difference? Developers would still need to develop for platform specific differences, while they need to put zero effort on emulation..

Flutter support would require a lot of effort to get right. Transition would need a lot of time. Quite hard argument to win with limited resources.

I get you are passionate about Flutter, but we have seen similar story multiple times. Over the last 10 or more years. Community might make something (like we have seen with Qt 6 support, Python and Rust apps etc), but before people like you do a lot of heavy lifting at the start, it won’t move forward.

I do not want to sound too pessimistic, but Jolla is a small team and things like these are a huge effort, with unproven track record.

1 Like
25

To have fully supported native apps that don’t drain your battery in 2 seconds.

Huh? Android emulation requires you to replicate entire AOSP API, translate all the calls into something SailfishOS can work with and translate responses back into something Android apps understand. That’s a completely unsupported, constantly moving target and a monumental task to develop and maintain. You simply can’t rely on it for production.

On the other hand developing and maintaining a Flutter embedder is a straight forward process fully supported and documented.

I’m not passionate about Flutter. I merely offer a suggestion. I could say they should use Dioxus/Rust but that would be a very bad idea. The heavy lifting has been done. The framework is there right for the taking. I’m not going to do it, I’m not a C or Qt/C++ dev. SailfishOS guys are C/C++ devs familiar with the OS so it would be very easy for them. If I had a client that was willing to pay me to now go and learn C/C++ then I’d do it.

And that’s precisely the reason why Flutter is a better fit. Easy to maintain, very fast development velocity, huge pool of mobile app developers. For Qt you won’t find any mobile devs, you’ll find embedded devs and people from car industry but not mobile app devs.

1 Like
26

My 50 cents to this topic. I get your point, but flutter as google project is most likely not the best choice.

But I understand the appeal of platform-independent development, especially for smaller app projects. So what about Tauri (https://v2.tauri.app/)? Since it isn’t based on Big Tech and is built with Rust, it should be easier to contribute to, and it also allows you to implement native functionality.

1 Like
27

Something I like about Tauri is that it can use Servo as a webview :smiley: Tauri update: embedding prototype, offscreen rendering, multiple webviews, and more! - Servo aims to empower developers with a lightweight, high-performance alternative for embedding web technologies in applications.

28

How many apps were built with Tauri already ready to be recompiled to a new platform vs how many apps were built with Flutter? Moreover, from what I understood from the docs, Tauri isn’t in the same league as Flutter, nor React Native. It is in the same league as Ionic, PhoneGap and so on. It is a wrapper around web apps, so you build hybrid apps. With Flutter, you build native apps.

I also have concerns about Big Tech, but Flutter is FOSS, which alleviates those concerns quite a bit. If all this isn’t enough, then I don’t think Tauri would be the ideal alternative. Maybe Kotlin Compose Multiplatform could be it. It is published by JetBrains, a European company and, like Flutter, it compiles to native and like with Flutter, Linux is already a target platform of CMP. I don’t know the numbers, but I suspect that there are less apps built with CMP than there are with Flutter, though. The number of potential developer, though, is huge, because Android development skills are directly transferable to Kotlin CMP.

1 Like
29

The Rust backend part is AoT compiled, so it runs as native code if you create a SFOS target. The UI is rendered in Webview, so should be possible on SFOS as well. From my point of view it is a pro not to use dart but rust and whatever you choose for the frontend part of the app is a big pro. Rust is way more popular than dart or kotlin. And as long as the flutter maintainers even block OpenBSD as target, you can try your luck but it don’t if maintaining a Flutter Fork for SFOS is suitable.

AIK tauri apps would be NextChat and ChatGpt Desktop App :wink:

1 Like
30

The Rust backend part is AoT compiled, so it runs as native code if you create a SFOS target.

That’s why it is a hybrid app, because part is native, while the other part, the UI, is a webview. Flutter apps and Kotlin CMP are native, end to end, including the UI. That makes the whole difference.

Rust is way more popular than dart or kotlin.

It doesn’t matter how popular Rust is if it isn’t popular in this specific use case. Go is also more popular than Dart or Kotlin, even more than Rust, but I wouldn’t suggest a Go based framework because no one is using Go to develop mobile apps.

You are framing the issue in terms of which is the best language to support for developers to adopt. That’s not at all where I’m coming from. What I am stating is that there are tons of Flutter apps that run fully natively and are already out there that could be very easily compiled to SFOS with very little effort from their publishers. I for one, would be delighted to be one.

Check this out:

Tauri doesn’t even register. I suppose it contributes to “other”.

AIK tauri apps would be NextChat and ChatGpt Desktop App :wink:

Amazing. That means that if SFOS were a target of Tauri, NextChat and ChatGPT desktop app developers could easily compile their apps for SFOS. It would still leave out the massive number of existing Flutter apps.

And as long as the flutter maintainers even block OpenBSD as target

Where did you pull this out of? How exactly can a Flutter maintainer block any platform? AFAIK, the most they can do is not accept having to maintain it themselves, which is perfectly legitimate.

31

I’m perfectly aware of the upside argument, but there is one large downside which applies equally to the KDE apps we’ve had ported (using QT5.15 and QT6…) these apps do not use Silica.

Now, for many cases, it’s not so important (ie. a webbrowser, a game with a generated 3d env.). But, it is a hallmark of this OS that integration is so organic. That things look familiar. I’m guilty of breaking the rules (a lot) but it’s a goal of mine to get closer to the design goals of the OS, since it’s the only mobile I can use (well, since meego / maemo) without destroying the device.

SOOO, I’m wary of the idea of a flood of ‘apps for apps’ sake which just do ‘whatever’ design wise and don’t fit into the SFOS design universe. Even if I’m guilty of messing up myself.

3 Likes
32

This is not true. Kotlin is used by far more application developers. But it’s also beside the point since Java is used by a factor more. Which is beside the point, since Javascript and HTML rule supreme. With a bit of python, just for fun.

Now, the QML we have is a bit dated, but it’s programmed with JS. So, we’re already on top.

1 Like
33

Speaking as a user, my favourite mobile OS of all time was Windows Phone. Back then it was far superior to Android, IMO. Yet, I got fed up of not being able to use my banking app, then it was my favourite note taking app, then it was my parking app… you get the idea. I must not have been the only one to either not try or to abandon Windows Phone, because it ultimately died.

So, yes, apps for apps sake is the life and death of a mobile platform. And I guess that if the developers of this OS didn’t think the same, they wouldn’t have bothered having Android as a runtime.

1 Like
34

No, apps for apps sake are the staple of the mainstream. The mainstream has entirely failed to meet my minimal expectations of a mobile operating system. Both Google and Apple. And I used to be a mac fan boy. Never buying from those worlds, ever, again.

For me, these are qualitative judgements. Even though I fail to live up to the standard, it is there and is reflected in the usability of SFOS. It’s what drove me to do all the app work for SFOS that I do (I’m involved in the development or maintenance of over 50 apps).

To pull an example that might clarify, I haven’t stopped playing my piano (which is over 100 years old) because I can’t get midi soundfonts for it. Nor have I stopped subscribing to the (print) edition of the New York Review of Books, just because it doesn’t have an app (well, maybe it does, but I read it in print). And even though I don’t benefit directly, when someone does a native app for SFOS, if I can be off assistance, I will be.

None of this precludes Flutter apps, but the bar is high and the amount of work to ‘really’ integrate flutter so that it does not look like a stranger in a strange land, is not trivial. For my part, I’d rather invest my time in QML & JS.

6 Likes
35

I do believe you may be unaware that it’s a business with multiple vertical segments. The android runtime stuff is, I believe, only profitable for Jolla because it’s used (mostly?) on yocto embedded linux in automobiles. Which is probably a dead end, but I only know Jolla has been split into two parts now, one to serve the auto market, and that’d be with android compat stuff (++), I’d guess.

4 Likes
36

More popular than Dart. To be honest, I had to implement a Flutter app once, and during that time I really learned to dislike some of Dart’s language peculiarities.

Kotlin and Rust are relatively close in popularity. My earlier wording was a bit unclear on that point.

Source: Stack Overflow Developer Survey 2025
https://survey.stackoverflow.co/2025/technology

In general, I also prefer native applications, especially those using native UI toolkits.

1 Like
37

Heh. Looking at that survey, Assembly is more popular than rust.

I think a better metric would be deployed applications, in our case, mobile applications. But I have to admit I care more about winning developer mind share for the platform. So I have to make sacrifices as a developer? At least I have a usable platform. But I’m not anything like the norm, so one can safely ignore me :slight_smile:

2 Likes
38

Saying Qt is basically JS is definitely an uncommon opinion.

39

I know little about flutter, but it would be asome to be supported by Jolla.
But over it, I think the Jolla game changer will be a Jolla App Store where people could pay for apps. That would create another branch of viability to Jolla and its ecosystem.

Open source developers don’t eat from love and pasion.

2 Likes
40

No, I was saying QML is largely programmable by JS. That is not an opinion, it is the nature of the framework. QT is a larger thing than QML and you can use other means to create UIs than QML. I started building with QT long before QML existed and, frankly, am happy for QML, though that doesn’t mean not writing C++ for any of a number of reasons.

3 Likes
42

As a user and new to SFOS. Reading through the discussion, I tend to lean towards the Jolla model.

If there is going to be a unique (European) OS, then native development is the way forward. The bridge to utilise Android apps via App services is sufficient in my mind as a transitional aid.

I love the idea of a system that will run on anything (after embed is available) and can see the benefit for Android developers. However, I can see the possibility, as stated above, that ultimately the ‘Native’ flutter apps would not truly comply or fulfill all the complexity of the OS. There are bound to be mismatches in function that would need to be fudged to fit by the embedder, if my comprehension is correct. So I see this as a sales pitch for flutter, not a benefit for Jolla.

Android flourished because Google had lots of cash to throw at it. Stating the obvious, that is the main issue for Jolla. So as per the quote above, as a user an App shop would be great and supply a flow of cash for developers. I think the new phone may decide Jolla and SFOS future. In the current political climate a solid OS and quality product, could well bring in the needed investment, if not now when?

43

Flutter is Google’s SDK

No thanks.

2 Likes
44

Probably never. What makes and breaks a mobile platform is the app ecosystem. Nowadays Android phones are amazing, but many years ago, Windows Phones were far superior, IMO, but their lack of apps was the real killer. This was my personal experience. I switched from Windows Phone to Android, not because I preferred Android, but because I could do things on Android which I couldn’t on Windows. And, it wasn’t even the mainstream apps. It was the long tail. So, any European OS that doesn’t run the apps that people need, will struggle to succeed. Microsoft burned tons of cash trying exactly this and they failed.

I agree when you say that “native development is the way forward”, but I don’t agree with what it implies. Flutter apps are native apps. Their compilation results in binary code that is directly executable by the target platform without the need for an interpreter, a JIT runtime, anything. This is far more native than running Android apps through some compatibility layer.

Your comprehension about the limitations of the embedder is incorrect. Flutter’s greatest advantage is that while it gives developers a common development tool with a ton of code reuse, it is fairly easy to integrate with platform specific code. So, if there is a Jolla specific function not available in any other platform, any developer could simply write it in, C or C++ (or whichever language is supported in Jolla) and use platform channels to use it from Flutter. I know this because I’ve developed native code to be used from Flutter to add features not available in Flutter, but presented by the target OS (I’ve done this for iOS, for Android and even for Web).

Back again to the native argument, Flutter would be the swiftest way to get native apps into Jolla, leveraging existing investment, but keeping the options open to Jolla specific features.

Yet, I am not strongly advocating for Flutter (well, maybe a bit because of how enormous the existing code base is), but everything that I said is applicable to Kotlin CMP. The downside to CMP is that it is more recent. It has 2 upsides, however. One is that any Android app that was developed with Jetpack Compose would be a potential candidate to be ported to CMP with varying degrees of effort (I would expect a lot more than with Flutter, though). The other upside is that Kotlin CMP is developed by JetBrains, a European company, so politically, probably a more tenable option.

If you think that you will build a European ecosystem around QT that becomes more than a niche, you are dearly mistaken. It simply will not happen.

1 Like