11 ms·

SwiftUI and Catalyst: Apple executes its invisible transition strategy

164 points by colinprince 7y ago

atonse 7y 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 7y ago
  > Apple benefits from having higher average quality of developers in its ecosystem How can you conclude this with any sort of certainty?
  - atonse 7y 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
    - cwbrandsma 7y ago
      I'm an iOS developer, I've been coding the platform since iOS 3, and I'm a .Net developer coding in C# since Beta 1. Initially that argument was slightly true. But has long since passed and is completely bullshit now. As soon as it was apparent there was a goldmine in iOS development the floodgates opened wide. There is zero difference between the average Windows developer and the average iOS developer anymore, and there hasn't been since at least iOS 5. (most likely iOS 4)
      - derefr 7y ago
        Sure, iOS software has no bar. How about macOS software, though? Or tvOS, or watchOS? You know, the platforms that aren’t goldmines :)
        holy_city 7y ago
        MacOS apps are mostly made by cross-platform devs, and it's not exactly a great experience. Half the trouble is figuring out how to put something together that makes sense on both Windows and MacOS.
      - atonse 7y ago
        That's likely true for the long tail of mediocre developers (whereas there probably wasn't as much of a long tail before on the Mac side).
      - doomlaser 7y ago
        On the Mac, it's a bit different. Take a look a longtime Mac software boutiques like Panic and Rogue Amoeba.
        tonyedgecombe 7y ago
        It's interesting that I can't reel off Windows equivalents of those companies. Where are the companies that embrace the and celebrate the Windows platform like Panic or Omni Group?
- pjc50 7y 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.
  - atonse 7y ago
    Although I have to say, VB6 was AWESOME in the late 90s. :)
    - chenster 7y ago
      The same argument goes to Objective-C in the 80s :)
      - linuxlizard 7y ago
        And COBOL in the 60s. :-D
      - saagarjha 7y ago
        I still find writing Objective-C relatively enjoyable in this decade. It’s much nicer than C++, for example.
    - piggybox 7y ago
      VB6 was my first programming language and it was indeed awesome to open my eyes.
    - api 7y ago
      There are still no desktop rapid UI dev tools on par with VB6.
- derefr 7y 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.
- scarface74 7y 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
  - CharlesW 7y 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.
    - scarface74 7y ago
      No, those transitions started (and became sure things) long before there was any commitment from "A-list" developers to support them. The famous deal where Microsoft promised to keep bringing Office to the Mac for five years was in 1997. Those five years encompassed the classic MacOS to OS X transition. Apple’s five year roadmap was far from a secret to developers. The whole Carbon API for OS X was done after major developers insisted on it to bring their apps to OS X. Adobe and Microsoft committed to port their software to x86 when Apple announced the transition in 2005. Heck Microsoft was on stage committing to the Mac in 1984.
      - CharlesW 7y ago
        > The famous deal where Microsoft promised to keep bringing Office to the Mac for five years was in 1997. I believe you're conflating "Apple needing an Office story to sell to enterprise" with "Apple needing pre-commitment from Microsoft before implementing a hardware or OS transition". Those transitions would've happened regardless of whether we lost a few A-list developers. Apple did not ask permission from developers before deciding to advance their platform.
- tonyedgecombe 7y 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 7y 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 http://bonkersworld.net/organizational-charts
  - sorenjan 7y 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?
    - maxxxxx 7y ago
      UWP is getting better but last time I looked it still had some weird restrictions. For many things WPF is still your best bet because you can be pretty confident that you will be able to do what you need to do.
  - FpUser 7y 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.
    - Rusky 7y ago
      You could equally just pick one of the above commentor's list and use it for 20 years (minus a few for the relatively new ones). They all still work, whereas when Apple transitions they remove the old option.
- OldSchoolJohnny 7y ago
  "Apple benefits from having higher average quality of developers in its ecosystem" What?! How on earth do you come to that conclusion?
