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.
Sad that they got acquired because it was just fascinating what they were doing, even if I was never going to use it.
SproutCore 2.0 became Ember.js 1.0, but I don't know if Apple are still using it.
No idea if they ever did anything with it!
I'm on the outside, but best I can tell:
- You're thinking of a UI design tool called "Ninja"
- Google purchased Motorola Mobility and the Ninja project got cancelled
- Google launched Google Web Designer, that basically had an almost identical UI. As far as I can tell the internals are different, but probably shared some code or at least design work.
(There's a decent argument it encountered it in iOS and macOS too.)
[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.
[2] https://medium.com/goodones/pareto-optimal-apple-devtools-b4...
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.
That said, the Swift 6 / Strict Concurrency transitions truly have been rough and confusing. It's not super clear to me that much of it could have been avoided (maybe if the value of Approachable Concurrency mode had been understood to be important from the beginning?), and the benefits are real, but my gut feeling is that a lot of the "Swift is too complicated" stuff is probably just misplaced annoyance at this.
Simple example:
Objective-C
if myObject {
}
in swift if myObject != nil {
}
Also opitionals in swift could have totally be avoided if they adopted a prototype based langue (basically object are never nil). Lua did this, and it is very elegant
But meanwhile, we got a half backed optional system, which is backwards (similiar to Java), and didn't help with the practicality of the language at all, and meanwhile you still can crash an app doing myArray[1]
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.
I get that there's a tradeoff. Rust requires you to be way more explicit about what you're intending upfront and that can, in the long term, lead to simpler code -- but there's no dimension (depth-wise or breadth-wise) that I'd call Rust simpler.
Swift already does have those things but unlike Rust, they are opt-in.
Not going to argue which language is simpler, but sorry, you don't seem like someone who knows Swift very well.
Swift is a nice language, and it's new support for the bare necessity of affine types is a good step forward, but it's not at all comparable with Rust.
* automated exclusivity with value types and value witness tables, classes as arc types (ie Arc<Mutex<T>>)
* automated interop with C/C++/Obj-C through the clang ast importer
Maybe they could have started with rust and added on what they needed, but why not build a new language at that point where things so fundamental are involved?
Source: I worked in lattners org at the time of swifts inception (on an unrelated backend) but that was the motivation. I also worked on the swift compiler for a little bit some years later on in my career.
Having done both ObjC with nonnull annotations, and Swift, I agree that it’d be hard to forgo the having first-class support for Optionals
[1] https://duneroadrunner.github.io/scpp_articles/PoC_autotrans...
That's all. Enjoy yourselves.
How easy is it to port, say, a Leopard-era Objective C app to ObjFW?
- There was a bug or two I had to patch, but the code is readable, so it wasn't a big deal
- OFString, etc aren't intended to be 1:1 replacements for NSString, etc. This wasn't a real problem. They mostly match, and all I needed to do was write a few categories
- The runtime functions are not compatible at all, but most projects wouldn't touch those
- CoreFoundation and the other C APIs are not there at all, so you'll need replacements
- It is a replacement for Foundation framework, not AppKit, so if it is a GUI app you still have a lot of work to do
My main complaint with GNUstep is the licensing. The runtime itself is MIT which is great, but its implementation of Foundation/AppKit is LGPL. ObjFW, including its runtime, is LGPL. At least with GNUstep one day I can create my own version of Foundation based on Cocotron or swift-corelibs-foundation or something, and not need to muck with rpaths + ship a bunch of .dll/.dylib/.so files with my app in order to comply with the license.
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
I just wish there were Objective-C bindings for more CF classes without having to mess with C.
I don't work there anymore, I wonder if they're using the C++ - Swift interop that now exists.
That aside, I was glancing through the source code for the engine and noticed this:
https://codeberg.org/brentsimmons/SalmonBay/src/branch/main/...
I wonder why they opted to do this instead of NSJSONSerialization - maybe I'm just misunderstanding the use for the class tho.
I shipped a cross-platform C# project, and once I realized I could expose "ordinary C" from the Objective C part, it was very easy to integrate the two without using a framework. (It helped that the UI was 100% Objective C, so there wasn't much surface area between the C# and Objective C parts. We initially used MonobjC, but first I had to work around a shortcoming, and then we needed to remove MonobjC due to licensing and some of the newer C# integration layers were not available.)
You can reach into built-in components and precisely modify just what you want while keeping everything else platform-native and without having to reimplement everything. I've never seen anything like this before, anywhere. Maybe OLE on Windows wanted to be this (I've seen similar capabilities in REALLY OLD software written around OLE!) but the entirety of Windows' interface and shell and user experience was never unified on OLE so its use was always limited to something akin to a plugin layer. (In WordPad, for example)
The only thing that even seems reminiscent is maybe Android Studio, and maybe some "cross-platform" toolkits that are comparatively incredibly immature in other areas. But Android Studio is so largely intolerable that I was never able to dig very far into its debugging capabilities.
I feel like I must be in some sort of honeymoon phase but I 100% completely understand now why many Mac-native apps are Mac-native. I tried to write a WinUI3 app a year or two ago and it was a terrible experience. I tried to get into Android app development some years ago and it was a terrible experience. Writing GUIs for the Linux desktop is also a terrible experience. But macOS? I feel like I want to sleep with it, and I weep for what they've done with liquid glass. I want the perfection that led to Cocoa and all its abstractions. Reading all the really, super old documentation that explains entire subsystems in amazingly technical depth makes me want to SCREAM at how undocumented, unpolished and buggy some of the newer features have gotten.
I've never seen documentation anything like that before, except for Linux, on Raymond Chen's blog, and some reverse-engineering writeups. I do love Linux but its userspace ecosystem just is not for me.
Maybe this is also why Smalltalk fiends are such fans. I should really get into that sometime. Maybe Lisp too.
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.
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.
As for sandboxing, 9front/plan9 uses namespaces, but shared directories exist, of course. That's the point on computing, the user will want to bridge data in one way or another. Be with pipes, with filesystems/clipboard (or a directory acting as a clipboard with objects, which would be the same in the end).
Oops, you are right about COM. I got them mixed up because I was thinking of the integration in WordPad.
> 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.
Mac apps are Mac native because the APIs are amazing and the ROI can be really really good. It takes so much effort to do the same from scratch, especially cross-platform, that, you're right, I can smell anything written in Qt (because the hitboxes and layout are off) or GTK (because the widget rendering is off).
With that said though, wxWidgets seems to translate EXTREMELY well to macOS, though last I used it, it didn't have good support for Mojave's dark mode. Maybe support is better nowadays. For example, Audacity appears to me as just a crammed Mac-native app rather than blatant use of a cross-platform toolkit, and wxPython used well can be completely mistaken for fully native.
(I am open to being corrected)
wxWidgets has properly supported dark mode for a bit now.
Nah, they are perfectly sane. They look like little ASCII envelopes because that's exactly the metaphor. Square brackets send messages.
https://developer.apple.com/documentation/ObjectiveC/objc_ms...
https://www.mikeash.com/pyblog/friday-qa-2017-06-30-dissecti...
IMHO the whole 'message' and 'sending' lingo should be abandondend, the job of objc_msgSend is to look up a function pointer by certain rules. There are no 'messages' involved, and nothing is 'sent'.
The conceptual difference is significant as an object can respond to messages that it doesn't have a method for. You are, conceptually, just sending a message and leave it up to the object what it wants to do with it (e.g. forwardInvocation:). That is, after all, what sets "object-oriented" apart from having objects alone. Optimizations that can be made under the hood don't really affect the language itself.
Clang produces a warning in that case though (something along the lines of "object might not respond to ..."), I don't think that feature is particularly useful in practice (also because it kills any sort of type safety) :)
We have new ways to approach problems nowadays, so it may be fair to say that object-oriented programming is a relic of the past. I mean, it is telling that Smalltalk, Objective-C, and Ruby are the only languages to ever go down that road. Still, if you are using an OO language, then it makes sense to lean into OO features. Otherwise, why not use a language better suited to your problem?
I wouldn't say so, most object-oriented languages don't work like Objective-C/Smalltalk. Today, I think most programmers would agree that inheritance is the defining feature of object-orientation.
Understandably, language evolves. If OO means something different today, what do most programmers call what used to be known as OO? I honestly have never heard anyone use anything else. But I am always up for refreshing my lexicon. What did most programmers settle on for this in order to free up OO for other uses?
I guess Simula, which is older than Smalltalk, doesn't get a say.
I have never programmed in ObjC but was curious to learn how it works, and so I decided to write a ObjC runtime [0]. It took less than 2000 lines, and a large number of them are comments. Now I wonder how easy would it be to do dome lispy symbolic computing in it. Maybe something like a Prolog.
[0] https://gist.github.com/namandixit/76cd084676acdf16cfd014cbb...
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.
I think every OO language should be using Smalltalk's message-passing style rather than holding hard references, and Objective-C is a great model. But discard the rest.
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.
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
From my experience, when it creates working Objective-C, it's great. When it slips up, it slips up majorly.