We know what the next iMac is.

[JMacHack]

...the whole reverse scrolling/scrollbars/scroll arrows thing is a great example of how what works for a touchscreen doesn't work for a mouse - or even a trackpad - by the way.

I disagree, though when I first started using Mac I was confused by the scroll wheel's direction, but it took maybe a month to get used to it. And after using a trackpad (or touch device) it just comes naturally now.

Let's face it too, this UI change was gonna happen eventually. Kids, and young adults today may not know a world without smartphones or iPads. Hell, my brother who's only 7 years younger than me had no clue that chromebooks didn't exist until I graduated! With touch devices becoming as ubiquitous as they are, I think it was the right decision.

Also I dunno when exactly, but the point above is why I think eventually Macs will adopt touch interfaces. It might not be with the first ASi Macs, or in the next 5 years, but as kids grow up in a touch device world, they're gonna default to that control scheme.

 

[Yebubbleman]

So you've tried running iOS Apps on a 2-in-1 tablet, then? Apps written from the ground up for a multi-touch-only operating system? As in, not desktop Windows apps made with bigger buttons because there is zero market for Windows applications that aren't optimised for desktop/laptop.

I've tried running actual mobile apps on a 2-in-1 convertible. Whether they're iOS or not is irrelevent; they're perfectly touch optimized apps that are designed to function either in full-screen or windowed mode. And yes, the experience sucks. I'd much rather run tablet apps ON A TABLET. It's clunky running them on a convertible 2-in-1.

...and who said anything about it being "as good" as a real iPhone/iPad? It just has to be better than running touch-centric apps on a non-touch laptop.

Apple cares about the user experience even if you're too stubborn to. And that is crap user experience whether you realize it or not. As Apple has said, most apps will adapt without a touchscreen. Catalyst is their answer for those that won't. You don't have to like or agree with that. It simply is.

I never said there wasn't. You do realise that Windows 8 was a major flop (for many reasons, but including the attempt to force a mobile-inspired UI onto desktop users without a large mobile software library to back it up) making Windows 10 a really hard sell and resulting in MS having to extend support for the 11-year-old Windows 7 until early this year...? Those who ignore history...

Those who don't understand history...make themselves look like fools.

Windows 7 was always scheduled to have its extended support end in 2020. "Extended Support" doesn't mean that support originally was supposed to end on a certain time, but by popular demand it got extended. Every Microsoft product has mainstream support, in which features and support are added to the product, and then extended support thereafter where security and stability updates are issued. Windows 7's EOL date was never "extended" from a previous date. That's not how that works. Secondly, Windows 10 has been a success for Windows users; partly due to Windows 8's failings, but also due to the fact that it combines the best of both OSes and allows for a more diverse set of form factors (desktops, laptops, 2-in-1s, convertible 2-in-1s, tablets, phones, etc.).

Again, you make yourself look like a fool by telling me I don't know history that you don't even fully grasp. Go educate yourself!

It is absolutely Apples MO to lock everything down where possible, all their other product lines are locked down, and they'd love to get a 30% cut of every software/services transaction on a Mac - but they clearly understand that, in the current climate, locking down Mac OS would not be acceptable to many Mac OS customers. If the day comes where their market research suggests that climate has changed, locked-down MacOS will suddenly become the magical and courageous thing to do.

Bro, you don't know what you're talking about. Like, not at all. Apple had a clear opportunity to lock macOS down with this transition. They didn't take it. They actually opened some things up more. The facts disagree with your opinion. That may change; but that's certainly doesn't look likely given the current trajectory.

Apple's stance on anything could change. You've cited one of many examples. That's why I'm concentrating on the one fact they have explicitly committed to - that they will allow iOS Apps to run natively on Apple Silicon - rather than your personal interpretation of their carefully chosen words during interviews and presentations. (...and, frankly, even that could always turn out to be missing in action when ASi Macs finally launch).

You're concentrating on that one fact like it exists in a vacuum. It doesn't. Native iOS apps on Apple Silicon Macs is one piece of an overall puzzle. Catalyst is the adjacent piece. And Apple is stating that's where they want developers with apps that don't just translate to keyboard and mouse to go, not touchscreen. You're not going to see them reverse course on this anytime soon.

...and yes, the bar to that one was very low because only a disk partitioning utility and an existing open-source EFI "BIOS emulation" module - none of which were Apple proprietary - prevented you from just inserting a bog-standard Windows XP DVD and installing away. Geek types had Windows XP up and running on Intel Macs almost on day 1 without any help from Apple - Bootcamp was just a polished and shrink-wrapped way for regular users to do the same without hosing their MacOS installation.

Actually, most of what you say is inaccurate. Without Boot Camp, third party users got close to being able to stably install and boot Windows XP, but it was a far cry from what Apple added in. And no, nothing of what Apple added in was open source. CSM wasn't even widely adopted outside of Apple until PCs started using UEFI in 2012. Furthermore, other than the CSM module, the only things that were added into "Boot Camp" was the ability to dynamically partition a GPT drive, to add in a partition and fool it into believing that it is an MBR partition on an MBR drive, and lastly Windows XP drivers for the Apple hardware, along with a Windows version of the "Startup Disk" control panel item. THAT'S IT! The only thing Apple added in that people couldn't figure out on their own was the CSM support and most of the drivers. But those are big deals.

...and if you turn it off you could possibly load a tampered-with OS that (say) lets you run iOS Apps without downloading them from the App store. I've never suggested that this is anything but speculation but there is an argument for tying features like iOS support to having secure boot enabled. That hasn't happened so far - but then they're still supporting Macs that don't support secure boot, and iOS support is a brand new feature. Should Apple decide to do that, they're certainly not going to let former promises about "not locking down MacOS" deter them from locking down brand new features.

...except that's not how Secure Boot works. That's like saying "my car has 5G, so maybe Verizon will introduce a firmware update to my car that will enable a turbo engine". Two completely different concepts that have absolutely nothing to do with each other. Secure Boot has absolutely zero to do with application execution nor does it have anything to do with the checks that Apple makes to determine whether there's jailbreaking going on. "Speculation" isn't imagining that two completely unrelated concepts will somehow have something to do with each other. That's called "imagination". And you're welcome to do as much of that as you want! But that's not how technology works.

iOS apps will not run on MacOS without there being MacOS implementations of iOS-only frameworks like UIKit that deal with things like mapping mouse/trackpad/keyboard events to touch events. If you think that's trivial, then you haven't thought about the issue in depth. If you look at the help for the existing iOS "simulator" in XCode, there's a laundry list of frameworks that it doesn't support. If you want to nitpick as to whether that constitutes a "subsystem" then feel free to choose some other name, but the point is that it's not something that appeared by magic "because Apple Silicon". Apple had no need to add iOS app support to MacOS - it's not something that a third party could hack together for anything other than a gimmick (if only because it needs to work with the App Store) - and the fact that they have gone that extra mile proves that they don't see Catalyst alone as sufficient.

There are no iOS only frameworks outside of the UI layer. Period. The stack is otherwise identical across iOS, iPadOS, and macOS and has been for quite some time. The only difference is that the fully compiled applications are now on the same architecture as the Mac. I have plenty of WWDC videos that explicitly state this. What do you have to prove to me otherwise? "Speculation" Rubbish about how "Apple may say this now, but they may change their mind later"? Get real. Get educated.

Do you want to start with the way that Apple II software didn't run on a Commodore 64 even though they both had a 6502 processor? Or that Windows for PowerMac never appeared (other than via emulation), even during the period when MS were shipping a PPC version of NT 3.51 for IBM and Motorola PPC systems? Or that the PPC Mac couldn't run PS3 games even though they both used PPC?

...or that ASi Macs won't be able to (usefully) run ARM Windows or ARM Linux unless Apple release (or support the development of) Linux & Windows drivers for ASi graphics, ASi disc controllers and whatever other functions currently handled by generic PC industry hardware that Apple moves onto the ASi SoC.

