Archive for the ‘Announcements’ Category

More on SE-0110: Important fallout, please read (Updated)

Update: Statement from Austin

…I’d like to appreciate my heartfelt thanks to everyone who reached out to me one way or another. It’s clear to me that the Swift, Apple platform developers, and swift-evolution communities are amazing, and that the people in them are kind, wonderful, generous, passionate, and caring. The Core Team in particular has done an incredible job shepherding the community, befriending people on and off the lists, and leading an open-source project of great technical and social complexity.

After thinking about things, I plan to continue participating in swift-evolution and looking for new ways in which I can serve the Swift and Apple developer communities. I hope to listen more, speak less, be more sensitive to other peoples’ feelings, and offer fair, well-considered feedback.

Often the Swift core team will ask for community help to develop and sponsor a proposal. I’ve worked on several of these. These proposals are generally aimed towards simplifying the compiler, enhancing the language, or addressing technical issues that place stumbling blocks in the effective delivery of compilation.

The reconsideration of SE-0110 should not reflect in any negative way on Austin Zheng. He worked hard on a proposal whose intent was to serve the large Swift developer community. I congratulate Austin for shepherding through this proposal, which can be a long, frustrating process.

The usability regression was unexpected. I applaud the core team for its flexibility in responding to the community’s real concerns when its implementation showed issues.

Today, Austin tweeted:

If my posting of the SE-0110 notice last night contributed to a negative atmosphere, I apologize. I have written to Austin and I hope he will reconsider his decision and rejoin Swift Evolution.

State of the Swift PM from the Swift PM PM

From Rick Ballard, Swift Package Manager release manager, a status update with regard to Swift 4. Here’s an overview of the proposals that have recently been incorporated into the system:

We’ve implemented a number of evolution proposal[s] this Spring:

• SE-0152 [ ] introduced a “tools version”, stored in a comment at the top of the Package.swift manifest, which allows you to declare what version of the Swift tools your package requires, and to avoid resolving package dependencies against package versions which require newer tools than those you are using. The tools version is also used to control whether to enable new features such as the revised package manifest API, and to determine which Swift language version is used to interpret the manifest.

• SE-0158 [ ] redesigned the Package manifest API, adopting the Swift API design guidelines and cleaning up some problems in our API. Existing packages can continue to use the old Package manifest API until they update their Swift tools version.

• SE-0151 [ ] introduced a property to control which Swift language version should be used to compile a package’s sources. If this property is not set, the default is determined by the package’s Swift tools version.

• SE-0146 [ ] added explicit control over what products a package vends to clients, and what targets are used to build each product. Packages using the new manifest API must declare any products which they wish their package to vend.

• SE-0175 [ ] removed the conditional “pinning” feature and replaced it with a simpler “resolved package versions” file (“Package.resolved”), along with improvements to SwiftPM’s dependency resolution behaviors.

• SE-0150 [ ] added support for packages which depend on a branch, rather than a tagged version, of other packages. This is especially useful during bringup of a new package, and in-between tagged releases. In order to enforce stability for tagged versions, a tagged package version must only depend on other packages’ tagged versions, not on branches.

• SE-0162 [ ] added API for controlling where the source files for each target should be found. This allows SwiftPM to support source trees that don’t conform to the standard package layout conventions.

• SE-0149 [ ] added support for a “–path” flag to `swift package edit`, allowing users to take full control over an edited dependency and share it between multiple top-level packages.

In addition to these proposals, we’ve made other significant improvements:

• On macOS, package manifest interpretation and the package build are now sandboxed, to help mitigate the effects of maliciously crafted manifests.

• Many error messages and diagnostics have been improved, including information about conflicts during dependency resolution.

• Xcode project generation has been improved, and now allows schemes to reference package targets across regenerations of the project.

• There have been a host of smaller improvements and bugfixes.

All these changes are available in the Xcode 9 beta released today, and in the Swift 4.0 Development snapshots available at

