Thoughts on Cocoa

https://lists.apple.com/archives/cocoa-dev/2019/Oct/msg00004.html

by pier25 • 7 years ago

202 350 7 years ago

lists.apple.com

codefreq• 7 years ago

For me it just redirects to apple.com

markdown• 7 years ago

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

sliken• 7 years ago

It did for me 2-3 times, and I was puzzled. I tried a 3rd time and it worked.

jimbob45• 7 years ago

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

ch_123• 7 years ago

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

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

ahartmetz6• 7 years ago

But you can still use any of them. Especially GDI/Win32 which just won't die.

c-smile2• 7 years ago

GDI.

If FillRect(hdc,rect) is the only thing that you need from it then it will work for you, yes.

But GDI does not support antialiasing so, let's say, Ellipse(hdc) will just draw an illustration to Brezenham algorithm but not that you would want to present to the user.

Same thing about alpha channel - no transparency in GDI.

So forget GDI for UI purposes. You may try to use that GDI+ horse... But it is pure CPU rasterizer and so forget it too on modern high-DPI monitors.

Yes, GDI is still with us but the chorus is here already to sing "Sic transit gloria mundi".

carlosrg• 7 years ago

All of these are still maintained and get new OS features.

badsectoracula19• 7 years ago

Microsoft may shit out a new toolkit every other year (which is a shame, they should be fixing their existing stuff instead) but at least they maintain them for basically eternity. You can pick up anything and it'll be there for years to come (though not everything may be bundled with the OS forever - IIRC some less used some are downloaded on demand, but still the applications do not break).

(though personally i mainly trust core Win32 as everything else is built on it and because of that it is the most likely to remain stable)

thrower1232• 7 years ago

However, there is effectively a 0% chance that an app written using those technologies will stop working arbitrarily.

SigmundA2• 7 years ago

I would say it's worse. At least Apple uses the same frameworks they want you to use.

Of the ones you listed office (word, excel etc.) doesn't use them, they have their own framework.

Why should I use UWP if its not good enough for the office team? I want to use what they are using.

kyberias• 7 years ago

Why is Office your only reference here? Office also runs on Android. It needs to be more portable.

Other references: Visual Studio runs on WPF and many Windows apps are UWP.

FpUser7• 7 years ago

Luckily for GUI apps I've had enough "wisdom" and am only using Win32. Delphi (another shining example of backwards compatibility and being TRUE RAD) has shielded me from writing too much code for functional GUIs. So I mostly work on improving functionality and feature set rather than chasing whatever latest tech/framework is in vogue at the moment. Most of them come and go. Especially in web development.

tonyedgecombe2• 7 years ago

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.

duskwuff• 7 years ago

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

TBurette• 7 years ago

The fact that they had a long time to transition doesn't negate the fact that they have to spend the time doing the transition.

At market-rate developer salary, it doesn't take a lot of man months for the port not to be worth the investment for small shops.

badsectoracula19• 7 years ago

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

ben5093• 7 years ago

It's a bit judgmental, though the original complaint is also a bit whiny.

The reality is that Turtle couldn't make the business case to port to Cocoa at any point for 18 years, probably because most of their customers were Windows.

That's not them being lazy, that's just them directing their resources according to market demand and engineering constraints.

And Apple is not being greedy or uncaring, they also have to direct resources according to market demand and engineering constraints.

If Turtle had more Mac customers, they'd have either ported their app, or they'd purchase a Carbon compatibility library. And if more developers were actively using Carbon, Apple would put more resources into it.

They aren't, and so the two are going to part ways.

setpatchaddress• 7 years ago

Jens is way oversimplifying the developer story around Carbon, FWIW. It existed because Adobe and Microsoft wouldn’t port their apps without it, and that wasn’t going to change in the foreseeable future. It wasn’t deprecated in the technical sense until 2007.

Yeah, the arc was that Cocoa was the future, but as late as 2007, Carbon was still widely considered a viable target for new apps.

saagarjha13• 7 years ago

Addendum: the kernel remained 32-bit until Snow Leopard.

bluedino• 7 years ago

And 64-bit macs came out in 2003, 64 bit intel macs didn't come out unti 2006

badsectoracula19• 7 years ago

This complaint says far more about the developer than Apple.

