Didn't expect to see cappuccino mentioned ever again. It was so wild, you can use AppKit documentation for cappuccino. Apps were so pretty and yet so fast.

I remember back in 2009 I really liked their coffee machine icon. I emailed the devs, they referred me to some design studio, and then to my surprise they replied and said that it's Francis Francis X1. Now I'm looking at it in my home office.

Holy shit, it’s still being actively developed and maintained https://github.com/cappuccino/cappuccino

Same. I remember when this first came up and I was like "this is so weirdly interesting."

Sad that they got acquired because it was just fascinating what they were doing, even if I was never going to use it.

Anyone know if this is or ever was the basis for Apple's iCloud web apps on iCloud.com (e.g. Keynote / Pages / Notes etc.)? Those apps are heroic attempts to replicate the desktop app experience in the browser. I'm curious what web framework is underlying it. Side note - if I could install 3rd party apps w/ similar UIs in my iCloud dashboard that would be interesting.

Weren't they acquired by Motorola?

Obj-C’s simplicity can be nice, but on the other hand I don’t miss having to bring in a laundry list of CocoaPods to have features that are standard in Swift. I don’t miss maintaining header files or having to operate in old codebases that badly manage Obj-C’s looseness either.

>[1] https://github.com/swiftlang/swift-evolution/blob/main/propo... -- apologies to the authors, but even as a previous C++ guy, my brain twisted at that. Inside Swift is a slim language waiting to get out... and that slim language is just a safer Objective C.

These kinds of features are not intended for use in daily application development. They're systems-language features designed for building high performance, safe, very-low-level code. It will be entirely optional for the average Swift developer to learn how to use these features, just in the same way that it's optional for someone to learn Rust.

I go back and forth. I do miss the simplicity of objc at times though. I think in a short amount of time someone can become close to an expert in objc. Swift is already incredibly complicated and there's no end in sight.

> Inside Swift is a slim language waiting to get out... and that slim language is just a safer Objective C.

Rust? Rust is basically a simpler Swift. The objective-c bindings are really nice too, and when you're working with obj-c you don't have have worry about lifetimes too much, because you can lean on the objective-c runtime's reference counting.

I think the way to think about it is that with Rust, it's as if all the goodness in Swift was implemented with in the "C" level, and the Objective-C but is still just library-level a runtime layer on top. Whereas Swift brings it's own runtime which greatly complicates things.

Obj-C does have a "nonnull" annotation now (apparently added to assist Swift interop). One of the final jigsaw pieces turning it into a really pleasant language.

I don't think objc has the equivalent of a null pointer exception. You can freely send messages to a deallocated object. Since ARC, it is rare, at least in my experience, running into any memory related issues with objc.

Objective-C did not have null pointer exceptions, though some libraries added them.

If you use Objective-C objects, operations on null pointers are just a no-op, so there is not such thing as chasing exceptions.

Interestingly, I recently auto-translated wget from C to a memory-safe subset of C++ [1], which involves the intermediate step of auto-converting from C to the subset of C that will also compile under clang++. You end up with a bunch of clang++ warnings about various things being C11 extensions and not ISO C++ compliant, but it does compile.

[1] https://duneroadrunner.github.io/scpp_articles/PoC_autotrans...

The one really funny feature of Objective-C++ is that it lets you write C++ using modern C features that haven't been pulled into C++, and you don't have to actually use the Objective part. Designated initializers before C++ got them were the main actually useful application of this.

I think C++ have caught up with C99 already. So it's late 90s, not mid-90s :)

What C features can you not realistically use from C++?

I've been playing around with low-level Metal a bunch lately, any many of their docs and samples seem still be mostly in Objective-C/C++ and not Swift, so have been forcing myself to get into it.

At first I had the usual revulsion to the syntax, but after a few days getting used to it, I actually don't mind it at all now. (I still wouldn't say it's "elegant", but I can live with it).

Being Metal shader code is basically C++ anyway, and C++ is a language I'm familiar with, having a couple of .mm files to hold the Objective-C++ for API bridging and working in regular .cpp (and .h) files for the rest is pretty straight forward compared to having to learn Swift. (Especially with all the complaints I've heard about its complexity, including from Chris Lattner himself lately, which aligns with some of the other comments here).

Though to be fair, "Swift seems overly complex so use C++ instead" seems like a tough argument to make with a straight face ;-p

Yeah, Objective-C++ is surprisingly great. It sounds like a terrible idea, but the bridging works pretty much seamlessly, and Obj-C and C++ don't actually overlap all that much so they don't step on each other's toes. Each language has strengths that shore up the weak spots in the other.

Obj-C++ was used for some hall-of-fame OS X apps, e.g. TextMate

I made some camera and GPU-heavy features in the Facebook and Instagram app in ObjC++, and yes, it was nice to have that impedance match.

I don't work there anymore, I wonder if they're using the C++ - Swift interop that now exists.

