> WebOS—true multitasking when iOS and Android couldn't handle it
Am I missing something?
Am I missing something?
"To switch between apps on the iOS3 you hit the home button, which takes you home, and then select your next app. Your previous app, assuming it isn’t one of a very limited list of apps that have services that can run in the background (e.g. iPod, checking email), quits completely. Switching back to the previous app relaunches it."
"In iOS 4 Apple promises app level multitasking without sacrificing performance or battery life. A single push of the home button still takes you home, but a double tap will bring up a list of recently used apps along the bottom of the screen. Scroll to find the one you want to switch to, select it and you’ve just “multitasked” in iOS 4."
Even on the Palm Pilot, you could switch reasonably quickly between, say, the Memo Pad and the Calendar, and not lose context in either app because they restarted. The OS was structured around giving apps the ability to freeze their state easily and rapidly thaw it later. I believe Android had some stuff for that, but it wasn't as comprehensive as what Palm had, and I can't speak to iOS APIs at all.
(In 2025, the "solution" to this is largely to just leave the apps running in the background like a desktop, now that cell phones are substantially more powerful today than the desktops of the WebOS era. Whether WebOS could have made a superior phone back in the day, we'd still be where we are today either way.)
[1]: https://www.anandtech.com/show/3779/apples-ios-4-explored/2
(These days few apps bother to do this anymore. I switch away from an app in a minute and upon switching back I'm back at the app's home screen.)
https://developer.apple.com/documentation/uikit/uiviewcontro...
(Also I had to reset the built-in camera to factory state and tell it to stop updating, because it couldn't even start with my phone's RAM anymore. Weird thing is I can't tell you what it was doing any better than the stock factory version.)
But on, ahem, a "real" phone, it is nice to just assume that either I'm still swapped in, or the user doesn't care anymore. It's not quite 100% accurate, but it's pretty close, and low-effort for the app developer who doesn't have to be guessing any more about what state is and is not important.
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
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.
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.
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.)
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)
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.
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.
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.
I love this, such a classic hack
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.
End Users only care whether the product does something they want - make toast, listen to music, prevent stds etc. Jobs shipped products that solved actual problems - desktop publishing, listening to music, making a phone call. They solved other problems also but shipping a product that might one day solve a problem is not a product category.
I think he's wrong about Android, although AFAIK Palm had a nicer task switching UI at first.
The app switcher UI for multitasking on Android didn't really exist yet though so WebOS was ahead there and I think that gave some people the illusion Android didn't support it at all.
[1] https://forums.anandtech.com/threads/t-mobile-g1-android-pho...
He is right in his analysis I think. The webos devices needed a price cut and time to build an app ecosystem, as evident by the hype around the fire sale and how many people really liked them then.
Dunno, it's a pretty straightforward statement.
WebOS was a legit Linux OS and had a lot of good features...
I actually own a discount touchpad. It was snappy as hell, promised to at some point have the Android app store, and could easily be jail broken by design. The software ecosystem was not even bad - my basic needs were all met.
The UI was slick feeling, like an Apple product, but the exterior finish was plasticy and more like an Android device. Battery life was incredible compared to Android devices of the time.
All in all, I really liked it. What might have been!
I don’t think HP was remotely interested in the previous operating system.