Objective-C Internals
alwaysprocessing.blog
alwaysprocessing.blog
• 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...
[1] https://developer.apple.com/documentation/objectivec/objecti...
Pity that Borland management has messed up and nowadays only enterprise developers care about them.
It was almost page for page identical, minus branding.
Sadly those PDFs are no longer available for download.
Are people still using it today? I thought Swift took over.
Yes, I am. Apple is too:
https://blog.timac.org/2022/1005-state-of-swift-and-swiftui-...
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.
In any case, there's only so much that hardware can to do compensate for crappy software. It's not inherently a hardware problem.
And since they mostly control software distribution, to then block anything that receives such warnings.
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.
It wouldn't be that much of an outlier in terms of naming convention.
Apple events
https://dougallj.wordpress.com/2022/11/09/why-is-rosetta-2-f...
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.
ObjC gives you very few guarantees that your runtime data is correct. Swift makes for more resilient programs all around.
Untrue. In fact, more and more compiler warnings have been added for Objective-C over the years.
Moreover, there's the static analyzer, as well as runtime checkers and sanitizers.
Pretty much every analysis of modern languages with compile time default analysis has shown that ultimately defaults matter.
Everything is useless if you don't use it. By this logic, Swift is also useless. ;-)
Your citation shows the clear trend, however. Swift usage is only increasing, and Objective-C is discouraged (not deprecated, discouraged) for new projects.
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.
> 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. :-)
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.
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.
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).
YMMV
https://github.com/iosre/iOSAppReverseEngineering
https://www.amazon.com/NSHipster-Obscure-Topics-Cocoa-Object...
and the ultimate:
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.
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.
first iOSs didn't support user's videos playback
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.
Regarding the influences, you mean Swift is inspired by C++ and ObjC by Object Pascal?
Object Pascal => Swift, C++ => Objective-C, in terms of language culture.
On the languages front, I can’t see the parallel you draw.
I guess you weren't part of the community culture of the said languages, which is something that cannot be really explained in a HN comment.