Xcode 9 lays the groundwork for first-class, native support in Xcode for Swift packages with the preview version of its new build system. This build system provides the flexibility and extensibility needed to allow Xcode to support new build models, such as Swift packages. Additionally, considerable work has gone into the SwiftPM library vended by the SwiftPM project, which will support integrating Swift packages into tools like Xcode.

So what’s left in SwiftPM 4? First, we will be implementing SE-0179 [ ], support for a `swift package run` command. Beyond that, we expect to start winding down this release and looking ahead to the next, though we are still open to suggestions or evolution proposals for modest features and fixes.

There are a few features that we originally considered for SwiftPM 4 which are unlikely to be included in this release at this point: performance test support, support for configuration files, support for repositories which contain more than one package, and build settings support. With the possible exception of configuration files, these are likely to be a high priority for the next release. In particular, the core team has done work on a design for build settings which we expect to invite comment and discussion on early in the next release; this is a fairly consequential feature, and we want to make sure to get it right. Since that feature is not landing in SwiftPM 4, we are considering adding some package properties in SwiftPM 4 that will help alleviate some of the biggest pain points here, such as a C++ language version property.

Other features we will likely consider for the next release cycle include support for package resources (such as image assets), license and metadata support, explicit support for handling source control forking, and a generic mechanism for invoking build tools that the package manager doesn’t natively support. Finally, we do anticipate supporting a centralized package index at some point in the future, and we may begin laying the groundwork for that in the upcoming year.

As always, we appreciate the support, feedback, contributions, and adoption we’ve gotten from the package manager community. We’re looking forward to working with you all over the upcoming year to make SwiftPM even better.

Apple open sources key file-level transformation Xcode components

Ted Kremenek writes on the swift-dev list:

This afternoon at WWDC we announced a new refactoring feature in Xcode 9 that supports Swift, C, Objective-C, and C++.  We also announced we will be open sourcing the key parts of the engine that support file-level transformations, as well as the compiler pieces for the new index-while-building feature in Xcode.

We will be releasing the sources in stages, likely over the next few weeks:

– For the refactoring support for Swift, there are some cleanups we’d like to do as well as some documentation we’d like to author before we push these sources back.  Argyrios Kyrtzidis and his team from Apple will be handling that effort.

– For the refactoring support for C/C++/Objective-C, these are changes we’d like to work with the LLVM community to upstream to the LLVM project.  These will likely be first staged to the swift-clang repository on GitHub, but that is not their intended final destination.  Duncan Exon Smith and his team from Apple will be handling that effort.

– We’ll also be open sourcing the compiler support for indexing-while-building, which include changes to both Clang and Swift.   Argyrios and his team will be driving that effort.  For the clang changes they will likely be first staged to swift-clang, and then discussed with the LLVM community to upstream them to mainline Clang.

– Finally, we will be open sourcing the remaining pieces of the Swift migrator.  Argyrios and his team will be handling the push back of changes there, and those changes will only be impacting the swift repository.

As usually, we’ll also be pushing back changes to have Swift work with the latest Apple SDKs.  We’re expecting that push back to happen early next week.  When that happens we will temporarily lock commit access to the repositories.  Details about that will be sent out later in a later email.  Until then, the downloadable toolchains from will continue to work with Xcode 8.3.2.  After we do the push back the downloadable toolchains will be moved to be baselined on the Xcode 9.0 betas.  This shift is necessary as changes to the overlays depend on the latest SDKs.

Xcodes and Kittens: These are a few of my favorite things

Fully redesigned source editor: You can now increase and decrease the source editor font using Command-plus and Command-minus. I have been waiting for this for years. Other highlights include an improved find and replace system, better scrolling, and integrated markdown support.

Better refactoring. Global renaming works across Swift, ObjC, IB, and other file types.  Apple says you can view changes in a unified presentation. The naming strategies for properties, getters, setters, and synthesized ivars are all coordinated.

Better boilerplate. “Fix-it automatically fills in missing cases in switch statements, and mandatory methods for protocol conformance with one click.”

