Literally the only reason why it’s hard to make an app for iOS and Mac OS is because they’re using ARM vs X86 which complicates things. Having them all be on ARM just streamlines the process.
Having worked on projects that use a single code base for iOS and Mac... this
isn’t the truth of it.
The truth is more: it depends heavily on the project. The real hurdle that
all projects with a UI have to face if they want to support iOS and Mac from a single code base is AppKit vs UIKit. And this hurdle can easily dwarf the amount of effort dealing with architecture differences. Objective-C did a lot of the work to mask architecture differences back in the Intel switch, and the 64-bit switch.
AppKit comes from NeXT. UIKit is a modern re-imagining of AppKit for iOS. There’s a lot of controls that are similar, but have been re-written in UIKit, behaving differently than AppKit. UIKit reimagines what text input, “pointer input” and app shortcuts look like to the developer. AppKit (and the developer) can’t assume CoreAnimation is enabled like UIKit does. Put bluntly, migrating to UIKit from AppKit (or vice versa) can be considerable work, precisely because you can’t share a ton of logic between the two.
It’s why Apple has been putting effort in Catalyst and SwiftUI, because this is the big hurdle.
I think the aim in the next 10 years is to have one unified operating system across devices, from AirPods/Watch to Mac Pro. Likely will rebranded AppleOS. The aim is to simplify application development so extremely well that developers don’t have to think too hard about which hardware you are targeting. Right now, even if you are writing apps for iOS, its not relatively easy to target macOS or bring Mac idioms to your app. The aim for Apple is remove that barrier and it’s also to make development on their platform remain relevant and competitive with the web and technologies like electron.
I don’t agree with the rebranding, Apple has been going in the other direction. Attaching branding to different flavors of iOS left and right. And even iOS itself is a macOS fork that still shares a
lot of code with macOS. Apple has been spending a surprising amount of effort keeping the lower level APIs in sync between the two, and even some higher level ones like MapKit, WebKit, etc. When it comes to development, they are more alike than they are different.
I think it shows just how much work is wrapped up in AppKit, UIKit and WatchKit, and how much it dominates a developer’s effort that needs to go into an app. It’s interesting, really.
I do agree that they will continue to make bridging things easier though. And I think we’ve already seen the two thrusts:
1) Catalyst - UIKit on Mac. This seems aimed at folks who either skip Mac while shipping an iOS app, or use something like Electron on the Mac while doing something more native on iOS.
2) SwiftUI - A forward-looking replacement for AppKit/UIKit/WatchKit/TVMLKit. SwiftUI is
the way to build new widgets, letting you share so much more code between iOS and Mac. I really think this is where we are going to see Apple spend effort going forward when it comes to new UI things.
SwiftUI probably has the best chance at reconciling AppKit and UIKit. However, it can’t erase the different idioms completely. Instead we see that certain iOS or Mac features are simply not available (yet) in SwiftUI. Time will tell if Apple intends this to be lowest common denominator, or if they have a real plan for making SwiftUI into something I can use to adapt between the two platforms with flexibility and power.