Yes, it says that they didn't bother to waste resources doing unnecessary changes.

But it also says about Apple that they do not respect the time and resources of the developers that bother to support their platform.

There is no way to spin Apple breaking APIs and programs that people have worked on (for developers) and bought (for customers) in a positive way.

eitland• 7 years ago

Yes, it says that they didn't bother to waste resources doing unnecessary changes.

Keeping up with API changes from a decade ago doesn't qualify as unnecessary.

There is no way to spin Apple breaking APIs and programs that people have worked on (for developers)

Here's the point. Apple isn't doing that. Apple don't visit customers with old macs to push breaking patches.

What happened is the developers made something that worked on old macs, didn't put in the effort to keep it up to date and are now complaining that Apple won't put in the efforts to support the old APIs on new systems anymore.

and bought (for customers) in a positive way.

This is the developers fault I guess.

vetinari3• 7 years ago

There weren’t many 32 bit only Intel based Macs.

I don't understand, why Apple even created x86 osx ABI.

When they introduced the first x86 Macs, the writing was already on the wall; in the same way, that there are claims that Carbon was deprecated for years, x86 was in the door on its way out. You would not create a new Carbon-based app today, Apple introduced ABI in similar circumstances? Well, maintaining it then for decades to follow comes with the territory.

Yes, as an user, I do mind removing it. For example, Apple had broken Preview scanning on Samsung MFPs for the entire Mojave lifecycle ([1], [2]), there's no indication that they are going to fix it, and as a workaround, users are using Samsung Easy Document Creator, which talks directly to scanner, avoiding Apple scanner libs. Yes, it a 32-bit app.

[1] https://discussions.apple.com/thread/8552818 [2] https://h30434.www3.hp.com/t5/Samsung/Scanning-problems-with...

Synaesthesia3• 7 years ago

When apple started their intel transition, intel used 32 bit CPU’s primarily. The first intel macs (core Duo) and intel dev kits were 32 bit, the core 2 duos onward were 64 bit. It’s really a small amount of Macs.

marcus_holmes• 7 years ago

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?

zerr2• 7 years ago

Cross-platform toolkits have much nicer and sane APIs compared to native SDKs. Even if I wanted to target the single specific platform, I'd still pick wxWidgets or Qt Widgets over Win32 or Cocoa.

etaioinshrdlu• 7 years ago

I would completely agree. It's a bit like html vs native though, you end up trading flexibility for compatibility and ease of development.

ratww7• 7 years ago

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.

tonyedgecombe2• 7 years ago

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

fit2rule4• 7 years ago

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

Good luck running 20 instances for some productivity apps.

fit2rule4• 7 years ago

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.

thrower1232• 7 years ago

Good luck running 20 Electron apps...

FpUser7• 7 years ago

Depending on design and particular engine/rendering library used there could be no problems at all. If we are talking say business UI on top of GPU accelerated graphics lib (no heavy 3d assets stuffed in regular and GPU RAM) you could run multiple instances with no problems.

threeseed2• 7 years ago

Normally I would've said this comment was ridiculous.

But Google did exactly this with Flutter i.e. using a game engine and I found the experience to be significantly better than native development. Not only are you guaranteed of the same behaviour across platforms but you end up with a smoother, more polished app faster.

Definitely not suitable for every use case but for many it was impressive.

fit2rule4• 7 years ago

From where I stand, Game Engines are the New OS™. UE even has its own compiler system built-in, ffs...

FpUser7• 7 years ago

I am going multiplatform for my new GUI apps and I am actually considering game engines / rendering libs of which there are plenty.

filleduchaos2• 7 years ago

You could consider taking a look at Flutter's approach (it's basically a UI SDK built up from scratch around Skia). It's entirely open source and likely contains some decent tips (and you can piggyback off the engine layer and bolt on a different language for scripting).

enzo19822• 7 years ago

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

badsectoracula19• 7 years ago

Not all applications are the same. Your application may not have the same requirements from the OS than some other application. As an (extreme) example, an application written in C that only needs from the host OS is a top level window and basic events for handling input while doing everything else with custom code will be much more portable and easy to keep up with changes than an application written in a language with its own runtime, creates a native UI for each platform, uses native APIs and tries to integrate with the native OS.

saagarjha13• 7 years ago

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

enzo19822• 7 years ago

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.

