The Shape of Everything
A website mostly about Mac stuff, written by August "Gus" Mueller
» Acorn
» Retrobatch
» Mastodon
» Instagram
» Github
» Maybe Pizza?
» Archives
» Feed
» Micro feed
June 26, 2018

Jason Snell and Myke Hurley on the Upgrade Podcast #198: The Mac Is Dead, Long Live the Mac:

"Apple has said that it’s not merging iOS and macOS, but that sneak peek of iOS apps coming to macOS opens up a lot of questions about just what the Mac might look like in five years. Jason’s optimistic, but Mac users may be in for the biggest changes to the platform since the introduction of Mac OS X nearly two decades ago."

It's an interesting discussion, and I really do hope we see things from iOS move to the Mac, touch and Pencil support in particular. And the idea that "folks don't want to use touch on the Mac" is pretty dumb when you realize Apple sells a hardware keyboard for the iPad which works exactly the same way as a touch Mac would.

There are a couple of things that I was surprised the discussion didn't cover though. And what follows below are my half baked thoughts on what those are.

OpenGL and OpenCL were deprecated this past year, but Apple can't really get rid of those frameworks anytime soon because of legacy apps that aren't going to be updated to use Metal. It's a tough spot to be in.

Apple has dropped legacy frameworks very easily in the past though. But how exactly did that happen?

CPU changes. Once when MacOS went from PPC to Intel, and then once when MacOS went from 32 bit to 64 bit. Each time that transition happened Apple was able to say "OK, this legacy stuff just isn't going to be there on the new architecture". And since you had to recompile apps anyway to make them run on the new architecture, developers kind of shrugged and said "Well, yea. That's what I would have done too". It made sense.

So are we about to see 128 bit Intel processors anytime soon, to facilitate this change? I doubt it.

OK then, what about a new architecture?

Oh. Hello 64 bit ARM.

OK, so now we've got a new processor architecture for the Mac and now we need apps recompiled for them. Nimble indie shops and apps like Acorn and Retrobatch would most be certainly there on day one (just like we were for PPC to Intel and 64 bit), but then you've got the giants like MS and Adobe who usually have to be dragged kicking and screaming into the future. What's Apple to do about them?

Well, what if they made it easier for other apps to possibly take their place or at least fill in the gaps until the giants can ship something? Where can we find a billion other developers that already have a codebase that's ready to be compiled on another architecture, because they don't have decades of legacy code to clean up?

And if you look at from this angle, UIKit for MacOS makes perfect sense. Even if it's only to potentially help with a transition, that may or not actually happen. It gives Apple leverage.

And since UIKit on the Mac has already existed for years (presently contained in the iOS simulator), it's probably not as big of an investment on Apple's part as you'd think it would be. For sure, AppKit engineers have performed heroics to make it work as well as it does- but it's not like UIView wasn't already compiling on 64 bit Intel processors. It's there today. It was there 10 years ago.

This could go completely off the rails too.

What if MacOS on ARM only ran these new UIKit apps?

That's a scary thought for this MacOS developer.

But then again, we already have this and it's called iOS on the iPad. And maybe, just maybe, and remember these are half baked thoughts, but maybe Apple is wondering if some Pro users might be better served by MacOS Touch 1.0 running on ARM.