
Thoughts on Cocoa - pier25
https://lists.apple.com/archives/cocoa-dev/2019/Oct/msg00004.html
======
quelsolaar
This is why unfortunately the Mac is dead to me. I would love to support it,
but when OpenGL was deprecated it was just game over for me. A company that
forces me to learn a completely different language to access their basic APIs
and keeps changing them is just too mush of a hassle. Every hour spent on
maintaining a mac port is an hour not serving the 90% of users who aren't on
Mac.

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.

~~~
DCKing
Although I'm not a fan of OpenGL's removal, I think it's somewhat
misunderstood. OpenGL is an outdated design for modern GPUs. Its featureset
and architecture is too high level, leading to more buggy drivers and
complicated legacy support. There's two things you can do basically - keep
OpenGL around in perpituity, or move the complexity and responsibility of it
all to libraries.

Apple has defined their single graphics API to be Metal, kind of but not quite
like mainstream Linux where this has become Gallium3D (i.e. all open source
drivers implement their OpenGL and Vulkan and sometimes even Direct3D support
on top of Gallium3D). I fully expect OpenGL to be dropped from many future
Linux drivers too. I'm actually looking forward to the day Linux drivers will
go Vulkan only, as hopefully it allows things to get less buggy.

Even when OpenGL gets fully removed from macOS, you can still use OpenGL. You
can use Vulkan too. You just need a library for it, like ANGLE or MoltenVK. If
that would have been Apple's communication, there'd be a lot less fuzz about
this.

By the way, OpenGL still works on macOS 10.15. Deprecated does not mean it's
not working.

~~~
badsectoracula
> OpenGL is an outdated design for modern GPUs.

The thing is, in its entire lifetime OpenGL was never meant to be a GPU
abstraction layer - that only happened during GeForce2's time (and only for
Nvidia). Even SGI's implementation was doing a lot of stuff on the CPU (and
SGI even had a pure CPU implementation). OpenGL was always meant to be a high
lever immediate graphics API (immediate here meaning as opposed to
retained/scene graph APIs like OpenInventor).

> By the way, OpenGL still works on macOS 10.15. Deprecated does not mean it's
> not working.

Yeah but as it can clearly be seen, you cannot rely on Apple when it comes to
keeping things working.

~~~
DCKing
It seems to me then that OpenGL should have been a library instead of a driver
all along. Its original intent unfortunately has no bearing on what it has
become in the meantime.

> Yeah but as it can clearly be seen, you cannot rely on Apple when it comes
> to keeping things working.

Well yeah that's what deprecated means. At the moment, developers have a bit
longer to get on with the times though, so that's nice I guess.

~~~
rrss
> should have been a library instead of a driver all along

This would have required there to be a lower-level interface that different
vendors could all implement, which was not the case for early graphics
hardware. In the decades since graphics hardware has all evolved to look more
or less the same to SW (so vulkan became a nice fit), but that wasn't always
the case.

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

~~~
Mikhail_Edoshin
I was recently greeted by Brew message that my Mac OS X is too old and is not
supported :) It was simply a warning, the installation (GNU tar) run OK and
gtar worked. The OS is El Capitan and it's just turned 4 years.

