First, there have been some slight language updates. The
Sequence protocol has two new functions:
@availability attribute can now denote which version of Swift an API was removed at, and
UnsafeMutablePointer.initialize(from:) has been deprecated in favor of
UnsafeMutableBufferPointer. The goal there is faster memory initialization.
Additionally, there are a host of Linux improvements (courtesy of IBM), and a “a new family of conversion initializers to all numeric types that either complete successfully without loss of information or return nil.”
Swift 3.1 didn’t add features as they became available, either. In a blog post, core team member Ben Cohen says Swift releases actually have themes. The team decides which features are added, and when, based on a broader look at where the language should go. The blog post is an interesting look at how Swift is being framed piece-by-piece, and makes some interesting points about ‘designing’ the language for the long haul:
The coherent design is important both within the release—because it makes it easier for developers to learn to use the new features together—but also for the long-term health of the language. Without theming proposals, it is very difficult to see how an individual proposal fits into the overall direction of Swift. We would run the risk of making small local changes that we later regret when considering wider-reaching changes to which they are related. There is also a risk of not noticing the accretion of too many keywords or concepts in the language that individually make sense but overall don’t fit well together.
Elsewhere, Swift 3.1 has some neat new tools for package management, and lets you ‘pin’ dependency versions to a build. Packages can also specify the minimum version of Swift necessary, and “package versions which require newer Swift tools than those in use will be ignored by dependency resolution, so packages can adopt new Swift features without breaking clients who are using older Swift tools.”
Beyond Swift, Apple Makes Changes
As Swift 3.1 was released, so were updates to iOS, macOS, watchOS and tvOS. Under the hood, Apple made some important changes for those writing apps for those platforms.
Developers can now respond to App Store reviews, something we’d heard about a few months ago. It seems there’s a buffer period between the time a response is written and when it hits the App Store. Perhaps Apple wants to make sure developers take a breather before responding to an undeserved one-star review (responses have to adhere to the Terms and Conditions, after all). Apple also suggests focusing on poor reviews for the most recent version of an app, but says developers can respond to any review they like.
Apps with pricing info in their name (like ‘Free Pokemon Go Trainer!’) are also being rejected. The company says pricing info should not be included in the name, screenshots or previews of an app, as it’s “not considered a part of these metadata items.” Reading into that, Apple thinks it cheapens the App Store experience (and it’s right).
An updated version of the iOS Security Guide was also published, coinciding with the release of iOS 10.3, which has quite a few security patches. Most notably, the exploit that allowed hackers to use Safari to demand ransom was shored up.
This all comes ahead of WWDC, which takes place this June in San Jose. Registration for the developer event is now open, and closes March 31 at 10:00am PDT. Scholarships are open until April 2 at 5:00pm PDT, and Apple is leaning into Playgrounds this year. Hopeful students will have to build a “visually interactive scene in a Swift playground that can be experienced within three minutes.” Students will also have to provide their educational bonafides, and the scholarships are limited to those 13-17 years old.
Developers should expect sessions at WWDC regarding best practices on replying to reviews and security, and the ‘what’s new in Swift’ sessions are always popular. Unfortunately, we still don’t have ABI stability for Swift, but that’s set to arrive later this year with Swift 4.