Looking at the amount of RAM phones have nowadays I don't know if this is an issue, desktop Linux runs fine with those amounts. Also Android is not really memory efficient so they needed this workaround.
I currently have 35 apps "open" on my iPhone, most of which are probably React Native or similar.
Other times I'm sure I've hit 60-70.
Because of iOS's app management feature, most of the apps are actually dead, but if I go back and open any of them, they will open and load on the screen on which I left them.
Android does this too.
Desktop Linux cannot.
Can I open 60-70 or even 35 Electron apps simultaneously on 8GB of RAM on Linux?
And no, I do not want to to back to closing apps, that is simply an inferior experience.
> they will open and load on the screen on which I left them.
You can't be serious. Browsers can't even remember the most trivial of things - a tiny html page, retaining reading position, forcing a reload.
Of course many apps are no better (though some do try, just like on the desktop)
And it's especially worse with user input that just gets lost
> And no, I do not w to to back to closing apps, that is simply an inferior experience.
Ctrl+Q to close and a shortcut to open or is a faster and more convenient than swiping around. As is typing an app's name on a real keyboard. Tapping "desktop" icon is arguably better, though, that a mouse click
Of course some apps implement this better or worse, but for an app that doesn't implement this, booting me to the home page (which is just one tap away from where I was) is still miles better than hogging ram.
I don't want to close apps, I don't want to manage my computer's resources.
> It should just work and it should just work well.
That's just magical thinking (thought I totally agree with the sentiment, it should, and Linux should also be better), it doesn't, you're still doing the management, just using a different set of gestures.
For example, knowing about this poor "incredible engineering" I sometimes have to reopen the app in the middle of using another app not to lose my input/position there, especially when I need some basic cooperative behavior like copy paste in multiple steps, where I need to make sure no steps are lost. The primitive iOS system can't guarantee that! And in some instances I'd take the overall sluggishness due to RAM waste over this because then I'd still manage to complete the task, albeit slower, instead of having to redo the work (and in some old apps I could even save intermediate progress to those ancient things called files that Apple despises)
> which is just one tap away from where I was
Except it isn't. If you've scrolled to X% of the document, there is no 1 tap to get back there! And if it took you 5 taps to open that sub-page sub-group it the app setting, then getting from the hope page will take the same 5 taps + some time wasted remembering where you want to go to. And if you lose your input in the input field, same thing, 1 tap won't magically recover it.
And if you're temporarily in a place without (good) network conneciton, you might never get there in any number of taps becaus the page won't load.
Btw, if it's fine to lose user data, than Linux can OOM your apps for you just fine without any extra management on your side. Sure, its current state of app management is not as good as on mobile, it does lack some "engineering" in this regard, though not sure what's so magical about more careful killing of apps
> it's fine to lose user data, than Linux can OOM your apps for you just fine
That's the point. Android and iOS have cooperative applications by design. They implement an interface and apps will save their state on command and restore it on next run quickly.
You can't get it back properly without the apps being cooperative to a degree
Again, what I've started with - this is simply false. App Store, the first party gateway to all apps, doesn't. It loses the app page you're in all the time and can't even remember your search query. Safari doesn't
> On Linux no app CAN implement this because the protocols do not exist.
What do you mean, what stops an app from saving position and restoring it in the absence of some magical protocol? How have some apps done in since before the phones existed?
Huh? I just tested it now and the App Store reopened on the same page I was on and Safari also opened on this page and it remembered what I had written into the text box.
More generally apps can store whatever info they want when they're going away to be retrieved when coming back transparently.
On the other hand semantics on the Linux desktop are such that the operating system cannot inform an app that it is going away transparently.
An app that is SIGKILL'd cannot save anything (unless it is proactively saving all the time which is terrible for battery life), an app which is SIGSTOP'd must save it's entire memory space and cannot relinquish locks or GPU resources, and an app that is SIGTERM'd can ask the user to save their work etc. (which is not what a transparently closed app should do).
No wonder you've been oblivious to this issue with 40 apps. Test better, I suppose? Maybe give it more time for the system to fully offload the app, maybe run a few intensive games if you want it faster or just wait longer?
Have you tried other tabs in Safari? Turned off the internet to see whether it's redownloading a page. (by the way, Safari uses 1G of cache, that's enough to store all my 40 tabs basic htmls, yet it doesn't, it finds other less relevant data more important)
And just for this I've tested two more native apps: opened settings/filters in Magnifier, and started editing a password in Passwords app. I was glad that both of these seem to remember the state, and their app switcher screenshot reflected it (well, except for passwords, which is hidden), but then after a longer time reopened them, and position was gone and I was back on the main page - exactly the experience I came to rely upon with trivial bits of state simply gone.
> is SIGTERM'd can ask the user to save their work etc. (which is not what a transparently closed app should do).
Why can't it save the state without asking??? Have you used text editors with hot reload? They just quit with "unsaved" (but not "lost") files.
And GPU buffers? And in-flight network requests? And notification handling? And D-Bus presence? And watchdogs? And other held resources like pids and fds?
If you want to checkpoint/resume applications arbitrarily, as AOSP does, you have to virtualize all of those resources anyway. Check out the CRIU patchset (since merged to mainline) which can even resume applications seamlessly across hosts, without any VM being involved.
This gets brought up several times in this discussion. Hardware with drivers, firmware and device trees exist, see e.g. Fairphone. It even works with open source camera apps (e.g. done in /e/OS). The problem is not (only) the hardware, it is that the Linux desktop stack is wholly unoptimized for phones. And the fact that Meego/Maemo/etc. are now almost two decades ago shows that it is not 'would be easy to solve'. Heck, Linux laptops, which have been available since forever still have far worse battery life than Windows or macOS.
You need a stack that is designed from first principles for phones. Luckily we have one that is open source (AOSP).
Depending on the phone they'd struggle to go in a low power state when the screen is off or can't access other power saving features because the manufacturers keep everything under wraps.