~~~
plorkyeran
Under 1% of homebrew users are on 10.11
([https://formulae.brew.sh/analytics/os-
version/30d/](https://formulae.brew.sh/analytics/os-version/30d/)), so
continuing to test on that OS version would not be a good use of the
maintainers' time.

~~~
reaperducer
Interesting that there are five times as many Brew events from Catalina
machines than El Capitan machines, and Catalina isn't even out yet.

~~~
guitarbill
El Capitan machines are already set up, Catalina machines are being set up?

------
rcarmo
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](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.

~~~
ralfd
That is a bunch of Buttons, Textfields, Dropdowns and Listviews? How hard can
that be in Cocoa?

In their blog post they said they worked for three years on the Mac version
... maybe the company is just one person not having much time or coding
experience. Maybe I am underestimating the problem, but in my time they would
have just hired a student or the nephew of their neighbor to hack something
together useful.

~~~
ratww
They also mention in another post that four different contractors gave up on
migrating it, three targeting Cocoa and one Qt. Maybe the codebase is brittle
and hard to work with and not really worth the effort.

------
tonyedgecombe
Apple started selling 64 bit machines in 2005 and supported it in the
operating system with Leopard:
[http://theocacao.com/document.page/343](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.

~~~
duskwuff
The first response sums it up nicely:

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

\- [https://lists.apple.com/archives/cocoa-
dev/2019/Oct/msg00021...](https://lists.apple.com/archives/cocoa-
dev/2019/Oct/msg00021.html)

~~~
badsectoracula
> But that's part of what lost them their lead after the '90s

I think that guy lives in a bubble, Microsoft is still by a huge margin the
lead in desktop OS market share :-P.

And really the main reason is that they try their hardest to not break
people's applications. If Windows suddenly couldn't run the applications
people wanted, everyone would migrate to Linux (and some to Mac, but Linux is
free so the majority would go for the free stuff).

~~~
yardie
I've seen quite a few legacy Windows app needing to be run as administrator,
compatibility mode, or both. Just because you can do something doesn't mean
you should. It's glaringly irresponsible that applications should be given
read/write access to the C:\Windows folder because that was acceptable in the
90s.

Now when I get an exe that needs to run in compatibility mode I don't even
bother with it. I'm not compromising my computer because a developer has
abandoned their software.

~~~
badsectoracula
Good for you, but other people want their computers to do work for them with
the applications they want to use.

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

~~~
noisem4ker
Win32, WinForms and WPF desktop applications are all able to follow the OS
theme. With Metro there's been a departure to a visually incompatible
paradigm. This is to say that the lack of UI consistency is a political
problem, not a technical side effect of keeping old UI technologies running.

~~~
stickfigure
I wouldn't be so sure of this.

I made the Windows -> Mac transition in 2008 and recently played around with a
modern Windows machine. I was pretty stunned to find the Control Panel
experience... not unchanged, but still eerily similar to Windows XP.

Windows' Control Panel is a trainwreck of UX compared to OSX System
Preferences. Being such a core part of the OS, I really expected to see, well,
something new and better. But then I remembered how countless programs embed
themselves in the control panel via DLLs, so Microsoft probably can't make
major changes to the UX without breaking binary compatibility with ancient
software packages.

~~~
saagarjha
macOS has third-party preference panes too.

~~~
zapzupnz
Yeah, but they're all separate from any other preference pane. Everybody gets
the same framework to create completely independent prefpanes, not hijack
Apple's existing ones.

There are no hooks, for example, to modify the Displays prefpane; if Apple
decides they want to update it, they're free to do so. On the other hand, a
lot of graphics card vendors _still_ needlessly add their own little tab to
the display adaptor control panel and the desktop's context menu.

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

~~~
Synaesthesia
I’d you’re talking about swift yes they changed a lot since the early versions
and many code examples are out of date. I believe the language has stabilized
now.

~~~
protomyth
Most, but the Objective-C examples also have breaks.

~~~
saagarjha
Only very rarely.

~~~
protomyth
Uhm, the OpenPanel changes basically crapped on a whole group. Apple does not
keep its examples updated. Heck, now its hard to find examples at all.

~~~
Klonoar
I still write ObjC more often than most, and I’m pretty familiar with their
stuff - I’m generally the first to claim examples are like a needle in a
haystack, but they almost always do work when you find them.

They definitely might be outdated, tho.

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

~~~
ubercow13
Is this the reason that everything on iOS app store is transitioning to
subscriptions where before an app cost $3 and now it costs $3 a month, because
developers worked out that the cost of keeping up with Apples constant
platform changes is too much?

~~~
bluk
I think that’s more that developers want to make a decent living. The vast
majority of subscription apps have a server side maintenance cost. As the
platform matured and developers realized those users were going to stick to
their apps for years without paying another penny, then it becomes untenable.

~~~
blub
That's simply not true, many offline apps are transitioning to subscriptions
and maybe add some lame cloud sync as an excuse/afterthought.

Happened to me recently with an app which is the interactive version of a
book. From one day to the other they switched from buying chapters/the book to
some stupid subscription.

If they can't make a living they need to charge more and if they can't charge
more they need to find a real job/business.

~~~
acdha
The problem is that so many companies burning VC cash and/or ad dollars have
trained customers to think software costs less than a cup of coffee. If you
charge what you need for a sustainable business up front, your sales will be
enormously less and you’re going to get tons of negative reviews from people
who think a $20 app would need to cure cancer to justify that price. (And, of
course, even $3 deserves lifetime free updates and new features)

It’s especially bizarre that you’re ranting about them needing to find a real
business when that is exactly what they’re doing by finding a billing model
which is viable long-term.

~~~
blub
Very few developers have proven that they're capable of building a sustainable
business (like e.g. OmniGroup).

It's impossible to say if a particular app will in a week:

a) still be available

b) if it will have switched to subscriptions or free + IAP or free with ads
and IAP

c) what the IAPs will be and if your old (if any) IAPs will still work.

