Thoughts on Cocoa(lists.apple.com)
lists.apple.com
Thoughts on Cocoa
https://lists.apple.com/archives/cocoa-dev/2019/Oct/msg00004.html
350 comments
Carbon UI framework has been deprecated for 12 years. Cocoa has been available since the first Mac OS X version, so ~20 years ago, and it's still be main UI framework on macOS, and it will still be for years.
You can't come now and whine that Apple changes UI frameworks too often.
You can't come now and whine that Apple changes UI frameworks too often.
I coded in Objective-C back in the NeXT days, did various (small) Cocoa and iOS apps and still use Macs daily - but work at Microsoft now.
Despite my own personal plights with small desktop utilities I write now and then, I don't think Apple has broken Cocoa _that much_ or that it is untenable for a small company to ship cross-platform desktop apps these days (never mind Electron, I'm talking about toolkits like Qt, Xamarin, etc.). _Especially_ if their core functionality can be cleanly detached from the UI.
I poked around a bit to figure out the detail to which the software does estimations, and it does seem like there is a very complex UI:
https://www.turtlesoft.com/Images/Goldenseal%201024x768.jpg
...but I keep wondering how much of it could be abstracted away by a cross-platform toolkit, and what kind of separation there is between the estimation/modeling code and the UI itself.
We'll never know without a good overview of the internals, but my guess (based on looking at many internal corporate apps over the years, from the pre-web days) is that this evolved organically over time and built up technical debt by literally following UI abstractions rather that isolating their core code from it.
Despite my own personal plights with small desktop utilities I write now and then, I don't think Apple has broken Cocoa _that much_ or that it is untenable for a small company to ship cross-platform desktop apps these days (never mind Electron, I'm talking about toolkits like Qt, Xamarin, etc.). _Especially_ if their core functionality can be cleanly detached from the UI.
I poked around a bit to figure out the detail to which the software does estimations, and it does seem like there is a very complex UI:
https://www.turtlesoft.com/Images/Goldenseal%201024x768.jpg
...but I keep wondering how much of it could be abstracted away by a cross-platform toolkit, and what kind of separation there is between the estimation/modeling code and the UI itself.
We'll never know without a good overview of the internals, but my guess (based on looking at many internal corporate apps over the years, from the pre-web days) is that this evolved organically over time and built up technical debt by literally following UI abstractions rather that isolating their core code from it.
Apple started selling 64 bit machines in 2005 and supported it in the operating system with Leopard: http://theocacao.com/document.page/343
There weren’t many 32 bit only Intel based Macs.
This complaint says far more about the developer than Apple.
There weren’t many 32 bit only Intel based Macs.
This complaint says far more about the developer than Apple.
> my current windows app STILL WORKS ON VISTA, i don't have to do ANYTHING to
"stay up to date" with Windows, cuz they support backward compatibility, and
don't force changes on developers.
> Meanwhile, our Windows version hasn't needed any work since 2000.
Microsoft's impressive backcompat is a blessing as much as it is a curse, and is also the cause of the [subjective opinion incoming] awful User Experience and complete lack of UI and UX consistency, and it remains the number one reason I don't wish to go back to Windows.
> Meanwhile, our Windows version hasn't needed any work since 2000.
Microsoft's impressive backcompat is a blessing as much as it is a curse, and is also the cause of the [subjective opinion incoming] awful User Experience and complete lack of UI and UX consistency, and it remains the number one reason I don't wish to go back to Windows.
I would have much the same sour grapes attitude of many in this thread, except for one point: Apple cannot even keep code examples working. Most of the code samples on Apple's dev site don't even compile a year or two after they are written and Apple doesn't bother keeping them updated. This is a rather large problem and verification of how hard it is to keep up.
This is entirely by design.
Apple doesn't want you to build an app 20 years ago, make no updates to it and continue to sell it as though nothing has changed in the time since.
Their website is compromised of mostly broken links, the design is dated and it is showing reviews and awards from 10 years ago.
Clear to me that they couldn't be bothered to put any effort in at any point in the buyer's journey so I say good riddance to them.
Apple doesn't want you to build an app 20 years ago, make no updates to it and continue to sell it as though nothing has changed in the time since.
Their website is compromised of mostly broken links, the design is dated and it is showing reviews and awards from 10 years ago.
Clear to me that they couldn't be bothered to put any effort in at any point in the buyer's journey so I say good riddance to them.
Well, they'd only have to do one major transition, to Obj-C/Cocoa and for that the writing was on the wall for 20 years (and official for 15 years) and everything would have been much smoother.
Had he used Cocoa, the rest, would have been trivial (to x86, to 64 bit, etc).
Or he could use whatever they like (C++, Pascal, what have you), and have their own UI/compatibility layer between OSes, like Adobe for example does (and several others, big and small: Sublime Text is an one man shop, and they make their own UI just fine).
The first response in the thread is not far off:
The people I hear complaining about this are those who, like you, didn't move to Cocoa. Carbon was a _temporary_ transition API*. It was necessary when Mac OS X shipped in March 2001, but even though it wasn't yet formally deprecated, it was clear it would be. The Carbon UI frameworks were deprecated circa, um, 2006(?). QuickTime has been deprecated nearly as long. 64-bit systems shipped in the mid-2000s, even before the x86 transition, and it was obvious then that 32-bit would eventually go away.
Eighteen years is _forever_ in the tech industry. At the time Cocoa was introduced, the Mac itself hadn't even been around that long!
It sounds like keeping an app limping along on 30-year-old APIs, and then suddenly trying to move it forwards all at once, is a bad idea. By comparison, keeping a Cocoa app up to date isn't that big a deal. I was maintaining Cocoa apps during the 64-bit, x86 and ARC transitions and had to make very few code changes. I've been out of the UI world for about 8 years, and there have definitely been significant changes in areas like view layout and document handling, but adapting to those isn't rocket science.
Yes, Microsoft is rather fanatical about compatibility. But that's part of what lost them their lead after the '90s: the amount of development resources needed to keep everything working exactly the same, and the difficulty of making forward progress without breaking any apps.
—Jens
Had he used Cocoa, the rest, would have been trivial (to x86, to 64 bit, etc).
Or he could use whatever they like (C++, Pascal, what have you), and have their own UI/compatibility layer between OSes, like Adobe for example does (and several others, big and small: Sublime Text is an one man shop, and they make their own UI just fine).
The first response in the thread is not far off:
The people I hear complaining about this are those who, like you, didn't move to Cocoa. Carbon was a _temporary_ transition API*. It was necessary when Mac OS X shipped in March 2001, but even though it wasn't yet formally deprecated, it was clear it would be. The Carbon UI frameworks were deprecated circa, um, 2006(?). QuickTime has been deprecated nearly as long. 64-bit systems shipped in the mid-2000s, even before the x86 transition, and it was obvious then that 32-bit would eventually go away.
Eighteen years is _forever_ in the tech industry. At the time Cocoa was introduced, the Mac itself hadn't even been around that long!
It sounds like keeping an app limping along on 30-year-old APIs, and then suddenly trying to move it forwards all at once, is a bad idea. By comparison, keeping a Cocoa app up to date isn't that big a deal. I was maintaining Cocoa apps during the 64-bit, x86 and ARC transitions and had to make very few code changes. I've been out of the UI world for about 8 years, and there have definitely been significant changes in areas like view layout and document handling, but adapting to those isn't rocket science.
Yes, Microsoft is rather fanatical about compatibility. But that's part of what lost them their lead after the '90s: the amount of development resources needed to keep everything working exactly the same, and the difficulty of making forward progress without breaking any apps.
—Jens
Come on, there certainly are reasons to complain about Apple deprecating stuff and strongarming developers into their walled garden, such as OpenGL, the fast-move to Swift/Swift versions, SIP/mandatory signed apps, XCode a moving target with OS updates, EFI BIOS updates for eg. booting from afs only downloadable as part of 6GB Mojave and soon Catalina OS updates, deprecation of semi-official Mac OS ports without equivalents on brew, stone-age Unix userland tools (bash, awk from early 2000), Java (and now Python) unbundling, and probably others I'm not aware of since right now I'm not very much into developing on Mac OS and iOS.
But Carbon isn't one of them. I knew Carbon was about to be deprecated in 2005 when I was coding a crappy UI for a crappy OCR solution. Carbon was just a forward-compat GUI lib on Mac OS classic (1998?) for apps to run on Mac OS X (2000).
But Carbon isn't one of them. I knew Carbon was about to be deprecated in 2005 when I was coding a crappy UI for a crappy OCR solution. Carbon was just a forward-compat GUI lib on Mac OS classic (1998?) for apps to run on Mac OS X (2000).
As an open source developer, I have mixed feelings about this.
Yes, Microsoft seems very keen on keeping Windows compatible even with ancient versions of the OS. New stuff usually is optional and APIs that behaved strangely in Windows 95 still behave the same way in Windows 10.
In Apple land, APIs may change their behavior whenever Apple deems it necessary. I ran into issues because of this with almost every macOS update since 10.8. And I see that even big players like Adobe keep running into compatibility issues all the time.
On the other hand, I'm spending just a few hours per week working on my project [0] and I manage to support an app that now runs on 10.5 through 10.14 and on three different CPU architectures with a single package. So no, I don't think you need to "throw 100 programmers at it" to get a working macOS version.
[0] https://github.com/enzo1982/freac
Yes, Microsoft seems very keen on keeping Windows compatible even with ancient versions of the OS. New stuff usually is optional and APIs that behaved strangely in Windows 95 still behave the same way in Windows 10.
In Apple land, APIs may change their behavior whenever Apple deems it necessary. I ran into issues because of this with almost every macOS update since 10.8. And I see that even big players like Adobe keep running into compatibility issues all the time.
On the other hand, I'm spending just a few hours per week working on my project [0] and I manage to support an app that now runs on 10.5 through 10.14 and on three different CPU architectures with a single package. So no, I don't think you need to "throw 100 programmers at it" to get a working macOS version.
[0] https://github.com/enzo1982/freac
Context: The authors software website: https://www.TurtleSoft.com
A screenshot: https://www.turtlesoft.com/Accounting-Software.html#Chart_Of...
I want to be respectful to an indie developer, but think it’s worth considering the kind of niche he works in (guessing windows -centric) and probably does more high touch sales.
I want to also guess that many of the people on that thread are from an older generation of developers, might be worth considering what the tradeoffs have been in language improvements that have attracted more people to writing software compared to the authors in that thread saying C++ is all they need.
A screenshot: https://www.turtlesoft.com/Accounting-Software.html#Chart_Of...
I want to be respectful to an indie developer, but think it’s worth considering the kind of niche he works in (guessing windows -centric) and probably does more high touch sales.
I want to also guess that many of the people on that thread are from an older generation of developers, might be worth considering what the tradeoffs have been in language improvements that have attracted more people to writing software compared to the authors in that thread saying C++ is all they need.
I hear and also feel the pain. I've been doing multi-platform app development since the 90's, and keeping up with Apple is starting to feel like a fools game - the work one has to do, just to stay on the platform and current with the vendor changes to the OS is very frustrating.
Which is why I'm just going to use an engine-only approach from now on. I can, fortunately, eschew native UI's .. since I work on creative tools and my users prefer to have the same pixel-equivalent interface on each platform rather than shifting paradigms.
I think that game engines are the future for all app development. There's not much I can't do in Unreal Engine, for example .. with the benefit that the same app truly runs everywhere.
If Apple want to continue to subvert developer minds to keep them on the platform, fine by me. The engines see this as damage and easily allow a lot of us to route around the problem.
Which is why I'm just going to use an engine-only approach from now on. I can, fortunately, eschew native UI's .. since I work on creative tools and my users prefer to have the same pixel-equivalent interface on each platform rather than shifting paradigms.
I think that game engines are the future for all app development. There's not much I can't do in Unreal Engine, for example .. with the benefit that the same app truly runs everywhere.
If Apple want to continue to subvert developer minds to keep them on the platform, fine by me. The engines see this as damage and easily allow a lot of us to route around the problem.
The only Cocoa API that has been deprecated in recent years is drawers. Apple is not going to suddenly rewrite their entire desktop apps and utilities in UIKit/Marzipan anytime soon (if ever - hell, they won't even rewrite them in Swift anytime soon), so Cocoa is well established and here to stay for a long time. So unless your app is entirely built out of drawers, I don't see how the mere presence of Marzipan can affect your long term business.
Not specifically Cocoa - but audio in Catalina is a city block-sized dumpster fire.
A good set of big audio developers - Steinberg, Ableton, Avid, NI, Presonus - and not a few of the smaller developers have had to send out emails saying "Whatever you do, don't upgrade yet!"
I'm sure there's a shiny happy Cupertino reason for this, but is it ever an annoying waste of time and resources for everyone involved.
A good set of big audio developers - Steinberg, Ableton, Avid, NI, Presonus - and not a few of the smaller developers have had to send out emails saying "Whatever you do, don't upgrade yet!"
I'm sure there's a shiny happy Cupertino reason for this, but is it ever an annoying waste of time and resources for everyone involved.
This constant iteration is exactly how software development works now.
By contrast to this, Quickbooks for Mac went through a ground-up rewrite in Cocoa about 10 years ago and has been keeping up with the transitions. It's really beautiful software that's a delight to use. They even used an SQLite data format so that you could easily access your own data.
Apple's is best at how it gently breaks stuff to move everyone forward.
By contrast to this, Quickbooks for Mac went through a ground-up rewrite in Cocoa about 10 years ago and has been keeping up with the transitions. It's really beautiful software that's a delight to use. They even used an SQLite data format so that you could easily access your own data.
Apple's is best at how it gently breaks stuff to move everyone forward.
It's not like Microsoft is any better. UWP, WPF, WinForms, and GDI are all in various states of disrepair and neglect.
I'm not familiar with the architecture of the app in question but are the UI parts and business logic/processing parts not properly separated such that a full app rewrite is needed? Someone referred to the backward compatibility of Windows apps as a curse: this is especially true when companies finally decide to update a VB6 or early 2000s WInForms app to something modern, the first step of which is to extricate all of the business logic in click handlers. By the time Cocoa came out the concept of separating your application into logical layers such that things like the UI could be swapped out with newer tech faster were well known so this shouldn't have been such a big deal if the app was constructed correctly.
They also have a blog post with more a detailed explanation than the linked mailing list post
https://turtlesoft.com/wp/
https://turtlesoft.com/wp/
> Meanwhile, our Windows version hasn't needed any work since 2000.
I see they haven't updated their website since 2000 as well. It's hard to have sympathy for software companies that don't invest in their business.
I see they haven't updated their website since 2000 as well. It's hard to have sympathy for software companies that don't invest in their business.
The paradigm programmers deal with today is demoralizing: it’s lousy to know your work will disintegrate in five or ten years.
For a while Mac OS 10 had support to run Mac OS 9—- via nicely integrated emulation. Then Apple removed it.
I’d just love it if the current OS supported all previous versions, via emulation.
For a while Mac OS 10 had support to run Mac OS 9—- via nicely integrated emulation. Then Apple removed it.
I’d just love it if the current OS supported all previous versions, via emulation.
The operating system is a foundation all developers needs to upon, and you want this foundation to be solid in many ways.
Being secure and offering the latest technologies available to the developers is one aspect, but being stable (in terms of ending support) and supporting those previous technologies for a long amount of time is another. I feel like Apple isn't doing the later.
Being secure and offering the latest technologies available to the developers is one aspect, but being stable (in terms of ending support) and supporting those previous technologies for a long amount of time is another. I feel like Apple isn't doing the later.
Apple's app stores are stuffed with quality apps. They don't need to give developers a quality experience because the supply is there anyway. So they don't. Small development shops have similar negotiating power and position to struggling unsigned music bands.
For me the last straw was notarization. I am not going to beg for permission to release software for Apple's platform. Considering the dire state of the Mac software scene Apple should be the ones on their hands and knees begging developers, the arrogance is incredible.
Not sure if they're complaining about runtime compatibility on macos but does anyone know if I wrote a Cocoa app few years ago on Snow Leopard or whatever would it still run as-is on macos version of today?
If not, then I can sympathize with their complaint that keeping up with macos updates will be more effort than Windows. The one time carbon to Cocoa update will be worth doing if my Cocoa app is not broken by next 10 os updates requiring constant code updates.
If not, then I can sympathize with their complaint that keeping up with macos updates will be more effort than Windows. The one time carbon to Cocoa update will be worth doing if my Cocoa app is not broken by next 10 os updates requiring constant code updates.
When you consider investing into user facing software trough specialized API's and tools, it's safe assume only 5-10 year useful life. The consequence is that investing into user facing apps and developers has limits because ROI is limited by current and near future user base.
Separating all the program functionality from all the OS/UI stuff pays off over longer term.
Separating all the program functionality from all the OS/UI stuff pays off over longer term.
Apple makes my preferred platforms, but macOS and iOS have poor backward compatibility, and this is particularly bad for games.
Yearly ABI changes and removals impose a recurring maintenance burden on developers to revise their apps just to keep them working. I think it's one of the factors driving the move to subscription pricing.
Yearly ABI changes and removals impose a recurring maintenance burden on developers to revise their apps just to keep them working. I think it's one of the factors driving the move to subscription pricing.
I wish they would just open source Cocoa (AppKit) if they're going to just abandon it. There were some really good ideas in there, and I think it could possibly develop an active community to continue experimenting with them.
IMO the problem this time around isn't the pivot, but the absolute half-heartedness of the pivot: two half-finished solutions: Swift UI and Catalyst, neither of which works very well yet, and this after about 5 years of pitiful development on Cocoa proper while simultaneously asking people to kind of switch to Swift. So it really feels like 3 half pivots in those 5 years, all to end up with something less polished than Cocoa in its heyday.
I really respect anyone who put up with working on Cocoa apps the last 5 years. The documentation has been sparse to non-existent on new features (often times for a year or longer your best bet was to wade through a WWDC video to get any information at all), coupled with a really miserable Mac App Store experience that was forced on you. It's really sad that when you would find some bug in Cocoa, unlike in the past, you could basically determine that this was it, as everything feels end of the line and thus not likely to be fixed.
IMO the problem this time around isn't the pivot, but the absolute half-heartedness of the pivot: two half-finished solutions: Swift UI and Catalyst, neither of which works very well yet, and this after about 5 years of pitiful development on Cocoa proper while simultaneously asking people to kind of switch to Swift. So it really feels like 3 half pivots in those 5 years, all to end up with something less polished than Cocoa in its heyday.
I really respect anyone who put up with working on Cocoa apps the last 5 years. The documentation has been sparse to non-existent on new features (often times for a year or longer your best bet was to wade through a WWDC video to get any information at all), coupled with a really miserable Mac App Store experience that was forced on you. It's really sad that when you would find some bug in Cocoa, unlike in the past, you could basically determine that this was it, as everything feels end of the line and thus not likely to be fixed.
I'm looking at doing desktop apps for my latest project. It's not simple.
It used to be simpler, although fragmented. There wasn't one tech for all targets, but there was at least one tech for each platform that did a good job.
How come writing a desktop application is harder now than it was 20 years ago?
It used to be simpler, although fragmented. There wasn't one tech for all targets, but there was at least one tech for each platform that did a good job.
How come writing a desktop application is harder now than it was 20 years ago?
> For anyone smaller, it's hard to justify the constant need to rewrite code just to stay in the same place.
This sort of says it all about modern progress, or indeed modern capitalism - you need to run all the time just to stay in place. This is also known as the Red Queen's Race [0].
[0] https://en.wikipedia.org/wiki/Red_Queen%27s_race
This sort of says it all about modern progress, or indeed modern capitalism - you need to run all the time just to stay in place. This is also known as the Red Queen's Race [0].
[0] https://en.wikipedia.org/wiki/Red_Queen%27s_race
I guess they don't have the resource to update their homepage last 20 years how they can update the app?
Their website still shows how long does it take to download files on the Dial-Up connection.
Their website still shows how long does it take to download files on the Dial-Up connection.
You can complain about OpenGL all you want, and praise Metal, but it doesn't matter how much better it is. i cant rewrite all my shaders, and do the API integration. The fact that the richest company cant hire 10 engineers to maintain compatibility, and are pushing all this work on to thousands if small independent developers is just rude.
With apples history, why spend time embracing, their new tech if you cant count on it sticking around. For developers who write small one-off apps for iOS its fine, but for people who make larger long term applications Apple is very developer hostile.