ben5093• 7 years ago

I think it's more of a challenge when you have someone who is more skilled as a subject matter expert than as a programmer, which may be the case when you're the tech person or even founder of a small business.

That person may not be doing good unit testing, they might not use the best tools, and find that supporting different configurations may require a lot more manual work rather than maintaining some carefully crafted #ifdefs.

And maybe one person could do it, but one salary they can't justify based on the demand may as well be 100 programmers.

kalleboo• 7 years ago

They also have a blog post with more a detailed explanation than the linked mailing list post

https://turtlesoft.com/wp/

saagarjha13• 7 years ago

The version numbers are a bit off in that.

galad874• 7 years ago

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.

microtonal• 7 years ago

I think another issue is that on Apple's platforms the changes are quite abrupt, whereas most other platforms are gradual. E.g., if you wrote a Qt (the toolkit) application in 1996, you could have slowly transitioned your application to Qt 5 version by version. In the meanwhile, you have gone from non-standardized C++ to C++98, to C++11. So, you would have an application with a modern language and toolkit, which was gradually developed over the last 23 years. The same for Windows applications.

For me, the truth is somewhere in the middle. Yes, there is more churn on Apple platforms. On the other hand, it also allows Apple and the ecosystem to move faster. It is amazing what they have been able to achieve with (just naming some random things): wide Touch ID support, Metal, or application sandboxing.

galad874• 7 years ago

You could have done the same with Carbon to Cocoa: transition a window/view at a time. You can use Cocoa windows and views in Carbon.

Plus you can keep using your C++ core even if the UI is Cocoa. The same applies to Swift, you can write or rewrite parts of the app in Swift and keep part of it in C++/Rust/Objective-C or your preferred language.

The same happens in SwiftUI, you can mix it with NSView and UIViews.

plorkyeran6• 7 years ago

Carbon continued to work for 13 years after it was officially deprecated. Waiting over a decade to get started on a transition doesn't mean that the transition was abrupt; it just means that you procrastinated until you got a hard deadline and so caused scheduling problems for yourself.

sneak• 7 years ago

I think that is precisely what they are doing. I can run apps that worked on Windows 95 today in 2019 unmodified. Cocoa or not, I can’t do that with osx apps that are even 3-5 years old sometimes.

Microsoft and Linus have a specific fanatical attitude about the installed base of existing apps. Apple simply does not.

pornel• 7 years ago

I actually like that. Some software dies and makes room for more modern replacements. All Mac software that I have is modern and consistent.

Contrast this with Windows, where browsing through system settings is like going back in time from Windows 10/8 to XP to 95 all the way to 3.11, if you click "Advanced" enough times.

Some Windows applications (especially installers) pop up dialogs that don't support anti-aliased fonts. It gives an impression of an OS with wildly inconsistent GUI and legacy garbage all over the place.

pgcj_poster• 7 years ago

Linus personally has really strong opinions about breaking userspace, but the Gnu/Linux distributions do not. Heck, when I installed Inkscape from the Debian 10 repositories, copy and paste wasn't working because they decided to remove python-uniconverter due to bugs.

cpuguy833• 7 years ago

Linux is a very different case. Linus is talking about the kernel breaking comparability with userspace.

The kernel not breaking userspace is quite a different thing, and in particular when comparing the macOS kernel and Linux because Linux specifically has a stable ABI and macOS doesn't. On macOS it's libsystem that provides the stable abi and kernel interfaces change underneath.

Beyond the kernel API's and libsystem you have the actual platform interfaces. Carbon is a deprecated framework and has been for a long time. If apps are using carbon then they must get updated, Apple has been warning about this since 2017 (beyond just the depreciation notice in 2012 and everything in between).

And Windows95 apps almost certainly do not run unmodified... it's been awhile and things may have changed, but as I recall in XP (sp2, even?), they introduced the thing to run an app in compatibility mode and you actually select which is version to be compatible with. This works in some cases and not in others. Not to mention win32 support has held back Windows stability and progress for a long time.

Mikhail_Edoshin2• 7 years ago

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.

xhruso003• 7 years ago

Apple dropped security updates on El Capitan with release of Mojave. El Capitan is supported on MacBooks from 2009. I think it's time to upgrade.

plorkyeran6• 7 years ago

