Hacker News Reader

Comment by walterbell | Hacker News Reader

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

View on HN

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

Reply on news.ycombinator.com