- wvenable 7y 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 7y 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).
    - kitsunesoba 7y ago
      QuickTime Player was Carbon for a long time, too, and if I recall correctly so was iMovie.
    - wvenable 7y ago
      It's in the Wikipedia article for Carbon: https://en.wikipedia.org/wiki/Carbon_(API) https://en.wikipedia.org/wiki/Carbon_(API) Apple's original plan was presented in 1997. Steve Jobs announced the "change of direction" in 1998. iTunes was released in 2001. NeXTStep (and thus OpenStep and Rhapsody) already had a file browser/desktop application unrelated to the Finder.
    - linguae 7y ago
      It is true that iTunes and Finder were written in Carbon, but it is also true that Apple's original plan was for Yellow Box (the OpenStep API that later became Carbon) to be the main API for developing programs under Rhapsody, which was essentially NeXT with Mac OS 8 theming and UI guidelines. Rumor has it that Adobe and Microsoft balked at the prospect of having to port their applications to Yellow Box (there was no guarantee in 1997 that Apple's purchase of NeXT would pay off), which led to Apple announcing its Mac OS X strategy during WWDC 1998, which included Carbon as a first-class API for the development of Mac OS X applications alongside Cocoa (Yellow Box). Regarding iTunes, one detail about Carbon that is sometimes forgotten is Carbon originally ran on Mac OS 8 and 9 to facilitate the transition to Mac OS X (https://en.wikipedia.org/wiki/Carbon_(API) https://en.wikipedia.org/wiki/Carbon_(API) ; to quote, "Carbon was introduced in incomplete form in 2000, as a shared library backward-compatible with 1997's Mac OS 8.1. This version allowed developers to port their code to Carbon without losing the ability for those programs to run on existing Mac OS machines.") Given that Mac OS 9 was still current when the first version of iTunes was released, it made sense for iTunes to be developed as a Carbon application (since Carbon applications can run on Mac OS 8 and 9 as well as Mac OS X) rather than as a Cocoa application (which can only run on Mac OS X).
- pwinnski 7y 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 7y ago
    Microsoft never shuts off the old targets because otherwise nobody would ever upgrade to the next version of Windows
  - brantonb 7y 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.
- addicted 7y 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.
  - kitsunesoba 7y 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.
    - mikece 7y ago
      Agreed...and with the luck of Microsoft in this department the one awesomely named product of the last 15 years -- Silverlight -- was doomed because it was too cool for Redmond. (That and Turtleneck Steve prohibited browser plugins on iOS.)
      - WorldMaker 7y ago
        The tech survived, the brand didn't. I wonder sometimes if the Windows Mobile team was correct and UWP should have just kept the Silverlight brand name even as the underlying tech shifted so much, because the outer XAML shell is still so similar at the end of the day.
- MR4D 7y 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 7y ago
  The modern way to write Windows apps is Win32 again.
  - FpUser 7y ago
    LOL. I never really strayed from this one on Windows. Everything else came with big limitations on what one can do.
gdubs 7y 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 7y 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.
  - gdubs 7y ago
    Correct, within the Apple ecosystem — Mac, iOS.
    - josteink 7y ago
      So not so much cross platform as it’s commonly used, but rather multi-targeting within the Apple-platform.
      - fastball 7y ago
        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".
  - nvrspyx 7y 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)
throwaway34927 7y 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.
- scarface74 7y 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 7y 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.
    - scarface74 7y ago
      The Apple III was backwards compatible with the Apple //. Copland and Taligent never shipped to developers or users so neither wasted time on it. I had an Apple //e card. Using the included software, you could setup a ProDOS partition on your hard drive, and copy files from the //e to the Mac. Apple bundled converters that you could use to convert AppleWorks documents to Mac app documents. Mac86 sucked but the DOS Compatibility Card for the PowerMac 6100/60 with a 486DX/2, a dedicated sound card, and the capability of adding 32MB of dedicated RAM was quite good until Windows 95 came out and it could only use 16 bit drivers. That was my second Mac.
    - inspector-g 7y ago
spinningslate 7y 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.
- eridius 7y 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.
  - spinningslate 7y 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.
thought_alarm 7y 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 7y ago
  Carbon.
  - diesal11 7y 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.
    - stefanfisk 7y ago
      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.
