> every year I try to learn how to create an XCode basic app and it’s different.

https://ardour.org was first ported to then-OSX in 2006. Almost nothing in the codebase that relates specifically to now-macOS has changed in that time.

XCode is a tool, not a platform. Cocoa is the platform, and it changes very little and very infrequently.

This is irrelevant in terms of developer experience. I’m sure it’s possible to maintain an existing app for years and years, but if every blog post in existence is written for a different version of the development environment (which are vastly different from each other) and the OS Vendor (Apple in this case) is deleting or never even producing documentation on these APIs, which definitely happens, the rot is too much to keep up with for people trying to learn the system.

One of the jobs of a software developer is to understand that companies that produce proprietary systems (such as Apple) have their own incentives that do not always align with the desires and needs of those creating software. Put simply, this means that you do not trust those companies to do the right thing for you, and instead you need to identify what level of their technological offerings seem most likely to represent the correct entry point for you/the project.

When we first ported Ardour to OSX/macOS, it was abundantly clear that XCode was a non-starter in terms of technology, partly because it was single platform, and partly because its scope was too large - as Unix-based developers we understood the merits (and occasional pain) of more modular toolsets. So I found a handy guide to writing "nibless applications" that completely removed XCode from the picture (along with some Cocoa boilerplate code that isn't actually required). As a result, we've continued to interact with the stable API core of Cocoa, even as Apple dither around the edges.

Apple (and Microsoft and .... ) are not your friends. They want you to build software for their platforms, but beyond making that possible in some way, their incentives do not align with yours in any substantive way (partly because they make software too, and have their own API goals and needs that may/will conflict with yours). If you don't understand this, you're inevitably going to have the sort of experience you describe above.

I don’t disagree with anything you said. If anything, it just supports my point that native development is needlessly hard. Again, none of this has been true of the browser vendors. They have every incentive to get people to use their stack and make it nice.

By the way, a blog post on how to create Nibless apps would be invaluable.

Not sure about browser vendors and their stack. I almost never hear of anyone who develops on a browser vendor's stack, they use 3rd party tools in JS and CSS and webasm etc ... After Node wrapped up the DOM and put a bow on it, it seems that people move on (up? down? sideways?) from webdev at that level (except the people developing alternatives to Node).

I'm not sure if this is the source I used, because the date is a little late, but it seems very thorough and excellent:

http://lapcatsoftware.com/blog/2007/05/16/working-without-a-...

I use the term native to mean "an application that runs on the metal and has direct access to system calls, not in a VM of any kind, including a browser".

Qt is native in that sense, just as much as any other toolkit designed for the same purpose.