> To my surprise, the Swift one had the full Swift runtime embedded into it — about 5MB, while the Objective-C one was super light — tens or maybe 100KB in total.
That's a huge difference, but I believe it's because Swift is meant to be somewhat cross-platform, right?
That experiment was done in 2015, when the Swift runtime had to be included. If you build an app now, it will link to the system runtime and be close to 100kb as well.
This seems to be premature optimization. The author forced himself to learn archaic Objective C for a completely unnecessary reason, and now is stuck with that design choice despite not having any benefits.
> The author forced himself to learn archaic Objective C for a completely unnecessary reason, and now is stuck with that design choice despite not having any benefits.
Some benefits:
1) Most Swift code written in 2015 when the author was starting won't even compile today, because the language has changed in non-compatible ways. Whereas Objective-C code written in 2015, 2005, and possibly even 1995 will usually still compile and run. The author mentioned low maintenance costs as a goal.
2) Swift compile times are still vastly slower than Objective-C.
3) The Swift tooling is still buggy, including the compiler, and especially the debugger (the author wrote an entire section about debugging).
Yup; 2015 was not the right time to move to Swift for most people.
If I started a new app today, I'd use Swift -- it's mature enough. But in 2015 and for a long time after, it wasn't really a good option unless you wanted to be on the bleeding edge (and you were willing to bleed).
Compile times will always be slower than Objective-C, but the compiled code _can_ be faster, with effort. And maybe someone will eventually break down and write a Swift-centric debugger.
Have you ever developed anything substantial with Objective C? If not, I suggest that 'unfamiliar' might be more apt than 'archaic'. Anyone starting a non-trivial iOS project in 2015 in Swift would still need to learn the basics of Objective C because so much of the documentation and examples were still in Objective C at that time. I don't think it's accurate to say that learning Objective C in 2015 had no benefits.
>The author forced himself to learn archaic Objective C for a completely unnecessary reason, and now is stuck with that design choice despite not having any benefits.
It's easy, now, to say that it was a poor choice/premature optimization/unnecessary/whatever. But, presumably, the author is unable to tell the future. At the time when the decision was made, there were benefits that the author deemed necessary (smaller distributable among other benefits).
I think even today Objective-C has some unique benefits for me. It's more low-level and more hackable. And I think some older APIs are not even available in Swift.
Of course, the pressure to rewrite would grow with every year as Apple continues deprioritizing Objective-C, but that's a problem for future me. :)
Aside from inline assembly, Swift can operate at just a low level, it just requires more work, since those operations are unsafe. All of Apple's public frameworks are importable into Swift. At this point there are more frameworks unavailable in Obj-C.
Depends what they are. Most of the time those are unavailable because they've been replaced with better Swift imports of the same API somewhere. Less commonly it's because they use one of the few C features that can't be imported into Swift or, even more rarely, because the API is fundamentally unsafe and they don't want it available in Swift. In all cases you can reexpose these APIs to Swift by writing your own C wrapper.
> The author forced himself to learn archaic Objective C for a completely unnecessary reason
I'd hesitate to put it that way.
Shipping software is always full of compromise, and we often have to stay away from the "bleeding edge," when we want to actually ship full-featured products.
I suspect that almost all the AAA apps are still ObjC.
I still use UIKit/AppKit for my work. I simply can't get the results that I need from SwiftUI.
And yet here they are, with a great app, some amount of sustained revenue, and a front page post on HN. Is that an accident?
The word that comes to mind after reading that post is “intentionality.” Many deliberate decisions, including for hard tradeoffs like this one. To me, that speaks to the importance of vision and judgment over the apparent correctness of individual choices.
It's been a long time since I did anything in macos/ios land, but in my experience most of the learning curve wasn't in Objective C, which is a fairly straightforward C-like language, but in all the platform APIs. Has Swift changed things much in this regard?
That's a huge difference, but I believe it's because Swift is meant to be somewhat cross-platform, right?