d) if they'll decide to sell your info to the next available bidder

This is why almost all apps are worthless and why I've essentially stopped
purchasing or downloading apps. It's simply not worth the trouble to invest
time to learn to use an app and investigate whether you can trust the
developer.

------
coldtea
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

~~~
pjmlp
While I agree with you relating to Carbon, Microsoft is pretty much the still
only game in town for desktop computing (which also includes laptops and 2-1
hybrids) in worldwide market share.

~~~
coldtea
Yes, but macOS has enough native apps for everything, and the advent of web
apps and mobile apps, made the whole point moot.

You can do everything and more on a Mac.

~~~
pjmlp
Go look around anyone doing office work on their phones.

Tablets, sure, when converted into pseudo-laptops, and unless we are talking
about iPads here, the European shops are increasingly replacing their Android
tablets on sale by Windows 10 laptops with detachable keyboards and touch
screen.

As someone that does native/web development, the only area where Web wins are
the typical CRUD applications, anything more resource intensive just brings
the browser to halt, and for stuff like WebGL it still hit and miss.

As for doing everything and more on a Mac, as much as I like Metal Compute
Shaders, they aren't a match to CUDA tooling.

Finally, as much as I like Apple's platforms, they are out of reach for a
large segment of the world population, no matter what.

~~~
coldtea
> _Go look around anyone doing office work on their phones._

Depends on the office work. A lot of stuff is doable on a phone even, as many
common place apps are available, if it wasn't for the ergonomics (small
screen, no full keyboard, etc).

> _As someone that does native /web development, the only area where Web wins
> are the typical CRUD applications, anything more resource intensive just
> brings the browser to halt, and for stuff like WebGL it still hit and miss._

As someone who is a heavy user of the other apps (NLEs, DAWs, drawing/bitmap
editing) where the web is a non-starter (and I don't care for all the half-
arsed attempts at web-DAWs and such), I agree.

But for business, CRUD apps are 90% of their needs, plus Word/Excel etc, for
which Google Docs is a lot of the way there (and even if not, they exist in
good shape natively for both Windows and Mac).

> _As for doing everything and more on a Mac, as much as I like Metal Compute
> Shaders, they aren 't a match to CUDA tooling._

Perhaps, I don't use CUDA or do 3D at all.

> _Finally, as much as I like Apple 's platforms, they are out of reach for a
> large segment of the world population, no matter what._

Sure, but that's also true for workstation-like PCs, and commercial
compilers/IDEs, which you're in favor of, no? :-)

~~~
pjmlp
Workstation like PCs and commercial compilers/IDEs can be had for cheaper
prices than Apple hardware.

~~~
coldtea
Depends on the "workstation like PCs" and "commercial compilers/IDEs".

Anytime I put together a decent PC with best of breed parts, it goes to 3-4K.
And commercial offerings from Dell with similar specs also go there, same for
laptops, e.g. Lenovo, and the like.

And I've seen commercial compilers/IDEs priced in the $1K/$2K range, with
which you can surely buy a Macbook Air or similar...