Better Assets including Named Colors. Support for named colors, wide-gamut icons, HEIF images (the ones they discussed during the keynote this morning), and of course, the larger iOS Marketing images.  I suspect “Added option to preserve image vector data for matching Dynamic Type scaling” won’t be as exciting as I’d hope, but I’m looking forward to finding out more.

Github Integration. “GitHub account integration for easy browsing and one-click creation of a project and the associated GitHub repository.”

First class playgrounds. New playground templates designed to run   (depending on the target) on macOS, in the simulator, and on iOS Swift Playgrounds. If you’re looking for them, choose File > New > Playground. They’re not in “File > New” anymore.

What’s New: Things that caught my eye

I love the idea of ARKit, although I wonder about the practicalities of how people will interact with their iDevice while holding it up to look through it. You build a basic AR experience with SceneKit or SpriteKit, and then configure real world anchors based on flat surface destinations. ARKit can pull ambient light estimates for the captured scene, provide overviews of the visualizing camera, and allow you to “hit test” against modeled sufaces.

CoreML looks really really cool. It leverages training data sets to build models that allow you to predict outcomes for new data as it arrives. Apple has introductions to obtaining CoreML models, integrating them into your apps, and importing third-party machine learning to Apple’s framework. The framework is pretty sparse, so it looks like most of the magic will happen behind the scenes.

It was going to happen eventually, and DeviceCheck allows you to access per-device (developer-specific) data that lets you track which devices have previously interacted with your servers and software.

The new Vision framework offers high-performance image analysis and computer vision tech for face identification, feature detection, and scenery classification. Looks a lot like OpenCV-style stuff at first glance.

You’ll be able to create app extensions that help filter unwanted messages using the new IdentityLookup framework, and provide workarounds that respond to unwanted received messages.

The ColorSync framework doesn’t have much there to play with, but its few constants intrigue me.

The FileProvider (and associated FileProviderUI) frameworks are both major components for accessing documents across applications. We’ve seen a bit of this before, but the new fully fleshed out APIs are fascinating.

Finally there’s CoreNFC, which detects and reads NFC tags and their NDEF data. This framework is limited to the iPhone 7 and 7 plus.

Don’t forget to check out the “diff overview” here.

Swift Style: WWDC Sale

Celebrate style in a half shell during WWDC week!

