A perfect case for NFC is the STid app. It’s my digital badge for work access and cafeteria meals. They’ve phased out physical tags, so I keep an old GrapheneOS Pixel on me solely for this reason.
I agree it would be useful with NFC, managed to install BankID from Swedbank on the JP2 following this excellent guide though:
I had tried without success before, the crucial step missing was the positioning settings I think.
1 Like
I see it this way: if anyone is going to rewrite a vendor’s app for another platform, it should be the vendor itself. They are the ones who decide whether supporting an additional platform is worth the investment.
Until then, if Jolla offers Android app compatibility as one of Sailfish OS’s key features, it should strive to deliver the best possible Android app support, simply because customers rely on it. A company’s willingness to strive for perfection is what turns a good company into a great one. At the same time, Jolla can continue encouraging vendors to develop native applications.
This way, Sailfish OS can benefit from both worlds: access to commercial business applications through Android compatibility, while continuing to grow a high-quality native open source ecosystem where it makes sense.
DigiD (government app used to login to government or other authorized entities) requires NFC for their ‘ID-Check’ (dutch) although the app is use-able without this ID-check certain more privacy sensitive features are behind this additional check.
Of course! I don’t think anyone’s disagreeing with anyone here. I think attah just meant that e.g. writing NFC tags is not hidden behind proprietary code, so we can just have a native Sailfish app for it. This topic is meant to collect use cases where a native application is unlikely to see the light of day, most likely because it’s proprietary software.
2 Likes
I a little bit disagree here and agree with Attah. While I agree that vendors (especially European ones) should start to make native apps for SFOS themselves, I don’t think that will happen immediately. I think it is better that volunteers does the port for platform from open source platforms when possible. For example, I don’t think Signal will soon make native app, but I’m eternally grateful of Whisperfish. Whisperfish has been downloaded much over 100k times. This gives great indication for organisations what kind of demand there already is for native app.
Edit. sorry for off topic!
Fair enough, I think we’re mostly in agreement.
It’s just that I don’t believe there’s such a thing as a free lunch, at least not in the long run. Relying entirely on volunteers isn’t enough. Android App Support itself—including components such as the NFC and Bluetooth bridges—is commercial software that requires continuous development and maintenance. Jolla phones themselves weren’t built by volunteers either, and customers pay for them.
My point is that Jolla should be strong in both worlds: commercial software and open source. Success comes from supporting paying customers while also attracting developers with first-class development tools, APIs, and documentation. We don’t need to reinvent the wheel—we can look at what Google and Apple have done to build thriving ecosystems for users and developers, and adapt the lessons that make sense for Sailfish OS.
In any case, I’m simply grateful that Jolla provides a genuine alternative.
Out of curiosity, which version and from where did you download it?
I’m running e/OS (Lineage-based ROM), and it is not even offering me SimplePay as a contactless payment method, thus I’m stuck with Curve, which has a very uncertain future.
History shows, and logic dictates, that striving for on-par compatibility with a competitor’s ecosystem is a sure fire way to kill the platform and guarantee that the native app ecosystem never grows.
In addition, allowing dependence on Android apps for any purpose is also harmful for any alternatives, and benefits only Google and its oligarchs.
3 Likes
I understand the concerns about dependence on Android and the importance of building an independent ecosystem. I also understand the risks of trying to compete directly with a much larger ecosystem.
However, my point is not about replacing native Sailfish applications with Android apps, nor about supporting Google’s ecosystem. I am talking about product quality and the promise that Jolla made when Android app support was presented as one of Sailfish OS’s features.
Every successful company has to follow market realities in order to survive and remain profitable. Customers judge the complete product experience. If they are dissatisfied, they are less likely to recommend the platform to their friends and colleagues. Fewer customers means fewer resources, which means slower development of the native ecosystem. This can become a cycle that pushes a platform into a niche position.
Supporting Android apps properly does not mean abandoning native development. It means giving users a reliable bridge while the native ecosystem continues to grow.
Behind every platform there are developers and volunteers who need resources and sustainable funding. Better user experience brings more users, more revenue, and more resources for faster development cycles and a stronger Sailfish ecosystem.
I don’t want to state the obvious, but a great product needs both a clear vision and execution quality. Both are needed for a platform to survive.
I’m using the general Simple app (com.otpmobil.simple.phoenix), always the latest version (currently 2.47.1) downloaded from Aurora Store.
1 Like
I literally get an eye twitch when I see on the forum yet another excuse for missing or buggy functionality being that the team is small and resources are limited.
1 Like
Success of Valve’s Proton compatibility layer for Linux kinda is a counterargument for what you’re implying.
Valve’s Proton is a compatibility layer for running Windows games on Linux. Actually, I think Proton supports my point rather than contradicting it. Valve invested heavily in making compatibility work because they understood that a good user experience is essential for attracting and keeping users. Proton did not replace native Linux development; it made Linux a more practical platform by removing a major barrier. The same principle applies here: if Android app support is a promised feature, making it work well strengthens the platform and gives it more chances to grow.
3 Likes
Well I agree on your take. My reply was for the other fellow who seemed to imply Android compatibility is death sentence for Sailfish apps. I think Valve’s Linux support success gives another kind of perspective.
1 Like
I don’t know if that is a real counterargument… Is there any reason for game studios to make Linux native versions of their games, when they can just run the same Windows version in the compatibility layer?
Of course, some studios have made Linux native versions before, but has there been any significant change in the number of new ports, and if so, has Proton been the driving force behind these or is there maybe some other reason?
Is there any reason for game studios to make Linux native versions of their games, when they can just run the same Windows version in the compatibility layer?
I find it funny that most of the times the Proton version works faster and better than the native Linux ports.
Anyway, my take is that Proton has been absolutely critical for people to be willing to switch to Linux in general as it enables people to play games. I view Android support in same way in Sailfish. Only after there’s enough mass will the importance of those kind of compatibility layers start to be less important.