Quinn, if this feedback is above your pay grade then you need a raise and a promotion, because you've been around long enough to have more influence than that on a team as important as the Swift team.
For the expected quality of software in a third-generation project in late Beta, Swift 3 has become a trainwreck of Microsoftian proportions--at least in terms of process and expectation. Many of us devs are spending 90% of our time not developing our app, but babysitting Swift and trying to understand so many unvetted changes. That's fine if you're working on salary but for many of us, time is money.
This is made all the more difficult by not having a stable language spec, adequate documentation, code samples or working look-ups in Xcode for two years now. We're being treated like lab monkeys during late Beta as I said above. As others have said, it feels like we're developing in quicksand. The lack of attention to glaring bugs in the editor and the tool chain is deeply concerning.
I can't even build without segmentation fault 11's half the time, because Swift's type engine still can't deal with the complexity of larger, real-world code bases or literal declarations whose types should be easily inferred. That bug has existed since the first Swift 1.0 Betas. Typically the only way to work around these bugs is to proceed very cautiously, unit test the heck out of your app, use source control bisection to isolate changes that are too complex, and then find ways to break them up into simpler expressions.
The error messages we get are still sadistic. Many of them are nonsense, or are not actionable because they use terminology that only compiler engineers know. And many of them are downright misleading. A Fix-It will typically recommend a change, then change its mind, and then add some other suggestion a few seconds after you've already moved on. This is complicated by all the UI lag in the Xcode editor, and the pile of popup windows and mis-highlighted lines of code. Sometimes a batch of errors won't get reported, your app will run, and then the next time you build those errors suddenly get reported. How does that happen and how can we trust such an IDE?
Many of the recent Fix-Its are just renames, so why not just do them if they're straightforward? Instead, we get a Fix All in Scope command that still crashes Xcode if you dare use it. And here we are on Swift 3 and there is still no Refactor support at least for renaming? How is that acceptable in a modern IDE?
If you've banked on Core Data for your apps in the past, you're basically living a nightmare if you chose to migrate to Swift. Xcode decided to obviate mogenerator without fully understanding how it was used or even testing the ****** Core Data accessor code generated by Xcode. In Beta 5, we got OrderedSet that wouldn't compile. And then in Beta 6 we were told it was fixed but all they did was rename that string back to NSOrderedSet, and without taking the extra step to finally make to-many relationships mutable or properly typed. The underlying accessor code not only crashes at runtime, but we can't even see what that code is trying to do because it's hidden from our project. And we're supposed to believe these bugs will all get fixed in one or two more Betas?
Generally speaking, I think open-sourcing Swift has had predictable results. It has made Swift even more difficult to use with Cocoa as APIs diverge and get generalized. We could all cite 100s of examples where Swift code is far more complex or obtuse than Objective-C. And that especially includes the basics, like all the common things you need to do with strings, arrays, dictionaries and enums that require far more code and cryptic symbols now in Swift.
The bottom line is that for all the advances in Swift, as a language it utterly fails to achieve its original, primary goal which was to be easier to learn and use. It's not either of those, and its instability makes it a timesuck. Instead of building a modern compiler that understands developers, we are now expected to think like a compiler. Just look at how much of a typical Swift app's code is made up of optionals and typecasting. That does NOT make an app demonstrably safer to run or easier to maintain. Instead, you can actually measure the time and money lost in productivity.
Sorry for my annual rant, but this is the point each year where the Swift team needs to be reminded to get their act together. Please Alpha test somewhere else.
