Comment by potatolicious

Comment by potatolicious 6 days ago

12 replies

This is true - and WebOS was legitimately innovative here. At the time neither iOS nor Android could run more than one app at the same time. This was both an architectural matter and a UX matter.

On iOS and Android at the time, all apps were full-screen. When you switched to another app, the previous app suspended execution entirely. The OS would keep the memory footprint of the app warm in RAM if possible, but back then RAM was in short enough supply that more often than not the memory state of the process was dumped to disk instead.

There were lots of clever UX hacks to make this feel seamless - when an app was suspended it was also screenshotted, and the screenshot would be displayed to the user upon switching back, until the actual app could be restored and resume running.

But the app executable was totally suspended during this time.

Whereas on WebOS the UX was oriented around showing multiple "Cards"[1] at the same time, but each one represented a live running process that was able to interact to the user and render new UI.

This was a pretty big deal at the time.

Since then both iOS and Android gained a lot more capability and nuance around multitasking.

[1] https://www.anandtech.com/show/4508/hp-touchpad-review/2

jldugger 6 days ago

The Nokia N900, running Maemo, also supported multitasking in 2011. It was just toppled by a similarly dedicated team of executive fuckups.

  • eloisant 6 days ago

    To be honest there were a lot of mobile OSes at the time supporting multitasking, like Windows CE, because they were desktop OS (Linux for Maemo, Windows for CE) with little adaptation for mobile. That meant performances and battery life were not great.

    That's why those OS were mostly used by geeks and power users, and "regular" users were using feature phones that "just work".

    One of the strength of iOS and Android were to create a completely different userspace that what we had in desktop OS, more adapted to mobile. They combined the "just works" aspect of feature phones with the power of smartphones.

    • RiverCrochet 6 days ago

      Windows CE is quite internally different than Windows NT. It still does support multitasking, but kernel version 5 (which was on all the CE devices of the late 2000's/early 2010's) had a maximum of 32 processes. It was a platform specifically for embedded use, though the GUI was styled to resemble Windows OSes at the time and of course numerous Microsoft things were ported over.

      Windows Phone 7 moved to CE 6.0, then Windows Phone 8 to 10 were NT based.

      Wikipedia says Windows Phone 8 was released October 29. 2012, which is around the time the ARM-based Surface RT was also released. A significant event for Windows NT to be on an architecture other than x86.

      • zozbot234 6 days ago

        > A significant event for Windows NT to be on an architecture other than x86.

        Yeah, I too liked to run Windows NT 3.1 initial release on my DEC Alpha and MIPS workstations. Wait, what?

        (I think you meant to say that the support for ARM32 specifically in Windows RT and the NT-based Windows Mobile 8+ was a noteworthy milestone, which I suppose is a fair point.)

    • potatolicious 6 days ago

      +1. I sometimes hear nostalgia for the N900 but personally I don't get it.

      Anybody could run a full multi-tasking OS on a mobile device trivially. The performance sucked and you killed your battery super quickly.

      The innovation was in multitasking that didn't result in a terrible user experience, and it took a lot to get there! And the answer wasn't "welp what if we just treated this thing like a desktop".

      And it's still not a fully solved problem - there continues to be a lot of movement around how apps are defined so that they can be efficiently concurrent! (or at least give the appearance of concurrency)

      • jldugger 6 days ago

        My recollection was that the N900 battery lasted about a full day of normal use. Maybe two but it was a dice roll. That was pretty much on par with other smartphones on the market. IIRC the main thing android and iOS were doing was shutting down apps to save memory. But perhaps I saved a ton of battery by not buying a data plan? At the time, I had wifi at home and work, and a 100 dollar a year prepaid cell plan.

        And the UI did have plenty of affordances. Basically all the apps were custom, and I vaguely recall there being something close to the home / back on screen button android used in the early days. Heck, it's still a pita to switch apps on my Pixel: swipe up, but not too fast, or it'll bring up the full app list instead of the switcher.

        But sure, there's plenty to dislike about the n900: it had a resistive touch screen and a stylus. Turn by turn navigation sucked for most of its life. The app store launch was so botched that it was basically dead on arrival. The microusb port sucks.

    • hajile 6 days ago

      Elop refused to launch the Nokia N9 in ANY of their primary markets. He refused to advertise the phone AT ALL.

      Despite that, the phone sold several million devices and people were paying huge premiums (often $200-400 over price) to get it shipped from these secondary markets to where they lived.

      The demand was there and Elop decided to kill it anyway. He also never released the second phone required by their Meego contract with Intel as I recall.

    • nextos 6 days ago

      > That's why those OS were mostly used by geeks and power users, and "regular" users were using feature phones that "just work".

      The N9, N900's successor, shipped with MeeGo 1.2 "Harmattan" and had the most simple and elegant UI I've ever seen on a mobile. The phone-UI combination was a masterpiece. But it was still Linux, with all power-user features under the hood.

    • zozbot234 6 days ago

      Windows CE had nothing to do with Windows the desktop OS. We're talking entirely different codebases running on different kinds of hardware.

  • wmf 6 days ago

    The N900 battery could run down in 30 minutes due to true multitasking (especially when using the true desktop browser).

RankingMember 6 days ago

> There were lots of clever UX hacks to make this feel seamless - when an app was suspended it was also screenshotted, and the screenshot would be displayed to the user upon switching back, until the actual app could be restored and resume running.

I love this, such a classic hack

  • potatolicious 6 days ago

    So classic they still use it! iOS now offers a lot more multitasking options, but for the most part when you swipe away from an app it's still good ol' Mr. Screenshot.

    And if you'll excuse more nerding out - a lot of work is being done still to make this even more seamless. For example, iOS now heavily encourages the use of SwiftUI to define UIs, because rendering such UIs can be done by the OS outside of the app process.

    This means you can have an actual live UI while the actual app process is suspended. They literally don't have to wake the process until you tap on a button.

    It used to be that your app either got a full-time 60-120Hz runloop, or you got suspended completely. Now the OS can define a much more coarse-grained idea of "alive" without losing interactivity. It's super cool stuff.