Hacker News new | past | comments | ask | show | jobs | submit login

Perspective: I both develop in Swift and manage a team of 5 iOS engineers (including me). The majority of our project now is in Swift, including over 8 dynamic modules/frameworks and 10's of thousands of lines of code (all that to say it's not a small project).

I have to agree that there are some pain points with Swift:

- I developed a persistence layer (not Core Data), and had to rely on a "translation layer" that all clients must implement in order to use it. It ends up being about 100+ lines of glue code for each model we want to persist. Not ideal. - Retrieving data from API services and converting the data (JSON) into models results in a lot of glue code... A ton it. - I've frequently had to hack my way around the lack of Generic Protools (using base classes instead). - Compile times suck. Feels like I've been thrown back a decade in this regard.

Despite these issues, not a single one of us would go back to objective-c. Overall, the velocity of our team has only gone up since we started using Swift:

- Type safety and Optionals have removed an entire class of bugs in our app, freeing up more time to write features. - Generics have added a level of clarity to the code base that wasn't even possible before. - The code base is easier to understand, easier to maintain and easier to modify. - Oddly, the need to write Unit Tests and use Swift has literally "forced" us into protocol-based programming...a good thing IMO. I'm seeing much better software architecture as devs can't lean on automatic mocks, forced instead to create protocols and keep classes/types separated and injectable. To be clear, it's more difficult to write that kind of code, but the quality of code has gone up since we switched to Swift.

I've noticed that some of the complaints about the lack of dynamism in Swift don't seem as valid. For example: Responder chains. This is easily done using a protocol (something we did for deep linking within the app).

Other issues, like observability, can be solved by things like React, and using Observables. Not only is React more powerful than KVO, but it's obvious where it's being used in the code base (because you're using an Observable).

I can't deny that there are places where having dynamism would certainly remove a lot of glue code. But my experience is that the "old guard" (me included, really) relied too much on the dynamic nature of objective-c to solve problems that could have been better solved in another way.

While I would like to see dynamism come to Swift, I would NOT want to see it imported wholesale from objective-c, but instead conservatively placed and annotated in such a way as to say to those of us who use it: "Here be dragons...proceed at your own peril".




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

Search: