What’s new in Swift 6.2

Honest question. Not trying to troll. One of the pitches in the earlier days was “C&#x2F;Objective-C OK, but you can’t write safe&#x2F;next level code with it—-Swift will close that gap.”<p>N years later, it doesn’t feel like there has been a step change in Apple software quality; if anything Apple software feels less solid, and looks cool “look what I did” extension points. I mean, some of the tings you could do with runtime categories, and runtime prototypes were really cool. Now when I work on my 2 apps that originally happily port to Swift&#x2F;UIKit, I’m just left confused with how to make things work. I’m happy when it finally works, and don’t ever try to improve the thing, it’s too much work.<p>There’s lots of different variables at play here; I’m not trying to stretch inference too much. Heck, it could have been that with adding Swift to the mix, the forces that have contributed to reduced quality in Apples stuff would be even worse.<p>I’m just frustrated. When I work in Elixir, I’m like this is cool. When I work in Kotlin, I don’t feel like “Apples got a language like this too, but it’s got that extra special zing that used to make stuff Apple touched cool.”

The article doesn’t give enough attention to the glacial but steady changes in the ownership model that will have great benefit in avoiding copies in value types, Swift’s strength and Achilles heel.<p>I have to say Paul Hudson has almost single-handedly taken over communicating the essentials of Swift to the world; he’s fantastically reliable, brief but enthusiastic, guiding people around the many pitfalls.

Free-form identifiers are neat for test-case naming, but not for `HTTPStatus.`404``. I think having `HTTPStatus.Error404` was a bad idea to begin with. Just use semantic names like `HTTPStatus.NotFound` and you wouldn&#x27;t have a problem in the first place. Now, a single character typo can easily make a 404, 403 and create a bug. It&#x27;s less of a problem with semantic names.<p>If you want constrained numeric types in Swift, that&#x27;s another problem to tackle. But `HTTPStatus.`404`` seems to be the least ideal way to go about it. It lets you do stuff like to declare `HttpStatus.`404`` with a value of 403 too.

“Swift has turned into a gigantic, super complicated bag of special cases, special syntax, special stuff…”<p>— Chris Lattner, 2024<p><a href="https:&#x2F;&#x2F;blog.jacobstechtavern.com&#x2F;p&#x2F;apple-is-killing-swift" rel="nofollow">https:&#x2F;&#x2F;blog.jacobstechtavern.com&#x2F;p&#x2F;apple-is-killing-swift</a>

Lot of nice improvements here. I&#x27;m actually quite liking the async API after using it in a couple small apps and learning the fundamentals.<p>I really wish the entire Swift team would spend a quarter fixing bugs and improving the compiler speed, though. So many trivial SwiftUI cases trigger the &quot;this is too complex for the compiler&quot; errors which are so frustrating to fix.

I&#x27;ve been starting to use Swift again lately after like four years, and while the language is beautiful &amp; the package management story is now a LOT better with SwiftPM, I found that none of it plays nicely with XCode, Simulator, or anything to do with iOS&#x2F;macOS development -- its primary use-case!<p>I found myself awestruck that I *HAD* to use XCode or xcodebuild, and could not just run `swift build` and generate an iOS app.<p>In the end, I had to:<p>- compile the .app structure myself<p>- run codesign manually<p>- manage the simulator manually<p>- bundle xcAssets manually<p>- provide swift linker flags manually targeting the toolchain&#x2F;sdk I needed<p>- manually copy an embedded.mobileprovision<p>It was a good learning experience, but what&#x27;s the story here? Did Apple just give away Swift to the OSS community and then make no ongoing effort to integrate their platforms nicely into the non-xcode build tooling? Looking into <a href="https:&#x2F;&#x2F;github.com&#x2F;stackotter&#x2F;swift-bundler">https:&#x2F;&#x2F;github.com&#x2F;stackotter&#x2F;swift-bundler</a>

It sure feels like Swift governance is broken.<p>They&#x27;re just shoveling stuff in to the language.<p>Individually, most items aren&#x27;t so bad, but collectively they&#x27;ve got a mess and it&#x27;s getting bigger fast.<p>None of the decision-makers seem to have the sense or incentive to say &quot;no&quot; to anything.<p>It&#x27;s sad, because the language had such promise and there are some really nice things in there.<p>Well, at least it&#x27;s relatively easy to avoid or ignore.

&gt; InlineArray does not conform to either Sequence or Collection<p>Why not? Does this mean I need to make a struct which wraps InlineArray and implements Collection? Why didn&#x27;t they do that?<p>EDIT: found the answer (I still have concerns):<p>&gt; While we could conform to these protocols when the element is copyable, InlineArray is unlike Array in that there are no copy-on-write semantics; it is eagerly copied. Conforming to these protocols would potentially open doors to lots of implicit copies of the underlying InlineArray instance which could be problematic given the prevalence of generic collection algorithms and slicing behavior. To avoid this potential performance pitfall, we&#x27;re explicitly not opting into conforming this type to Sequence or Collection.

Swift is collapsing under the weight of its increasing complexity. So many, many special cases &amp; they keep adding more!<p>As a developer it becomes so very hard to reason about code behaviour. This is especially true with concurrency, which was meant to simplify concurrent operations, but in actual fact is a nasty can of worms. In an effort to &quot;hide the complexity&quot; it just introduces a huge amount of unexpected &amp; hard to grok behaviour. The new &quot;immediate&quot; Task behaviour &amp; non-isolated async behaviours are good examples of this.

Spans and inline arrays are the two missing pieces of performance puzzle Swift needed. I&#x27;m super hyped for the release!

Do you try to put everything on the main actor to dramatically reduce your debugging time?

Coding in both swift and rust is really a funny experience. It&#x27;s like two roads being built going toward the same city, but starting from widely different places.

Mostly nonsense updates.<p>Swift was my favorite programming language after C++&#x2F;Java since 2014. I&#x27;ve been faced major updates few times happily. It was one of the most easiest language. But now,<p>I tried to update a project from Swift 5.x to 6.x which has 150+ source files itself and no external libraries which is written by my own use and it has almost all swift 5.x features. They made up Swift as super hard. I decided not to use Swift 6 anymore and yes I don&#x27;t need to reduce debugging time, Even though I don&#x27;t have powerful computer and debugging time isn&#x27;t matter to me &amp; development time is actual matter to me.<p>The language itself becomes Rust (the programming language using by aliens). I Hope Swift language is upgrading itself for Aliens or the Swift team is filled with Aliens. Now, I feel ObjC is super easiest language than Swift.<p>PS: I understand Swift is Corporate Product &amp; upgrading towards SwiftUI than general purpose programming language. I never gonna use Swift 6 even I do use ObjC for my projects.

read news about rust and swift these days, it seems modern c++ might keep its dominance for the future

Swift is amateur hour in action by academics that don&#x27;t value practicality. The new Concurrency was ill thought, and done by people that just perhaps either don&#x27;t have enough practical experience, or are so enamored with the actor paradigm (erlang) that they had to shove it down the throat in a ecosystem where it is not used that much. No one is really using Swift for distributed programing.<p>Glad they are backtracking on this, and I hope they start remove features and simplifying things. Swift&#x27;s enemy is its own self and the people steering int into just an academic exercise, rather than a practical and performant language that can be used in many domains. Server side Swift right now is dead due to all these insane changes.<p>Hopefully things get better on the server&#x2F;other non ios domains, but the language needs to get simplified and become practical and fun to use.

does it really matter if it takes 1 hour to compile?

&quot;a new Observations struct that is created with a closure, and provides an AsyncSequence that emits new values whenever any any @Observable data changes&quot;<p>Is this another asinine onChange()-style mechanism that actually means WILL change? In other words, it tells you BEFORE the value is set on the object, so you can&#x27;t do jack squat with it much of the time.<p>That&#x27;s the M.O. of onChange now, which is utterly brain-dead. Gee, I&#x27;ve been told that a value changed in this object, so let&#x27;s recalculate some stuff. WHOOPS, nope, none of the other objects (or hell, even the affected object) can take action yet because they can&#x27;t interrogate the object for its new contents.<p>Truly incredible that they not only defaulted, but LIMITED change-detection to WILL-change, the least useful of the two choices.

&gt; So, rather than writing &gt; &gt; @Test(&quot;Strip HTML tags from string&quot;) func stripHTMLTagsFromString() {...} &gt; &gt; we can instead write &gt; &gt; @Test func `Strip HTML tags from string`() {...}<p>Maybe I&#x27;m just really new at programming, but this seems like an absolutely bad feature, and the example actually perfectly proves it:<p>You really want to name a function &quot;Hello World!&quot; instead of helloWorld, <i>just so your stack traces can pass a 5th grade English class exam</i>?

There&#x27;s a lot I love about Swift, but I fear it&#x27;s quickly becoming too complicated for its own good.<p>There are just so many ways to solve a problem now that it&#x27;s more or less impossible for someone to be familiar with all of them.

I have not looked at Swift since I last wrote some around maybe v3. I hear that it&#x27;s generally not a competitor to Rust, and is only really useful within the Apple ecosystem. Why is it not more useful as a C++ alternative, since I think that&#x27;s kind of what the initial goal was? Is it just that non-Apple support is new-ish and not yet matured? Or a more fundamental issue?