Jolla store - what is the plan?

Hello,
I am quite new to Sailfish os and I am wondering if Jolla store is dead. There are many unkept applications and it feels cluttered with dead applications. It is almost impossible to find something interesting there. I know, there is a openrepos.net, but primary source of applications should be Jolla store, as it should be more trustworthy.
Is there any plan to improve this state?

12 Likes

hi @susenerajce
there is no reason the jolla store would be more trustworthy. just limited in funcionality of the apps at some APIs are prohibited to use.
also, dont be confused; openrepos.net is the real store for sailfish apps :slight_smile:

Yes, but primary source of apps every new user is using is Jolla store. And current state is very sad. I would suggest atleast to remove nonfuncional apps.

2 Likes

Well, openrepos apps are getting broken even more often than Jolla store apps, precisely for that very reason - because many of them are using unstable APIs which are not being maintained in a backward compatible manner. A well-written Jolla store app has better chances (albeit still not guaranteed) to survive an upgrade. It’s a tradeoff - stability vs functionality. Both ends of the spectrum look equally sad IMO.

6 Likes

A well written OpenRepos app has probably the same chances to survive an update and a well maintained app will be updated within hours on OR should there be issues.
The crucial part here is “well written”.
The restrictions in JollaStore seem to be quite arbitrary in some cases and are a major hindrance to some developers.

3 Likes

Well, a Jolla Store app can be updated just as quickly as an OpenRepos app if there’s someone willing to do that. Yes, it will take a day or two longer for a Jolla Store app to get through acceptance but that’s not much of a difference given that many apps are not being looked at for years. API stability (or instability if you’re using an unofficial API) has a much greater impact, IMO.

Of course if you need an API that Jolla Store doesn’t allow, you don’t have any choice.

1 Like

I just wanted to emphasize that the “well written” part is what really counts and that it comes down to the individual app. The JollaStore is pretty much dead because OpenRepos is much more convenient for developers to use and the apps there are by no means inferior to JollaStore apps just because the developers don’t want to waste their time on circumventing some arbitrary store rules.

1 Like

Being “well written” is always a good thing, no doubt about that, regardless of where the app is. But I wouldn’t call Jolla Store dead just yet. I submit my apps to both places, even if that sometimes involves bending the rules a bit, except when there’s no chance whatsoever to fool the evil Harbour Validator script. The motivation behind it is quite simple - the more people see my app (and hopefully find it useful) the better. But that’s just me, of course. I have no way of knowing why other people are doing it.

Yes, OpenRepos may be much more convenient for developers but quite obviously Jolla Store is more convenient for users. So I guess it’s a question of what matters more to you - the process of programming, or the end result and the overall user experience. Since we are doing these apps for free, nobody is going to blame you for doing it wrong :slight_smile: It’s your choice and you can do whatever.

The Harbour rules may seem arbitrary from the first glace but in most cases there’s logic behind those. If nothing else, every API allowed in Harbour is an obligation for Jolla to keep that API backward compatible across releases which limits the development and design choices. It’s something so natural to try to avoid when you’re a platform developer.

4 Likes

This conservative approach is what makes the store a semi dead place. And it deprives the store user from some really usefull apps.
And i get that devs will be pissed if the api breaks and they’ll have to fix it. But i prefer having a few pissed devs that might have to tweak a thing or two during EA than users that cant enjoy good apps.

2 Likes

I wanted to take this opportunity to thank you for providing us with SFOS apps for years.

User matter a lot to me but my counter argument to this is that every minute wasted on trying to invent creative ways to circumvent Store validations is also time not spent on developing, maintaining the app which would benefit users as well.

3 Likes

I would like to know whether application developers really want Jolla to fulfill this obligation or prefer more APIs allowed in Harbour (accepting that it may break more often):

This poll is for all people who have written/are writing Sailfish applications:

  • stable APIs are very important, number of allowed APIs/libs in Harbour unimportant
  • something in between
  • stable APIs more important than number of allowed APIs/libs in Harbour
  • no preference
  • potentially unstable APIs ok (may break roughly once in 6 months), want more allowed APIs/libs in Harbour
  • potentially unstable APIs ok (may break roughly once in 3 months), want more allowed APIs/libs in Harbour
  • bleeding-edge APIs

0 voters

edit: can’t edit the poll anymore, but “something in between” is between “stable APIs are very important, number of allowed APIs/libs in Harbour unimportant” and “stable APIs more important than number of allowed APIs/libs in Harbour”

I think that, given the current release cycle, Jolla could allow more unstable APIs in Harbour, because releases are far away from each other. Even if each second Sailfish update breaks something, it’s not that often.

The only problem I see is communication:
As an application developer, I would like to know beforehand (even before early access, since it doesn’t give that much time) what will probably break. For this, it would be enough for Jolla publishing a “volatile” change log which gets updated as soon as the internal work on some component is done. That is, it’s clear that it will probably make it into the next release - if you are unsure, you can still add a warning like “don’t take anything written here for granted”…

And finally: Considering that most applications are open source and can be recompiled easily, Jolla should save resources and shouldn’t try so hard to maintain ABI (binary) compatibility.

2 Likes

That’s quite a developer-centric approach.

Obviously, regular users won’t be able to recompile your app. Even I am unable to compile most OpenRepos apps, although I’m quite an experienced developer. Almost every app (or at least every author) requires some special tweaks and tricks, turning the build process into an adventure for an outsider. Very rarely you can simply create a project in OBS or open it in Qt Creator on your laptop and build it. It just doesn’t work that way, let’s face it. And BTW, that makes it hard (pretty much impossible, with exception of pure QML cases) to contribute, but that’s a different topic.

In practice, if you don’t spend efforts on keeping your app compatible with earlier releases of SFOS, it will very soon only work on the exact version of SFOS which you’re developing for and maybe a release or two after that.

If you do pay attention to compatibility, then there’s no reason to not just compile it for the oldest supported version of SFOS and it will work on all subsequence versions too, thanks to ABI compatibility. And that’s what users expect - they expect to install your app on their (not your) version of SFOS and they expect it to keep working after upgrades. It’s impossible to achieve that without maintaining binary compatibility.

I’m on the user’s side in this dispute))

3 Likes

Yes, but my point is that many applications are dead many years and they are still in the store. It would be awesome to remove those apps, so the store is not cluttered by unusable apps.

And to openrepos and jolla store. I think if everybody who publishes on openrepos published also to jolla store, everybody who uses would benefit from it because more people would be attracted to use Sailfish.

1 Like

It would be even more awesome if apps didn’t die, except perhaps by their own hand. The current approach seems to do a pretty good job with that.

True. However, my personal experience is that everybody I’ve met in meatspace using Sailfish has some kind of developer/Linux power user experience, so I am a bit biased…

I think we all are, but we are all unsure about what’s the best way. :slight_smile:

Unfortunately, these wishes are contradicting :stuck_out_tongue_winking_eye:

Would it save considerable resources (which are then free for e.g., the browser) to

  • drop maintaining ABI compatibility at all costs (which is my impression currently), so that old, unmaintained apps die after some time, but apps where the dev is still active are just recompiled by the dev; while
  • continue to enforce stable APIs in Harbour (the amount of stability could still be discussed)
    ?