A prerequisite being a shiny new ARM based Mac?
Not really. Supporting multiple CPU architectures is probably the easiest part of trying to create a universal API. Apple has enough experience with fat binaries at this point that a developer can upload bitcode, and Mac users will get x64 binaries, and iOS users will get Arm64.
i don’t see how it can be done right. For years we’ve been told that OSX/macOS is not designed for touch. That is still true.
Having universal apps is going to impact either the touch end on ios or the desktop style on macos. A compromise is going to be made one way or another.
It isn’t easy, and I do suspect there will be some sort of compromise if they are serious about it.
The real challenge is AppKit vs UIKit. Most of the lower level stuff like Core<Whatever> and <Whatever>Foundation are already shared. Which has been making supporting both iOS and Mac easier. But AppKit was built in the NeXTStep era. The public API assumes certain things about a windowed, desktop environment that UIKit doesn’t. It exposes lower level event handling than UIKit does. UIKit is built with the assumption of CoreAnimation and hardware acceleration for 2D operations. The types of view hierarchies you build with the two are different, if similar.
If they want to build a universal framework, this dichotomy that exists must be reconciled. It isn’t impossible, but it poses some challenges:
- AppKit or UIKit must be deprecated, as you need to merge the two somehow, and it won’t be in a backwards compatible way. In this case, I see AppKit being the one on the chopping block, with UIKit picking up the functionality required to handle desktop machines (Menu bar handling, etc).
- Input handling needs to be reconciled, as UIKit provides input at a much higher level than AppKit. In AppKit, I can get access to raw key/mouse events, but UIKit is more siloed. This makes it a bit easier for UIKit to enable new input modes while hiding them from the developer (software vs hardware keyboards, pencil vs finger input), but doesn’t completely hide the need to do work for some forms of input: shortcuts for hardware keyboards, sensor input for pencil, right click for mice. And this will have a tendency to skew towards the minimum in many apps, especially cheap ones (which is most of them). Menu Bars may likely become less useful in universal apps, if they are focused on iOS users more, as another example, due to lack of effort and interest.
- Developers on the deprecated API are looking at something akin to a minor rewrite of their UI code to jump over to the updated API. And they will find that not everything they could do in the old API is available on the new one, for the sake of cross-plat consistency. So there will be those saying they have been abandoned because the new API can’t do X, and for the sake of consistency, the new API may never be able to do X, making it a complaint that won’t be solved. (See how UWP has had multiple iterations already since Win 8 attempting to entice users onto new APIs, only to see it fail in many ways in Pro apps)
I actually think it is possible to take UIKit and make a modern macOS app framework out of it. It is already a more modern version of AppKit in the core ways, and has been picking up macOS features to support new things (auto layout for split screen and multiple screen sizes). But the work in front of a project like this is how to make it easy to handle the myriad of inputs between the two platforms, and how to handle single window vs multiwindow applications. And getting devs onto the new API set on one of those platforms. Something Microsoft has demonstrated isn’t as simple as it sounds, since they’ve been at it for nearly a decade with limited success. I’d argue that Microsoft made a lot of mis-steps in their effort that Apple can avoid, but the proof is in the pudding here. Either Apple solves the carrot/stick issues for devs, or they don’t. Won’t know until we see what form such a framework takes, and devs get a chance to react to it.