I hadn't come across this. Insane (if true, I've never tried) that GnuStep is not 100% compatible, surely that would be the point.

How easy is it to port, say, a Leopard-era Objective C app to ObjFW?

That is one advantage of C++ - you can use higher level features like generic data types/algorithms, member functions, constructors, destructors, and iterators and still have performant code. You can use object-orientation without having to heap allocate each object and pay the cost of "virtual" calls. (which many other object-oriented languages couple together)

When I was writing apps at Apple for the low-integer-version-numbered iOSes, this is what we typically did (since we had a single-core CPU in the MHz and <1GB).

UI shell in UIKit Obj-C, over a C++ or CoreFoundation (C) business layer, talking directly to sqlite.

I haven't seen the source of Apple apps and frameworks in over 10 years now, but I hope for their sake a lot of it has moved to Swift by now.

If I were CFed I'd mandate 2026 as the Year of Claude Code Radar Burndown. Their backlogs are insane and Apple actually addresses maybe 5% of what it knows to be wrong in a given year. Make it 2% when a UI Refresh is mandated.

They're function calls right? I can't square the "message passing" conceit (implying putting message objects on queues, dequeuing etc) with the claim that Obj-C is just C with some extra stuff.

Writing objective-c code for mac os GUI apps was one of those things that finally made "interfaces"/"protocols" really click for me as a young developer. Just implement (some, not even all) method in "FooWidgetDelegate", and wire your delegate implementation into the existing widget. `willFrobulateTheBar` in your delegate is called just before a thing happens in the UI and you can usually interfere or modify with the behavior before the UI does it. Then `didFrobulateTheBar` is called after with the old and new values or whatever other context makes sense and you can hook in here for doing other updates in response to the UI getting an update. If you don't implement a protocol method, the default behavior happens, and preserving the default behavior is baked into the process, so you don't have to re-implement the whole widget's behavior just to modify part of it.

It's probably one of the better UI frameworks I think I've used (though admittedly a lot of that also is in part due to "InterfaceBuilder" magic and auto-wiring. Still I often wish for that sort of elegant "billions of hooks, but you only have to care about the ones you want to touch" experience when I've had to use other UI libraries.

> Writing GUIs for the Linux desktop is also a terrible experience.

I've found the DX for GTK to be at least tolerable. Not fantastic, but I can at least look at a particular API, guess how the C-based GObject code gets translated by my language bindings of choice, and be correct more often than not. The documentation ranges from serviceable to incomplete, but I can at least find enough discussion online about it to get it to do what I want.

Also, GTK apparently ships with a built-in inspector tool now. Ctrl-Shift-I in basically any GTK app opens it. That alone is extremely useful, and you basically have to do nothing to get it. It's free.

I've never tried Qt. The applications that use it always seem off to me.

As for OLE, you're actually thinking of COM, not OLE. They were co-developed together: COM is a cross-language object system (like GObject), while OLE is a set of COM interfaces for embedding documents in other arbitrary documents. Like, if you want to put a spreadsheet into a Word document, OLE is the way you have to do that. Microsoft even built much of IE[0] on top of OLE to serve as its extension mechanism.

OLE is dead because its use case died. Compound documents as a concept don't really work in the modern era where everything is same-origin or container sandboxed. But COM is still alive and well. It's the glue that holds Windows together - even the Windows desktop shell. All the extension interfaces are just COM. The only difference is that now they started packaging COM objects and interfaces inside of .NET assemblies and calling it "WinRT". But it's the same underlying classes. If you use, say, the Rust windows crate, you're installing a bunch of language bindings built from WinRT metadata that, among other things, call into COM classes that have been there for decades.

Mac apps are Mac native because Apple gives enough of a shit about being visually consistent that anyone using a cross-platform widget toolkit is going to look out of place. Windows abandoned the concept of a unified visual identity when Windows 8 decided to introduce an entirely new visual design built around an entirely new[1] widget toolkit, with no consideration of how you'd apply any of that to apps using USER.dll/Common Controls. As it stands today, Windows does not have a good answer to "what widget toolkit do I use to write my app", and even Microsoft's own software teams either write their own toolkits or just use Electron.

[0] Petition to rename ActiveX to WebOLE

[1] OK, yes, XAML existed in the Vista era, but that was .NET only, and XAML apps didn't look meaningfully different from ones building their own USER.dll window classes like it's 1993.

Apple should have made a modern Smalltalk on top of the Objective-C object model as a replacement for Objective-C instead of Swift.

I want to love Swift, but the funny thing is that as they solve more problem with Swift they also add so much complexity that you wonder if all the problems they solved just added new problems.

Hopefully, you're using ARC by now, so that's a no-op!

I wonder how well AI generates Obj-C - it might well produce better quality code for your token/buck!

In a previous life, one would select the programming language according how expensive developers were. Nowadays it's the quality that an AI can generate. What a wonderful future we've put together. /s