The Intel/x86 platform is an aberration because virtually all modern x86 personal computers (I'm sure there are exceptions) evolved from the proprietary IBM PC/AT system, which has always been joined at the hip with DOS/Windows and enjoyed such a dominant market share that any third party maker of disc controllers, GPUs, networking hardware etc. has been obliged to ship them with x86/Windows drivers. So when people talk about "x86" or "Intel" they actually refer to a loose collection of hardware and firmware standards that define a modern Windows PC. The reason that it was so easy to get Windows running on the early Intel Macs was that they basically were PCs, made from standard PC components. The Windows installer would run with a minor tweak to the (open source) firmware and all the required drivers were downloadable from the chipset manufacturers' websites. Bootcamp just wrapped it up and tied a ribbon around it.

We don't know what the exact hardware architecture of ASi Macs will be (there's some clues from the WWDC stuff but most of it is 'use our software frameworks as so and we'll worry about the hardware') - we know that things like PCIe and Thunderbolt/USB/3/4 will be there but we also know that - at the very least - the graphics and disc controller will be proprietary - and Apple's only commitment is to provide closed, MacOS drivers for those, which leaves them free to completely change the hardware interface with every subsequent new Mac.

That was quite the ramble! I read that a bunch of times over and not much of that was accurate or even made any kind of coherent sense. And mind you I deal with these technologies extensively as my career (not just during my off hours when I get quality time debating nonsense with you). I especially am amused by the part in bold which not only made no sense, but is also completely wrong. Also, Apple did define the hardware architecture of Apple Silicon Macs. That's in another WWDC20 video. So, no real mystery there other than the specifics of how much.

...but there we go off on an irrelevant tangent again because you've thrown in a red herring and insisted that it is a banana.

lol...what?

Bro, it's okay to admit you don't know crap about computers. It's fine. These forums cater to people of all expertise levels. But you're talking out of your behind here. I'm sorry.

You can't run native MacOS Apps (even ones re-compiled for ASi) on iOS and you can only run native iOS Apps on ASi MacOS because Apple has added MacOS implementations of the required framework, added the ability to install iOS Apps on Mac to the App store etc. Whether that's compatible with your statement "iOS is effectively macOS" is another one of your red herring/bananas.

"Implementations of the required framework" shows me that you neither understand frameworks, nor implementations. Why do you insist on debating things you don't know about?

You do realize that for many iOS Apps, a significant part of the iOS-specific development work is in the UI, and re-writing one to use AppKit/Catalyst/whatever (and testing and refining the result) can be a non-trivial job? Which is probably why Apple have conceded that Catalyst is not sufficient in itself by adding iOS support to MacOS. First, to use Catalyst, you have to modify your source code and, secondly, nothing in Catalyst is going to make your gesture-driven game or Pencil-based sketching app usable on a non-touch laptop.

I can't talk to you if you can't address the videos I've told you to watch twice already. Apple's stance is Apple's stance. You can talk to me until you're blue in the face about what Apple could do to reverse their current position and it would all be irrelevant because their current position is that most apps will work unmodified without the need for a touch screen and those that have difficulty are encouraged to use Catalyst. That's not my stance. That's Apple's. Deal with it.

Feel free to cherry pick specific interpretations of non-technical words that support your argument.



Hate to break it to you, but the iOSsification of the MacOS UI has been an ongoing drip-drip process since 2011 when Mac OS Lion removed the scrollbar arrows and made "reverse scrolling" the default.

OS X Lion - Wikipedia

en.wikipedia.org

...the whole reverse scrolling/scrollbars/scroll arrows thing is a great example of how what works for a touchscreen doesn't work for a mouse - or even a trackpad - by the way.

Interface elements are one thing. The interface itself is another. But feel free to cherry pick specific interpretations of non-techincal words that support your argument! ?

 

[theluggage]

You couldn't be more wrong on that front. It may not work for YOU, but that doesn't mean that it doesn't work for everyone.

...but the fact that it works for you means that it does work for everybody?

9 years after "Natural scrolling" was introduced there is still an option to disable it. I guarantee that Apple are not retaining that option for my personal benefit alone.

Meanwhile, if you know of anybody who didn't find "natural" scrolling immediately and intuitively obvious on a touchscreen iPhone, do tell.

We have seen multiple reports confirming that Apple and Microsoft have already begun discussions regarding opening up WoA in that manner.

The licensing issue is irrelevant: that's solved by a liquid lunch and the stroke of a pen. Producing efficient Windows drivers for "bare metal" ASi graphics, SSD drivers and any other functionality requires either Apple or Microsoft to do actual work... It's a lot easier for Apple if they only have to worry about supporting MacOS drivers.

Which is moot anyway, because:

Apple has also said that it does not plan to support Boot Camp on its future Macs.
"We're not direct booting an alternate operating system," Apple software engineering chief Craig Federighi said. "Purely virtualization is the route."

Apple Silicon: The Complete Guide

Apple introduced the first Apple silicon Macs back in 2020, marking the start of its transition away from Intel's chips. Apple's custom chips...

www.macrumors.com

...and virtualization doesn't require Windows drivers for "bare metal" ASi hardware - the hypervisor can either emulate some already-supported hardware - or installs paravirtualized drivers - and passes the actual work to the MacOS drivers.

 

[dmccloud]

...but the fact that it works for you means that it does work for everybody?

9 years after "Natural scrolling" was introduced there is still an option to disable it. I guarantee that Apple are not retaining that option for my personal benefit alone.

Meanwhile, if you know of anybody who didn't find "natural" scrolling immediately and intuitively obvious on a touchscreen iPhone, do tell.

I have no idea where you got the conclusion in your first sentence from - that's not even a logical extension of my point, which was that your experience is not representative of everyone. By logical extension, my experience which is completely the opposite of yours would also not be representative of everyone. This is especially true in this case since scrolling direction has NEVER been an all-or nothing proposition, even though you attempted to portray it as just that. The main reason the option to disable natural scrolling still exists in MacOS is because even Apple realizes that it is a matter of personal preference. None of this is an "all or nothing proposition", regardless of how hard you attempt to portray it as such.

The licensing issue is irrelevant: that's solved by a liquid lunch and the stroke of a pen. Producing efficient Windows drivers for "bare metal" ASi graphics, SSD drivers and any other functionality requires either Apple or Microsoft to do actual work... It's a lot easier for Apple if they only have to worry about supporting MacOS drivers.

Which is moot anyway, because:



...and virtualization doesn't require Windows drivers for "bare metal" ASi hardware - the hypervisor can either emulate some already-supported hardware - or installs paravirtualized drivers - and passes the actual work to the MacOS drivers.

There are two major issues with your claims here. First, it would fall upon Apple to create the drivers regardless of whether you are running Windows in Boot Camp or via virtualization, since it is their hardware Windows would be running on. The only difference would be whether Apple builds drivers for use in Windows proper (as they do with Intel-based Macs now), or builds something running on a hypervisor level to translate system and driver calls from Windows to Mac. either way, Apple would still have to reach an agreement with Microsoft regarding Windows on ARM in order to access the APIs that are specific to WoA. The licensing issue isn't as simple to resolve as you claim, especially since Microsoft would have to first alter their existing licensing agreements for WoA before Apple could even begin to work on virtualization of the OS.

 

[theluggage]

Windows 7 was always scheduled to have its extended support end in 2020.

My mistake (I was thinking of XP which got 12 years rather than the usual 10 and a couple of extra security patches after that). Still, the end of Win 7 support caused a great wailing and gnashing of teeth that even reached the mainstream press... My basic point was that Windows 10 uptake was lukewarm, partly due to the Windows 8 flop (https://www.cnet.com/news/windows-10-continues-to-crawl-its-way-up-on-desktop-pcs/).

The only thing Apple added in that people couldn't figure out on their own was the CSM support and most of the drivers. But those are big deals.

The CSM support (and bootloader tweaks) was exactly what the XOM people worked out on their own (helped by EFI being an open standard).

Bro, you don't know what you're talking about. Like, not at all. Apple had a clear opportunity to lock macOS down with this transition. They didn't take it. They actually opened some things up more. The facts disagree with your opinion.

As far as I can tell the facts are (a) the boot process is now based on iOS secure boot, (b) they've added "kernel integrity protection" which has added a lot of new restrictions and kernel extensions, (c) they've removed target disc mode in favour of a SMB-based system with authentication and (d) they've explicitly stated that they will not support direct booting of alternative operating systems. These are not all bad things, but what they are not is "opening up". The closest thing to opening up is that you can now set "secure boot" per-operating system - but this seems to be entirely focussed on booting MacOS and they're not going to support anything else (not that anything else could run usefully without drivers for proprietary ASi hardware).

Secure Boot has absolutely zero to do with application execution nor does it have anything to do with the checks that Apple makes to determine whether there's jailbreaking going on.

When you say "Secure Boot has absolutely zero to do with application execution", are you claiming that security protections like Gatekeeper - or whatever prevents unauthorised iOS Apps from running - can't possibly be knobbled by loading a suitably patched version of the operating system (which is what Secure Boot prevents)?

'cause preventing loading compromised operating systems that might bypass security features is pretty much the point of secure boot.

There's nothing unreasonable about the idea that some future MacOS features might require secure boot (especially now that developers who need to turn it off can have a separate secure MacOS installation).

That's like saying "my car has 5G, so maybe Verizon will introduce a firmware update to my car that will enable a turbo engine".

Last I looked, 5G couldn't be used for physically downloading engines, but secure boot systems were quite useful for preventing the circumvention of security features via a hacked OS. Currently, it's only possible to run iOS Apps on a securely-booted iDevice (the same secure boot system that Apple are implementing on ASi Macs). If Apple doesn't require the same protection when they're run on an ASi Mac, that's something of a u-turn. That's not an unreasonable speculation - someone with a DTK could prove or refute it at a stroke (if they fancy breaking their T&Cs) but unless you've got something better than that absurd metaphor...

Also, Apple did define the hardware architecture of Apple Silicon Macs.

...in enough detail to enable someone to write a Windows or Linux driver for (say) accelerated ASi graphics? Of course not - that's way beyond the scope of WWDC and would include information about the forthcoming Apple Silicon chips that may never be shared without NDAs up the wazoo - if at all.

To reiterate the point: it's going to be very hard for anybody to produce alternative operating systems that can direct boot - usably, if at all - without Apple support - and they've said they won't support booting other OSs, plus it makes things much simpler for them if they only have to worry about their own MacOS drivers.

There are no iOS only frameworks outside of the UI layer. Period.

...and changing an application from one UI framework to another requires significant developer effort, period.

That was quite the ramble! I read that a bunch of times over and not much of that was accurate or even made any kind of coherent sense.

TLNR: the simple fact that two platforms share a common processor doesn't magically make them able to run the same Apps. You seemed to have a problem with that blindingly obvious assertion. I'm sorry if my attempt to explain why "up" isn't "down" didn't succeed - that's always tricky.

"Implementations of the required framework" shows me that you neither understand frameworks, nor implementations.

I know what frameworks and implementations of frameworks are thanks very much: they are things that don't automatically write themselves just because two platforms suddenly share the same CPU family.

So, I've done some homework:

However, you might still want to update your code to account for differences between the iOS and macOS environments. For example, while the system matches touch events to mouse events, macOS supports only one such event at a time,
...
macOS provides versions of all iOS frameworks for your app to link against, but some features of those frameworks may be unavailable in macOS. In particular, frameworks that interact with iOS-specific hardware, such as Core Motion and ARKit, return errors when you try to use features that aren’t available. Similarly, frameworks like HealthKit and HomeKit aren’t supported on macOS and return errors when you use them.

Apple Developer Documentation

developer.apple.com

So, sure, you're right in that all the frameworks are there now, but they're not completely implemented. A framework that returns errors is better than one which simply doesn't load - marginally. Meanwhile, there's a laundry list there of why some applications might need modification. Also, on that page, I see two references to Catalyst, one of which explains why you don't need to use it and nothing to say "for best results switch to Catalyst".

...and they actually say that the iOS support uses existing Catalyst infrastructure (obvious in hindsight) which is better than either of our explanations as to why iOS support was suddenly a thing. Of course, that means that Apple could have added iOS support in Intel, since Catalyst exists for both and most iOS Apps were debugged as Intel binaries.

Interface elements are one thing. The interface itself is another.

An interface is made of interface elements. Over the years, a whole bunch of iOS interface elements have turned up in MacOS. Recently, some Mac elements/concepts/whatever have started turning up in iPadOS. Now Macs are going to be able to run iOS Apps. The distinction between the platforms is being eroded. That's the point - not whether or not "merge" is the best word for that process.

 

[dmccloud]

My mistake (I was thinking of XP which got 12 years rather than the usual 10 and a couple of extra security patches after that). Still, the end of Win 7 support caused a great wailing and gnashing of teeth that even reached the mainstream press... My basic point was that Windows 10 uptake was lukewarm, partly due to the Windows 8 flop (https://www.cnet.com/news/windows-10-continues-to-crawl-its-way-up-on-desktop-pcs/).



The CSM support (and bootloader tweaks) was exactly what the XOM people worked out on their own (helped by EFI being an open standard).



As far as I can tell the facts are (a) the boot process is now based on iOS secure boot, (b) they've added "kernel integrity protection" which has added a lot of new restrictions and kernel extensions, (c) they've removed target disc mode in favour of a SMB-based system with authentication and (d) they've explicitly stated that they will not support direct booting of alternative operating systems. These are not all bad things, but what they are not is "opening up". The closest thing to opening up is that you can now set "secure boot" per-operating system - but this seems to be entirely focussed on booting MacOS and they're not going to support anything else (not that anything else could run usefully without drivers for proprietary ASi hardware).



When you say "Secure Boot has absolutely zero to do with application execution", are you claiming that security protections like Gatekeeper - or whatever prevents unauthorised iOS Apps from running - can't possibly be knobbled by loading a suitably patched version of the operating system (which is what Secure Boot prevents)?

'cause preventing loading compromised operating systems that might bypass security features is pretty much the point of secure boot.

There's nothing unreasonable about the idea that some future MacOS features might require secure boot (especially now that developers who need to turn it off can have a separate secure MacOS installation).



Last I looked, 5G couldn't be used for physically downloading engines, but secure boot systems were quite useful for preventing the circumvention of security features via a hacked OS. Currently, it's only possible to run iOS Apps on a securely-booted iDevice (the same secure boot system that Apple are implementing on ASi Macs). If Apple doesn't require the same protection when they're run on an ASi Mac, that's something of a u-turn. That's not an unreasonable speculation - someone with a DTK could prove or refute it at a stroke (if they fancy breaking their T&Cs) but unless you've got something better than that absurd metaphor...



...in enough detail to enable someone to write a Windows or Linux driver for (say) accelerated ASi graphics? Of course not - that's way beyond the scope of WWDC and would include information about the forthcoming Apple Silicon chips that may never be shared without NDAs up the wazoo - if at all.

To reiterate the point: it's going to be very hard for anybody to produce alternative operating systems that can direct boot - usably, if at all - without Apple support - and they've said they won't support booting other OSs, plus it makes things much simpler for them if they only have to worry about their own MacOS drivers.



...and changing an application from one UI framework to another requires significant developer effort, period.



TLNR: the simple fact that two platforms share a common processor doesn't magically make them able to run the same Apps. You seemed to have a problem with that blindingly obvious assertion. I'm sorry if my attempt to explain why "up" isn't "down" didn't succeed - that's always tricky.



I know what frameworks and implementations of frameworks are thanks very much: they are things that don't automatically write themselves just because two platforms suddenly share the same CPU family.

So, I've done some homework:



So, sure, you're right in that all the frameworks are there now, but they're not completely implemented. A framework that returns errors is better than one which simply doesn't load - marginally. Meanwhile, there's a laundry list there of why some applications might need modification. Also, on that page, I see two references to Catalyst, one of which explains why you don't need to use it and nothing to say "for best results switch to Catalyst".

...and they actually say that the iOS support uses existing Catalyst infrastructure (obvious in hindsight) which is better than either of our explanations as to why iOS support was suddenly a thing. Of course, that means that Apple could have added iOS support in Intel, since Catalyst exists for both and most iOS Apps were debugged as Intel binaries.



An interface is made of interface elements. Over the years, a whole bunch of iOS interface elements have turned up in MacOS. Recently, some Mac elements/concepts/whatever have started turning up in iPadOS. Now Macs are going to be able to run iOS Apps. The distinction between the platforms is being eroded. That's the point - not whether or not "merge" is the best word for that process.

There are two completely different platforms with differing use cases and form factors at play here, which is why your repeated attempts to equate the two platforms is a futile attempt. There is no logical reason to migrate Core Motion, HomeKit, or ARKit to the Mac, because they would have limited (if any) utility on that platform. That's the biggest reason not all iOS/iPadOS apps will be migrated to MacOS. For example, a game such as Pokemon Go (which uses GPS/geolocation, ARKit, and Core Motion) would be crippled on a Mac to the point where it would be nothing but a waste of time and resources to make it a cross-platform app. Apps such as Earnin (which uses the GPS/geolocation framework as well) would also be rendered largely useless under MacOS because unless you are carrying a Mac around and turned on all day, it wouldn't be able to track your work hours. The contact tracing apps that are popping up in the wake of COVID-19 are another type of app which would have limited utility on MacOS, for the same reasons as Earnin and related apps.

You keep throwing the word "merge" around as if Apple is planning to formally merge iOS (or iPadOS) and MacOS into a unified operating system. The problem with your claims is that your outcome is the OS equivalent of trying to combine an apple and an orange into a new fruit. While they share some common features (seeds in the middle, a skin protecting the fruit within, growing on trees), the fruits themselves are entirely different, and are often used and consumed in different ways. A MacBook/iMac/Mac Mini/Mac Pro is used in a completely different manner than an iPad or iPhone, and that is not a trend which is likely to change at any point in the forseeable future. Just because something can theoretically happen does not mean that it will or should happen.

 

[theluggage]

I have no idea where you got the conclusion in your first sentence from - that's not even a logical extension of my point,

Perhaps if you hadn't started off with "You couldn't be more wrong..." immediately followed by your own opinion. I didn't quibble with the other poster who likes "Natural" scrolling.

As I said - contrast with the introduction of natural scrolling on the iPad where it was so obvious that people didn't even think about it.

First, it would fall upon Apple to create the drivers regardless of whether you are running Windows in Boot Camp or via virtualization, since it is their hardware Windows would be running on.

The drivers in a virtualised OS do not necessarily need to know about the ultimate GPU hardware. They can talk to the hypervisor, the hypervisor talks to Metal or whatever. Hypervisors can also emulate widely-supported hardware so guest OSs can use their built-in drivers. AFAIK the guest-side graphics drivers in Parallels are written by Parallels, for example. Not saying that's the only way of doing it, but at worst it's a way of doing it without Apple.

For direct boot, that's not an option.

Anyway, it makes no practical difference whether Apple writes the drivers or gives Microsoft the information they need to write the drivers, or gives them the MacOS driver source to port... or whatever.

The licensing issue isn't as simple to resolve as you claim, especially since Microsoft would have to first alter their existing licensing agreements for WoA before Apple could even begin to work on virtualization of the OS.

I really don't know what your point is here. It's still licensing - not a technical issue. Licensing operating systems to hardware makers is what Microsoft does, even with WoA. MS don't even have to make a shrink-wrapped public version of WoA if that's the sticking point - they could do a deal with Apple or Parallels to bundle it with a hypervisor (like the SoftWindows 95 emulator on the PPC). For all we know it is already agreed - Apple, Microsoft and Parallels all have reasons to make it work. The material issue is really how much work WoA needs to cope with any differences between Apple Silicon and generic ARM - which is an unknown somewhere between 'some' or 'lots' (unless there are Apple or MS employees here who don't like their jobs).

 

[theluggage]

There are two completely different platforms with differing use cases and form factors at play here, which is why your repeated attempts to equate the two platforms is a futile attempt.

...of course there are some iOS Apps that make zero sense unless they are literally on a phone. That's not at issue.

There are also plenty of iOS Apps that would make sense on an ultraportable laptop but for the fact that they're designed for touchscreen use. Gesture-based games, freehand drawing/sketching apps, quite a lot of music programs that use multi touch... Imagine using Logic Pro Remote on a touchscreen right in front of you with the main software running on a second large display. That's apart from the way that all iOS Apps were primarily designed to be used at reading distance with a touch screen.

Even Catalyst won't make a handwriting or art app that makes good use of Pencil work on a Mac that doesn't have Pencil...

You keep throwing the word "merge" around as if Apple is planning to formally merge iOS (or iPadOS) and MacOS into a unified operating system.

If you're saying that "merge" should mean "formally merge iOS and MacOS into a unified operating system" I wouldn't argue with that. It's not what I've been proposing I don't even remember who first used the word. Oh wait.

I don't see Apple reversing course within four months of WWDC and suddenly deciding to merge the iMac and iPad Pro lines,

Which was actually reasonable since you were referring to the original poster's slightly silly suggestion about a "giant iPad running iPadOS magsafed to the stand" - and I quite agree that Apple aren't going to do that after what was said at WWDC.

All I've been suggesting was that there was now an argument for making some sort of 2-in-one Mac with a touchscreen given the established fact that MacOS is suddenly going to inherit a shedload of existing apps from iOS that would be nicer to use on a touch screen. An iPad-like unit on a magnetic stand that could be detached or pivoted and used in "large-format tablet" or "easel" (depending on its size) is a possible solution - as is a 2-in-one style laptop.

That does not involve "formally merging iOS and MacOS into a unified operating system" except that for certain people the meaning of "merge" now seems to alternate between "adding any iOS features whatsoever to MacOS which Apple have pinky-promised they won't do" and "formerly merging iOS and MacOS" whenever I point out all iOS features that have shown up in MacOS. I'm happy to dump the word. The etymology of "merge" is not the point I am trying to make. The point is that, regardless of what Apple might have said about "merging" or Catalyst a bunch of iOS features have been incorporated into MacOS (and a few the other way) culminating in the ability to run "most" iOS Apps unmodified.