It wasn’t the case for Imageworks, which I finally added aarch64 a month ago. On the other hand, I believe I compiled arm 32 bit with a 3.4 target and the aarch64 with a 4.2 target.
That is not a sustainable strategy 
EDIT: and thanks for updating your apps!
EDIT2: Since this is a burning issue, I’m going to bring it up at the next community meeting.
Just to confirm, I uploaded (the app tidings) aarch64 built against the 4.2 target and armv7hl with the 3.4 target and I can install on both 3.4 and 4.2. I’ve booked myself into the community meeting.
Now to get the bugs out
My idea would be that you give your apps a new name for the 64bit build. Maybe just add a -64 suffix?
I could, but that would mean maintaining one additional build because of an artificially introduced restriction, and that’s not fun. I’m already maintaining two builds (openrepos vs harbour) for quite a few of my apps, that’s enough for me. After all, it’s not a paid job, it’s something I do in my spare time. It must be fun, there’s no other motivation. My openrepos builds do include aarch64 rpms, and if there’s no way to do it for Jolla Store then so be it.
That is perfectly understandable. How would you feel if someone else packaged aarch64 versions of your apps for Jolla Store with a different name? You could do what you consider fun, and someone else might consider helping with that bit fun. No, I’m not volunteering (not yet at least), just thinking that someone might
Well said! I also do this because it’s fun, that’s actually one of the bigger drivers for me personally!
Separate 64-bit builds could be scripted easily enough (thanks, sfdk!) but still, it’s a chore. Even worse, it’s a workaround, amd the issue should be fixed on Jolla Store side.
Jolla Store is the safest place to get apps. It it causes issues like this, it drives the devs to OpenRepoa and Chum instead, and that’s not a good thing in the long run… The “homebrew” community has existed peacefully alongside the “official” store and, in my opinion, that should be the case in the future, too.
Jolla Store is the safest place to get apps. It it causes issues like this, it drives the devs to OpenRepoa and Chum instead, and that’s not a good thing in the long run…
While it is off-topic, I couldn’t let it slide.
I would argue that Chum is the safest as you have a chance to examine a code from which the package has been generated.
In the case of Jolla Store, packages are checked for installation and tested a bit, but you don’t know whether some kind of evil code would kick in later. For the sake of the argument, rm -rf ~ could be just behind if (today() > data_of_submission+5*days). As the testers in the Store do not have code, it is impossible to test for such “nice” feature if they do tests within couple of days after submission.
In practice, we don’t read through the code on Chum submissions either as there is no manpower to do so. But it would be possible to find if some complaints will start coming in.
Chum obviously has more libs under the hood, way more open API that the Store. So, while care has been taken to ensure consistency of the build environment and libs, it is possible that something can go wrong with the apps in some conditions. But I would consider Chum to be rather safe place.
So, as explained above, Chum and Store have different trade-offs in terms of safety which has to be realized. Now, if we could push into the Store submission system directly from Chum builds automatically, you could combine the both advantages as well. Obviously, marking in the Store that the package has been Chum-built as a quality sticker to convey that info to the users.
Sorry for going off-topic.
By opening the sources I kind of implicitly agree that anyone can do anything with those - changing, recompiling, redistributing under the same or a different name and so on.
At the same time (and partly because of that 
) I would appreciate if Jolla set up a system of building and signing rpms internally before pushing them to Jolla Store, as well as some sort of procedure of checking the rpm signature prior to installing the app, maintaining a CRL and checking installed packages against it and so on, to allow users to verify that rpms are actually built from the sources they claim to be built from. That would be a great step towards providing certain level of security.
So far, Chum (thanks, @rinigus and @piggz) has gotten closer to that distribution model than Jolla Store. At least one can be reasonably sure that OBS compiled the sources from the location/revision specified in the service file. And 64-bit builds of my apps are already there🤷♂️
Jolla could have chum included by letting the user enable it in the Untrusted SW section of the settings -with a big red fat warning- to make things a bit easier for the user but i don’t think that it will ever happening.
Kodi 64bit would be nice
tIDE – post must be at keast 20 chars
I just checked availability of apps on my Jolla C, which happens to be left on SFOS 3.1, It shows an old version of SeaPrint from before it started to require 3.4. And i was going to say “and later 4.x”, but at least according to Harbour, the current version is compatible with 3.4. (And i always have built with the latest build engine, even EA once or twice - which might not be so smart, but that’s what i have done).
@slava, @rinigus: My thoughts are in this direction, git → obs (signed) → chum → harbour. We can’t get around signing if we want to take this ‘seriously’.
I’m doing ‘extra’ work to try to ease the initial experience people have (since harbour is the first impression). But in the long term, obs/chum does make things a lot more fun, even if only because it’s fast and works directly from auditable code.
A stupid question. Should one just leave old build up? I’ve generally been removing them (since often bug fixes are involved) . But I’m just making myself more work, or? It’ ok for the divide is 3.4/4.2, 32bit/aarch64 at the moment…
AFAICT the harbour webpage is just a submission form, Jolla hangs on to several if not all versions submitted. 3.4 downloading now - let’s see what happens.
Edit: latest SeaPrint shows up, installs and starts just fine on my Jolla C, now running 3.4.
No artificial 4.x requirement there 
(despite all 3 packages having been built built with 4.2.0.19EA).
I would love this also. Editor by @GoAlexander is very nice, but needs some usage/controls improvement.
The problem I found with tIDE when I tried to build for aarch64 is outdated code. It would build and install, but menus are not showing because of some deprecated element…
I just added it it to the wiki at https://forum.sailfishos.org/t/apps-that-havent-been-ported-to-aarch64 and someone has already made a ticket about the bug.
Can we get downloads from the Jolla Store that are 32-bit packages? Seems like a ton of stuff is missing in 4.3 that was there in 4.0 (it’s been a while since I actively used SFOS)
i wanted to build armadillos tasklist for aarch64 and provide it via obs
i did stumble over 2 points:
i did open already an thread for problem 1 and got now answer so far.
for problem 2:
should / shall we include this lib as separated package and if yes how ?
http://lycis.github.io/QtDropbox/