
SwiftUI and Catalyst: Apple executes its invisible transition strategy - colinprince
https://www.macworld.com/article/3402057/swiftui-and-catalyst-apple-executes-its-invisible-transition-strategy.html
======
thought_alarm
There is a disconnect between what Apple's engineers say vs. what the Apple
pundits at large think, and that disconnect is fucking gigantic.

Apple has never described Swift, Catalyst, or SwiftUI as a transition from or
to anything. Instead, Apple has gone out of its way to say that these are
_not_ transitions. Remember that big "NO" slide from last year?

When a transition is required, Apple does not ever hide it.

Classic Mac to OS X was a transition.

PPC to Intel was a transition.

UIWebView to WKWebView is a transition.

SwiftUI is no more a transition from AppKit/UIKit than Storyboards were a
transition from NIBs and programmatic UI.

Modern ObjC syntax, Enterprise Objects, Java/Cocoa Bridge, Ruby/Cocoa,
Python/Cocoa, Key-Value Observing/Encoding, ObjC Garbage Collection, ARC,
Storyboards, Playgrounds, Swift, SwiftUI, etc. These are not transitions.
These are all just tools in the toolbox. Some more useful than others.

The only thing Apple's engineers are trying to do here is create stuff that
developers find useful. There is no hidden or invisible strategy with this
stuff.

~~~
setpatchaddress
Carbon.

~~~
diesal11
Has been deprecated since 10.8 (2012) and was never ported to 64 Bit. It was
pretty clear they weren't working on a Carbon replacement imo.

~~~
stefanfisk
True, but the official deprecation was quite sudden, and anyone using at the
time and who expected Apple to be open and sensible about their API direction
was caught quite off guard.

------
atonse
I largely agree, although disagree about the point that this is unique to
Apple.

I think Microsoft also does quite a good job of maintaining compatibility and
slowly bringing people forward (to the point where it's often used as a
negative argument). As an outsider, the whole UWP thing felt like a bit of a
mess, so I'm not even sure what's the "modern" way anymore to build Windows
apps – is it UWP? WinForms? something else?

Apple benefits from having higher average quality of developers in its
ecosystem, which allows them to sunset things faster than, say someone like
Microsoft, who has to keep things backwards compatible for a decade+. While
there are larger applications (Adobe Suite) that dragged their heels on the
move from Carbon to Cocoa, a lot of software on macOS/iOS is written by
independent developers who do tend more to keep up with the latest frameworks.

~~~
addicted
Having been through the whole .Net Framework -> .Net Core processs, I think
one of the biggest problems with MS is that they just have pathetic naming.

Apple creates these new names that are unique, exciting, and evoke something
concrete. It makes it easier to remember what they mean when they’re talking
about something. So for example, their new UI framework is called SwiftUI
which builds off the swift legacy and logo and the emotion of being faster
therefore better, whereas MS’s was UWP. WTF is UWP supposed to evoke. How am I
supposed to mentally associate that with something.

And the .Net stuff was otherworldly. You had .Net Core, .Net framework, and
.Net standard. Other than Core, neither of the other have any unique meanings.
All the 3 are frameworks and standards. Or strongly associated with frameworks
and standards. 2 of them are technologies, and one is just a document, but
they all sound the same.

.Net core sounds like it should be a subset of the other stuff, yet it’s the
future. If it wasn’t MS who invented .Net Core, they may have given it a
different name, say, I don’t know, Mono, and it wouldn’t confuse the crap out
of people. They would need to be told it’s a ground up rewritten open source
implementation of the .Net Framework which will eventually supersede it once
and they would not get confused again.

~~~
FridgeSeal
Oh my god yes Microsoft’s naming conventions are mind boggling.

.Net Standard, .Net Framework, .Net Core, and they all do slightly different
things, and they seemingly change with version, and now there’s .Net Framework
5, which apparently replaces/unifies some of them but it’s not super clear.
Then you’ve got C# and F# and the specific language versions of those. Oh
also, don’t forget the fact that there’s inexplicably like, 3 different
package managers, which may or may not pull from the same place and it’s not
clear what the differences are.

