Comment by walterbell | Hacker News Reader

Comment by walterbell | Hacker News Reader

Parent Full thread

This question has been endlessly asked and answered, https://www.theverge.com/2021/4/22/22396449/apple-ipad-pro-m...

The answer is obvious to Apple iPad Pro + Magic Keyboard customers:

   MOBILE MICROTASKING

No, dear Apple, it will not compete with your precious Macbook revenue, because an iPad is not a laptop. Your customers who are pleading for un-crippled iPads will keep buying desktops and laptops. But it will be life-changing for on-demand portable anytime anywhere access to OSS code and professional apps, for last-minute edits, quick checks during video calls, testing-while-learning and countless other scenarios. iPad enables flexible computing, i.e. unlimited use cases -- and revenue! Still the only mobile device with 4:3 HiDPI screen.

Apple continues to pour billions into science experiments like Vision Pro (iPad-on-Skull) and anemic cloud services, while refusing to improve the workflows of millions of customers who are willing to pay for repackaging of existing technology already sold by Apple. Fortunately, the industry has not been standing still while Apple squandered a decade of feature-frozen tablet supremacy. Google is now shipping VMs on both phones and tablets.

> At a privately held event, Google recently demonstrated a special build of Chromium OS — code-named “ferrochrome” — running in a virtual machine on a Pixel 8. However, Chromium OS wasn’t shown running on the phone’s screen itself. Rather, it was projected to an external display, which is possible because Google recently enabled display output on its Pixel 8 series... Hopefully, Google will offer the ability to run Chrome OS alongside Android in a future device

As much as I would like macOS on iPads, running macOS applications on an iPad without the Magic Keyboard would suck. Windows can do it though, so it's not really an excuse.

But, in Microsoft's case, it's sort of different. They had Windows 10 Mobile for tablets which is the closest thing to iPadOS, I suppose. Windows 10 Mobile couldn't run Win32 applications, similar to how iPadOS can't run macOS applications. Microsoft killed Windows 10 Mobile...

Implementation-wise though, it's a big effort for Apple. They can't just make macOS applications runnable on iOS. Something like reverse Mac Catalyst for iPadOS wouldn't work due to how complicated and different macOS is compared to iPadOS. It would probably have to be a full on emulation of macOS on iPadOS for applications to run.

