Also, the Objective-C Runtime reference[1]. About a decade ago, I learnt Objective-C in a day, by reading "The Objective-C Programming Language" and the Runtime Reference. It's such a beautiful and simple language, if you know C. I wish Swift were as simple and succinct. AFAIK, Objective-C++ is still the easiest way to bridge C++ code with Swift code. Knowledge of Objective-C is still relevant for anyone building apps that need to use C++ libraries.
Objective-C was my first "real" language, started working with it with almost no knowledge of C to make some Mac Apps on Rhapsody and later Mac OS X. Nice documentation and an awesome first language, not least due to the lovely Foundation and AppKit frameworks and the nice UIs of ProjectBuilder and InterfaceBuilder at the time. It was pure fun writing software in that environment.
I learned to program in Objective C, it was fun. Spent many hours digging behind the scenes, but the only fun fact I remember is that it’s a strict superset of C, so any C program is a valid Objective C program. Always found this fascinating.
Are people still using it today? I thought Swift took over.
In my estimation, these are the primary reasons why some developers continue to use Objective-C:
1) Rewriting an existing code base is almost always massively expensive and dangerous.
2) 9 years later, the Swift tooling is still atrocious. Compile times are much longer, the compiler still crashes, the debugger still doesn't work reliably. It's a major step down from the mature Objective-C tooling.
3) There are still land mines with interoperability between Swift code and Apple's underlying Objective-C frameworks. Performance bottlenecks, unexpected object bridging issues, erroneous nullability annotations, etc.
4) C and C++ compatibility, as mentioned by another commenter.
> 9 years later, the Swift tooling is still atrocious. Compile times are much longer
To be fair you can’t really compare them since the Swift compiler is giving you a lot more guarantees than Objective-C which gives you basically zero. Rust is also atrociously slow to compile.
History has shown time and time again that static analysis is an appeal to unrealized perfect humans and not pragmatic realities of developers doing the least possible or hubris
Static analysis is useless unless run , and most developers won’t run it because it’s not the default (so they have to go out of their way to do it) and/or because they believe they are above needing it.
Pretty much every analysis of modern languages with compile time default analysis has shown that ultimately defaults matter.
I was never just comparing language to language. My original comment was this: "9 years later, the Swift tooling is still atrocious. Compile times are much longer, the compiler still crashes, the debugger still doesn't work reliably. It's a major step down from the mature Objective-C tooling."
If you can write the same program with Objective C or Swift, you definitely can compare tooling. Who cares about guarantees? People care about result. I actually feel that recently iOS and macOS programs became more buggy and unreliable compared to old versions. Not sure if that could be attributed to Swift.
Almost no new projects within Apple are written using Objective-C, and old code is actively rewritten for many reasons, with security being a large one.
Your citation shows the clear trend, however. Swift usage is only increasing, and Objective-C is discouraged (not deprecated, discouraged) for new projects.
I hope you won’t mind me saying so, but I’m most reminded of NeXT’s reverse-acquisition of Apple.
It’s not quite as stark, but the same pattern is emerging — folks that couldn’t or wouldn’t adapt found themselves working on ever-shrinking islands — the blue box, ported userspace libraries, drivers, file systems, etc.
I’ve written a lot of C and ObjC over the years, and I get where you’re coming from, but there are good reasons to move past C/ObjC for systems and application programming.
Swift has some serious warts and is hardly my favorite language, but it brings a lot to the table relative to ObjC, and there’s still room to resolve many of its issues.
> I hope you won’t mind me saying so, but I’m most reminded of NeXT’s reverse-acquisition of Apple.
> It’s not quite as stark, but the same pattern is emerging — folks that couldn’t or wouldn’t adapt found themselves working on ever-shrinking islands — the blue box, ported userspace libraries, drivers, file systems, etc.
This sounds like mainly a "political" consideration. Of course Jobs eventually became CEO and pushed his own agenda on the company (just as Cook and Federighi are now pushing their agenda). It's worth mentioning, though, how Apple promised and indeed was in the process of delivering 64-bit Carbon before it was yoinked back at the last minute! Anyway, I fully realize that I'm effectively unemployable right now in a Swift-oriented world. Thank goodness that I'm self-employed. :-)
Dynamic dispatch with heavy reliance on runtime metadata is a huge attack surface in terms of being able to leverage a data bug into full control of execution.
Additionally, the language provides very few runtime or static compile-time guarantees relative to Swift.
This disparity grows even larger if one leverages C directly — which is both common and often necessary when writing ObjC code.
Can you give an example exploit that goes from a data bug to full control given dynamic dispatch?
Less runtime / static guarantees may mean you pass the wrong class type to a method, but typically all that happens is that that object cannot perform the right selector. I can sort of see this being slightly chained to get some mild exploit, but I’d imagine this is pretty edge condition / rare as it would need to respond to the expected selector in the right way useful for exploit.
I’ve written a ton of obj-c and work in it, and almost never need or see the use of C.
Since Apple now controls the entire hardware stack for all their products (except the mac pro), they could conceivably design their own assembly language ('Apple Assembly'?) optimized for, and only for, Apple silicon and bypass the problem.
There's millions of man-hours invested in optimizing software and hardware for the ARM64 ISA. Abandoning that for a nebulous "we can optimize for our stack" is not a worthwhile tradeoff.
Nebulous? When TSMC can no longer economically cram more transistors onto the dye, Apple will need other ways of increasing performance to keep the upgrade cash coming in. Apple previously co-developed PowerPC with Motorola (and IBM) for this very reason. At this time, Apple has all but kicked its third-party developers out of kernel space on its operating systems which will make for easy transition to future architectures. I would go so far as to speculate Apple is already designing proprietary RISC-V extensions and even their own FABs to produce them. One would expect such extensions to help Apple's systems execute Swift and ObjC better (faster and more securely) than general purpose processors and to optimize shared memory and fabric access between CPU, NPU and GPU cores.
These are all standard ARM instructions. Apple tweaks the semantics of some of them in Rosetta mode to better support what they’re doing but it’s otherwise not involving any new encodings.
As named, the extensions called ‘Apple’s secret extension’ are not standard, they are Apple specific and it’s not just ‘tweak the semantics’, it’s custom and only turned on for Rosetta 2 because otherwise they would cause unexpected results for software expediting normal ARM behavior.
It's possible, if they were motivated to really invest in it, to introduce some innovations. For example, it could warn about badly designed software, major flaws, etc... at the assembler level.
And since they mostly control software distribution, to then block anything that receives such warnings.
I do. Not only because I don‘t want to rewrite my apps but because for me Objective-C is beautiful and better to read than any other language I tried. I never saw the point of learning a new language to implement the same things. The only benefit I could see was for Apple, pushing me a bit farther into their ecosystem which is incompatible with anything else. When it became obvious that Swift was the way to go I switched to js / hybrid app development for new projects. This seems to also die out now, but I‘m still sticking to it.
While I see some of the benefits of swift, I find it unnecessarily unreadable. One might argue about this, but as a developer, I value how readable the code is (no matter the language).
Going over various projects written in swift on github, more than 50% don't even compile without serious refactoring.
OTOH, grab a project in obj-c, from 15+ years ago, compiles with minimal changes (or, most of the time, without any).
I'm a big fan of Chris Lattner and his work, but swift is not his most successful children. While I believe his intentions were good, the end result is a mess worse than brainfuck (the programming language).
I use ObjC as a thin layer to talk to macOS/iOS frameworks with the rest of the code being mostly C and some C++. Swift would not only be complete overkill for that but also a lot more hassle with build system integration (don't even know if cmake supports mixed C/C++/Swift projects out of the box)
Most new code is probably written in Swift, but there’s still lots of ObjC code out there and people are still writing it to maintain/extend those code bases.
Can't speak to personal experience, but my understanding is Objective-C++ (which is most of C++ plus all of Objective-C) is still popular for bridging the Objective-C/Swift and C++ worlds. Though apparently Swift is getting a C++ interop system, so that might become less common!
I prefer Objective C to Swift. I'm not professional Apple developer, though, just write code for fun in my spare time, so I have luxury of being able to select tools I like. I guess, in professional setting Swift took over most new projects.
The bridging layer for react native apps is written in Objective-C for most native iOS things, so most react native libraries and apps will have a fair amount. Older apps and Apple also ensure it will stay alive for some time to come.
(This is my own channel), but I recently made a video on Objective C calling conventions specifically for Reverse Engineers that you might enjoy, with more iOS videos incoming:
As for modern RE resources, I can recommend Jonathan Levin's series of books on MacOS and iOS internals as a good reference. It's probably the newest information you are going to be able to get on iOS/mac internals outside of apple.
I really enjoyed Objective-C some very powerful ideas around message sending and handling. And you could just use C and C++ I loved it. I never got to use smalltalk. And Objective-C felt as close as I could ever get.
Believe it or not (i'm walking on air), there was a time when Apple had an official Cocoa-Java bridge . They were betting heavily on it, rewrote WebObjects on Java, etc.
Then, for some reason, people began to realize ObjC was quite all right after all, despite its crazy bolted-on syntax, and it “caught on”, for some reason. Maybe because Mac OS X was already dog slow and memory hungry as it was to even consider Java. And, funnily enough, ObjC was the slower solution to C/C++ on Carbon, that they somehow menage to run on a phone with 128MB of RAM and a DVD player SOC.
Yeah, the Mac OS community was raised in Object Pascal and C++, Java came to be due to a mix of its initial hype, agreement with Sun, and fear that Objective-C would be too alien for the Mac developer community, due to its syntax and semantics.
Copland was going to be a microkernel based with C++ frameworks, as an additional note, similar in spirit on how BeOS turned out to be.
As that proven not to be an issue, and the community did indeed adopt it, they decided to cut down on costs of having multiple languages.
A bit ironic, as we are back to the Object Pascal / C++ days, with two similar inspired languages.
I wrote a bridge between macOS APIs and Common Lisp using the Objective-C runtime and it’s pretty nice to be able to work with system APIs at a high level, and not be forced down to “bag of bytes” C FFI. Hopefully, Apple’s move towards Swift will maintain the Objective-C runtime even if they eventually deprecate the language itself.
• Programming With Objective-C (current): https://developer.apple.com/library/archive/documentation/Co...
• The Objective-C Programming Language (older): https://developer.apple.com/library/archive/documentation/Co...