~~~
pjmlp
No need for a Ferrari when a Fiat does the job.

Naturally there are those that feel entitled to get a Ferrari to go down the
grocery store, but that is their problem.

If one is buying enterprise class prices, then it is always going to be more
expensive with Apple's hardware, because those compilers and IDEs are not part
of Apple's offering, adding to the already expensive hardware price.

And if by hardware workstation, you want a really beefy one, the Apple's
alternative is only their top hardware.

Thus at the end of the day, when one does the math of what one is getting per
buck/dollar/yen/..., still way over the usual budget on PC side.

------
tannhaeuser
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).

~~~
swerner
Apple may initially have intended Carbon as temporary, but has changed their
stance when they started adding new APIs that never existed in MacOS 9 -
HIView/HIWindow was intended to unify Carbon and Cocoa, there was even a 64
buy version of Carbon that shipped in Mac OS betas, and when Retina-Display
Hardware shipped, Carbon received new APIs to deal with that.

Likewise, Cocoa in 10.0 was buggy and incomplete. It took until about 10.4,
10.5 for Cocoa to reach feature parity with Carbon and many Cocoa applications
were using Carbon for certain features (in facts, last time I checked, Cocoa
menus were implemented in Carbon).

~~~
Klonoar
HIView and HIWindow were added, if I recall correctly, because it allowed
other toolkits (tk, Qt (who only recently moved off this), etc) to draw the
native look “properly”. It was never actually up to date or well documented,
and they kept it around just so the OS didn’t look so totally bizarre as you
moved through it (like you see on Windows).

Bolting on Retina support to that is such a no-brainer that I hesitate to call
it adding features - that was table stakes in making sure the switch to retina
didn’t look like total ass.

None of this stuff ever changed how Carbon was deprecated. People just sat
around not listening to Apple, and then the last two years the bigger GUI
toolkits finally did the work to transition properly.

~~~
swerner
HIView was up to date and documented, and there were WWDC sessions teaching
developers why they should move to HIView and how to do it. Likewise, Apple
provided documentation about how to port your Carbon application to 64 bit
Carbon. Maxon reportedly even had a 64bit Carbon version of Cinema 4D ready to
ship when Apple suddenly announced that they would abandon 64bit Carbon -
telling developers to disregard the 64bit Carbon they were still shipping in
betas.

~~~
Klonoar
Yeah, no, this really wasn't the case.

Toolkits that used HIView/HIWindow looked very out of date compared to proper
Cocoa implementations (Qt, contrary to popular belief, wasn't really "native"
for the longest time since they did this - it's part of why it always looked
off).

There are very valid reasons to be frustrated with Apple, but the writing has
been on the wall for this stuff for years now. Nobody should be complaining at
this point.