So, it would seem like starting with macOS then implementing iPadOS on-top would be better than starting with iPadOS and implementing macOS, which is literally what Mac Catalyst is. So now, Apple has to make sure that all iPadOS APIs work with Mac Catalyst (they don't yet) and they have to do something to make the UX work better when switching between touch and M&K.

Bringing it back to Microsoft and Windows now. It's quite similar actually. Think of Windows 10 Mobile = iPadOS, UWP = iPadOS apps, Win32 = macOS apps. Microsoft killed Windows 10 Mobile and replaced it with full-on Windows 10. Windows 10 can run UWP apps.

Similarly, Apple will likely have to kill iPadOS and fully implement compatibility with iPad apps on Mac for macOS to ever be on iPads.

> starting with macOS then implementing iPadOS on-top

This would lose the security properties of iOS, which is a big part of the value proposition for iPhones and iPads.

> They can't just make macOS applications runnable on iOS.

Other operating systems can run in _parallel_ with iOS. Hardware support for nested virtualization has shipped on Apple Silicon since M2. Google implemented Android Virtualization Framework. There's no shortage of candidate VM operating systems. Microsoft implemented WSL (Windows Subsystem for Linux) VM. Apple could ship ASF (Apple Subsystem for FreeBSD) VMs.

> This would lose the security properties of iOS, which is a big part of the value proposition for iPhones and iPads.

Right. Apple is adding more and more security features from iOS into macOS. But, people are going to complain about that too.

> Other operating systems can run in _parallel_ with iOS

Absolutely, but there is a performance hit and memory management becomes an issue. You still need a host OS as well to unify the UX. Also, there needs to be some way for IPC between the applications of different OSes.

> Microsoft implemented WSL

WSL has networking and memory management issues. WSLg sort of works. Its architecture is wild [1]. Display scaling is terrible though. IPC between Windows and WSL guests is limited.

WSL 2 was released in 2020 and it still has issues. It's not a simple problem to solve.

Microsoft has also gone from WinRT, UWP, WinUI, MAUI, and now WinUI 3 trying to unify application development [2]. Again, it's not a simple problem to solve.

I think the only OS that has actually unified application development across all form factors is Android/Chrome OS. But, people complain about how limited Chrome OS is.

[1] https://github.com/microsoft/wslg?tab=readme-ov-file#wslg-ar...

[2] https://www.irrlicht3d.org/index.php?t=1626

ChromeOS solves the memory management very well.

Depending on how you use it, you have up to 3 VMs running in the background with Wayland passtrough: ARCVM (Android), Crostini (Linux dev environment) and Borealis (SteamOS).

All these VMs run Linux and Google uses MGLRU in cooperation with Chromes tab discarder to balance memory.

Wow. Never knew about the move to ARCVM. Though the first thing that comes up when I search it is memory and CPU usage issues though :/

Google et al. has put a lot of effort into improving Linux's virtualization capabilities. Goes with being the OS of choice for pretty much all servers I suppose.

The problem with WinRT, UWP, WinUI, MAUI, and now WinUI 3 is the usual Microsoft mess.

As anyone can imagine by that list, every new acronym requires a rewrite, and most folks that aren't on Microsoft pay list no longer care.

Well, with Android/Chrome OS they just recently released Jetpack Compose Material 3 Adaptive which is further iteration by Google to try to unify UI development between form factors [1]. And there's the breaking changes with every major version of Android [2]. Then there are the incompatibilities for Android apps for Chrome OS [3].

You can shit on Microsoft all you want, but those listed APIs still work. People expect Microsoft APIs to exist essentially forever, so every breaking change pretty much has to be a new API.

Having a single simple API for developing across different devices and inputs that automatically provides great UX across the board just isn't possible. It's going to be complex and it's on the developer to cater to each device. An API to cater to everything is literally web APIs.

[1] https://chromeos.dev/en/posts/io-2024#android-on-chromeos

[2] https://developer.android.com/about/versions/13/behavior-cha...

[3] https://developer.android.com/topic/arc/manifest

Tell me you never used those APIs, without telling me.

No they don't work, that is why each iteraction requires a rewrite.

WinRT for Windows 10, isn't the same as WinRT for Windows 8.1, isn't the same as WinRT for Windows 8.

WinUI 3.0 has features that are Windows 11 only, although Project Reunion promised compatibility across Windows 10 and 11, it is still quite far from Win 2.0 in features and tooling, years away in fact.

Likewise the WinRT used by WinUI 3.0 in Win32 mode, isn't the same as WinRT used by WinUI 2.0 in UWP mode. Meaning the set of underlying COM plumbing differs in behaviour and exposed set of interfaces.

And I will leave it here, as Github issues and discussions already have plenty of rant material on the matter from the Windows developer community.

I'm not saying that the newer APIs are backwards compatible with the older ones. I'm saying that they're not which is why they are different APIs. WinRT is a bit different since you target a Windows SDK. But, likewise newer SDKs have APIs that are not backwards compatible.

What I am saying is that the older APIs are forwards compatible with newer versions of Windows. On Windows 11, you can still run applications using those old APIs.

On Android and iOS, your old app may break when running on a newer OS version.

Microsoft doesn't have the luxury of changing the behavior of older APIs on newer versions of Windows, so they end up having to make completely new ones.

Try to run a Windows 8.0 WinRT application on Windows 11 to see how forward compatible it is.

> But, in Microsoft's case, it's sort of different.

Microsoft has a long history of trying to make both work, but I think the reality of it is actually not that far away:

Windows 10/11 is a very poor tablet OS, a ton of stuff will be clunky with touch as it's currently just a very thin layer of adjustments on top of the OS, and expecting to get access to all the potential of the machine without a keyboard and trackpad will be a recipe for disappointment.

So, if the iPad had to rival the Surface Pro, it could probably do it tomorrow by just sticking macos on it with the accessibility options (virtual keyboard, mouse etc) and call it a day.

Where Microsoft is truely different is that they still shipped the Surface Pro and let users deal with it. The UI in tablet mode is almost the same, with just the taskbar a bit bigger. Sometimes you'll absolutely need a mouse, so if you don't have one you pull the virtual mouse, solve your situation and go back to what you were doing. Sometimes the entry field is from an obscure API and doesn't pop the keyboard, so you pop it manually and deal with it. Or you absolutely need a shortcut, so again you pop the keyboard in the middle of nowhere, hit the shortcut, and make the keyboard go away.

This is the clunkiness Microsoft has fully embraced, and it makes their tablets actually "just work" as you're given all the tools to straightly do what you want to do. That's where Apple is backing out, and chose to build a DisneyLand OS instead of a gritty, dirty and clunky, but fully functional city like environment.

I get why people want a more polished and elegant experience, but if the goal is to get things done, it's probably the most realistic way forward.

Apple could provide an opt-in, obscure Accessibility mode for clunky-functional.

> As much as I would like macOS on iPads, running macOS applications on an iPad without the Magic Keyboard would suck.

The ability to run macOS on an iPad with a keyboard and mouse (and perhaps even a second screen), and run ipad OS when you're away from those things would be pretty great.

The hardware is already capable of this.

I wish they would at least allow VMs on iPadOS. With the release of macOS 15, you can now use iCloud in the guest macOS VM [1].

[1] https://developer.apple.com/documentation/virtualization/usi...

Bingo bango. In truth they just need to allow actual apps to use the virtualization that’s already in the goddamn things. It’s maddening.

Ferrochrome was canceled.

Could an equivalent demo be constructed using open-source components, e.g. via GrapheneOS?

I guess if enough people care, then again, what is the business case?

Being a cool technology demo will end the same way.

The same business case for headset displays powered by phones.

Reply on news.ycombinator.com