Platform Steering Group

Fellow Swift enthusiasts,

I am delighted to share an update on our community support goals that the Core Team announced last year in an announcement regarding creating new steering groups. For those of you who may have forgotten, the distinction between a workgroup and a steering group is:

  • Steering groups are responsible for the overall strategic direction in a broad area or a necessary process that affects the entire community.

  • Workgroups represent functional areas of the project and drive work in a particular domain or focus area (e.g., Swift on Server, C++ interoperability). Various active contributors lead workgroups.

In that announcement, the Core Team announced we would be turning the Language Workgroup into a steering group and creating a peer steering group called the ecosystem steering group. From the announcement:

Successful programming languages have an extensive supporting system focused on developer experience and productivity through tooling, documentation, and other development resources.

The new Ecosystem Steering Group will focus on growing that support structure for Swift. It will support the evolution of developer and documentation tooling, the website, the package manager, and the package ecosystem. The steering group will also support the work to bring Swift to additional platforms and the tooling to make creating such ports easier. Finally, the group will support the growth of Swift in standard or industry-leading developer productivity tooling including cloud-based IDEs and continuous integration systems.

As the Core Team looked to roll out this plan, we realized this charter encompassed a considerable breadth of surface to support the Swift community's goals, so we felt it better to split it into two steering groups: the Ecosystem Steering Group and a Platform Steering Group.

We made this distinction because bringing Swift to various platforms requires considering both the breadth and depth of technical concerns (such as ABI, platform-specific behaviors, and constraints) with the same level of concern and meticulousness as language design. This split will enable the Ecosystem steering group to tackle its comprehensive charter of the general developer experience and the broader Swift ecosystem more effectively.

After careful consideration, the Core Team has decided to launch the Platform Steering Group first, with the Ecosystem Steering group soon to follow.

Responsibilities of the Platform Steering Group

The Platform Steering Group will have purview over low-level tools in the Swift toolchain, like the SwiftPM build system, the debugger, and the linker, as well as the mechanics of the Swift runtime, including ABI stability and availability of runtime functionality based on platform constraints. You can find more details in the Platform Steering Group Charter, a draft of which can be found in a pull request and will be published on when finalized.

Platform Steering Group Members

I'm thrilled to announce the inaugural members of the Platform Steering Group. Saleem Abdulrasool will serve as the Core Team representative and will provide critical support for the steering group, particularly in its beginning.

The Core Team contacted individuals with expertise across various platforms to form the steering group. One of the first top priorities of the Platform Steering Group is to actively connect with community members who have helped port Swift to more places and facilitate deeper collaboration on those efforts with the Swift community. This outreach may lead to the creation of new workgroups, refinement of the membership of the Platform Steering Group, and so on.

The inaugural members of the Platform Steering Group are:

  • Alastair Houghton
  • Danielle Lancashire
  • Fred Riss
  • Kuba Mracek
  • Rokhini Prabhu
  • Saleem Abdulrasool (Core Team representative and member)

Alastair Houghton is a member of the Apple Swift team, specifically focusing on the language runtime. He was responsible for the backtracing feature in Swift 5.9 and was intensely interested in cross-platform support. Before working for Apple, he worked on everything from bare metal embedded systems to mainframes and has development experience on most major platforms.

Danielle Lancashire currently works on making the cloud more efficient with WebAssembly at Fermyon. She was previously an iOS developer and maintainer of tools like CocoaPods, Nomad, and Kubernetes. She is passionate about bringing clarity and stability to complex systems, which drives her excitement about applying Swift's expressiveness to new platforms and problems.

Fred Riss is a member of the Apple Developer Tools team working on various toolchain components, including debuggers, compilers, and linkers. He previously worked for over a decade on numerous toolchains in other environments, especially targeting embedded environments.

Kuba Mracek is an engineer at Apple who focuses on expanding Swift beyond mainstream operating systems and making Swift an excellent language for operating system development, including constrained embedded setups. In the past, he has worked on deploying Swift to sepOS, the OS running on the Secure Enclave coprocessor of Apple products, and more recently, he has been working as one of the primary engineers behind the vision for Embedded Swift.

Rokhini Prabhu is an engineer on the Darwin Runtime team at Apple and a contributor to the Swift Concurrency runtime, libdispatch, and friends. She spends much of her time exploring paths to integrate Swift in new platforms and spaces like lower-level user space libraries, the kernel, drivers, and embedded environments. She believes language design and adoption are coevolutionary loops influencing each other. She is excited to be part of a new phase of Swift being used in high-privilege, security-sensitive areas traditionally C-dominated.

Saleem Abdulrasool is a member of the Swift Core Team and has been an ardent champion for broadening Swift's reach to different platforms. He has been part of the efforts to support Swift on Android, the primary instigator and maintainer for the Windows port, and worked on the Swift for TensorFlow project. At The Browser Company, Saleem is actively involved with shipping Swift on other platforms and trying to expand the Swift community.

What's Next?

The Platform Steering Group has already had its first meeting, and its first task will be to finalize its charter and organize the outreach to the various ongoing community efforts to take Swift to multiple platforms and domains. Further, they will decide (with review from the Core Team) how to support community discussion around platform support and the formalities of making long-term decisions that impact Swift's platform support.

In the (hopefully not so distant) weeks to come, the Core Team plans to follow suit shortly by announcing the members of the Ecosystem Steering Group.

A Special Thank You to Tom Doron

I'd also like to thank Tom Doron, who is stepping away from his role on the Core Team and various Swift workgroups. A new opportunity has arisen for Tom that will consume most of his attention, and he prefers to hand his Swift open-source leadership responsibilities off so they receive the necessary attention. I've had the privilege to work closely with Tom over the years, watching his entrepreneurial spirit help trailblaze the building of the Swift on Server community — leaving the Swift on Server Workgroup with several fantastic leaders who will carry the torch forward — and seeding work in critical technologies like SwiftNIO and the forward-looking effort on Distributed Actors.

Ted (on behalf of the Swift Core Team)


CC @platform-steering-group

1 Like

This isn't an April Fools joke right!?

How does one apply to join the Steering Group of Silly Walks?


I have never seen core tam members joke like that, and Swift forum is not an entertainment resource. There are no reasons to treat this message as a joke even it was posted at 1st April.


well… RFC: ProbablySafeBufferPointer


Yeah) but there is no sarcasm or irony in Ted's message as in 2018th humorous proposal

This is not an April fools post.


This is a huge step forward, congratulations!

Great news!
I feel that steering the overall strategic direction is what the Swift community is missing right now. Please keep the beautiful simplicity of the language and not allow it to be riddled with unnecessary bells and whistles, especially those that serve the needs of particular frameworks rather than language itself.