SwiftUI and Catalyst: Apple executes its invisible transition strategy

https://www.macworld.com/article/3402057/swiftui-and-catalyst-apple-executes-its-invisible-transition-strategy.html

by colinprince • 7 years ago

164 147 7 years ago

atonse4• 7 years ago

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.

DC-3• 7 years ago

Apple benefits from having higher average quality of developers in its ecosystem

How can you conclude this with any sort of certainty?

atonse4• 7 years ago

I have no empirical evidence for this of course, because there's no way to really measure this, AND it's getting more moot because of things like Electron.

But you can infer it historically by a few observations:

- More people intentionally get into mac software, than back themselves into it because it was for a job (like Windows/.NET development). So there's a quality vs quantity argument there.

- Just use independent windows applications vs mac applications. There's almost always a much higher level of fit and finish on the Mac side.

- Judging by how quickly a lot of iOS apps start to adopt newer frameworks and technologies

pjc503• 7 years ago

Apple benefits from not being in "Enterprise".

Enterprise is where you have average developers with mediocre managers and ill-formed specifications working to inadequate (but overrunning) budgets. Something gets nailed together to support the business, and once it's working you're never allowed to touch it again. The king of this kind of line-of-business app used to be VB6. There was a brief phase were people wrote intranet applications with embedded ActiveX controls and got permanently stuck on IE6. These days it's more likely to involve SAP or Sharepoint.

These customers made Microsoft a lot of money from all those desktops and Windows Server client access licenses, but they're extremely conservative.

And maybe they have a point; I can see what the advantage of UWP is for Microsoft, but as a developer it's not a clear win over WinForms.

atonse4• 7 years ago

Although I have to say, VB6 was AWESOME in the late 90s. :)

module00002• 7 years ago

The king of this kind of line-of-business app used to be VB6.

You say that like it's not still happening... VB6 is still the go-to tool at a certain blue cross and blue shield franchise - and probably at many others around the country. They post jobs(active postings right now) for .NET developers with VB6 experience. They do it under the guise to "help port existing applications", but in reality they are still developing new features with it, and will likely never stop.

derefr6• 7 years ago

as a developer it’s not a clear win over WinForms

Can you put a WinForms app into the Microsoft Store? UWP apps having a marketplace to sell them is kind of a point in their favour, even if it’s an entirely-artificial restriction Microsoft made up to push UWP.

addicted3• 7 years ago

Seriously. The true geniuses are the non enterprise startup developers developing in JavaScript.

Wait what...

Edit: There’s nothing wrong with being a JS developer. Heck, my main job is JS. My point is the choice of language hardly determines what kind of developer you are. I’ve seen great developers working on VBA and I’ve seen shitty developers working on C/C++ and Java.

To play devils advocate, I don’t think there are too many terrible developers working on Haskell and Rust though. Yet.

kelnos• 7 years ago

ill-formed specifications working to inadequate (but overrunning) budgets. Something gets nailed together to support the business, and once it's working you're never allowed to touch it again.

That sounds like a small startup, too.

(I won't speak to the "average developers" and "mediocre managers" bit, though I assure you they're not unique to big enterprises.)

jasonlhy• 7 years ago

I absolutely agree on you, the entry level of Windows developer used to be lower than other developers. People use visual studio to drag and drop the controls, glue the code all together. You don’t need to type command, you don’t need to understand how the things work behind.

This may be ok for a junior position, and in closed environment. However, people are lazy and not all people are hard core. As a result, there are a lot .NET senior who don’t actually “know” how to code. Nowadays things become extremely complicated, all sort of API, library and framework. Even Microsoft can’t provide a completed solution, and it go back to command line approach with .NET core. I have been recently contacted by my ex-employee who want me to do some C# API communication freelance because their .NET developers just don’t know how to read the documentation and implement them in code.

derefr6• 7 years ago

I'm not even sure what's the "modern" way anymore to build Windows apps – is it UWP? WinForms? something else?

I feel like Microsoft has made this intentionally obscure because their business model requires that they talk out of both sides of their mouth: they want enterprises building their line-of-business CRUD apps to feel confident and secure in using older APIs like WinForms, by telling them that they’re using first-class APIs that will be supported in the long term, and aren’t being deprecated just because there are other, newer APIs; and, at the same time, they want developers coming into the ecosystem fresh to find UWP first, so that UWP apps get built and make Windows tablet usage easier/better.

scarface746• 7 years ago

Whether there are a lot of Indy developers on the Mac doesn’t matter. If Microsoft’s and Adobe’s software don’t run on a new Mac platform, it’s a non starter.

You saw that in each transition:

68K -> PPC -> Intel

And

Classic MacOS -> Carbon -> Cocoa -> 32 bit -> 64 bit

CharlesW2• 7 years ago

You saw that in each transition:

No, those transitions started (and became sure things) long before there was any commitment from "A-list" developers to support them. Getting commitment was an orthogonal task, and itself took significant technical and relationship work from both Apple and the developers. (Note: I was in developer relations for a few of these transitions.)

Whether there are a lot of Indy developers on the Mac doesn’t matter.

Indie developers matter, not least of which because they're typically the first to adopt new Apple-only technologies.

tonyedgecombe3• 7 years ago

Frameworks I have used for UI work on Windows include MFC, ATL, WTL, WinForms, WPF, UWP and pure win32. After a while you kind of get burnt out on the never ending changes.

Apple might force you along but they seem to have fewer transitions overall and a much clearer strategy.

frou_dh• 7 years ago

I feel like I hit the sweet spot by only ever using WinForms, then getting out.

Their framework strife seems like a manifestation of their depiction in this classic: http://bonkersworld.net/organizational-charts

sorenjan• 7 years ago

Is WPF still a good option? It looked like Microsoft put a lot of weight behind that for a while, they even made parts of Visual Studio in it. But I haven't heard anything about it for years, I guess it got replaced by UWP? Does UWP use XAML too?

FpUser3• 7 years ago

That is exactly why I use Delphi when doing GUI apps on Windows. Single GUI framework that works like a charm for more then 20 years. It is very unfashionable to say mildly but it is the fastest tool to get things done for Windows GUI apps.

OldSchoolJohnny• 7 years ago

"Apple benefits from having higher average quality of developers in its ecosystem"

What?! How on earth do you come to that conclusion?

wvenable5• 7 years ago

Mac OS X wasn't originally planned to have Carbon. Adobe basically told them there is no way they are completely re-writing all their apps for OS X. So Apple took another year, added Carbon, and Adobe ported Photoshop over.

Apple doesn't benefit from higher average quality of developers; they just benefited from having much fewer of them to support. The long tail of Windows is really really long -- businesses run on multi-million dollar software packages designed in the 90's. Apple has no such ecosystem.

The big ecosystem they do have (iOS apps) is very different and far more forgiving. There are thousands of unmaintained iOS apps that simply don't work anymore but they only cost $1.

saurik• 7 years ago

