Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'd been thinking of getting into Apple platform dev, but there really seems to be this strong contradiction in people saying to go full bore Swift/SwiftUI but reading this and as well following the Swiftcord devs' discord, there's a lot of problems with Swift/SwiftUI as a replacement for Obj-C/UIKit/AppKit. There also seems to be more and better documentation/examples for the Obj-C APIs than Swift; yes Obj-C is old, but Apple has been ringing the bell that this is the future for years now. How do you pick one to know you can just get things done, no matter what the requirements?


I went through this decision a few years back (end of 2020-ish) and decided to go with Swift because it seemed SwiftUI wasn't really far enough along yet, and some experimentation with SwiftUI caused me to agree.

I wanted to avoid Objective C, largely because I liked the safety of Swift (optionals, if let, guard let, etc) to make it less likely that I'd introduce crashes.

The funny thing I found was that I ended up needing to know how to at least read Objective C code anyway, because like you say, the docs use a lot of it. StackOverflow had a lot of it too. So I had to get good at translating between the two.

Unlike the web dev world I was used to, there are way fewer Swift/ObjC devs out there, and the answers are fewer and less up-to-date.


This is one of the big issues with many tech stacks these days: the somewhat frequent churn of the libraries and APIs. Things change under your feet in a few months, or a year, if not weeks, forcing you change your code to adapt, and then test and release everything again, etc.


I'm in a similar position. Can you not use UIKit in Swift or do you have to use SwiftUI?


Not only can you use UIKit / AppKit in Swift (always have been), you can wrap them into SwiftUI as well. There's really no need to choose nowadays.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: