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

I spent 3-years with Swift recently

Makes me want to ask: Why? Why do this?

It is a decent language for 2005. But it has some serious shortcomings (reference counting garbage collector? Really?)

The worst thing IMO is its dreadful support for threads. The "DispatchQueue" seems to be a wrapper around "fork/renice". There is no attempt at memory protection.

But it is full of little niggles that get very irritating in this day and age.

I never used Objective-C so it may be a vast improvement on that.

It is no longer 2005, and we deserve, and we have, better languages.

My time as an Apple developer left me with the overwhelming sensation that Apple hates its developers. So much cool looking stuff that mostly worked...



ARC is for classes, structs use don’t have that and classes are heavily discouraged.

DispatchQueue is anything but fork/renice. Also there is async/await now. GCD should be used for concurrent work only now, not async work.

Memory protection is fully implemented in Swift 5.10, but compilation only warns, enabled by default as errors in Swift 6.


I really like the struct-based method of modeling data in Swift. The language makes this very convenient. Unfortunately the new Observation framework which is at the center of SwiftUI requires classes.

https://forums.swift.org/t/any-future-directions-for-support...


This makes sense, observation requires a durable identity, which structs don’t have.

Two struct might be the same, but when I observe for changes in one, but not another, a distinction arises which is best captured by object-based identity


I did obj-c on a popular consumer app about 10 years ago. Recently had to make an app. I used async/await and SwiftUI heavily. Used observableobject and actors as well. It’s very nice, much like a React/typescript app. UIs used to be torture

I did have to build some things that I felt should have come standard. For example, I had to build a class that provides a thread-safe way to enqueue objects and process them in a background task, which used DispatchQueue internally.

By and large, it’s a world of difference from what it was and my experience has been joyful. Xcode cloud just worked so that’s cool. Profiling is wonderful (signposts etc). Could there be improvements? Sure. Are there other languages with better features? I think so. But I haven’t found myself longing much for something provided by other languages and platforms

Point is, I no longer dread iOS development. In fact, it’s quite fun.


I'm coming back to iOS development after years of doing web stuff. SwiftUI will feel very familiar to anyone that's done React and massively reduces the amount of boilerplate and ceremony it takes to build for Apple platforms. It has some rough edges but overall feels like the most modern mainstream UI toolkit now.


> I did have to build some things that I felt should have come standard. For example, I had to build a class that provides a thread-safe way to enqueue objects and process them in a background task, which used DispatchQueue internally.

That is DispatchQueue. Or NSOperationQueue. Or preferablly Swift concurrency.

Most wrappers around dispatch queues are unnecessary and use it incorrectly. (I would say this is true of operation queues themselves.) Swift concurrency is better than dispatch, though.


> Swift concurrency is better than dispatch, though.

For some things, sure.


FWIW the concurrency story has been getting substantially more attention over the past couple of years with first-class language support. Swift 6 aims to be data-race-safe by default.


2005? Swift is from 2014.


I'm not sure where you get your references from but Swift is one of the most modern and advanced languages out there.

The documentation of Apple is worse than hot garbage though. As in, at least with hot garbage you have something.


What do you mean? Apple has lots and lots of documentation saying that function signatures exist! (/s just in case)


I've gotten better at navigating the Apple docs, but yea, they are not the best. The one thing I will say, when they give code snippets in their docs, the code snippets are really good. But you just need to read the API of a framework or see the functions tied to a type, it could be a lot better.




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

Search: