After doing some reading about portable, or semi portable app distribution platforms on linux you basically have Flatpak, Snap, AppImage and native .deb.
For the desktop given Flatpaks benefits from sandboxing and where performance issues and storage constraints are not an issue these are my preferred apps to install (using ubuntu in my case).
For the librem 5 or any other linux mobile phone that has limited resources i have come to the conclusion that flatpak is not a good choice (as long these resource constrainst exist), and .deb native installs are better.
To illustrate the point you only have to install one flatpak app, say it has 10MB and it will eat up about 3GB in storage due to required compendium libraries. So the app size as far as a user is concerned isn’t 10MB it is 3GB. On the other hand PureOS already has libraries installed installed in order to enable packaged repository apps, so a 1MB .deb app once installed relies on those libraries already installed and that are part of the system, whatever that .deb overhead is, is now just added to the flatpak overhead.
Conclusion is to only use .deb apps on the phone until such time where storage is not an issue. 32GB of phone storage is sufficient when only running .deb apps. I don’t think it is sufficient to also run flatpak on mobile phones. This might be a flatpak issue and i wonder if this could be optimized for mobile usage, but i have not found a way.
I think one advantage flatpaks still have is that many applications/apps are distributed via flatpak and the development of mobile friendly Linux apps is rather new (using libhandy or libadwaita). So you likely want to have the newest release fixing certain issues with responsiveness, scaling and others.
I don’t think you will get these patches as fast via the native route using .deb packages from your repository and using third-party repositories can lead to breaking your system in worst case when dependencies or packages cause conflicts. Flatpaks won’t have this issue and at least the runtimes and extensions from flatpaks can be shared between apps.
From my experience flatpaks are slower on startup though than apps running outside a sandbox. So depending on the optimization some apps have already received or not, this might be important.
I would assume when you can get your application in a good state from your repository as .deb package, use that. But flatpaks might still be a good option depending on the case. I would just recommend to avoid applications with very heavy dependencies like Electron for example.
Totally understand. I tried building all the newest .deb arm64 apps from source that weren’t up to date in the default PureOS repository (this is however also problematic because you have to install all the dependencies as you mentioned that can cause conflicts and you may have to install whatever compiles the app, RUST, C or whatever other programming language libraries so when i went that route it also added a lot of storage overhead - maybe i can build them on my desktop instead? then just copy the build directory to the mobile phone for install?)
From my experience applications written in C with less or smaller dependencies can be build on the phone (in my case Pinephone or Pinephone Pro since I’m still waiting for my Librem 5 - but their CPUs aren’t much apart in terms of performance). For apps built with Rust… well, if they use cargo for dependency management… they tend to download some minutes, build all their crates (nearly draining the whole battery during that time - tens of minutes) and finally compile… ^^’
So I would recommend cross-compiling those or install them as flatpak or AppImage if available. Rust apps are typically statically linked. That means at least the crates (Rust dependencies) won’t inflate storage requirements as much in comparison to build them locally.
For cross-compiling on your desktop it might make sense to setup a VM because you want to make sure everything matches the PureOS on your phone when it comes to dependencies you don’t want to build as well. The other option would be to cross-compile and build an AppImage but this will cost more storage.
I suggest and use chroot environment with /usr/bin/qemu-arm-static copied from the host in the preparative step. I put there /usr/sbin/policy-rc.d to block manipulation with my x86 system service state. Its content something like
#!/bin/sh
[ “$(hostname)” = “k2” ] && exit 101
[ “$(hostname)” = “pisa-virt” ] && exit 101
[ “$(hostname)” = “baree” ] && exit 101
exit 0
to block it runs on the server side but allows services and systemd manipulaton if volume is used as NFS root for other computers and devices, then I install PureOS and buid there
/usr/sbin/debootstrap
–keyring=/srv/nfs/pureos-archive-keyring.gpg
–arch=arm64
–include=debian-keyring,mc,libc6-dev,libstdc++6,busybox,aptitude,etckeeper
byzantium /srv/nfs/pureos-arm64 https://repo.pureos.net/pureos /usr/share/debootstrap/scripts/amber