Been chatting about 1.0 — when it’s coming, what it will involve. The only thing that seems likely is that 1.0 will compile for 8.0, not that 1.0 will be code stable or act as a language development endpoint. Chris Lattner wrote, “Our goal for Swift 1.0 is for *apps* to be binary compatible with the OS, not for Swift 1.0 frameworks to be compatible with swift 2.0 frameworks.  The formal goal (what we’re shooting for) is relatively straight-forward, because apps are hemespherically sealed, and there is almost no dependence of swift 1.0 apps on the OS.”

I asked Lily Ballard about when he saw Swift debuting. He told me, “I’m assuming 1.0 will be live when Xcode 6.0 is released, which I’m assuming has to be done for iOS 8. But that seems awfully soon for Swift, so maybe that won’t actually be the case. Or maybe they’ll do a 1.1 soon after to fix a lot of this stuff.” What everyone can agree on is that iOS 8’s timeline is way too early for Swift, and Apple reserves the right to continue to grow the language in a way that will keep breaking code.

It’s a very odd time to be a tech writer, with an interest in eventually writing about Swift (in my mind, my opus will be called A Swift Kick in the Ass. Dibs.) because to date Apple has continued to update its Swift Programming Language volume at each beta iteration. I assume this will continue as the language continues its evolution and development, which leaves the door open for getting-up-to-speed tutorials, best practices, and tips/tricks but excludes the standard-reference crowd who would be otherwise competing with the Word of Apple.  As a side note, readers expecting Apple-style auto-updating texts will be disappointed by the economics and realities of the tech writing world.

For now, it’s a swiftly moving target (pardon the pun — but yes, it was intentional) trying to keep up with where the language is and where it will be. It’s surprising how much keeps changing beta to beta, in terms of how much code even in a core set of routines needs to be re-written and re-thought through.

Over time playing with the language, what stands out the most though is how often the Swift language doesn’t really fit the Cocoa workflow with its requests, errors, and optional results. There are apparently bunches and bunches of radars for Result types filed with Apple. On the whole, the Cocoa libraries don’t take full advantage of Swift’s generics and enumerations, and other data types because they weren’t written to. Moving to Swift is like bending your head sideways through Rust and F# and all those other cool but psychedelic languages. It’s taking me time, but some of this stuff is starting to sink in and make me look at Swift as a destination of its own rather than just another way to get at the familiar APIs.

The machine-translated APIs don’t help reinforce confidence. They’re full of confusing choices and things that just seem wrong. I’ve started bypassing type inferencing when using Cocoa APIs. I document what I expect to receive, despite the visual redundancy. Upside, it’s giving some of the devs over in #swift-lang some good chuckles.

The more I use Swift, the more I think the Cocoa community should be looking at it as a long-range target. Sure, you’ll be able to develop and submit apps in it sometime soon, but it would probably be a really bad choice to do so for any team serious about maintainable, stable code for the next year at least.