Pick up a copy of Swift Style with a nice discount. The ebook will be 25% off the normal price during WWDC. Use the coupon code Swift_WWDC_2017 at checkout to apply this dub-dub discount to your purchase of the Swift Style ebook at Pragmatic Programmers. (If you encounter any problems during checkout, contact

Thank you for reading my blog and supporting me and my books!

Update: the discount is already live. You don’t have to wait until next week:

Announcing the Thud Programming Language

Thud is an uncompiled programming language based on rocks (also known as “sedimentary development”). Thud is natural, organic, easy to read, and easy to write, as it consists entirely of the keyword Thud.

Thud is type safe and thread safe as Thud has no types or threads. You may type the word Thud in any medium regardless of physical state, with an intrinsic guarantee that each atomic Thud cannot and will not metaphysically interact with any other Thud.

Thud has a low learning curve, regardless of language background. Most developers will be able to Thud in as little as thirty easy lessons.

As Thud is uncompiled and will not run on any computer, it has a very low memory footprint, depending on the local geographic features of the implementation site. Individual instances may be thrown at LLVM developers, who will emit ouch, although this is an unexpected benefit and not a result of the non-existent optimizations built into the toolchain.

Thud is static. Any Thud errors (for example, Thump or GastricDistress) can safely be ignored by any Thuddist developers. Type annotations are unneeded, as are Thud debuggers or Thud unit tests. To ensure correctness, one may throw a Thud at a nearby barista, tax auditor, or neighborhood association chairperson, regardless of LLVM background.

Thud is inherently nullable. That which has no Thud, is not Thud. All instances are therefore automatically guaranteed for thuddability, as non-thuddable elements are not Thud, or on every second Thursday, spork.

Thud includes a powerful macro system for metaprogramming, consisting of leaving Thud instances alone, as they aren’t meant to do anything in the first place.

Thuds can exist concurrently, although there is no mechanism for cross-Thud communication, shared memory, or metamorphic rock formations. Although Thud has a “C-Binding Manifesto”, a lack of developer availability means that at the current time, developers must make their own mean-spirited comments towards C-APIs rather than relying on each Thud‘s natural disdain.

Thud does not allow dependencies, ensuring that you will never encounter errors when using ThudPods or Delenda Est decentralized repository managers.

Thud is not hosted at GitHub, simplifying the need to respond to trivial pull requests and user-sourced corrections. You can support Thud by sending large envelopes of unmarked cash to my personal address.

Swift Drawing: Would you buy this book?

Over the years, I have received any number of letters, emails, and tweets asking if I were going to update my iOS Drawing book. I first wrote a version for Addison Wesley/Pearson as a kind of fun side project between major iOS releases and it was warmly received. Readers liked the practical solutions for low-level drawing and fancy effects.

Since then iOS evolved and Swift arrived. With new types like UIGraphicsImageRenderer and type extensions for structs like CGRect, drawing has a lot of updated power tools on hand and ready to deploy.  Using C-based APIs with Swift can be a bit tricky, so it might be nice to have some guidance and examples. Plus, playgrounds now make the perfect sample code platform.

So would you be a potential purchaser  if I wrote this? I updated about 25% already, just to get a feel for the changes (and I think they’re quite cool), and am looking at using Leanpub to roll out the book a bit at a time. I’m hoping there’s enough traction out there in potential reader-land to make this worth building. I’d anticipate finishing just before WWDC.

Thoughts? Interest? Please let me know. Thanks!

Swift 4: Release Process and Phase 2

Release Process

The Swift 4 release process targets Fall 2017:

Swift 4 is a major release that is intended to be completed in the fall of 2017. It pivots around providing source stability for Swift 3 code while implementing essential feature work needed to achieve binary stability in the language. It will contain significant enhancements to the core language and Standard Library, especially in the generics system and a revamp of the String type. More details can be found on the Swift Evolution page.

Swift 4 Phase 2

The Swift 4 two-stage release plan was established in July 2016: focusing on essentials and ABI stability.  Swift  4 only focuses on Phase 1 at this time. Stage 2 starts now.

All design work and discussion for stage 2 extends to April 1, 2017. The intent is to timebox discussion to provide adequate time for the actual implementation of accepted proposals.

Deferred ABI and Status Updates

Ted Kremenek writes,

Since July, we now have a much better understanding now of how to achieve ABI stability, with an ABI Manifesto detailing the list of all language/implementation work that is needed to achieve ABI stability. We have made substantial progress in that work during stage 1, but much remains to be done. Once Swift achieves ABI stability the ABI can be extended, but not changed. Thus the cost of locking down an ABI too early is quite high.

Deferring ABI stability enables Swift to focus on language fundamentals. An ABI dashboard will be wired up from the Swift Evolution Github repository. This will present a table of remaining ABI tasks and display their status.


Swift Foundation API improvements are folded under the phase 2 umbrella, “to continue the goal of making the Cocoa SDK work seamlessly in Swift. Details on the specific goals will be provided as we get started on Swift 4 stage 2.”

Unimplemented Proposals

The following accepted proposals are rolled forward into Swift 4 Stage 2:

  • SE-0104 “Protocol-oriented Integers”: This proposal requires revision and another round of review based on other changes that have been made to the language and standard library since acceptance.
  • SE-0075 “Adding a Build Configuration Import Test”: This is (still) an additive proposal and no other changes affect this proposal. It will be carried forward and considered accepted for Swift 4.
  • SE-0042 “Flattening the function type of unapplied method references”: This proposal requires another round of review. This is a significant source-breaking change, and the bar for such source-breaking changes is considerably higher in Swift 4 than it was in Swift 3.
  • SE-0068 “Expanding Swift Self to class members and value types”: This is (still) an additive proposal and no other changes affect this proposal. It will be carried forward and considered accepted for Swift 4.