Multiplatform target (Flutter and/or Kotlin CMP)

Applications Others
1

Hi, I just learned about Sailfish OS from YCombinator and I thought that this forum would be more appropriate to share my reaction as a developer.

I don’t know how well the Android compatibility layer works, but I suspect that native would always work better. Yet, I find it, very hard to come up with a business case where it would make sense to invest in building QT apps for such a niche OS. In fact, we don’t have separate implementations for the mainstream OSs like Android and iOS. Yet, our apps run natively on Android and iOS… and Linux, and Windows and MacOS and even as PWAs, because they are Flutter apps.

When I say that our apps run natively I actually mean natively. Flutter doesn’t produce hybrid applications that look native but are actually packaged web applications. No, Flutter produces actual native code on each of the platforms that it targets. It has two not so secret sauces. One is the Dart language, which compiles natively to each of the platforms it targets (one of them already being Linux - this is important for Sailfish OS - Flutter Linux Embedder: Main Page ). The other is that rather than trying to adapt to each platform’s very different set of widgets, Flutter draws everything on a canvas. It works like a game engine, making for an extremely consistent development experience across platforms.

So, if we could just compile our Flutter apps as Sailfish OS native apps, we would do it in a heart beat. Of course it would require testing on an emulator and on actual devices, but the effort required is minimal when compared to having an entirely separate implementation (and being Europeans we’d love to publish our apps to a European platform!).

Some facts about Flutter:

  • There is an outdated claim about there being more than a million published Flutter apps. Imagine just a small fraction of them getting published as Sailfish OS native apps as well. With over 1M published apps, Google's Flutter expands its support for web apps and WebAssembly | TechCrunch
  • Toyota is embedding Flutter in its infotainment systems.
  • Canonical is betting on Flutter for desktop apps and they’re contributing to Flutter to make it feel better integrated into the Linux desktop.
  • Coming from our own experience, while Flutter gives us this wonderful abstraction over the OS that we’re working on, it doesn’t prevent us from diving to the platform level to take advantage of platform specific features.

While I am talking a lot about Flutter, I am doing so because that is the platform that we have the most experience with. I suppose that most of what I said could well be applied to Kotlin KMP and, especially Kotlin CMP (it also looks very promising). So, while I am not strictly suggesting that you should run to make Sailfish OS a target of Flutter, I am suggesting that as one of two possibilities. The other option would be to make Sailfish OS a target of Kotlin CMP.

Let me put this in a different way. If Sailfish OS were to provide its own Flutter embedding or Kotlin CMP embedding, it would be running apps that had been developed to run on Android (and other platforms) without needing those apps to go through the Android runtime itself.

Either case would possibly bring in a ton of mobile developers that QT will never be able to.

6 Likes
2

There is no bussiness case.

You do it because you like/love it. (the OS and community)

5 Likes
3

Why would you support new os, new platform, new language. There’s never “business case where it would make sense to invest in”. You do it cause you want to.

2 Likes
4

Flutter seems to run on Aurora OS, but in any case some adaptations need to be done to bring flutter support on SailfishOS.

1 Like
5

On a second thought the reason can be that you are not fond of the duopolly and having to pay the apple/google tax.

But then again you can be a bitch like spotify and epic (among others) and cry about it and sue and want the government to interfere.

6

Someone started an adaptation, but his git repository is unfortunately down :frowning:
https://git.mrcyjanek.net/mrcyjanek/flutter-sailfishos

2 Likes
7

flutter runs on sfos @mrcyjanek ported it

9

I wasn’t trying to second guess yout intentions. I was just making a point about that there is no way to make money in SFOS right now.

10

Then we would be flooded with apps which are in the style of Android. Vast numbers of them. 95% of them being recompiles Android/Apple they will be completely unsupported on SFOS by the developers who have their hands full.

It is an advantage to the platform that developers write specifically for it. If that means fewer apps, that’s not inherently bad.

This has played out multiple times in the past. WinCE was used in everything from phones, to cars, to boats. Meego was backed by every man and his dog from Intel down as “write once, run everywhere, on everything” for phones, computers, cars etc etc.

Neither of these worked out, and this was no surprise.

SF is not going to be better off in the long term with minimal effort from dilettantes. It will be worse off. Critically, if a flood of Android coding dominates on SFOS, it’s own native environment dies. Just because your Android app compiles to SF machine code does not make it native - just less bad than Electron.

Indeed this is true. But beyond that, the business case for (probably the majority) of Android apps is scamming. Pushing ads, stealing address books, stealing crypto, selling out the users directly, or indirectly through the use of “platform toolkits” which are doing these things.

Mobile development has an excellent business case only for the principals - Apple, Google, Samsung. Using Googles tooling won’t make SF business case stronger. It only makes the business case of SF users moving to Android stronger.

While I am glad to see anyone writing for SF however they want to, a unique OS only has a point when it has it’s own unique apps, developed primarily for it’s style, and for the specific needs and whims of it’s users. Simply making it have all the same apps, renders SF pointless.

More will be less.