Under 1% of homebrew users are on 10.11 (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.

reaperducer6• 7 years ago

Since macOS updates are free, is there a reason you haven't moved off of El Capitan?

Do you just like the way it looks and feels? Is there an essential program that you use that need El Cap? Are you using a 2008 MacBook?

I'm not being critical. I have to run Jaguar on a dedicated machine I keep in the closet for a niche reason, so I'm curious what problem you face.

saagarjha13• 7 years ago

Homebrew in general is very aggressive about dropping support for older versions.

ratww7• 7 years ago

On the other hand, I've been programming in Windows since about the same time.

In the GUI front I had to work on Win32, MFC, WebForms, Silverlight, XAML and WinRT.

I've been trough two DirectX breaking upgrades where we had to rewrite pretty much everything that touched the API because of deprecations.

Sure, old things keep working for users, but if you stick with ancient technology it gets way too hard to hire developers.

I'm not complaining though: I love writing code and upgrading things is a breath of fresh air. Every Microsoft API was significantly better than the one preceding it, IMO.

jmnicolas2• 7 years ago

I write Windows desktop app in WPF since December 2009 and I'm confident that I won't write them in anything else for at least the next 10 years (desktops are supposed to be dead by then but I hope the 'visionaries' are wrong.

kitsunesoba4• 7 years ago

Furthermore, from the start Carbon was intended as a transitionary solution and Apple told devs this many many times. Carbon apps were supposed to be the bubblegum-and-duct-tape answer for holding users over while you worked on your Cocoa version. It’s not Win32 or MFC and Apple never claimed it was.

AprilArcus2• 7 years ago

This is true in hindsight and seemed obvious at the time, but in fact Apple insisted that Carbon was a long-term solution and treated it as an open-ended commitment. They dogfooded it internally, using it to write the Finder and iTunes, two first-party apps so central to the user experience that novices confused them for the OS itself. There were working betas of Carbon 64, and Apple's decision to reverse course and deprecate Carbon on 64-bit platforms in the middle of the release cycle caused significant developer whiplash.

vor_2• 7 years ago

Carbon wasn't presented that way in the beginning. They were supposed to be the three equal pillars of OS X development. Carbon was the C-based procedural framework, Objective-C was the object-oriented framework, and Java was, well, the Java framework.

That's why they have drink-themed names to fit with Java. Porting a classic Mac app to Carbon was called "Carbonization."

reaperducer6• 7 years ago

Carbon UI framework has been deprecated for 12 years

Interestingly, Carbon still pops up here and there, even in programs from large companies with tons of resources like Adobe.

The giveaway is when you ask it to do something hard and instead of getting the SPOD, you get the watch icon.

kzrdude• 7 years ago

As a kid who learned computers on Mac OS 7, that's beautiful

Klonoar6• 7 years ago

The NSMenu system is still Carbon actually, as far as I know (last I dug deep into it).

threeseed2• 7 years ago

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.

ubercow133• 7 years ago

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

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.

matwood2• 7 years ago

From iOS version to version the API typically does not change that much. The big changes are often new APIs, and those are also the ones most often in flux. Adding support for the Apple Watch or Shortcuts for example.

I never found iOS API changes any more extreme than Android or the web.

blub8• 7 years ago

Essentially yes. Apple apps require constant maintenance between SW versions as proven by the quantity of compatibility updates on every new iOS version ever.

A particularly funny case was one otherwise rock-solid app which started SIGBUS'ing on iOS 13.

Nokinside• 7 years ago

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.

seanalltogether• 7 years ago

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

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

tannhaeuser• 7 years ago

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

saagarjha13• 7 years ago

deprecation of semi-official Mac OS ports without equivalents on brew

Apple doesn’t deprecate ports, since they don’t run it.

badsectoracula19• 7 years ago

In other saner platforms (Win32 or even X11, if you ignore Gtk and Qt) you can pretty much assume that if something is deprecated it will still remain around even if it wont get updates as doing otherwise will break all the applications that rely on that tech that people bought and rely on. Especially when that deprecated something is still used by developers despite it being deprecated.

But apparently Apple doesn't care about their users and developers.

Saying "told you so" doesn't help much, the only thing that helps is keeping things working. Anything else doesn't matter.

Though if there is anything that can be "told you so"'d that would be bothering with Apple's platforms when Apple doesn't care about you.

calcifer2• 7 years ago

X11, if you ignore Gtk and Qt

You don't need to ignore those. GTK+2 was released ~17 years ago and Qt4 was ~12 years ago. Apps written with them still run perfectly fine on modern Linux distros.

swerner4• 7 years ago

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

Klonoar6• 7 years ago

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.

protomyth4• 7 years ago

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.

Synaesthesia3• 7 years ago

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.

protomyth4• 7 years ago

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

quelsolaar5• 7 years ago

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.

wffurr• 7 years ago

Use ANGLE and keep writing OpenGL. It has Metal and Vulkan backends and papers over all the various GL driver bugs.

quelsolaar5• 7 years ago

There are workarounds for everything. The problem with the Mac is that I have to work around everything. No C API, XCode, lack of extension support, driver bugs, poor documentation, weird manifest files, the OS switching run directory randomly... You cant behave like that when you are a small platform.

jiofih3• 7 years ago

On the other hand, as a user, this is one of the reasons I switched to Macs a decade ago. The apps available were of extremely high quality and actively supported.

If something with a GUI hasn’t been updated in 20 years, chances are it’s not gonna be stellar software. Both technology and UI conventions have changed a lot.

quelsolaar5• 7 years ago

No you dont get it. It's not about maintaining or not, its about what a developer spends their time on. Do you want the developer to spend months moving the code from one legacy API to a new one, that will give the user no tangible benefit, or do you want the develop new features requested by the users?

lonelappde5• 7 years ago

It's gonna be 100times as fast as modern software, for one thing. And more debugged too.

wayneftw4• 7 years ago

What Mac-only apps that you use do you consider high quality?

I’m asking because outside of some big ones that I don’t use, like Final Cut Pro or Pro Tools - most of the Mac apps I’ve found are very low on features or “options” (flexibility). They all seem to try and follow Apple’s model of only serving the happy path and completely ignoring anyone who needs more than that - e.g. power users.

Even normal users get annoyed by this tendency, like recently when Apple removed the “mark all as read” option from Mail in iOS.

eecc• 7 years ago

Every hour spent on maintaining a mac port is an hour not serving the 90% of users who aren't on Mac

Oh come on spare us the ethics lesson. You know perfectly well that OpenGL is an archaic stone around the neck for many developers. To the point that many (all) industry players are trying their hand at superseding it (of course also for lock-in, but that’s not the only reason.)

During transitions things come and go, adoption sway and ideas change.

Deal with it, it’s a fact of life

rleigh• 7 years ago

It's also a fact of life that that economics dictates where effort is spent. If I port all my OpenGL code to Metal, that's a big undertaking in both time and money. And what do I gain? Nothing. The program will render the same views both before and after the change. It's not directly adding value. So why would I bother?

Also bear in mind that I currently support the application on Windows, Linux, FreeBSD and MacOS. OpenGL rendering works the same on all four platforms, and I have a unified cross-platform codebase which compiles without any trouble on all of them. If I switch to Metal, that's going to mean dropping all the other platforms which use OpenGL. Or it's going to mean having a separate MacOS-specific implementation for Metal. Dropping the other platforms is unacceptable.

MacOS is a niche. Windows is a bigger market. Depending on the application, Linux might be as well. Consider that Windows, Linux, and even FreeBSD can support beefy modern GPUs while MacOS is quite limited in the on-board GPUs on its laptops and other systems. When push comes to shove, MacOS is the platform which I will drop first. It's already got the oldest and most limited OpenGL implementation and the poorest hardware, and this makes it the worst choice for running my application in the first place.

If Apple want to retain developers like me, then they can provide a first-class current OpenGL implementation based on top of Metal. And then they can also provide a high-quality Vulkan implementation also based on top of Metal (or the other way around). Because if I do upgrade, I'll be upgrading to Vulkan on all four platforms, not to Metal.

DCKing4• 7 years ago

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.

badsectoracula19• 7 years ago

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.

quelsolaar5• 7 years ago

My application, does precisely what i want in terms of graphics, and runs at 600FPS. Explain to me why my users would benefit from me spending months switching to a different API? Life is too short for that. The loosers in all this are the Mac users. The reason to support Mac is to be nice to the users, not because it makes financial sense. If apple is going to actively make it harder why bother?

vbezhenar4• 7 years ago

They could implement OpenGL API over Vulkan, so it's just a library, no need to touch drivers.

bepvte• 7 years ago

Gallium3D is a framework for building drivers, not a graphics API. The intel drivers do not use gallium3d (yet), and neither do nvidias.

overgard• 7 years ago

I think it would have been a lot more palatable if they hadn't gone off and made their own API (why not Vulkan?)

notfudplease• 7 years ago

This is blatantly false.

You may be thinking about OpenGL 1.x and the fixed pipeline. Modern OpenGL is perfectly capable of running virtually every game and professional app out there.

OpenGL does NOT work on macOS and hasn’t worked for a very long time. Apple only allows to use an ancient version of OpenGL, which is not really my definition of “working”.

Nobody is going to ever remove OpenGL from Linux (or Windows) drivers. OpenGL/D3D powers everything there. Vulkan and Direct3D 12 are just the lowest level and are not a replacement for OpenGL nor Direct3D 11. Drivers may implement them on top of Vulkan/D3D12, but removing? Never.

Finally, Apple has never told anybody to use MoltenVK because they don’t want you to. And I would not be surprised if they end up banning such layers if they find they get popular.

ryandrake• 7 years ago

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.

This is only a problem for game developers who live right on the GPU hardware and need to squeeze absolutely all the performance out of it. Which is probably a small number of admittedly very important developers: Game engines and AAA studios. For the rest of developers who have more modest requirements, I don't really understand what "modern" graphics APIs provide, besides tons of extra boilerplate code and headaches.

When I was a graphics programming newbie, it was great to have the whole fixed function pipeline all set up and ready for me to experiment and learn. If I had to learn from nothing on Vulkan, I'd probably have given up before the first 1000 lines. Drawing a triangle in OpenGL vs. Vulkan: http://sol.gfxile.net/temp/hellotriangle.png

It's so strange--in most of the software world, newer APIs and tools tend to be higher and higher level abstractions. "Modern" Electron apps run Javascript, HTML and CSS on an embedded browser which itself running on a high-level native toolkit which is probably written in C or C++, which compiles to assembly, etc. You can have a web server in one line of python. In contrast, the more modern graphics APIs get, the lower-level and more verbose they get.

TheKnack• 7 years ago

There are well supported ways to keep using OpenGL on MacOS and iOS. This company is offering a wrapper that makes OpenGL run faster on top of Metal than it did natively, and promises support for future OS versions indefinitely..

https://moltengl.com/

mjw1007• 7 years ago

So I suppose if Apple cared about not being hostile to developers they'd have the option of buying that company and giving the product away for free.

wjakob• 7 years ago

Note that this is only for OpenGL ES!

coldtea10• 7 years ago

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.

I think their idea is, if you're not going to make a full-on Mac app -- leveraging the extra capabilities, the native APIs, the native look, etc and updating with the platform --, don't bother.

It's perhaps too much for its small market share (2-10% depending on region, though with much better share of the richer, actually-paying-for-software demographic), but if that wasn't the case, what would really differentiate macOS from Windows?

Just the UI and under the hood stuff, when both are running the same identical apps and codebases?

musicale2• 7 years ago

It's an example where some effort on Apple's part would save a multiplicative factor of developer effort and user frustration. I expect the cost to users of a couple hundred megabytes of flash storage is a fair trade-off for not having your apps break with every yearly iOS update.

mwyah• 7 years ago

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

blinkingled• 7 years ago

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.

badsectoracula19• 7 years ago

Depends on what you used, i guess. I bought an iMac in late 2009 which i think came with Snow Leopard and i upgraded to new macOS versions whenever they came out up until El Capitan which was the last version to support it (i've heard that you can run Sierra with an unsupported patch too but didn't try it). I've also got (some bought, others free) a few applications from their developers' sites - that was before the Mac App Store.

After every single macOS upgrade some application would stop working. By the time i installed El Capitan, no application that i had installed since the Snow Leopard days worked.

Mac App Store didn't help either though. I've only bought a couple of applications from there, but one game - NOVA 3 - broke after an OS upgrade (do not remember which) and then was removed from the store instead of being updated. Of course this is partly the developers' fault, but on Windows this would never have been an issue as i have games and applications more than a decade older than NOVA 3 that still work on the latest Windows 10 with little to no fixes.

I also had a similar case with iOS - i got an iPod Touch some time ago, bought a bunch of things, several versions later nothing worked. Eventually the device itself stopped being supported and developers were both forced to not support it and did require later versions of iOS. Typical case of forced obsolescence since otherwise it was a fine device.

This experience alongside Apple's attitude towards (ignoring) backwards compatibility is what makes me stay away from their systems.

mantap4• 7 years ago

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.

kitsunesoba4• 7 years ago

Having updated OS X 10.0 era Cocoa apps to run on modern macOS, it’s really not that bad. Actually, it’s way easier than I’d expect given the age of Cocoa and how its first few years were full of rapid evolution.

plorkyeran6• 7 years ago

Simple ten-year-old 64-bit Cocoa apps will generally run on modern macOS with no changes. The more complex your app is the more likely it is to have been broken by an OS change since macOS is not especially concerned with backwards compatibility, but the actual APIs you're programming against won't have changed much in that time.

charlesism2• 7 years ago

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.

badsectoracula19• 7 years ago

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

charlesism2• 7 years ago

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

matwood2• 7 years ago

it’s lousy to know your work will disintegrate in five or ten years.

I think it has always been this way. Software does rot if not maintained. If it's not through API changes, then it's security issues.

rcarmo• 7 years ago

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.

dagmx• 7 years ago

Without using their software, and just going based off of screenshots, I don't see anything that couldn't be ported to Qt fairly easily.

Now if there is a lot of intertwined code that makes the UI less portable, that's another issue, but I currently don't see how their UI layer could be so complex as to not be easily shifted to Qt.

The cross platform nature alone would be worth the cost in my opinion.

silvestrov• 7 years ago

Or even electron (gasp). The application looks like simple webpages.

It might even work better as a web site, so the customers don't have to worry about backups, sharing data, etc.

ralfd• 7 years ago

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.

ratww7• 7 years ago

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.

seltzered_3• 7 years ago

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

Apparently they tried QT in 2015: https://turtlesoft.com/wp/?p=198 .

js22• 7 years ago

Goldenseal was written in C++, using the CodeWarrior Pro development environment. We used the PowerPlant application framework (part of CodeWarrior). The layout for some windows was done using Constructor (also part of CodeWarrior). CodeWarrior is a great program. Thanks, Metrowerks!
The basic database features in Goldenseal are based on NeoAccess, licensed from NeoLogic Systems. Unfortunately we ended up re-writing a large percentage of the code there, which explains 6 or 8 months of the delay in our shipping date.
We have used OOP (object oriented programming) throughout Goldenseal. It's a very good programming model which makes it easy for us to add new features, without getting lost in the 5+ million lines of code that the program now contains. A lot of that is comments and spacer rows, but it still represents many programmer-years!
We estimate that about 50% of the code is for the basic interface—screen display, file management, mouse behavior. About 25% handles data storage for the many object classes, and 25% handles posting, action dialogs, basic accounting and estimating features.

https://www.turtlesoft.com/Goldenseal-Software-Reference/Sof...

princekolt• 7 years ago

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.

swerner4• 7 years ago

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

vlozko• 7 years ago

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.

kec2• 7 years ago

Garbage collection was deprecated almost immediately after it was released and has never been supported on iOS (which let’s be honest is the target for 95% of all cocoa developers)

protomyth4• 7 years ago

Well, to be technical, the OpenPanel API changed pretty drastically too.

I would expect that a second round of problem will come up because Swift is going to get access to APIs that Objective-C will not get.

gok• 7 years ago

This was a developer that didn't even bother moving to Cocoa yet

ciconia• 7 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

mantap4• 7 years ago

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.

galad874• 7 years ago

Notarization is an automated process, it's not an app review, there is no "begging". Anyway, you can just run unsigned apps on macOS.

ttoinou• 7 years ago

Yes, but for how long is this going to last?

sjwright• 7 years ago

Apps aren't required to be notarized and it trivial for any vaguely competent person to dismiss the one-time warnings about unsigned apps. So it's only a big deal if you choose to make it one.

To be perfectly honest, if you can't even jump through that absurdly minimal hoop, I wouldn't want your software running on my mother's computer anyway.

mantap4• 7 years ago

Apps are required to be notarised. You can turn the requirement off, but that doesn't negate its existence.

I hope you and your mother are happy living without open source software. No good deed goes unpunished.

zapzupnz2• 7 years ago

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.

notarized_off• 7 years ago

It's a power grab.

University students and people from countries on the US trade sanctions list will (I predict) not be able to share binaries in a future macOS, for example. It also gives apple a way to ban certain categories of program at the behest of the legal apparatus they have to operate in.

You can turn it off now, but you can't tell me you will always be able to turn it off.

I will abandon macOS when it is financially convenient - I hope you are delighted.

mantap4• 7 years ago

I used to write a lot of apps for Mac. Including free and open source software. Now I have to pay $$$ and jump through hoops just to keep on doing it. It is amazingly arrogant for them to expect me to pay for doing them a free service. You can have as much autoschadenfreude as you want.

dang• 7 years ago

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

https://news.ycombinator.com/newsguidelines.html

perspective1• 7 years ago

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.

andrew_• 7 years ago

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.

badsectoracula19• 7 years ago

Their UI inconsistencies (i find the UX perfectly fine myself) mainly comes from their insistence on creating new toolkits left and right due to their internal power struggles. They have improved existing stuff several times, but they most likely have a Google-like situation where new stuff is rewarded more than keeping old stuff running (though unlike Google they also manage to keep old stuff running, so perhaps things aren't as bad).

noisem4ker2• 7 years ago

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

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.

spsful• 7 years ago

...Political?

GnarfGnarf• 7 years ago

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

mikece• 7 years ago

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.

m-p-3• 7 years ago

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.

sercand• 7 years ago

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.

c-smile2• 7 years ago

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

abujazar• 7 years ago

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

TheOtherHobbes• 7 years ago

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.

macintux2• 7 years ago

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.

pier255• 7 years ago

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.

KibbutzDalia2• 7 years ago

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.

pier255• 7 years ago

FYI Flutter basically works like a game engine.

seltzered_3• 7 years ago

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.

lonelappde5• 7 years ago

His users are surely customers from 20years ago who never wanted to switch to anything new.

blub8• 7 years ago

This is exactly how software should be: it should just work reliably for years and decades on end.

fortran77• 7 years ago

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

seltzered_3• 7 years ago

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

mrpippy2• 7 years ago

The screenshot is from classic Mac OS, which means it’s at least 15 years old. I love the classic Mac OS, but a product being actively sold for much newer OSes needs up-to-date screenshots.

tolmasky• 7 years ago

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.

xhruso003• 7 years ago

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

FpUser7• 7 years ago

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

thesquib6• 7 years ago

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

reaperducer6• 7 years ago

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.

ratww7• 7 years ago

Curiously, the website of the software in question has been using the same design since at least early 2003

https://www.turtlesoft.com

https://web.archive.org/web/20030420115300/http://www.turtle...

donatj• 7 years ago

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.

guitarbill3• 7 years ago

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.

vbezhenar4• 7 years ago

Hacker News looks like it was from 1995. Works fine for me.

reaperducer6• 7 years ago

But HN is updated minute-by-minute. It's up to date. The guy moaning in on the Apple listserv said he hasn't touched his Windows app since 2000.

yyyk• 7 years ago

You're reading him too literally, and in the process create a strawman. It's obvious he updates his software; Business software must be updated to match changing legal requirements, besides a nonsubscription business has nothing to sell without updates.

He's saying that Windows per se did not require extra work for compatibility after he got it done since forever, while Mac needs adjustments and rewrites every once in a while, and the last time was too much for him. I guess he'd rather spend the time doing features.

coldtea10• 7 years ago

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

pjmlp10• 7 years ago

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.

coldtea10• 7 years ago

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.

ratww7• 7 years ago

In another post they mention that four different contractors tried to update their software and gave up, on top of the four years they spent themselves.

I think the problem is that their software is just a complete mess but they won't admit it. This whole thing has "sunk cost fallacy" written all over it.

twarge• 7 years ago

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.

FpUser7• 7 years ago

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

thesquib6• 7 years ago

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

floatingatoll• 7 years ago

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

musicale2• 7 years ago

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.

cmsj• 7 years ago

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

Thoughts on Cocoa

Related Stories