[ninkendo]

Never. Not ever, ever ever.

Apple currently has 5 major build trains: macOS, iOS, watchOS, tvOS (which also runs HomePod), and visionOS. Huge amounts of the code are already the same between them: they literally just build the same stuff with different build settings… except for the UI. The UI has actually unique stuff in each train.

This has become more true over time… teams are likely sick of not having certain dependencies on certain trains, so they’re becoming more identical at the foundation/framework level every release.

Saying they’ll make a macOS with a touch UI is like saying Honda is finally going to make a motorcycle with four wheels and a full car frame. The UI is the differentiating factor in the OS’s. Everything else has already converged or is rapidly doing so.

If the goal is to support macOS apps on iOS then there’s a dilemma: how do you suddenly make apps that are designed from the ground up for a mouse, good for touch? The answer is you don’t: you just make the rest of the system identical (make the same APIs available everywhere) and ask developers to make the UI parts different.

I could almost believe that they’d make a macOS VM available for use with a keyboard and mouse within iOS. But to me it’d make more sense to do a sort of reverse version of how iOS apps are supported on macOS… where macOS apps are run natively on the iPad, but rendered with the iPad’s window management (modulo whatever multitasking features they still need to implement to make this seamless) and strictly require a keyboard and mouse to be in this mode. There’s just no reason to make a VM if you’re doing this: you can just run the binary directly. The kernel is the same, the required frameworks are the same. No VM is needed.

[transpute]

VMs are needed by professional developers who want to run CLI tools and services (e.g. web server, database) without the security restrictions of iOS, while retaining the OS integrity of the iPad Pro device.

Even if a macOS VM had only a CLI terminal and a few core apps made by Apple, using a Swift UI framework that was compatible with a touch interface, it would be a huge step forward for iPad owners who are currently limited to slow and power-expensive emulation (iSH, ashell). Apple could create a new app store or paid upgrade license entitlement for iOS-compatible macOS apps, so that users can pay ISVs for an app version with iOS touch input.

[ninkendo]

What you’re talking about sounds great but it’s not “a touch optimized version of macOS”. You’re describing a CLI environment in a sandbox.

Apple will never ever take macOS and change its UI to be optimized for touch. Or at least if they do, it’s time to sell the stock. They already have a touch UI, and it’s called iOS. They’re converging the two operating systems by making the underlying frameworks the same… the UI is literally the only thing they shouldn’t converge.

[hi-v-rocknroll]

The mythical convertible iPad Pro "docking" to a "MBP Base" to use it as a touchscreen. ;)

I like the fact that a number of iPad and iPhone apps now run on macOS without a simulator or any ceremony. While they are touch-optimized, they're easy enough to use with a pointing device. The gotcha to such mythical OS convergence is the inverse is untrue since a desktop UI is unusable 1:1 on a tablet with the coarser granularity of tapping and less keyboard access.

Perhaps OS-level AI in the future will be able to automatically follow design guidelines and UX rules and generate a usable UI (Storyboards or such View parts) on any platform given a description of data, its importance, and a description of what it should try to look like.