Hacker News Reader

> 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.

> 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.

> 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...