While I agree with your premise (that Apple's lack of care or rigour for platforms likely stems mostly from having very few people to support), the specific story being provided for Carbon doesn't fit the history to me given that not only was iTunes written with Carbon (and was a holdout in switching to AppKit for a lot longer than Adobe), but so was Finder (a core piece of OS X, and that didn't transition until 10.6).

threeseed2• 7 years ago

Actually the number of unmaintained apps is relatively tiny.

The reason being that Apple routinely forces developers to update their apps if they want to stay on the store.

pwinnski• 7 years ago

I think the difference is in the second step. Both companies excel in moving the target forward, but Microsoft rarely, if ever, shuts off access to the old targets, maintaining compatibility essentially forever, which keeps them from ever being able to make major transitions.

There are any number of ways to develop for Windows, and the fact that many, even most developers use Visual Studio is different from the Apple approach: everybody must use Xcode. This sucks for companies like MetroWerks that once developed a popular IDE for MacOS only to be shut out, but it's necessary to ensure that the tail end of the migration, that pesky step 2 of shutting things off, happens.

bluedino• 7 years ago

Microsoft never shuts off the old targets because otherwise nobody would ever upgrade to the next version of Windows

brantonb• 7 years ago

I’m an iOS developer and I use AppCode as my primary IDE. It does have a dependency on Xcode, so it has to be installed.

addicted3• 7 years ago

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.

kitsunesoba2• 7 years ago

Branding is far more important for dev tools than many realize. They’re just as much of a product as iPhones and Surfaces are but this has yet to register with the eng teams of a lot of companies.

chenster4• 7 years ago

I will counter argue the imputation of misnaming with the auto industry examples that the Japanese cars with catchy and sexy names such as Toyota Camry, Honda Clarity, Nissan Rogue; whereas the German counterpart with unimaginative M-Benz c300, e550; BMW i300, i3, i8... and yet German cars sales remain strong

mattlondon2• 7 years ago

I don't see how SwiftUI/SUI is any different from UWP?

I guess beauty is in the eye of the beholder.

I do agree though with the .NET stuff - I have been out of the ecosystem for a while and have no idea what is going on any more.

r00fus3• 7 years ago

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.

There is a thought here: when something is well designed (including branding), it's possibly attributable to a better process used to create the product as a whole (in this case the frameworks and API).

I've worked at places where acronyms are rife, and they're usually places that didn't feel the product needed to be sold (possibly because they didn't think they had any competition).

Other places I've worked where we actually pitched/sold the product (either internally or externally) resulted in a lot more overall thought about what the product did and how the customer would use it and consequently the naming.

pjc503• 7 years ago

Oh god yes. It's absurdly confusing. Not to mention "Windows 10 IoT Enterprise" versus "Windows 10 IoT" - the former is minified real x86 Windows, the latter is the CE successor and runs on the Raspberry Pi.

FridgeSeal2• 7 years ago

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.

astrange3• 7 years ago

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

I mean the pun is obvious, but a swift is a kind of bird.

I specifically think it's a bad idea to name things "fast", because history will catch up to you and it might not be fast anymore, or it might be unsafe - and then what will you call the next thing?

Actually, this happened in Swift. -Ounchecked (no bounds checks) was originally "-Ofast", but thankfully they changed it.

MR4D• 7 years ago

Apple is better about clarity (or, being dogmatic if you prefer that view).

You are right, MSFT has done a great job, but they made enough of a mess in the '00's that they kicked out their CEO and put in Nadella.

Thankfully, Nadella seems to understand the importance of making things clear to make things simple for people. I hope to see that continue. Microsoft of the 90's still seems a long time ago (but sure looks like Apple today!)

Developer quality of MSFT in the 90's and AAPL today is probably a wash (except for that everyone has been around computers for years now - that wasn't true in the 90's).

jxdxbx• 7 years ago

The modern way to write Windows apps is Win32 again.

FpUser3• 7 years ago

LOL. I never really strayed from this one on Windows. Everything else came with big limitations on what one can do.

gdubs2• 7 years ago

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• 7 years ago

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.

gdubs2• 7 years ago

Correct, within the Apple ecosystem — Mac, iOS.

nvrspyx• 7 years ago

He probably means in the way that Apple means it with SwiftUI and Catalyst. Cross-platform = Apple devices (i.e. macOS, iOS, iPadOS, watchOS, tvOS)

jayd16• 7 years ago

There's far more to building a cross platform app than making sure the UI fits on both screens. I might have missed it but does Apple plan to consolidate things like file system, networking, installation lifecycle, and notifications?

ajconway• 7 years ago

The core APIs are the same, so you get most things for free — file system, networking, media recording/playback, graphics, and more. Installation takes place before the app gets to run any code. Notifications are similar enough to be hidden under a tiny abstraction (macOS even supports Push notifications, although I’m not aware of any app that uses them). Really, UI was the only area where you could feel like you’re developing for different operating systems.

mattlondon2• 7 years ago

How does SwiftUI help for other platforms? Genuinely curious if this will work on Windows, Linux & Android too? So far it looks like it is entirely targeted at the mac ecosystem (aka we-want-all-our-software-to-look-like-iOS ecosystem)

bobbylarrybobby• 7 years ago

SwiftUI is just one instance of a new feature in Swift called function builders that allows creating custom DSLs within Swift. As Swift’s cross-platform support grows, two things can happen: SwiftUI can be customized go work with the GUI toolkits of other systems, and other system-specific DSLs can be developed to take advantage of each system’s own unique capabilities and APIs.

throwaway34927• 7 years ago

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.

scarface746• 7 years ago

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• 7 years ago

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.

macintux• 7 years ago

The transition to PowerPC only worked, as I recall, because Metrowerks wrote a compiler to handle the heavy lifting.

gok2• 7 years ago

ObjC Garbage Collection comes to mind.

spinningslate2• 7 years ago

[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.

eridius2• 7 years ago

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.

spinningslate2• 7 years ago

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.

dwaite• 7 years ago

Where Apple says something is an OS, they really mean it as a distinct user experience.

They want to make the infrastructure that applications rely on as similar as possible, including UI efforts like Catalyst and SwiftUI. But at the same time, they know that the user interface on a iPhone is fundamentally different than what is shown on a TV. They added Xbox/dualshock controller support specifically for tvOS - but wound up adding it to iPhone and iPad since they were really adding to the underlying platform.

thought_alarm• 7 years ago

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• 7 years ago

Carbon.

diesal11• 7 years ago

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.

tinus_hn5• 7 years ago

I would say the invisible strategy here is to move away and ultimately deprecate AppKit because it carries decades of legacy compatibility and is limited by being bound to Objective C, while clearly Apples vision is that the future is Swift.

SwiftUI and Catalyst: Apple executes its invisible transition strategy

Related Stories