4 ms·
> Are people still using it today? Yes, I am. Apple is too: https://blog.timac.org/2022/1005-state-of-swift-and-swiftui-ios16/ https://blog.timac.org/2022/100
by lapcat 3y ago
> Are people still using it today?
Yes, I am. Apple is too:
https://blog.timac.org/2022/1005-state-of-swift-and-swiftui-ios16/ 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.
- MichaelZuo 3y agoSince 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.
- lapcat 3y agoApple has already done this to some extent, though I don't have the references offhand. In any case, there's only so much that hardware can to do compensate for crappy software. It's not inherently a hardware problem.
- MichaelZuo 3y agoIt'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.
- saagarjha 3y agoThere’s no need to do something like that. They just don’t optimize for certain code patterns.
- AceJohnny2 3y agoBypass the problem?? They'd only create more. 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.
- vaxman 3y agoNebulous? 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.
- saagarjha 3y agoYeah, that’s called arm64, except for the bit that other people can also use it.
- MichaelZuo 3y agoarm64 + special proprietary bits = 'Apple Assembly', or whatever marketing name, seems within the realm of possibility. It wouldn't be that much of an outlier in terms of naming convention.
- tinus_hn 3y agoI’m pretty sure there’s some Apple specific instructions that help with Rosetta 2.
- saagarjha 3y agoNot for Rosetta 2.
- tinus_hn 3y agoHere’s more information: https://dougallj.wordpress.com/2022/11/09/why-is-rosetta-2-fast/ https://dougallj.wordpress.com/2022/11/09/why-is-rosetta-2-f...
- saagarjha 3y agoThese 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.
- catiopatio 3y agoAlmost 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.
- lapcat 3y agoCitation needed. I've already provided a citation: https://blog.timac.org/2022/1005-state-of-swift-and-swiftui-ios16/ https://blog.timac.org/2022/1005-state-of-swift-and-swiftui-...
- catiopatio 3y agoI cannot provide a citation for my evidence. Your citation shows the clear trend, however. Swift usage is only increasing, and Objective-C is discouraged (not deprecated, discouraged) for new projects.
- lapcat 3y agoI find it interesting that Objective-C would need to be discouraged, which suggests that Apple engineers don't independently prefer Swift. ;-)
- catiopatio 3y agoI 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.
- lapcat 3y ago
- jamil7 3y ago> 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.
- vbezhenar 3y agoIf 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.
- saagarjha 3y agoPeople care about guarantees when their device gets hacked, for example.
- user-the-name 3y ago[dead]
- dagmx 3y agoUsers care that their app doesn’t crash and doesn’t corrupt their data, or allows for RCE. ObjC gives you very few guarantees that your runtime data is correct. Swift makes for more resilient programs all around.
- lapcat 3y ago> Objective-C which gives you basically zero 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.
- dagmx 3y agoHistory 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