Coming from Python (and a little bit of Rust) I had literally no idea what was
going on. I tried to learn C# twice and gave up out of sheer irritation and
confusion.

~~~
thrower123
Is there a third package manager now? There's the blessed one, NuGet, which
most use, and Paket, which the cool kids and F# people use, but if there's
another one out there I'm drawing a blank.

~~~
FridgeSeal
You can use the CLI as to do stuff. Not sure if it counts as package manager,
but coming from Python, being faced with 3 different ways to install packages
(I'm still not sure how environments/projects are supposed to work in .Net)
certainly added to the confusion.

------
gdubs
SwiftUI looks like it can bridge that final gap I’ve had with my Metal and
SpriteKit projects, which were _almost_ entirely cross platform. There will
still likely be distinctions in touch handling vs mouse — I haven’t had time
to fully explore SwiftUI yet — but I’m looking forward to simplifying the code
even further.

~~~
vardump
> which were almost entirely cross platform...

Cross-platform Metal and SpriteKit? Wouldn't it be better to code against
Vulkan (== MoltenVK) or OpenGL if being cross platform is the goal?

Or do you mean "cross platform" as for example Microsoft has often done.
Within _their_ platforms.

Current difficulty of developing native cross platform projects is depressing.
You have to use domain specific tools like Unity, React Native, etc. Or just
target the web browsers.

~~~
gdubs
Correct, within the Apple ecosystem — Mac, iOS.

~~~
josteink
So not so much cross platform as it’s commonly used, but rather multi-
targeting within the Apple-platform.

~~~
fastball
Mac OS / iOS / tvOS / WatchOS are certainly different platforms. The iPhone
and the Mac are very different products with very different use cases, so of
course they are different platforms.

It's not "all-platform", but this is definitely "cross-platform".

------
spinningslate
> [Catalyst/SwiftUI] provides iOS developers with a familiar set of tools and
> access to an entirely new platform

Rather think that's the wrong way round. Whilst it might be true in the short
term, it's really part of the MacBook/MacOS obsolescence plan. The next
generation of MacBooks - whatever they're called - will be an evolution of
ipad, using ARM hardware and running an iOS-derived OS. The recent creation of
ipadOS is another symptom of that transition.

Not that it changes the central thrust of the piece: that Apple does slow,
sustained, steady evolution well. But Catalyst/Swift aren't primarily about
giving developers access to an extra platform; it's to make sure there's a
ready-made market of apps and developers when the macbook range as we know it
goes away.

~~~
eridius
> _The next generation of MacBooks - whatever they 're called - will be an
> evolution of ipad, using ARM hardware and running an iOS-derived OS._

No they won't. I mean, it's conceivable that they could be using ARM chips
(though Apple would need a strategy for emulating x86_64 in this case, like
they did for PowerPC->i386), but there's no way they're going to be running
iOS.

Apple is slowly expanding the capabilities of the iPad, that's certainly true,
but it's not even close to replacing a laptop for all tasks. iPads are
becoming usable for more and more tasks, but there's a very long way to go
before the laptop is obsolete, and I don't expect iPad to ever actually go
that far (if it did, it would just end up being a laptop). Even given laptop
hardware, iOS is not set up to be able to replace macOS for all tasks.

Even ignoring all that, Catalyst is if anything evidence to the contrary, that
Apple sees macOS as being very much alive and wants to encourage more apps to
be developed for it. Catalyst isn't _just_ iOS apps on macOS, it's also tools
to extend your iOS codebase to adopt macOS-specific features, like multiple
overlapping windows of arbitrary sizes, menu bars, a mouse¹, titlebar
controls, and more.

¹I know iOS 13 now supports using a mouse on iPadOS, but it's just an
accessibility feature that looks to the app like a touch, it doesn't e.g.
support hover states, or encourage smaller click targets, or anything like
that.

~~~
spinningslate
>No they won't. I mean, it's conceivable that they could be using ARM chips
(though Apple would need a strategy for emulating x86_64 in this case, like
they did for PowerPC->i386)

Exactly. Apple has proven it can do emulation very successfully - it's already
done it twice (M68K->PPC->x86)

> there's no way they're going to be running iOS

I didn't say "running iOS", I said "an iOS-derived OS".

>Catalyst is if anything evidence to the contrary, that Apple sees macOS as
being very much alive and wants to encourage more apps to be developed for it.

That's the other interpretation. I don't see it personally: the central thrust
of the article is that Apple is really good at gentle evolution. MacOS has
seen no meaningful innovation in years. iOS, by comparison, has evolved
significantly. It's been steadily gaining more features that move it towards
being a laptop-capable OS (e.g. multi-tasking). It's certainly not there yet -
but that's the trajectory.

To be clear, when I said "next generation macbooks" I didn't mean "next
revision". It's probably several revisions away and it'll happen
incrementally.

Still, of course, it's just opinion :). Thanks for sharing yours.

~~~
eridius
If iOS gains enough features to replace macOS, then it will just be macOS
again. iOS is gaining new features, but it's still a rather constrained and
touch-focused environment. For example, you can do split-screen on iPadOS, but
you can't do arbitrary overlapping windows. Instead they're focusing on ways
to save "scenes" and switch between apps, but each app still owns the portion
of the screen it's been given (and those portions are very constrained; full-
size, half, 1/3rd, or a slightly shorter 1/3rd in a slide-over; and the 1/3rd
size is literally supposed to be your iPhone UI). They added mouse to iPadOS
but strictly as an accessibility feature, and apps can't even detect that the
mouse is there, let alone add mouse-related functionality. The file system is
still heavily locked down. There's still no process spawning or any indication
that Apple will ever allow process spawning (which is a hard blocker for a lot
of developer tools). iPads support external screens, but not as the primary
display (that's basically just for projecting stuff, e.g. presentations or
photos).