6 Likes
11

The russian implementation can be found here: omprussia / Flutter / Flutter Embedder · GitLab

I don’t know if it works on sailfish or needs some changes but generally it shouldn’t be too difficult.

2 Likes
12

Seems like it’s just a dumping ground for rpms, not sure russians understand open source

13

Go one folder up and check the Flutter project.

1 Like
14

The Russian fork of Sailfish OS (Aurora OS) made the decision to go with Flutter.
Perfectly valid decision, BUT the result is currently a fugly mishmash of app styles, just like on Android.

By using their current SDK, Sailfish OS has a consistent UI look-and-feel.
It would be very difficult to replicate everything in Flutter.
Jolla doesn’t even have enough resources to fix years-long issues in their current stuff.
There is no way they will have the resources for a well-executed move from QT to Flutter.

Also, the fact that you use the same Flutter codebase for several OSes is not really something to brag about. That is why so many apps nowadays look like shit. They just use some half-assed copy of the native behavior for controls from one OS, and then they impose this behavior on other OSes as well, where it makes even less sense.
I can only imagine the horrors to come now that iOS 26 has been launched…

4 Likes
15

Jolla simply won’t have any apps by sticking with Qt then.
Since most new mobile apps are made with Flutter it makes sense to support it.
I haven’t heard of a single studio developing mobile apps in Qt.

Imagine asking a studio or a company to publish their app on SailfishOS and one of the requirement for them to do so is to onboard an entire team of C++/Qt engineers to port maintain their app. Even if Jolla had millions of devices sold, nobody would port their app to it.

With Flutter it would be a trivial thing, essentially it would be just compiling for the proper target and that’s it.

1 Like
16

This is barely a Jolla decission. Flutter is a Google project and they refuse to accept new platforms. FreeBSD, which – I dare to say – has a bigger user base, was immediately turned down. Why should Jolla support a platform by a hostile company?

Anyone who ever worked with Google code upstream knows that they disrespect their downstreams. Anything may change at any moment, there is no API, no dev contract. This makes it time and effort expensive for Jolla to maintain it on its own.

3 Likes
17

That has absolutely no relevance to the discussion and is flat out wrong.
First of all, Flutter is a fully open source framework with a better license than Qt.
Secondly, Flutter team is committed and has ensured that Flutter is embeddable into any platform. They provide first party embedder for Android, iOS, macOS, Windows and Linux, web and wasm. And that’s more than enough, you can’t force them to maintain embedders for niche platforms.

It’s up to the other platforms to implement the embedder for it and maintain it which for Linux engineers is a trivial task to do. There are embedders like flutter-pi for Raspberry Pi kiosks etc.

Sailfish OS could create an embedder where the Flutter app is a view inside a bare bones Qt app and that’s pretty much it. KDE has actually already created it.

You don’t need Google at all. Google doesn’t care about Jolla nor should Jolla care about Google. You don’t even need Flutter team. The embedder api is stable and Flutter is fully committed to that. That’s how flutter runs on so many platforms already and you can’t change that over night so drastically and even if you do so what? The Jolla embedder will be updated, shipped and it’s all good. Nobody will intentionally screw anyone, this is serious framework being even embedded into cars infotainment systems etc so no worries.

I Flutter is perfect match for Jolla but more importantly developers have shown that it’s a perfect match for them.

So the question is do you want a platform with no developer adoption and no future or you want to foster a vibrant ecosystem?

If you ask me, I think Jolla should support both a Flutter and React embedder (in React it’s not that simple but still doable) since those are by far the most used cross platform UI frameworks.

I have over 10 Flutter apps that I could port to Jolla in a single week if they provided an embedder.
I will definitely not switch my company to Qt or hire a team C++ developers, onboard them and spend years porting the apps in order to support a niche platform like Jolla. Not a chance in hell. It’s not economically viable.

I can guarantee you that this is a pivotal issue that will either make Jolla great or kill it again.

1 Like
18

Perhaps you shall start with the embedder then.

1 Like
19

No business case. When a client will have a need for it then I’ll buy devices and develop it.

Not that I don’t want to, but I would have to dive deep into SailfishOS and as I understand it has proprietary components etc so it would be hard for me to do it as opposed to them doing it themselves. It would be an undertaking for me that would not be worth the effort for me personally but it would benefit greatly for SailfishOS.

Until then in order for me to port my apps without anyone paying for it or with me spending my own resources I’d need an official embedder provided by the vendor, Jolla or SailfishOS.
Then I can port my apps, publish it and if somebody uses it then great, if not then also fine.

1 Like
20

This is exactly how I position myself.

2 Likes
21

Yes, that’s what every dev does.

And I think it would have even greater adoption than Linux desktop because most Flutter devs don’t develop responsive apps because they only target mobile form factors. So they don’t want to publish on desktop because the UI will suck to use. But they can don’t need to make it any more responsive than it already is in order to publish for Jolla.

This would work. Jolla could create some hype, go present at FlutterconEU next year and you’ll see how many ppl would be publishing their apps to it.