- tinus_hn 7y 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.

164 points by colinprince 7y 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 7y ago
> Apple benefits from having higher average quality of developers in its ecosystem How can you conclude this with any sort of certainty?
- atonse 7y 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
  - cwbrandsma 7y ago
    I'm an iOS developer, I've been coding the platform since iOS 3, and I'm a .Net developer coding in C# since Beta 1. Initially that argument was slightly true. But has long since passed and is completely bullshit now. As soon as it was apparent there was a goldmine in iOS development the floodgates opened wide. There is zero difference between the average Windows developer and the average iOS developer anymore, and there hasn't been since at least iOS 5. (most likely iOS 4)
    - derefr 7y ago
      Sure, iOS software has no bar. How about macOS software, though? Or tvOS, or watchOS? You know, the platforms that aren’t goldmines :)
      - holy_city 7y ago
        MacOS apps are mostly made by cross-platform devs, and it's not exactly a great experience. Half the trouble is figuring out how to put something together that makes sense on both Windows and MacOS.
    - atonse 7y ago
      That's likely true for the long tail of mediocre developers (whereas there probably wasn't as much of a long tail before on the Mac side).
    - doomlaser 7y ago
      On the Mac, it's a bit different. Take a look a longtime Mac software boutiques like Panic and Rogue Amoeba.
      - tonyedgecombe 7y ago
        It's interesting that I can't reel off Windows equivalents of those companies. Where are the companies that embrace the and celebrate the Windows platform like Panic or Omni Group?
pjc50 7y 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.
- atonse 7y ago
  Although I have to say, VB6 was AWESOME in the late 90s. :)
  - chenster 7y ago
    The same argument goes to Objective-C in the 80s :)
    - linuxlizard 7y ago
      And COBOL in the 60s. :-D
    - saagarjha 7y ago
      I still find writing Objective-C relatively enjoyable in this decade. It’s much nicer than C++, for example.
  - piggybox 7y ago
    VB6 was my first programming language and it was indeed awesome to open my eyes.
  - api 7y ago
    There are still no desktop rapid UI dev tools on par with VB6.
derefr 7y 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.
scarface74 7y 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
- CharlesW 7y 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.
  - scarface74 7y ago
    No, those transitions started (and became sure things) long before there was any commitment from "A-list" developers to support them. The famous deal where Microsoft promised to keep bringing Office to the Mac for five years was in 1997. Those five years encompassed the classic MacOS to OS X transition. Apple’s five year roadmap was far from a secret to developers. The whole Carbon API for OS X was done after major developers insisted on it to bring their apps to OS X. Adobe and Microsoft committed to port their software to x86 when Apple announced the transition in 2005. Heck Microsoft was on stage committing to the Mac in 1984.
    - CharlesW 7y ago
      > The famous deal where Microsoft promised to keep bringing Office to the Mac for five years was in 1997. I believe you're conflating "Apple needing an Office story to sell to enterprise" with "Apple needing pre-commitment from Microsoft before implementing a hardware or OS transition". Those transitions would've happened regardless of whether we lost a few A-list developers. Apple did not ask permission from developers before deciding to advance their platform.
tonyedgecombe 7y 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 7y 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 http://bonkersworld.net/organizational-charts
- sorenjan 7y 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?
  - maxxxxx 7y ago
    UWP is getting better but last time I looked it still had some weird restrictions. For many things WPF is still your best bet because you can be pretty confident that you will be able to do what you need to do.
- FpUser 7y 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.
  - Rusky 7y ago
    You could equally just pick one of the above commentor's list and use it for 20 years (minus a few for the relatively new ones). They all still work, whereas when Apple transitions they remove the old option.