Ultimately, there's no point in relaxing these restrictions for an "iOS-
derived" laptop OS. The primary argument in favor of unifying macOS and iOS
was the fact that iOS has a lot of developer momentum and that way you can use
iOS apps on macOS, but that's exactly what Catalyst gives us already. Apple is
working towards unifying stuff at the developer API level (e.g. Catalyst,
SwiftUI, etc) but at the OS level macOS and iOS are quite distinct and will
stay that way.

------
throwaway34927
TLDR: over time, Apple transitions from one technology/development platform to
another. author calls this an "invisible" strategy because... it's done
properly and methodically.

~~~
scarface74
I can’t think of a single transition that Apple botched. They even had a good
transition strategy from the Apple //e to Mac for users with the //e card.

~~~
ken
Apple II->III? Mac->Copland? Mac->Taligent? Apple IIgs->Mac?
HyperCard->(nothing)? Carbon 32b->64b (as originally promised)? FCP 7->X?
iMovie HD->08? iWork '09->2013? Mac Pro 2012->2013->2019?

It depends on your definition of "botched", but I can think of lots of
examples of cases where Apple either gave up, or essentially reverted their
changes, in the face of public outcry or technical hurdles.

I wouldn't really call the IIe card a "transition strategy", either, any more
than Mac86 was. It was a kluge to add another entire computer as an add-on
card. It didn't help move your programs or data at all. It also only emulated
a IIe (8 years old at that point), not a IIgs (only 5 years old). It was only
a 'transition' for the absolute penny-pinching-est buyers, i.e., education.

~~~
inspector-g
Some of your examples are pertinent, but I think calling MacOS->Copland,
MacOS->Taligent, HyperCard->(nothing) "botched transitions" is a bit
disingenuous.

Copland never shipped, and as such was not a transition at all, because the
public was not directly involved in the internal failure. Taligent basically
never shipped anything, and so the same argument applies.

The replacement OS that Apple _actually_ shipped (OS X) aided a legacy
transition that I think went down basically as well as it possibly could have
(given the inherent dissimilarities between the two OSes).

HyperCard was merely killed off, so there was clearly no transition at all.
That's like saying Newton->(nothing) failed as a transition.

