7 ms·

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 a

by KMnO4 3y ago

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.

neverartful 3y ago
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.
- jguimont 3y ago
  And for what it is worth, the times I had to use Objective-C, it is a nice superset of C language that reads cleanly and is easy to grasp.
- kjs3 3y ago
  Around here, anything that happened before 2017 or so is 'old', and therefore 'bad'. The echo chamber has spoken.
- internetter 3y ago
  Hell it's 2024 and I find myself translating Objective C into Swift
lapcat 3y ago
> 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).
- KerrAvon 3y ago
  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.
papereditor 3y ago
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. :)
- jshier 3y ago
  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.
  - papereditor 3y ago
    Interesting! So all the NS_SWIFT_UNAVAILABLE APIs are still easily bypassable in Swift?
    - jshier 3y ago
      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.
      - KerrAvon 3y ago
        Yes, it's very rare that something is actually unavailable. You can even use things like `sysctlbyname` in Swift without writing C.
ziddoap 3y ago
>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).
jmull 3y ago
> not having any benefits Actually, building on stable abstraction is a pretty nice benefit when your focus is on the product. Swift is quite nice, IMO, but has also changed quite a bit since 2015 and using it would likely have lead to a bunch of work to keep up.
ChrisMarshallNY 3y ago
> 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.
lovelyviking 3y ago
May be you can point out a few particular features of swift that would bring real advantages for his project?
shermantanktop 3y ago
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.
danenania 3y ago
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?
- papereditor 3y ago
  You are correct. Swift is lighter on the eyes, but it still uses the same APIs when paired with UIKit/AppKit. SwiftUI is a different thing though. It's like React for UIKit/AppKit and has a different API.

by KMnO4 3y ago

neverartful 3y ago

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.

jguimont 3y ago
And for what it is worth, the times I had to use Objective-C, it is a nice superset of C language that reads cleanly and is easy to grasp.
kjs3 3y ago
Around here, anything that happened before 2017 or so is 'old', and therefore 'bad'. The echo chamber has spoken.
internetter 3y ago
Hell it's 2024 and I find myself translating Objective C into Swift

lapcat 3y ago

> 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).

KerrAvon 3y ago
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.

papereditor 3y ago

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. :)

jshier 3y ago
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.
- papereditor 3y ago
  Interesting! So all the NS_SWIFT_UNAVAILABLE APIs are still easily bypassable in Swift?
  - jshier 3y ago
    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.
    - KerrAvon 3y ago
      Yes, it's very rare that something is actually unavailable. You can even use things like `sysctlbyname` in Swift without writing C.

ziddoap 3y ago

>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).

jmull 3y ago

> not having any benefits Actually, building on stable abstraction is a pretty nice benefit when your focus is on the product. Swift is quite nice, IMO, but has also changed quite a bit since 2015 and using it would likely have lead to a bunch of work to keep up.

ChrisMarshallNY 3y ago

> 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.

lovelyviking 3y ago

May be you can point out a few particular features of swift that would bring real advantages for his project?

shermantanktop 3y ago

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.

danenania 3y ago

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?

papereditor 3y ago
You are correct. Swift is lighter on the eyes, but it still uses the same APIs when paired with UIKit/AppKit. SwiftUI is a different thing though. It's like React for UIKit/AppKit and has a different API.