Details on an unnecessary optimization I geeked out on a while back:
Tagged pointer string keys https://objectionable-c.com/posts/tagged-pointer-string-keys/ #objc #iosdev
Hat tip to @mikeash for the seminal post on tagged pointer strings
A little history about why we have this: when returning an object, *something* has to keep it alive long enough for the caller to take ownership of it by retaining it.
In CoreFoundation and Swift, we do this by retaining it first then "giving" the retain to the caller, but without ARC to automate releasing it later this leads to a *lot* of code clutter.
Autorelease allowed pre-ARC ObjC to avoid all the clutter by "giving" the retain to the pool instead of the caller.
We wouldn't have this problem with DOGE's interns if they had to learn COBOL, FORTRAN, and PASCAL - like I had to.
BTW: My major programming language? Perl
Second only to Objective-C... NOT SWIFT. Obj-C!
Thanks go out to @elementary for the most beautiful Linux UI out there.
And to @js for the most beautiful #ObjC implementation ever. #ObjFW
Reminder to pass .workItem as the autorelease frequency for any dispatch queues you make: https://developer.apple.com/documentation/dispatch/dispatchqueue/autoreleasefrequency
It would be the default if there wasn't a small risk of a compatibility break due to something incorrectly relying on an object sticking around.
(This will matter less and less as more stuff gets rewritten in Swift, but for now it's hard to tell which things might have ObjC code underneath)
This post was recently shared at work about how block memory works under the hood in #ObjC. If you, like me, used to frequent fuckingblocksyntax.com you might enjoy this old post! https://www.cocoawithlove.com/2009/10/how-blocks-are-implemented-and.html
I'm trying to customize how some #objc methods are imported into #swift as #async methods, but it seems like the clang attributes for this don't really work?
In this example I want the second closure to be considered the completion handler, and if the argument to that closure is false (i.e. 0) then it should throw an error. But it seems to ignore these attributes and generate a form that isn't throwing?
https://clang.llvm.org/docs/AttributeReference.html#customizing-swift-import
Here’s my blog post on how to deal with #ObjC protocols as types when they get bridged to #Swift.
https://www.humancode.us/2024/09/19/objc-protocols-in-swift.html
at the risk of sounding like an idiot. i have some xib warnings after updating to sequoia.
i can’t update to the new SFSymbols without dropping support for everything except the bleeding edge. not an option.
i don’t really want to ignore these warnings for the next 5 five years.
what are my options here?
is there something akin to @ available for xibs?
or is my best bet to assign these with bindings and use @ available in code?
I really miss #ObjC’s dynamism.
When working in a project that has multiple libraries that get integrated at different speeds, I sometimes have to commit code upstream, wait for that library to make it downstream, then commit code that uses it downstream. With ObjC and its dynamism, I can use simple protocol-based tricks to commit both sides of the dependency at once, and rely on runtime checks to see if the other side has made it into the build. That lets me commit code and move on. Code cleanup is also super simple once all the pieces have made it in.
It’s damn near impossible to do this in #Swift. I admit I’ve added `.m` files to the build just so I can use ObjC to break the waterfall dependency. Actual engineering is reality-based, #sorryNotSorry.
Swift is a fantastic language, but its purity is often too rigid for actual engineering projects. Sometimes NSClassFromString() is what you need to get your job done.
After being with Mozilla for a little over 5 years, I've been laid off today, alongside a group of some of my favorite people. So, I'm on the job market! I've got ~8 years #iOS, #Swift, and #ObjC under my belt, working on everything from libraries all the way through full user-facing features. So, I'm #opentowork. Remote (US), working out of the Chicagoland area. 
LinkedIn in bio. Boosts would be much appreciated!
@stroughtonsmith Reading it all in one phrase makes it unclear, but as an enum
UIWindowSceneResizingRestrictions: Freeform, Uniform, None
is pretty clear. I wish NeXT/Apple had used _ to separate types from values, tho.
#objc
Simple (dumb?) but very important question to all #Swift, #SwiftUI, #ObjC developers using #Xcode:
How do you secure your API keys?
It's clear that they don't belong hardcoded in the app. But how do you secure your keys?
Whether hardcoded or via `Config.plist` with a hex editor, they can be extracted from a binary. So what is the "right" way?
Please boost, thank you. 
Blog post: How to expose (some) symbols from your #Swift library directly to #ObjC via headers.
This was a topic of conversation I had here some time ago, but I never put it together as a blog post. I hope you can use this in your own projects!
https://www.humancode.us/2023/08/09/objc-headers-swift-implementations.html
I miss you everyday. I even miss your internals. #objc
https://alwaysprocessing.blog/series/objc-internals
sucht wer von euch einen freelancer für native iOS-apps oder kennt ihr leute, die suchen? dann freue ich mich, wenn wir mal miteinander reden, denn: ich suche für mich nach einem neuen auftrag (und explizit keine festanstellung)
https://zeitschlag.net/lebenslauf/
tl;dr: #iOS-apps seit ~2016 in #swift und #objc. ich mag gutes handwerk und saubere lösungen, kann mich schnell in neue sachen einarbeiten. ihr wisst schon: das übliche.
danke fürs teilen <3
I’ve done nearly 30 years of C/C++ by now, and probably 20 years of Objective-C. So usually, that's my baseline for programming. These languages don't hurt, they're just “how programming is”. Better languages are “oh cool I get to have fun”.
That said, I recently wrote some new Objective-C code and … actually wanted to go back to Swift. Those square brackets really are a downside of the language. The Swift-style of method call syntax is superior.
️ 