OldSchoolJohnny 7y ago
"Apple benefits from having higher average quality of developers in its ecosystem" What?! How on earth do you come to that conclusion?
wvenable 7y 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 7y 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).
  - kitsunesoba 7y ago
    QuickTime Player was Carbon for a long time, too, and if I recall correctly so was iMovie.
  - wvenable 7y ago
    It's in the Wikipedia article for Carbon: https://en.wikipedia.org/wiki/Carbon_(API) https://en.wikipedia.org/wiki/Carbon_(API) Apple's original plan was presented in 1997. Steve Jobs announced the "change of direction" in 1998. iTunes was released in 2001. NeXTStep (and thus OpenStep and Rhapsody) already had a file browser/desktop application unrelated to the Finder.
  - linguae 7y ago
    It is true that iTunes and Finder were written in Carbon, but it is also true that Apple's original plan was for Yellow Box (the OpenStep API that later became Carbon) to be the main API for developing programs under Rhapsody, which was essentially NeXT with Mac OS 8 theming and UI guidelines. Rumor has it that Adobe and Microsoft balked at the prospect of having to port their applications to Yellow Box (there was no guarantee in 1997 that Apple's purchase of NeXT would pay off), which led to Apple announcing its Mac OS X strategy during WWDC 1998, which included Carbon as a first-class API for the development of Mac OS X applications alongside Cocoa (Yellow Box). Regarding iTunes, one detail about Carbon that is sometimes forgotten is Carbon originally ran on Mac OS 8 and 9 to facilitate the transition to Mac OS X (https://en.wikipedia.org/wiki/Carbon_(API) https://en.wikipedia.org/wiki/Carbon_(API) ; to quote, "Carbon was introduced in incomplete form in 2000, as a shared library backward-compatible with 1997's Mac OS 8.1. This version allowed developers to port their code to Carbon without losing the ability for those programs to run on existing Mac OS machines.") Given that Mac OS 9 was still current when the first version of iTunes was released, it made sense for iTunes to be developed as a Carbon application (since Carbon applications can run on Mac OS 8 and 9 as well as Mac OS X) rather than as a Cocoa application (which can only run on Mac OS X).
pwinnski 7y 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 7y ago
  Microsoft never shuts off the old targets because otherwise nobody would ever upgrade to the next version of Windows
- brantonb 7y 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.
addicted 7y 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.
- kitsunesoba 7y 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.
  - mikece 7y ago
    Agreed...and with the luck of Microsoft in this department the one awesomely named product of the last 15 years -- Silverlight -- was doomed because it was too cool for Redmond. (That and Turtleneck Steve prohibited browser plugins on iOS.)
    - WorldMaker 7y ago
      The tech survived, the brand didn't. I wonder sometimes if the Windows Mobile team was correct and UWP should have just kept the Silverlight brand name even as the underlying tech shifted so much, because the outer XAML shell is still so similar at the end of the day.
MR4D 7y 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 7y ago
The modern way to write Windows apps is Win32 again.
- FpUser 7y ago
  LOL. I never really strayed from this one on Windows. Everything else came with big limitations on what one can do.

gdubs 7y 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 7y 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.
- gdubs 7y ago
  Correct, within the Apple ecosystem — Mac, iOS.
  - josteink 7y ago
    So not so much cross platform as it’s commonly used, but rather multi-targeting within the Apple-platform.
    - fastball 7y ago
      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".
- nvrspyx 7y 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)

throwaway34927 7y 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.

scarface74 7y 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 7y 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.
  - scarface74 7y ago
    The Apple III was backwards compatible with the Apple //. Copland and Taligent never shipped to developers or users so neither wasted time on it. I had an Apple //e card. Using the included software, you could setup a ProDOS partition on your hard drive, and copy files from the //e to the Mac. Apple bundled converters that you could use to convert AppleWorks documents to Mac app documents. Mac86 sucked but the DOS Compatibility Card for the PowerMac 6100/60 with a 486DX/2, a dedicated sound card, and the capability of adding 32MB of dedicated RAM was quite good until Windows 95 came out and it could only use 16 bit drivers. That was my second Mac.
  - inspector-g 7y ago

spinningslate 7y 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.

eridius 7y 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.
- spinningslate 7y 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.

thought_alarm 7y 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 7y ago
Carbon.
- diesal11 7y 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.
  - stefanfisk 7y ago
    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.
tinus_hn 7y 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.