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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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).
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
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.
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.
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?
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)
> [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.
> 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.
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.
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.
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.
[+] [-] thought_alarm|6 years ago|reply
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.
[+] [-] tinus_hn|6 years ago|reply
[+] [-] setpatchaddress|6 years ago|reply
[+] [-] atonse|6 years ago|reply
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.
[+] [-] pjc50|6 years ago|reply
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.
[+] [-] addicted|6 years ago|reply
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.
[+] [-] derefr|6 years ago|reply
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.
[+] [-] wvenable|6 years ago|reply
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.
[+] [-] DC-3|6 years ago|reply
How can you conclude this with any sort of certainty?
[+] [-] tonyedgecombe|6 years ago|reply
Apple might force you along but they seem to have fewer transitions overall and a much clearer strategy.
[+] [-] OldSchoolJohnny|6 years ago|reply
What?! How on earth do you come to that conclusion?
[+] [-] pwinnski|6 years ago|reply
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.
[+] [-] MR4D|6 years ago|reply
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|6 years ago|reply
[+] [-] scarface74|6 years ago|reply
You saw that in each transition:
68K -> PPC -> Intel
And
Classic MacOS -> Carbon -> Cocoa -> 32 bit -> 64 bit
[+] [-] gdubs|6 years ago|reply
[+] [-] vardump|6 years ago|reply
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.
[+] [-] jayd16|6 years ago|reply
[+] [-] mattlondon|6 years ago|reply
[+] [-] spinningslate|6 years ago|reply
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|6 years ago|reply
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.
[+] [-] dwaite|6 years ago|reply
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.
[+] [-] throwaway34927|6 years ago|reply
[+] [-] scarface74|6 years ago|reply