------
enzo1982
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](https://github.com/enzo1982/freac)

~~~
saagarjha
Although, it seems like you’re reimplementing platform controls? This seems
like a mini-Qt:
[https://github.com/enzo1982/smooth](https://github.com/enzo1982/smooth)

~~~
enzo1982
Yes, that's my own custom UI framework. Most of the platform dependent stuff
is implemented in the smooth library.

In hindsight, it would have been easier to just use Qt, GTK or wxWidgets. But
I learned a lot by doing this myself and wouldn't want to miss that
experience.

------
seltzered_
Context: The authors software website:
[https://www.TurtleSoft.com](https://www.TurtleSoft.com)

A screenshot: [https://www.turtlesoft.com/Accounting-
Software.html#Chart_Of...](https://www.turtlesoft.com/Accounting-
Software.html#Chart_Of_Accounts)

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.

~~~
fortran77
You are being mean. Picking on a guy's website because it's not shiny and new
for you.

~~~
seltzered_
Wasn't trying to be mean, but to understand his perspective when he stated
that "For anyone smaller, it's hard to justify the constant need to rewrite
code just to stay in the same place. Return on investment is just not there."

His reply post goes a bit more into his story of trying to update the app:
[https://lists.apple.com/archives/cocoa-
dev/2019/Oct/msg00027...](https://lists.apple.com/archives/cocoa-
dev/2019/Oct/msg00027.html) . While I get author's gone through some rough
experiences, I wonder he could have sought outside investment/advising to get
a solid rewrite done & grow the business.

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

~~~
jbverschoor
Good luck running 20 instances for some productivity apps.

~~~
fit2rule
Who runs 20 instances of an app? That just sounds like poor design.

Anyway, I have no problems running multiple instances of a small and light UE-
based app. Most I've had running on one machine is 5 .. but I'm not seeing the
limitation you're indicating.

~~~
thesquib
Just open multiple windows in electron and you're there!

~~~
fit2rule
Electron is just poorly engineered software.

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

~~~
swerner
QTKit was deprecated, and support for objective-C garbage collection, once
praised as the future, was removed altogether.

~~~
vlozko
To the best of my knowledge, there wasn’t much of a difference in programming
style going from GC to ARC except for a few exceptions like all those pesky
CFMakeCollectable calls that ended up being no-ops anyway.

~~~
swerner
You have to add all kinds of reference qualifiers (__strong, __weak, ...).

~~~
plorkyeran
You don't have to explicitly mark things as strong as it's the default. Having
to manually break references cycles with weak pointers does make the migration
not as simple as just changing the compiler flags, but I've never heard of it
being all that difficult. Apple managed to migrate Xcode in a single version.

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

~~~
macintux
Worth pointing out that Catalina hasn’t been released yet. There’s a good
chance the problem(s) won’t be fixed by then, but it’s a little OTT to gripe
about beta software.

~~~
pier25
I started using macOS in 2007 and I've learned the hard way it's not a good
idea to update to a major version right away. These days I usually wait about
a year before installing a new major version. I barely installed Mojave the
other day.

~~~
jmnicolas
I do the same with Windows. I upgraded to Vista 1.5 years after it's initial
release and never had a complaint about the OS which was much better than XP
for me.

~~~
FpUser
I skipped Vista completely (except one machine I used to test my software
with) and went to Win 7. Same thing with Win 8.

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

~~~
FpUser
I can't even fathom what would poor Quickbooks ever do without Apple "gently
breaking stuff".

------
jimbob45
It's not like Microsoft is any better. UWP, WPF, WinForms, and GDI are all in
various states of disrepair and neglect.

~~~
ch_123
I would say that the main difference is that many applications written for
Windows 95 will work just fine on a Windows 10 system. The Mac ecosystem has
nowhere near the same amount of longevity.

~~~
sebazzz
And even well written games, like Deus Ex. Not it's successor ironically
though.

~~~
badsectoracula
With some tweaks, Deus Ex Invisible War runs fine here on Windows 10. In
general i didn't had any game or program i couldn't get it to run in Windows
10 and i have a lot of older software.

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

------
kalleboo
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/)

~~~
saagarjha
The version numbers are a bit off in that.

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

~~~
beefhash
I, for one, rather enjoy the 2000s aesthetic. Different tastes for different
folks.

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

~~~
badsectoracula
Eh, it isn't _that_ bad. Apple is such a case, sure, but other platforms are
better. Win32 is probably the king of backwards compatibility - software you
wrote or bought 25 years ago will work just fine on modern Windows 10
(assuming you didn't do _too_ many mistakes :-P). But Linux in general should
have decent backwards compatibility too, at least for stuff not relying on Gtk
and Qt (or C++ if you go far back). Some time ago i compiled some examples
from a GUI toolkit i was working on on a RedHat from 1998 and they worked on
Debian from 2018 just fine.

In source code form you may even surpass Win32 as code written for X11/Xlib
and Motif (to some extent since that wasn't 100% compatible between different
Unices) will still compile with little to no modifications.

And of course anything you write to run in a web browser has good chances to
work in the future (client side only). Well, assuming Google doesn't
completely take over and decide that they know better than anyone else if it
is a good idea to remove stuff or not.

Also while not exactly OSes, but several platforms exists that provide
isolation from the underlying OS madness. E.g. Java/JVM is an example of a
platform that almost never breaks stuff. Languages like Smalltalk and Common
Lisp also tend to be very stable. Free Pascal and Lazarus developers also try
hard to avoid breaking code (there is still breakage but it is very rare and
in almost all cases is about bugs in the compiler - personally i had only a
couple of cases where i had to fix code over the last 15 years and that took
me only a few minutes).

~~~
charlesism
Great point. I made some assumptions without taking a mental inventory. The
issue is disproportionately an Apple issue (and even then, an issue with
programs that rely on Apple APIs).

------
m-p-3
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.

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

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

~~~
zapzupnz
> the arrogance is incredible

Every time I see a developer completely fail to understand what notarisation
is and how it works then proceed to say that their faulty understanding was
the last straw and that they'll stop developing for macOS, I can't say I feel
anything but delight. If basic reading comprehension is beyond so many
developers, I can't imagine wanting their code on my machine, even in a
sandbox.

The arrogance is incredible, indeed.

~~~
dang
Please don't be a jerk on HN, even if another comment was provocative.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

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

~~~
mantap
Forget snow leopard, Apple can't even keep compatibility for the version they
released 1 year ago.

When Apple announces a new OS update at WWDC you have approximately 4 months
to install a beta on an external drive and fix any incompatibilities. Oh and
it's a moving target, they only freeze it just before release. This process
repeats every single year, sometimes they are so excited to break shit that
they do it in a patch release but that's much rarer.

If there's a silver lining it's that Apple has gotten so bored with the Mac
that they don't change as much as they used to, it's certainly not as bad as
it used to be, but not because Apple has suddenly started caring about
backwards compatibility.

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

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

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

------
marcus_holmes
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?

~~~
ratww
> there was at least one tech for each platform that did a good job

I think the problem is exactly the opposite: there used to be "at most one
tech for each platform", but now there's too many choices. On top of that
there's also Electron and many multi-platform widget libraries. This gives a
lot of "analysis paralysis" to developers. There just isn't a silver bullet.

...I mean, except for MacOS, ironically, where only Cocoa matters (at least
until Marzipan). Carbon has been a second-citizen from the start, and was
deprecated in 2007.

On Windows there's UWP, WPF and WinForms, which are very productive, and are
open source now, on top of that. The only problem IMO is that they're only
"great" if you use C#. Writing windows apps with C++ is way too verbose.

On Linux it's more complicated (and I'm not familiar with it) but at least
users are much more forgiving when it comes to desktop consistency.

~~~
tonyedgecombe
To be fair C# is probably the best choice for the majority of desktop
developers.

------
ciconia
> 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](https://en.wikipedia.org/wiki/Red_Queen%27s_race)

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

------
mwyah
Seems like they call themselves "Turtlesoft" for a reason.

------
cmsj
“Meanwhile, our Windows version hasn't needed any work since 2000”

I honestly don’t see that as a good thing. What are these people doing if they
haven’t touched their code in almost 2 decades?

------
reaperducer
_Meanwhile, our Windows version hasn 't needed any work since 2000_

While I don't disagree that it's hard to keep up with Apple, if you haven't
updated your Windows product in 19 years, then it's probably not a product I
would want to use anyway.

Imagine if web developers thought the same way. Very few web sites exist today
as they did in the year 2000, and those that do are ultra niche, or abandoned.

~~~
donatj
I disagree completely. If software genuinely hasn’t needed to be updated since
2000, it’s solid, dependable. It’s a hammer. I use the same hammer I use today
I used 20 years ago.

It’s a tool, not a gimmick. Think the UNIX tools used billions of times a day
we don’t even think about.

~~~
guitarbill
Hammers don't have security issues, which is where the analogy breaks down.
Sometimes, these UNIX tools haven't changed much on the outside, but they are
getting updates.

If you look closer though, the BSD and GNU variants of common tools have
diverged. And while I like BSD's conservative approach, some of the GNU
features are damn useful.

------
thesquib
Does anyone know if the current macOS still uses elements of Carbon under the
hood? What about Catalina?

------
codefreq
For me it just redirects to apple.com

~~~
markdown
Its a thread that starts with this:

Subject: Thoughts on Cocoa

From: Turtle Creek Software via Cocoa-dev <email@hidden>

Date: Wed, 2 Oct 2019 13:14:44 -0400

Sadly, we just decided to abandon the Cocoa update for our app. It's not easy
to walk away from 3 years of work, but better 3 years lost than 5. Time will
be better spent on our Windows version.

TurtleSoft started Mac-only with Excel templates in 1987. The first prototype
of our current stand-alone accounting app was in the early 90s. Since then,
programming for Mac has gone through four primary programming languages
(Pascal, C++, Objective C, Swift). Three, soon to be four chip architectures
(680x0, PPC, Intel, ARM). Four frameworks (MacApp or Think Class Library,
PowerPlant, Carbon, Cocoa).

Microsoft and Adobe are big enough that they've survived the many pivots. They
can just throw 100 programmers at it. Intuit has barely kept up. For anyone
smaller, it's hard to justify the constant need to rewrite code just to stay
in the same place. Return on investment is just not there. Seems like each new
update is more difficult.

Many good apps for Mac have died in one pivot or another. We managed to lurch
through most of the changes, but not this one. Thinking ahead to the
consequences of Marzipan was the last straw.

Meanwhile, our Windows version hasn't needed any work since 2000. It probably
will take less than a year to get it updated to 64-bit and a better interface.

Casey McDermott TurtleSoft.com

------
floatingatoll
I wish this post focused on the core issue: they don’t make enough money from
Mac sales to be willing to replace a framework (Carbon) deprecated by Apple 15
years ago, and are instead terminating Mac support.

I’m surprised they didn’t do that sooner, but blaming Apple for ending Carbon
support is beside the point of “not enough revenue”.

------
xhruso00
They can't update their web
[https://www.turtlesoft.com](https://www.turtlesoft.com) and they charge $495
for a non-accounting licence. Seriously, the web looks like it was done around
year 2000.

~~~
FpUser
Should they? Maybe it is not that pretty but it is functional. Many modern
sites on the other hand show big nothing picture that one has to scroll down
and hunt for info. And I love that light grey text on white background which
is nigh to impossible to read for many not so young eyes.

And since they have pretty specific product I am pretty sure that their
customers do not give a flying hoot about how the site looks. They need
specific functionality from the product

~~~
thesquib
This 100 times. Form over function is apparently more important these days.

------
GnarfGnarf
Qt seems like a good solution to multi-platform requirements.

------
c-smile
That happens all the time. With any OS.

On Windows, if you have an application that draws stuff using GDI+ (20+ years
technology) then you will discover that it is not moving today on high-DPI
monitors. GDI+ is pure CPU rendering and the Moore's is over. GPU rendering is
the only option these days.

Yes, GDI+ still works. You see it renders something in your applications on
Windows 10. But you cannot use the application on your new cool monitor.

Same with CoreGraphics on Mac. CG is GDI+ alike thing by nature - pure CPU
rasterizer. Something tells me that it will die pretty soon too.

Good abstraction/isolation layer is definitely needed for the applications
that want to survive on the long run.

As an example, Norton Antivirus started using such UI layer (Sciter Engine -
[https://sciter.com](https://sciter.com)) 12 years ago. First versions were
using GDI rendering backend. Then we added Direct2D GPU accelerated backend.
With the same API. Application code and architecture did not change all these
12 years.

Same thing on MacOS. Initially the engine used CoreGraphics. Then OpenGL gfx
backend was added. And now we are working on Metal. And Vulkan for these
matters.

But API of the engine is the same as it was initially.

TL;DR: Good application architecture is still the thing.

------
KibbutzDalia
I think the future is game engines. You can write once and run everywhere. As
soon as there’s one with first-class support for Rust (as the world is clearly
and rapidly moving to Rust) the rest will be moot.

~~~
pier25
FYI Flutter basically works like a game engine.

------
abujazar
They probably should’ve started porting their app to web tech 10-15 years ago
rather than ranting about progress in native frameworks.

