I asked GitHub Copilot to provide a simple example Swift source code file along other necessities integrated in the C++/Objective-C++ codebase of the Nextcloud desktop client to consider the long term migration of Objective-C++ code to Swift.
No, thanks. 🫣 That looks even more inconvenient to maintain. I feel a bit sick now. 😅 That bridging is anything but straightforward…
It's interesting just how close Objective-C 1.0/1.1 was to JavaScript. A lot of the gritty code just copy-paste and works, as long as you remember to turn [foo message:bar] into foo.message(bar) and change ls.count to ls.length (which tripped me a few times). The object model's different, but you'll never notice in normal work.
Once the whip-me-beat-me C++ freaks started littering Obj-C with a bunch of type-shit, it got harder.
#objectivec #objc #javascript
back in my early industry days when i was porting the adventure game studio (AGS) engine and games to mac/ios, i developed a healthy hatred of Objective-C which was used as interface glue between the engine code and macOS/ios
i had been working with C/C++ for a long time, and had made the mistake of assuming all programming syntax was essentially C-like in structure
suddenly having to deal with obj-c syntax was like stepping into an alien spaceship:
@interface ClassName : SuperclassName {
// instance variables
}
+ classMethod1;
(param1_type)param1_varName;
- (return_type)instanceMethod1With1Parameter:(param1_type)param1_varName;
@end
i could sort of grok out what i needed to do by changing a few variables and ctrl-c ctrl-v the methods i needed, but the overall experience was so difficult that i was glad when i never had to touch it again
over a decade later, i am *so* impressed by what obj-C was attempting. after doing a lot of NeXTStep reading, i finally understand what it was trying to do: add smalltalk-80 message-passing and object orientedness to C. the changes to the syntax (like using the + and - to indicate class vs. instance methods) are actually pretty cool!
sad that i dismissed something so fascinating in the early days just because i was more worried about getting a project done on time than actually learning how it worked
@sgharms Apple still develops #macOS more than #GNUstep ever evolved. Problem is I don't like the direction it's going. I don't want a network request for every app that I open.
But GNUstep won't help. It's just a POC, not able to deliver meaningful software anymore.
In case you want to develop #ObjC on living systems, try @objfw on literally any OS out there. In case you want a system where ObjC really is used to develop current applications, try #MorphOS.
:mac: 🤘🏻🔻
#Metal :metal: + #glfw with #cpp code only.
Had to avoid #objc because my custom build system can't deal with that yet (and I didn't feel like changing that).
What a pain to get it to compile.
BUT
It's using the exact same shader as my #Vulkan :vulkan: #HelloTriangle thanks to #Slang ❤️
AND
```
$ wc -l src/main.cpp src/shaders/hello_triangle.slang
134 src/main.cpp
40 src/shaders/hello_triangle.slang
164 total
```
Folks I just accidentally waded into #multithreaded #programming in #c / #objc I did an untutored swing at it and I have multiple half made bowls of spaghetti. Any canonical books or references on getting oriented here. I’m pretty lost.
Hearing that people are successfully using this new diagnostic to track down longstanding Weird Multithreading Bugs®, so seems like a good time to mention it again: https://mastodon.sdf.org/@mikeash/114655617095364169
🧹 DYSNI — Do Ya Still Need It?
We deleted >800 lines of old Objective-C by asking one simple question: Do Ya Still Need It?
Simpler code. Less confusion. More clarity.
👉 https://paul-samuels.com/blog/2025/10/29/do-ya-still-need-it/
(At a later point I'm going to generate #ObjC bindings for #libpurple 3 using #ObjGTK and then use #ObjFW to integrate libpurple into #Adium. But I never said that, because probably it will never happen.)
Not sure the front of the joke but the punchline is "troll-free bridging" #objectivec #objc #programminghumor
Ok, as gorgeous as #Mavericks is, but the list of Software I need to backport becomes longer. Maybe it's easier to bite the bullet and update to 10.14. It's not as beautiful, but at least I wouldn't need to backport software written in #ObjC and 32 bit application still work. 😉
Eventually (which may be many years ahead) I'm going to have a cross-platform #ObjC app featuring both a native GTK and native Cocoa (Touch) interfaces.
Second aim is to develop my cross-platform #ObjC app #contacts2phone using @objfw
I'll then have two nice laptops allowing me to develop it: The Lenovo X280 running the most recent Ubuntu for #GTK development and the MacBook Air running a decent #MacOS X for #Cocoa development. iOS / CocoaTouch should be coming at some point as well.
https://codeberg.org/Letterus/contacts2phone/src/branch/add-gtk-view
Folks, I can definitely recommend this talk from @bugaevc at #guadec2025!
https://floss.social/@gnome/114873444742029431
Sergey has been of great help for my minor stumblings of trying to write #ObjC #GTK bindings for #ObjFW. He's got formidable knowledge und deep insight into #GObject especially and Cxx languages in general.
For our #ObjC lovers that want to build web apps: Objective-J is still in active development 🙃 https://www.cappuccino.dev/learn/objective-j.html
Bridging non-ASCII NSMutableStrings from ObjC will be slower at the point of bridging, *but* the String produced as a result will be much faster.
One particular case this tradeoff can end up not paying off in is if you then bridge the resulting String back to ObjC. If you're in that situation the recommendation is to not double-bridge strings if you can avoid it.
If you're in any other situation and this tradeoff is impacting your perf, please file a feedback.
Two obscure Swift changes I want to note:
ASCII String literals bridged to ObjC will produce a different type in the beta OSs. This generally has no impact (other than greatly improved performance), but code incorrectly treating `NSString *` as `char *` or `SEL` may need to change (e.g. %s format strings).
A message will be logged in any situation we're applying compatibility workarounds for this, and the workaround will be disabled if you use the latest SDK version.
What kind of worries me is the observation that many #GObject / #GNOME projects are in a somewhat abondoned state since the overwhelming use of mobile apps and web services around 2012 to 2014. There are some great exemptions like the #Evolution support by #RedHat and all the tools by @linuxmint.
Same is to apply to the #ObjC ecosystem which has seen few new projects since 2015 or so.
