Swift.org
swift.org.web.brid.gy
Swift.org
@swift.org.web.brid.gy
Swift is a general-purpose programming language built using a modern approach to safety, performance, and software design patterns.

[bridged from https://swift.org/ on the web: https://fed.brid.gy/web/swift.org ]
Embedded Swift Improvements Coming in Swift 6.3
Embedded Swift is a subset of Swift that’s designed for low resource usage, making it capable of running on constrained environments like microcontrollers. Using a special compilation mode, Embedded Swift produces significantly smaller binaries than regular Swift. While a subset of the full language, the vast majority of the Swift language works exactly the same in Embedded Swift. Additional information is described in the Embedded Swift vision document. Embedded Swift is evolving rapidly. This post describes a number of improvements made in the last few months, covering everything from improved C interoperability to better debugging and steps toward a complete linkage model for Embedded Swift. These features and bug fixes are included in the upcoming Swift 6.3 release, and you can try them out today with a Swift development snapshot. ## Libraries and Diagnostics ### Printing floating point numbers Previously, the `description` and `debugDescription` properties for floating-point types (`Float`, `Double`, etc.) were not available in the Embedded Swift standard library. With a new all-Swift implementation, you can now use these with Embedded Swift. ### Embedded restriction diagnostics There is a new opt-in set of warnings in the EmbeddedRestrictions diagnostic group that diagnoses language constructs that aren’t available in Embedded Swift, such as uses of untyped throws or calling generic functions on existential values. These diagnostics are enabled by default when building Embedded Swift, and can also be enabled in non-Embedded Swift using the compiler flag `-Wwarning EmbeddedRestrictions` or in the package manifest with: swiftSettings: [ .treatWarning("EmbeddedRestrictions", as: .warning), ] Read the full details at EmbeddedRestrictions. ### Swift MMIO 0.1.x The 0.1.x release of Swift MMIO, a package for memory-mapped I/O, includes many bug fixes and quality-of-life improvements, plus newly written comprehensive documentation on the Swift Package Index. The biggest addition is code generation support. There’s now an svd2swift tool and corresponding SwiftPM plugin that generates Swift MMIO interfaces directly from CMSIS System View Description (SVD) files. You can run it manually from the command line, or configure the plugin to handle everything automatically at build time. Debugging also got a nice upgrade with SVD2LLDB. This LLDB plugin lets you work with device registers using their actual names instead of fumbling with the raw memory addresses. It even includes visual decoding support to help you make sense of register values. For example, here’s what it looks like when you decode a hypothetical timer control register: (lldb) svd decode TIMER0.CR 0x0123_4567 --visual TIMER0.CR: 0x0123_4567 ╭╴CNTSRC ╭╴RST ╭╴S ╭╴RELOAD╭╴CAPEDGE ╭╴MODE ┴ ┴─ ┴─ ┴─── ┴── ┴ 0b00000001001000110100010101100111 ┬─ ┬─ ┬─── ┬ ┬─ ┬ ╰╴IDR ╰╴TRGEXT ╰╴PSC ╰╴EN ╰╴CAPSRC ╰╴CNT [31:31] S 0x0 (STOP) [27:26] IDR 0x0 (KEEP) [25:24] RELOAD 0x1 (RELOAD1) [21:20] TRGEXT 0x2 (DMA2) [17:16] CAPEDGE 0x3 [15:12] CAPSRC 0x4 (GPIOA_3) [11:8] CNTSRC 0x5 (CAP_SRC_div32) [7:7] PSC 0x0 (Disabled) [6:4] MODE 0x6 [3:2] CNT 0x1 (Count_DOWN) [1:1] RST 0x1 (Reset_Timer) [0:0] EN 0x1 (Enable) ## C Interoperability ### `@c` functions and enums @c` functions and enums section" href="#c-functions-and-enums"> The Swift evolution proposal SE-0495 provides support for defining C-compatible functions and enums with the `@c` attribute. For example, the following declaration defines a function that is callable from C with the name `MyLib_initialize`: @c(MyLib_initialize) public func initialize() { ... } The Swift generated header from the above example, which can be included in any C/C++ code, contains a declaration of this C function: void MyLib_initialize(void); This feature also works with the `@implementation` attribute introduced in SE-0436. If you have a pre-existing C header that documents a C interface, you can implement that C interface with a Swift function such as: @c @implementation public func MyLib_initialize() { ... } The Swift compiler ensures that the signature of the Swift function matches that of the C header. This allows you to replace an existing C library with a Swift implementation without affecting C clients. The `@c` attribute formalizes the `@_cdecl` attribute, fixing a number of corner cases in the process. ### Improved tolerance of mismatching C signatures The Swift compiler has historically required precise consistency between the Swift types for C functions imported from headers or declared in Swift with `@c` (formerly `@_cdecl`) or `@_extern(c)`. For example, if you declared a C function without nullability annotations in a header: void takePointer(const double *); And then separately defined in Swift with, for example: @c func takePointer(_ values: UnsafePointer<Double>) { ... } The compiler could fail to compile when it noticed the mismatch, often with a hard-to-understand “deserialization” failure. The compiler now keeps the different views on the underlying C declaration separate, diagnosing problems when the underlying C declarations themselves are inconsistent. This allows subtle differences such as nullability or sendability annotations to occur in C signatures without failing to compile. ## Debugging ### Debugger printing of values LLDB’s support for printing the values of Swift types in Embedded Swift has been improved. In addition, the `memory read` command now supports an optional Swift type name, so that you can take an arbitrary address and render it as a value of that named Swift type. The following example shows interpreting the address as the type `MyMessage`: (lldb) memory read -t MyMessage 0x000000016fdfe970 (MessageLib.MyMessage) 0x16fdfe970 = { id = 15 timestamp = 793219406 payload = "hello" ... } ### More data types inspectable in core dumps LLDB needs access to type layout information so it can display variables. Since Embedded Swift doesn’t contain reflection metadata, the Swift compiler emits all the type layout information as DWARF debug info. There have been several improvements to the Swift compiler’s debug info output, such as support for type declarations nested inside an extension. At the same time, LLDB added support for nested generic type aliases in Embedded Swift. These two improvements together make it possible to inspect many common standard library data types, such as `Dictionary` and `Array`, in Embedded Swift core dumps. Previously these data types were only accessible via the expression evaluator, which requires a live process. LLDB also has native support for the new `InlineArray` data type. ### Debugger armv7m exception frames unwinding LLDB’s support for producing backtraces after taking exceptions in armv7m has been greatly improved. Previously after taking an exception, you would be presented with a back trace like the following: (lldb) bt * thread 1 * frame #0: 0x0020392c NeoPixelRainbow`NeoPixelRainbow.swift_UsageFault_Handler() -> () + 28 frame #1: 0x00203910 NeoPixelRainbow`UsageFault_Handler + 8 frame #2: 0xfffffff8 frame #3: 0x00202a86 NeoPixelRainbow`NeoPixelRainbow_main + 8 frame #4: 0x00200256 NeoPixelRainbow`cinit_ctor_loop_end at startup.S:98 frame #5: 0x00200210 NeoPixelRainbow`Reset_Handler at startup.S:33 However this back trace would often be missing one or more frames before the start of the exception frame (`UsageFault_Handler` above). Now, LLDB is able to walk back through exception frames into the standard program frames and produce a backtrace that contains the missing frames. (lldb) bt * thread #1 * frame #0: 0x0020392c NeoPixelRainbow`swift_UsageFault_Handler() + 28 frame #1: 0x00203910 NeoPixelRainbow`swift_UsageFault_Handler() frame #2: 0x00203366 NeoPixelRainbow`static Application.main() + 2270 // Real exception location frame #3: 0x00202a86 NeoPixelRainbow`NeoPixelRainbow_main + 8 frame #4: 0x00200256 NeoPixelRainbow`cinit_ctor_loop_end + 18 frame #5: 0x00200210 NeoPixelRainbow`Reset_Handler + 16 ## Linking ### `@section` and `@used` attributes @section` and `@used` attributes section" href="#section-and-used-attributes"> The Swift evolution proposal SE-0492 introduced two new attributes that are useful in Embedded Swift. The `@section` attribute specifies that a particular global variable should be emitted into the named section: @section("__DATA,mysection") @used let myLinkerSetEntry: Int = 42 Also included is an `objectFormat` check that can be used within `#if` to conditionalize code on the various object formats (ELF, COFF, MachO, Wasm), that you can use to provide different section names: #if objectFormat(ELF) @section("mysection") #elseif objectFormat(MachO) @section("__DATA,mysection") #endif var global = ... The `@used` attribute lets the compiler know that the entity it’s attached to should always be emitted, even if it appears unused. ### Progress on the Embedded Swift linkage model Embedded Swift uses a different compilation model from regular Swift that delays code generation to later in the compilation process. This compilation model has not been fully defined and has various practical problems. One such issue involves duplicate symbols: if you have four Embedded Swift libraries whose dependencies form a diamond, like this: A / \ B C \ / D Then symbols from `A` that are used in both `B` and `C` would cause duplicate definition errors when linking both into `D`. The Swift compiler now emits symbols from imported modules using weak definitions, so the linker can de-duplicate them. This eliminates the need for flags like `-mergeable-symbols` and `-emit-empty-object-file` that provided partial workarounds. Another step along the path to formalizing the Embedded Swift linkage model is SE-0497, which defines a new `@export` attribute that controls how a function is visible to clients. The spelling `@export(implementation)` makes the implementation available for clients to emit, specialize, or inline, subsuming the longstanding but unofficial `@_alwaysEmitIntoClient` attribute. The spelling `@export(interface)` ensures that only the interface and _not_ the definition of the function is made available to clients by emitting a callable symbol, allowing library developers to fully hide the implementation of a function even in Embedded Swift. ## Try it out! Embedded Swift support is available in the Swift development snapshots. The best way to get started is through the examples in the Swift Embedded Examples repository, which contains a number of sample projects to get Embedded Swift code building and running on various hardware. If you have questions about the improvements described here, or want to discuss your own Embedded Swift work, we encourage you to join the conversation on the Swift forums. You can ask about this post in the associated thread, and share your experiences in the Embedded Swift category.
swift.org
November 17, 2025 at 9:09 PM
GSoC 2025 Showcase: Improved Console Output for Swift Testing
The Swift community participated in Google Summer of Code 2025, and we’ve recently been showcasing all of the projects and work accomplished here on the Swift blog. You can learn more by following these convenient links: * Bringing Swiftly support to VS Code * Extending Swift-Java Interoperability * Improved code completion for Swift * Improved console output for Swift Testing (this post) Each GSoC contributor has shared a writeup about their project and experience in the program. The fourth and last post in this year’s series, contributed by Kelvin Bui, improved the console output that is printed when running tests implemented with Swift Testing. To learn more, you can read the full post on the Swift forums. * * * ## Improved Console Output for Swift Testing Hello everyone! My name is Kelvin Bui, and I’m excited to share my GSoC 2025 project, where I worked on improving the console output for the Swift Testing framework with my mentor, Stuart Montgomery. ### Overview This summer, as part of Google Summer of Code 2025, I had the incredible opportunity to work on improving the console output for the Swift Testing framework. The primary goal was to transform the existing static log into a modern, clear, and highly useful tool for developers. The main achievement of this project is the design and implementation of a new, two-phase console reporter, with a primary focus on delivering a comprehensive **Hierarchical Summary** and **Detailed Failure Report**. It also leverages serialization to allow emitting output from a separate supervisor process, in alignment with future project directions. ### Problem & Motivation The default console output for `swift test` was functional but presented several challenges for developers working on large and complex projects: * **Difficulty Locating Failures:** In large test suites, critical failure messages were often lost in a long stream of success outputs, making it hard to quickly assess the health of a test run. * **Lack of Structure:** The flat log format made it difficult to understand the relationship between tests and their parent suites, especially in projects with many nested modules. Our vision was to solve these problems by creating an advanced console reporter that is both informative and intuitive. ### Key Technical Achievements **Hierarchical Test Display:** * A clear, indented tree structure that visualizes the relationship between suites and tests. * An “issues as sub-nodes” model for displaying rich failure context directly within the hierarchy. * An “out-dented” suite summary line that cleanly concludes each suite’s output. **Serialization-Based Architecture:** * A future-proof design that processes `ABI.EncodedEvent` objects, preparing the reporter for an out-of-process harness architecture. * Logic to build an in-memory representation of the test plan by consuming initial test discovery events and then looking up test details by ID for subsequent events. **Rich Failure Reporting:** * A dedicated `FAILED TEST DETAILS` section that provides comprehensive information for each failure, including the fully qualified test name, a detailed error message, and the exact source location (`file:line`). ### Visuals: Before & After The Advanced Console Output Recorder fundamentally transforms how developers interact with test results. By introducing a visual hierarchy and detailed contextual information, it elevates the diagnostic experience from a flat, hard-to-parse log into a structured, scannable report. **Current Console Output:** Prior to this project, the default `swift test` output presented a linear, undifferentiated stream of events. While functional, this format lacked visual cues, making it challenging to quickly identify test relationships, pinpoint failures within large suites, or understand the overall structure of a test run. The absence of clear demarcation between test suites and individual tests often led to slower debugging cycles and increased cognitive load for developers. **New Hierarchical Summary:** The new recorder introduces a rich, hierarchical display that immediately brings order and clarity to test output. Using Unicode box-drawing characters (with ASCII fallback), it clearly visualizes the nested structure of test modules, suites, and individual tests. This not only makes the test results significantly easier to read and navigate but also provides crucial context around failed tests, displaying detailed issue descriptions directly within their respective hierarchical nodes. This transformation dramatically improves the developer experience by offering instant insights into test organization and failure points. ### Challenges & Lessons Learned **Technical lessons:** * Designing for serialization & ABI: Refactoring to consume ABI.EncodedEvent taught me the value of decoupling - moving from in-process object graphs to a serialized event stream increases robustness and enables harness-style execution. It also exposed careful trade-offs: serialization simplifies process boundaries but requires stable encoding contracts and more explicit discovery/lookup logic for test metadata. * Building a thread-safe collector for results required balancing lock granularity and throughput. The adopted strategy (a single lock per event bucket, plus careful mutation patterns) simplifies correctness while keeping contention low for typical test workloads. * Cross-platform fallbacks: Supporting ASCII fallback for line-drawing characters taught me to design for the weakest terminal capability first, then progressively enhance for modern terminals. Testing across Windows/Linux/macOS terminals and non-interactive CI runners uncovered many small but critical edge cases (line-wrapping, width detection fallbacks). * Deciding what to show inline vs. in a details section is a UX trade-off; too much inline detail makes the tree noisy, and too little hides useful context. The two-tier approach (short inline message + full details section) balances these needs. **Collaboration & process lessons:** * Presenting to the workgroup matters: Early live presentation to the Swift Testing workgroup exposed design assumptions quickly and gave direction that influenced major architectural choices. * Iterative, small PRs win: Breaking work into digestible PRs (skeleton → ABI pivot → UI features) made reviews actionable and reduced reviewer fatigue. * Incorporating targeted reviewer comments (e.g., ABI pivot) showed the importance of documenting design decisions (why we choose serialization, how the tree is constructed), which speeds later onboarding and review cycles. **Personal growth:** I learned how to accept and act on high-quality feedback from senior engineers, and how to reframe technical trade-offs as testable hypotheses. The project sharpened my ability to move from mockups to production code while keeping maintainability and cross-platform compatibility as first-class concerns. ### Acknowledgements I’d like to express my deepest gratitude to my mentor, Stuart Montgomery, for his exceptional guidance, patience, and technical insights throughout this entire project. His mentorship has been invaluable. I’d also like to thank Jonathan Grynspan for his crucial, in-depth architectural feedback, which significantly improved the project’s long-term viability. Thank you as well to **Swift Testing Workgroup** , and all the other members of the Swift community who provided thoughtful feedback on the forums. This project would not have been possible without your collective expertise and support.
swift.org
November 15, 2025 at 3:09 PM
Swift GSoC 2025 highlight: Improved code completion for Swift
Our blog post series showcasing the Swift community’s participation in Google Summer of Code 2025 continues with our third update. Learn more about the projects and work accomplished: * Bringing Swiftly support to VS Code * Extending Swift-Java Interoperability * Improved code completion for Swift _(this post)_ * Improved console output for Swift Testing _(coming soon)_ Each GSoC contributor has shared a writeup about their project and experience in the program on the forums. Today’s featured project improved how documentation is displayed during code completion in IDEs, contributed by Ahmed Elrefaey. To learn more, you can read the full post on the Swift Forums! The project enhances SourceKit-LSP, an implementation of the Language Server Protocol (LSP) for Swift and C-based languages. Now you can see full documentation during code completion instead of just brief summaries, as well as what arguments are available to pass when calling functions. Editors that support the Language Server Protocol all benefit from these improvements to SourceKit-LSP, bringing these features to editors like VS Code, Neovim, IntelliJ IDEA, Vim, and more. This work has landed in the SourceKit-LSP project, and will be included in a future Swift toolchain release. * * * ## Improve the display of documentation during code completion in SourceKit-LSP Hi everyone! This is Ahmed Elrefaey. I’m excited to share with you an update on my GSoC project which improved the display of documentation during code completion for Swift. I worked on improvements to SourceKit-LSP, which is an implementation of the Language Server Protocol (LSP) for Swift and C-based languages. My GSoC project was mentored by Hamish Knight. ### Project Goals The aim of this project is to enhance how documentation is displayed in SourceKit-LSP during code completion by: 1. Showing the full documentation for a code completion item instead of the first paragraph only, which we call “brief documentation”. 2. Implementing Language Server Protocol’s signature help request showing the user which overloads are available, along with their corresponding documentation. ### Progress During this summer, we have made great progress on this project that I want to share with you. We have successfully implemented full documentation comment retrieval for completion items by lazily retrieving the full documentation comment upon request to avoid having to fetch all documentation comments at once. Here’s what SourceKit-LSP currently provides in VS Code (brief documentation): And here’s how it looks with full documentation: We have also implemented a large portion of signature help support, showing the available overloads and their corresponding documentation while editing. We reused the existing argument completion logic to determine the overloads and refactored the code completion item description implementation to reuse it in signature help. Here’s a quick demo of signature help in VS Code. To try this out in VS Code for yourself, you can download a main development snapshot from swift.org. If using Swiftly you can run `swiftly install main-snapshot`. Then, in VS Code you can pick “Select Toolchain” from the Command Palette and select the newly downloaded toolchain. ### Closing Thoughts I’m incredibly grateful for this opportunity to contribute to the Swift project, and I really learned a lot from this experience. I’d like to thank my mentor, Hamish Knight, for his unwavering support and guidance throughout this summer. I’d also like to thank Alex Hoppen, Rintaro Ishizaki, and Ben Barham for their valuable feedback during code review.
swift.org
November 13, 2025 at 11:00 AM
Introducing Temporal Swift SDK: Building durable and reliable workflows
The Temporal Swift SDK is now available as an open source project. Building reliable distributed systems requires handling failures gracefully, coordinating complex actions across multiple services, and ensuring long-running processes complete successfully. Rather than develop these resiliency features into every application or service you develop, an alternative approach is to use **workflows**. Workflows encapsulate your code so it runs durably and handles many common failure scenarios. Temporal is widely used for workflow orchestration across many languages. With the release of the SDK, Temporal is now available for Swift developers building production cloud services. An announcement post is also available on the Temporal blog with more information for their developer community. ## Writing durable workflows in Swift Durable workflows run to completion even when infrastructure fails. If your server crashes mid-execution, Temporal automatically resumes the workflow from where it left off with no lost state or manual intervention required. By bringing this capability to the Swift ecosystem, developers can focus on application logic while Temporal handles state management, retries, and recovery. The SDK provides a seamless Swift developer experience by: * Using familiar async/await patterns and structured concurrency to build maintainable workflow code. * Leveraging Swift’s strong type system to catch errors at build time rather than runtime. * Providing macros to reduce boilerplate when authoring workflows. Temporal workflows are particularly valuable for handling multi-step coordination in applications that must survive failures, such as data pipelines, business automation, payment processing, and operational tasks. ## What is Temporal and why does it matter? Temporal is an open source platform for building reliable distributed applications. At its core is the concept of durable execution, your code runs to completion even in the face of infrastructure failures. When a worker crashes or restarts, Temporal automatically resumes your workflow from where it left off, without requiring you to write complex retry logic or state management code. This is achieved through Temporal’s architecture, which separates workflow orchestration from actual work execution: * **Workflows** define the overall business logic and coordination. They describe the sequence of steps, decision points, and error handling for a process. Workflows must be deterministic. Given the same inputs and history, they must always make the same decisions. * **Activities** perform the actual work, such as calling external APIs, processing data, or interacting with databases. Activities should be idempotent, meaning they can be safely retried without causing unintended side effects. Modern distributed systems face common challenges: coordinating multiple services, handling partial failures, ensuring consistency across operations, and managing long-running processes. Traditional approaches require building custom retry logic, state machines, and coordination mechanisms. Temporal provides a platform that handles these concerns, allowing you to focus on your business logic. ## Getting started To get started with the Temporal Swift SDK, explore its documentation which provides detailed guides for implementing workflows and activities. The repository also includes a rich collection of example projects, demonstrating the SDK’s capabilities across different use cases from simple task orchestration to complex multi-step business processes. For a deeper understanding of Temporal’s core concepts and architectural patterns, check out the general Temporal documentation, which provides valuable context for building robust distributed systems. For a video introduction, watch this conference presentation from Server-Side Swift 2025 where the project was announced. ## Community and feedback Temporal Swift SDK is an open source project and we’re eager to hear from the Swift community. Whether you’re building microservices, coordinating long-running processes, or simply curious about durable execution, we’d love to know how the Temporal Swift SDK works for you. The project is actively developed and we welcome contributions, bug reports, and feature requests. Ready to start building reliable distributed systems? Visit the Temporal Swift SDK repository to get started.
swift.org
November 11, 2025 at 8:59 AM
GSoC 2025 Showcase: Extending Swift-Java Interoperability
This is the second post in our series showcasing the Swift community’s participation in Google Summer of Code 2025. Learn more about the projects and work accomplished: * Bringing Swiftly support to VS Code * Extending Swift-Java Interoperability (this post) * Improved display of documentation during code completion in SourceKit-LSP _(coming soon)_ * Improved Console Output for Swift Testing _(coming soon)_ Each GSoC contributor has shared a writeup about their project and experience in the program on the Swift forums. Today’s featured project improved interoperability between Swift and Java, contributed by Mads Odgaard. Mads recently presented on this project at the Server-Side Swift conference: Expanding Swift/Java Interoperability, and you may have noticed it in action in the recent Swift.org blog post: Announcing the Swift SDK for Android! To learn more, you can read the full post on the Swift forums. * * * ## JNI mode for SwiftJava interoperability jextract tool My name is Mads and I am excited to share with you what I have been working on for Swift/Java interoperability over the summer with my mentor Konrad Malawski for Google Summer of Code 2025. # Overview The swift-java interoperability library provides the `swift-java jextract` tool, which automatically generates Java sources that are used to call Swift code from Java. Previously, this tool only worked using the Foreign Function and Memory API (FFM), which requires JDK 22+, making it unavailable on platforms such as Android. The goal of this project was to extend the jextract tool, such that it is able to generate Java sources using JNI instead of FFM and thereby allowing more platforms to utilize Swift/Java interoperability. I am very glad to report that we have succeeded in that goal, supporting even more features than initially planned! Our initial goal was to achieve feature parity with the FFM mode, but the new JNI mode also supports additional Swift language features such as enums and protocols! With the outcome of this project, you can now run the following command to automatically generate Java wrappers for your Swift library using JNI, therefore opening up the possibility of using it on platforms such as Android. swift-java jextract --swift-module MySwiftLibrary \ --mode jni \ --input-swift Sources/MySwiftLibrary \ --output-java out/java \ --output-swift out/swift # How does it work? Each Swift class/struct is extracted as a single Java `class`. Functions and variables are generated as Java methods, that internally calls down to a native method that is implemented in Swift using `@_cdecl`. Take a look at the following example: public class MySwiftClass { public let x: Int64 public init(x: Int64) { self.x = x } public func printMe() { print(“\(self.x)”); } } It is roughly generated to the equivalent Java `class`: public final class MySwiftClass implements JNISwiftInstance { public static MySwiftClass init(long x, long y, SwiftArena swiftArena$) { return MySwiftClass.wrapMemoryAddressUnsafe(MySwiftClass.$init(x, y), swiftArena$); } public long getX() { return MySwiftClass.$getX(this.$memoryAddress()); } public void printMe() { MySwiftClass.$printMe(this.$memoryAddress()); } private static native long $init(long x, long y); private static native long $getX(long self); private static native void $printMe(long self); } We also generate additional Swift thunks that actually implement the `native` methods and call the underlying Swift methods. You can learn more about how the memory allocation and management works in the full version of this post on the Swift forums! An interesting aspect of an interoperability library such as `swift-java` is the memory management between the two sides, in this case the JVM and Swift. The FFM mode uses the FFM APIs around `MemorySegment` to allocate and manage native memory. We are not so lucky in JNI. In older Java versions there are different ways of allocating memory, such as `Unsafe` or `ByteBuffer.allocateDirect()`. We could have decided to use these and allocate memory on the Java side, like FFM, but instead we decided to move the responsibility to Swift, which allocates the memory instead. This had some nice upsides, as we did not have to handle the complexity of witness tables like FFM mode does. > For more info on memory in FFM, I strongly recommend watching Konrad’s talk try! Swift Tokyo 2025 - Foreign Function and Memory APIs and Swift/Java interoperability The most obvious place we need to allocate memory is when we initialize a wrapped Swift `class`. Take a look at the following generated code for a Swift initializer: public static MySwiftClass init(SwiftArena swiftArena$) { return MySwiftClass.wrapMemoryAddressUnsafe(MySwiftClass.$init(), swiftArena$); } private static native long $init(); Here we see that we are calling a native method `$init` which returns a `long`. This value is a pointer to the Swift instance in the memory space of Swift. It is passed to `wrapMemoryAddressUnsafe`, which is basically just storing the pointer in a local field and registering the wrapper to the `SwiftArena`. `SwiftArena` is a type that is used to ensure we eventually deallocate the memory when the Java wrapper is no longer needed. There exists two implements of this: 1. `SwiftArena.ofConfined()`: returns a confined arena which is used with _try-with-resource_ , to deallocate all instances at the end of some scope. 2. `SwiftArena.ofAuto()`: returns an arena that deallocates instances once the garbage-collector has decided to do so. This concept also exists in the FFM mode, and I recommend watching Konrad’s talk at try! Swift Tokyo 2025 to learn more! If we take a look at the native implementation of `$init` in Swift, we see how we allocate and initialize the memory: // Generated code, not something you would write @_cdecl("Java_com_example_swift_MySwiftClass__00024init__JJ") func Java_com_example_swift_MySwiftClass__00024init__JJ(environment: UnsafeMutablePointer<JNIEnv?>!, thisClass: jclass, x: jlong, y: jlong) -> jlong { let result$ = UnsafeMutablePointer<MySwiftClass>.allocate(capacity: 1) result$.initialize(to: MySwiftClass.init(x: Int64(fromJNI: x, in: environment!), y: Int64(fromJNI: y, in: environment!))) let resultBits$ = Int64(Int(bitPattern: result$)) return resultBits$.getJNIValue(in: environment!) } We are basically allocating memory for a single instance of `MySwiftClass`, initializing it to a new instance and returning the memory address of the pointer. It is the same approach for `struct` as well! # My experience with GSoC Google Summer of Code was an awesome experience for me! I got to work with my favorite language on a library that is very relevant! A HUGE thanks to my mentor Konrad Malawski, who provided invaluable guidance, was always available for questions and allowed me to experiment and take ownership of the work! I would definitely recommend GSoC to anyone interested, it is a great way to engage with the open-source community, develop your skills and work with some talented people! My number one advice would be to never be afraid of asking what might seem to be embarrassing questions, they might actually turn out to be great questions and lead to useful discussions and solutions.
swift.org
November 8, 2025 at 4:55 AM
GSoC 2025 Showcase: Swiftly support in VS Code
Another successful year of Swift participation in Google Summer of Code recently came to an end, and we’d like to shine some light on the projects and work accomplished! Summer of Code is an annual program, organized by Google, which provides hands-on experience for newcomers contributing to open source projects. In this series of four blog posts, we’ll highlight each of the Summer of Code contributors and their projects. You can navigate between the posts using these convenient links: * Bringing Swiftly support to VS Code (this post) * JNI mode for swift-java’s source jextract tool _(coming soon)_ * Improved display of documentation during code completion in SourceKit-LSP _(coming soon)_ * Improved console output for Swift Testing _(coming soon)_ Each GSoC contributor has shared a writeup about their project and experience in the program on the forums. The first project we’re featuring on the blog brought Swiftly support to Visual Studio Code, contributed by Priyambada Roul. To learn more, you can read the full post on the Swift forums. * * * ## Bringing Swiftly support to VS Code I am Priyambada Roul. I’m incredibly excited to share what I’ve been working on over the past three months as part of Google Summer of Code 2025 with Swift.org, alongside my mentors, Chris McGee and Matthew Bastien. My project focused on integrating **Swiftly** (Swift’s toolchain manager) into the **VS Code Swift extension.** ## The Problem We Solved We’ve made switching toolchains easier with Swiftly, allowing you to install and switch between Swift versions without leaving VS Code. Developers can now: 1. **Switch Swift versions** with a single click 2. **Install new toolchains** without leaving VS Code 3. **See real-time progress** during installations 4. **Automatically sync** with project-specific Swift versions ## What’s New for Swift Developers ### Swiftly VS Code Integration The VS Code extension now provides an entirely **seamless toolchain management experience** : * We now support macOS too! * See your current Swift version in the VS Code status bar * Click the version to switch between installed toolchains instantly * Install any Swift version directly from VS Code with real-time progress * Automatic detection of .swift-version files with prompts to switch ### Enhanced Swiftly CLI * Swiftly now supports a machine-readable JSON output format * Swiftly now reports toolchain installation progress updates in **JSONL format** * We have polished error reporting This experience is already shipping in the latest update of the VS Code extension, so you can try it yourself now! ### Things I learnt * Making a VS Code extension. While I have experience with TypeScript from web development, the VS Code extension API and its development workflow are different from what I’m used to. * I understood the structure and distribution of Swift toolchains, as well as how different versions can coexist on the same system using symlinks, environment variables, and PATH manipulation, across both macOS and Linux. * The extension spawns Swiftly processes and reads their JSON output streams in real-time. This involved learning about IPC mechanisms, stdin/stdout buffering and process lifecycle management. Want to see what we built? Check out the repositories: * **VS Code Swift Extension** : github.com/swiftlang/vscode-swift * **Swiftly CLI** : github.com/swiftlang/swiftly I have linked all pull requests and technical details in my **detailed project report** , which provides an in-depth look into the specific changes. This GSoC experience has been transformative. I came in as someone intimidated by large codebases, and I’m leaving with the confidence to tackle complex, multi-tool integrations. I’m excited to continue contributing to Swift community!
swift.org
November 7, 2025 at 3:12 AM
What's new in Swift: October 2025 Edition
_Editor Note: This is the first of a new series, What’s new in Swift, a monthly digest featuring what’s new in the Swift project and ecosystem, with insights and perspectives from across the Swift world. This October edition covers highlights from the Server Side Swift conference, major package releases, and the latest Swift Evolution proposals._ _Thanks to Joe Heck for sharing his conference experience and insights as our inaugural guest contributor._ ## Guest contributor highlights > At the beginning of October, I attended the Server Side Swift conference, my second year attending. I love that it focuses on using Swift both with and beyond Apple devices. This makes the conference a bit different from others you’ll see talked about by the community. > > The keynote, by Ben Cohen, talked about language performance and the balancing act of the advances and continued work on the Swift language to enable you to reach for extremely high code performance. Having developed server and infrastructure apps in the past myself, I highly value the combination of the ease of developing in Swift and its impressive safety guarantees while also being able to drive out that “goes brrr” code performance. > > In addition to low-level code performance, the conference had a great talk Observability in Swift-Side Swift on how to keep an eye on the performance of your service as part of a bigger system. I’ve long been a fan of distributed tracing, and the 1.0 release of swift-otel enables server apps to provide logs, metrics, and traces using the OpenTelemetry standard to system observability tools. The 1.29.0 release of async-http-client just makes that process even easier, and I’ll briefly note that the new Valkey client for Swift also now includes full support for distributed tracing. > > — Joe Heck Joe’s conference experience highlights some of the exciting developments we’re seeing across the Swift ecosystem. Let’s dive into the broader picture of what’s been happening in the Swift community this month. ## October 2025 updates ### Featured community projects * Swift SDK for Android - The Android workgroup announced in the blog a preview release of an SDK supporting Android, and a dedicated Android platforms category in the Forums. * The Swift Extension of VS Code - Useful for developing server apps in Swift, the Swift Extension of VS Code is rapidly evolving and just released v2.12.0 featuring swiftly integration and a new walkthrough for first-time users. * Swift Build and Packaging Workgroup - A new workgroup under the ecosystem steering group with a focus on the tools used to build and package Swift code. * Swift Package Manager documentation - The documentation for the Package Manager is refreshed and now published, including the API references, on docs.swift.org. ### Talks and presentations Talks from the Server-Side Swift conference, hosted in London at the beginning of October, are now being published online. The following are two talks that stood out to me, which I’d like to share to encourage you to investigate the Server-Side Swift playlist of talks. * Unlock Generative AI for Swift Server-Side Development - Mona walked through using a library she helped create that uses large language models with her server side code. * Building Networking Libraries with Span and Concurrency - Joannis talks about how Swift concurrency can support network libraries for heavily concurrent data flows and the new Span feature from Swift 6.2 to provide efficient access for network buffers. ### The Swift package ecosystem * Swift OTel - recent update 1.0.1 : An Open Telemetry exporter for a service to publish logs, metrics, and tracing to an OTel collector. * Swift Configuration - new release 0.2.0 : A new package, using the same pattern as swift-log and swift-metrics, to load configuration that supports a variety of loaders including JSON, YAML, and environment variables. * Swift Profile Recorder - new release 0.3.8 : An in-process profiler to help you capture what your code is spending time doing, so you can optimize its performance. * Swift Collections - recent update 1.3 : Among other updates, this adds UniqueArray to the collections provided - a high-performance collection type that takes advantage of the Swift’s performance advances with the types Span, InlineArray, and non-copyable types in Swift. * swiftly - recent update 1.1.0 : This adds deeper integration to help with developing Swift using VS Code. ### Swift Evolution The Swift project adds new language features to the language through the Swift Evolution process. These are some of the proposals currently under discussion or recently accepted for a future Swift release. **Under active review:** * SE-0497 Controlling function definition visibility in clients - The @inlinable attribute in Swift allows function definitions to be visible to callers, enabling optimizations like specialization and inlining. This proposal introduces explicit control over whether a function generates a callable symbol and makes its definition available for optimization purposes. **Recently completed:** * SE-0495 C compatible functions and enums (**accepted**) - This proposal introduces the @c attribute to mark Swift functions and enums as callable and representable in C, respectively. It aims to formalize and extend the experimental @_cdecl attribute. * SE-0496 @inline(always) attribute (**accepted**) - The Swift compiler uses inlining to optimize code by expanding function bodies into callers, but it may not always inline functions due to size concerns. The @inline(always) attribute allows developers to force inlining for specific functions. ### Share what you’re working on If you’re making something available that you’d like to highlight, create a thread on the Swift Forums Community Showcase. Please also nominate packages that you find interesting for potential inclusion into the Package Showcase hosted on Swift.org
swift.org
November 1, 2025 at 3:44 PM
How Swift's server support powers Things Cloud
You might be familiar with Things, a delightful personal task manager that has won two Apple Design Awards and is available across Apple devices including iPhone, iPad, Mac, Apple Watch, and Apple Vision Pro. At Cultured Code, the team behind Things, we care about a great user experience across every aspect of the product. This extends to our server back end, and after a rewrite our Things Cloud service has transitioned entirely to Swift. Over the past year in production, Swift has consistently proven to be reliable, performant, and remarkably well-suited for our server-side need. Things Cloud serves as the backbone of the app’s experience, silently synchronizing to-dos across devices. The robustness of this work is ensured by a rigorous theoretical foundation, inspired by operational transformations and Git’s internals. After twelve years in production, Things Cloud has earned our users’ trust in its reliability. But despite the enduring strength of the architecture itself, the technology stack lagged behind. Things Cloud synchronizes to-dos across different devices. ## Switching to Swift Our legacy Things Cloud service was built on Python 2 and Google App Engine. While it was stable, it suffered from a growing list of limitations. In particular, slow response times impacted the user experience, high memory usage drove up infrastructure costs, and Python’s lack of static typing made every change risky. For our push notification system to be fast, we even had to develop a custom C-based service. As these issues accumulated and several deprecations loomed, we realized we needed a change. A full rewrite is usually a last resort, but in our case, it was the only viable path for Things Cloud. We explored various programming languages including Java, Python 3, Go, and even C++. However, Swift – which was already a core part of our client apps – stood out for its potential and unique benefits. Swift promised excellent performance, predictable memory management through ARC, an expressive type system for reliability and maintainability, and seamless interoperability with C and C++. While we initially had concerns that Swift’s server support wasn’t as mature as that found in other ecosystems, both Apple and the open-source community had shown strong commitment to its evolution. Swift had reliably compiled on Linux for a long time; the Swift Server workgroup had coordinated server efforts since 2016; the SwiftNIO library gave us confidence in the foundational capabilities, and Vapor provided all the tools to get us up and running quickly. Convinced by these benefits and the opportunity to use the same language for client and server development, we embarked on a three-year journey to rewrite Things Cloud. We’ve been using it internally for the past two years, and it has now been live in production for over a year. ## The new Swift-based service architecture We’ll outline the core components of our new service architecture, highlighting the Swift packages we use. We’ve found that these components work well together to provide reliability and stability, and we believe this serves as a valuable reference point for others considering a similar transition to Swift. Overview of our new Swift-based service architecture. ### Code * Our **Swift** server codebase has around 30,000 lines of code. It produces a binary of 60 MB, and builds in ten minutes. * It uses **Vapor** as an HTTP web framework, which uses **SwiftNIO** as its underlying network application framework. * We compile a single “monolith” binary from our Swift source code, but use it to run multiple services, each configured by passing different parameters at runtime. * We use **Xcode** for its robust suite of tools for development, debugging, and testing. It provides us with a familiar and consistent experience across both server and client environments. ### Deployment * **AWS** hosts our entire platform, and is entirely managed by **Terraform** , an infrastructure as code tool. * We use a continuous integration pipeline to automate tests and build our Swift code into a **Docker** image. This is then deployed in a **Kubernetes** cluster alongside other components. * The **HAProxy** load balancer is used to route client traffic to the appropriate Swift service in the cluster. ### Storage * Persistent data is stored in **Amazon Aurora MySQL** , a relational database, which we connect to with **MySQLKit**. * To keep the database small, we’re offloading less-used data to **S3** , which we access via the **Soto** package. * More ephemeral data, such as push notifications and caches, is stored in **Redis** , an in-memory key-value database, which we access via **RediStack**. ### Other Services * The **APNSwift** package is used to communicate with the Apple Push Notification service. * **AWS Lambda** , a serverless compute service, powers our **Mail to Things** feature. This process is written in Python 3 due to its mature libraries for the processing of incoming emails. The results are passed to Swift using **Amazon Simple Queue Service**. ### Monitoring * We take the resilience of Things Cloud seriously and go to great lengths to ensure it. * In Swift, we generate JSON logs using our own logger. To produce metrics, we’re using the **Swift Prometheus**. * We use **Amazon CloudWatch** to store and analyze logs and metrics. It triggers Incidents, which reach the responsible engineer via **PagerDuty**. * To test how well our service can recover from transient errors, we employ **chaos testing**. Each day, our self-written chaos agent performs random disruptive actions such as terminating a Swift service or restarting the database. We then verify that the system recovers as expected. ## Results We wanted to thoroughly test the performance and stability of the new Swift service architecture before it was deployed in production. So during the development phase, we deployed the new system alongside the existing legacy system. While the legacy system continued to be the operational service for all requests, the new system also processed them independently using its own logic and database. This approach enabled us to develop and test the new system under real-world conditions without any risk to the user experience. Thanks to the confidence we built in the new system’s robustness and reliability through evaluating it with production workloads, we were able to deploy a hardened system from the very beginning. Now, with over a full year in production, we’re pleased to report that Swift has fulfilled its promise for server-side development. It’s fast and memory-efficient. Our Kubernetes cluster comprises four instances, each with two virtual CPUs and 8 GB of memory, and has handled traffic peaks of up to 500 requests per second. Compared to the legacy system, this setup has led to a more than threefold reduction in compute costs, while response times have shortened dramatically. Comparison between our legacy service and new Swift-based one. And one extra win: Swift’s outstanding performance allowed us to replace our custom C-based push notification service with a Swift-based one; this significantly simplified our codebase and operations. ## Conclusions Swift turned out to be a great choice for server usage. It delivered on everything we had hoped for: We’re now using a modern and expressive programming language, the code runs and performs well, and the Swift ecosystem provides all the integrations we need. With a year of production use, we haven’t encountered a single operational issue. For more information on our journey and experiences, you might enjoy our recent talk at the ServerSide.Swift conference. We encourage other teams to consider using Swift for server-oriented projects. While we chose to undergo a complete rewrite, the gradual adoption of Swift is also an intriguing option, especially considering the recently announced initiative aimed at enhancing Java interoperability. As for us, we believe our server architecture is in its best shape ever, and we’re thrilled about the new features we can build upon this solid foundation.
swift.org
October 30, 2025 at 11:43 AM
Introducing swiftly 1.0
Today we’re delighted to introduce the first stable release of swiftly, a Swift version manager that takes the pain out of installing, managing and updating your Swift toolchain. The latest version of Swift is bundled with Xcode for writing apps for Apple platforms. But perhaps you want to install Swift on a different platform like Linux, or use a different version of the toolchain for building services or command line tools. Downloading, extracting and installing a trusted build of Swift along with the relevant dependencies for your operating system can require quite a few manual and error-prone steps. swiftly has been around for some years as a community-supported tool for Swift developers using Linux. With this release, we’re officially supporting it as part of the core Swift toolchain, including hosting it as part of the Swift GitHub organization. We’ve also added macOS support to make it easier to install Swift separately from Xcode. ## Introducing swiftly swiftly is the best tool to install the standalone toolchain, providing commands to install Swift on a new system, update to the latest stable version, and experiment or test with nightly snapshots or older versions. It also makes it easy to switch effortlessly between multiple installed toolchains. You can even add a file to your project repository so swiftly will use the same toolchain version for all members of your development team. Naturally, swiftly itself is written in Swift, and is able to update itself to the latest version. ## Quick tour Let’s take a look at some of the features of swiftly! To get started, visit swift.org/install and install it. swiftly will provide directions after installation if there are any system packages, or shell commands needed for smooth operation of the new toolchain. The latest Swift toolchain is installed as the default, so you can immediately use it to start a new project. For example: $ swift package init The `swiftly use` command selects the default toolchain for Swift commands (e.g. `swift test`, `swift build`): $ swiftly use 6.0.3 $ swift --version -- Apple Swift version 6.0.3 (swiftlang-6.0.3.1.2 clang-1600.0.28.6) Target: arm64-apple-macosx15.0 At a later point, if there’s a new release of Swift you can install it alongside the existing toolchain with the `latest` command: $ swiftly install latest Pre-release of versions of Swift are available, including nightly “snapshot” toolchains. They can be easily listed using swiftly: $ swiftly list-available main-snapshot -- Available main development snapshot toolchains ---------------------------------------------- main-snapshot-2025-03-25 ... Once you’ve identified a snapshot toolchain, it can be installed using its name: $ swiftly install main-snapshot-2025-03-25 -- Installing main-snapshot-2025-03-25 Another way to temporarily use a specific version of Swift is to use the special ‘+’ selector. With this syntax, you don’t need to first switch to a different toolchain: $ swiftly run lldb +main-snapshot-2025-03-25 -- (lldb) _ If you’re building a SwiftPM project in a team setting and want to enforce a common version of the Swift toolchain on all contributors, simply create a `.swift-version` file in the root of your project folder with the desired version (e.g. “6.0.3”). As swiftly is updated with new features and bug fixes, you can run `swiftly self-update` to check and install new releases. ## How swiftly works By writing swiftly in Swift, we’re able to take advantage of the language’s features, support, and ecosystem of related projects. Swift comes with standard library features for working with the filesystem in its Foundation module. For network operations Async HTTP Client is there to work the HTTP requests. And to retrieve the latest Swift release, swiftly uses the Swift OpenAPI plugin to generate the code to interact with the swift.org website. Lastly, it takes advantage of Swift’s interoperability with C to use the existing libarchive library to work with archives. swiftly uses libarchive to extract the toolchains downloaded from the Swift website and the integration is simple. It can be challenging to build shell programs that work well across multiple platforms with minimal system dependencies; this motivated us to switch swiftly away from using a shell program to install it and become a self-installing binary application. swiftly has access to excellent argument parsing capabilities, beautiful `--help` screens, and the full standard library. The only remaining problem was being able to deliver the operating system and processor architecture specific binary to the users system with simplicity. The swift.org website helps with operating system detection, but it cannot reliably detect the Linux distribution. Luckily, there is the Swift Static Linux SDK that makes binaries that work with a wide range of distributions. The processor architecture can be determined on most unixes using `uname -m` . The result of all of this is the simplicity of a copy and paste from the website to your terminal and get started with Swift. ## Installing Swift, swiftly Moving forward, swiftly will become the default way to install Swift outside of Xcode. The initial version supports macOS and a variety of Linux distributions, including Ubuntu, Debian, Fedora, Red Hat Enterprise Linux and Amazon Linux. The swiftly documentation provides further information about using swiftly in a CI/CD environment, as well as setting proxy servers and custom install locations for enterprise environments. swiftly is an open source project, and so you can raise new issues or contribute pull requests at its GitHub repository. You can also ask questions or discuss swiftly on the Swift Forums. Special thanks to Patrick Freed for creating swiftly, contributing it to the Swift organization, and his continued contributions to this valuable tool. The community is what makes Swift amazing!
swift.org
October 30, 2025 at 11:43 AM
Swift 6.1 Released
Swift 6.1 is now available! This release includes new language enhancements to improve productivity, diagnostics improvements, package traits, and ongoing work to improve data-race safety usability and compile times. Read on for an overview of the changes to the language, package manager, and next steps for getting started with Swift 6.1. ## Language and Standard Library ### Concurrency Swift’s concurrency model allows writing `nonisolated` on properties and functions to indicate that an API is safe to call from any concurrent context. Swift 6.1 extends `nonisolated` to types and extensions. This allows you to write `nonisolated` to prevent `@MainActor` inference on a type, or to apply `nonisolated` to all methods in an extension without having to annotate every method: @MainActor struct S { let id: Int let name: String // mutable state and MainActor methods } nonisolated extension S: CustomStringConvertible, Equatable { var description: String { "id: \(id), name: \(name)" } static func ==(lhs: S, rhs: S) -> Bool { lhs.id == rhs.id } } Swift 6.1 also improves type inference for task groups by inferring the child task result type of `withTaskGroup` and `withThrowingTaskGroup`. Previously, you always had to write the child task result type as an argument when creating the task group: let messages = await withTaskGroup(of: Message.self) { group in for id in ids { group.addTask { await downloadMessage(for: id) } } var messages: [Message] = [] for await message in group { messages.append(message) } return messages } In Swift 6.1, the child task result type can be inferred from the task group closure: // No need for `(of: Message.self)` like before. let messages = await withTaskGroup { group in for id in ids { group.addTask { await downloadMessage(for: id) } } var messages: [Message] = [] for await message in group { messages.append(message) } return messages } The approachability of data-race safety remains an area of active development; you can find an overview of the approach in the vision document for improving the approachability of data-race safety. Many Swift Evolution proposals implementing the features described in the vision document are under active review, and your feedback will help shape these improvements. ### Implementing Objective-C types in Swift Swift 6.1 includes a new attribute, `@implementation`, which can be used together with `@objc` to provide an implementation for a declaration that has been imported from Objective-C. You can write `@objc @implementation` on a Swift `extension` to replace an Objective-C `@implementation` block. You write headers as normal for an Objective-C class, but instead of writing an `@implementation` in an Objective-C file, you write an `@objc @implementation extension` in a Swift file. You can even port an existing class’s implementation to Swift one category at a time without breaking backwards compatibility. ### Productivity enhancements Swift allows including trailing commas in collection literals to make it easy to append, remove, reorder, or comment out the last element as any other element: let rank = [ "Player 1", "Player 3", "Player 2", ] Swift 6.1 extends trailing comma support to tuples, parameter and argument lists, generic parameter lists, closure capture lists, and string interpolations: let numbers = [1, 2, 0, 3, 4, 0, 0, 5] let subsequences = numbers.split( separator: 0, maxSplits: 1, ) In addition to improved development ergonomics, code generation tools like plugins and macros can be simplified, because generating a comma-separated list no longer needs a special condition for the last element. You can find a complete list of language proposals that were accepted through the Swift Evolution process and implemented in Swift 6 on the Swift Evolution dashboard. ## Package and build improvements Swift 6.1 introduces _package traits_ , a new configuration for packages that allows them to offer different APIs and features when used in specific environments, such as Embedded Swift and WebAssembly. Package authors can define a set of traits in their `Package.swift` that their package offers, which provide a way to express conditional compilation and optional dependencies. The package can specify a set of default traits that are enabled in clients, and clients can customize the traits they use when they declare the dependency: dependencies: [ .package( url: "https://github.com/Org/SomePackage.git", from: "1.0.0", traits: [ .default, // enable all of the package's default traits "Embedded" ] ), ] Many editing features, such as jump to definition for APIs in libraries you’re using, are powered by indexing. Before Swift 6.1, indexing occurred when you built your project, which meant that any additions or changes to the library were only surfaced by those editing features after you perform a build. Swift 6.1 enables background indexing by default for SwiftPM projects in SourceKit-LSP. Cross-module and global functionality stays updated as you make changes to your project. ## Swift Testing Swift 6.1 enables custom Swift Testing traits to perform logic before or after tests run in order to share set-up or tear-down logic. If you write a custom trait type which conforms to the new `TestScoping` protocol, you can implement a method to customize the scope in which each test or suite the trait is applied to will execute. For example, you could implement a trait which binds a task local value to a mocked resource: struct MockAPICredentialsTrait: TestTrait, TestScoping { func provideScope(for test: Test, testCase: Test.Case?, performing function: @Sendable () async throws -> Void) async throws { let mockCredentials = APICredentials(apiKey: "fake") try await APICredentials.$current.withValue(mockCredentials) { try await function() } } } extension Trait where Self == MockAPICredentialsTrait { static var mockAPICredentials: Self { Self() } } @Test(.mockAPICredentials) func example() { // Validate API usage, referencing `APICredentials.current`... } For more details, see ST-0007: Test Scoping Traits. Swift Testing in Swift 6.1 also includes refined versions of the `#expect(throws:)` and `#require(throws:)` macros which return their caught errors, making inspecting them in test functions more ergonomic (ST-0006). ## Swift-DocC Swift-DocC introduces a more human readable and human writable alternative for symbol link disambiguation based on parameter type and return type information. For example, consider these three function overloads with different parameter types and return types: func doSomething(first: String, second: Int) -> Double func doSomething(first: String?, second: Int) -> Float func doSomething(first: String?, second: Int) -> Double Previously, if you wrote a link to one of these overloads you needed to include a short hash of that symbol’s unique identifier to disambiguate the link and uniquely reference the specific overload. Swift-DocC’s warnings aided in writing these hashes but a person can’t decode the resulting hash suffix (`-3c5j`) to determine which overload the link is referring to. Now, you can use a combination of parameter types and return types—like `-(String,_)`, `->Float,` or `-(String?,_)->Double`—to disambiguate the link and uniquely reference a specific overload. You can discover the minimal combination of parameter types and return types for each overload from Swift-DocC’s warnings about ambiguous symbol links. For more details, see the Ambiguous Symbol Links section of Linking to Symbols and Other Content. ## Install Swift 6.1 You can try out these exciting new developments in Swift 6.1 today! If you’re building apps for Apple platforms, Swift 6.1 is included in Xcode 16.3, now available from the App Store. And the easiest way to install the standalone Swift 6.1 toolchain is using swiftly, the new Swift version manager that runs on macOS and Linux. Additional installation methods, including for Windows, are included on the Install Swift page.
swift.org
October 30, 2025 at 11:43 AM
ICYMI: Memory Safety, Ecosystem Talks, and Java Interoperability at FOSDEM 2025
The Swift community had a strong presence at FOSDEM 2025, the world’s largest independently run open source conference, held every year in Brussels, Belgium. FOSDEM highlighted a range of Swift-related talks related to memory safety, a broad ecosystem around Swift including using it to develop web services and embedded projects, and new areas of the project including Java interoperability. In case you missed it, here are a few highlights from the event: ## Memory Safety in Swift The main track of the conference featured a talk presented by Doug Gregor on memory safety: “Incremental Memory Safety in an Established Software Stack: Lessons Learned from Swift.” If you’re interested in learning more about Swift’s memory safe features, this talk is a great place to start; it walks through the different dimensions of memory safety in Swift, the language’s safe interoperability with C(++), and reflects on lessons learned for both programming language design and adopting Swift in an established software codebase. To learn more about memory safety in Swift, see the Swift documentation page on memory safety, as well as the vision document on memory safety. ## Swift DevRoom FOSDEM is primarily organized into DevRooms, volunteer-organized conference tracks around technical communities and topics. This year Swift celebrated its inaugural DevRoom organized by a local community member, Steven Van Impe, with contributions from a large group of volunteers including proposal reviewers, speakers, and day-of-operations support. Swift’s first Swift DevRoom was a hit! 🎉 The room was packed with 12 talks, covering a wide range of topics and demos from the Swift ecosystem: talks related to running Swift on Linux, showcasing various IDEs like VS Code, and a whole hour dedicated to embedded content. A few talks to highlight from the event: * Building a Ferrofluidic Music Visualizer with Embedded Swift * Building container images with swift-container-plugin * Distributed Tracing in Server-Side Swift Check out the complete lineup to learn more! ## Java Interoperability In the Free Java DevRoom, Konrad ‘ktoso’ Malawski presented on Java interoperability in Swift: “Foreign Function and Memory APIs and Swift/Java interoperability.“ Konrad’s talk was a technical deep dive into the Java interoperability effort that launched in 2024, demonstrating the bridges and bindings needed to integrate systems written in Swift and Java while still maintaining great performance. Catch up on this talk to see how you can leverage existing libraries without complete rewrites. Work in early development has been released on GitHub for feedback and contributions, and your feedback is welcome on the forums.
swift.org
October 30, 2025 at 11:43 AM
Swift at Apple: Migrating the Password Monitoring service from Java
_Swift is heavily used in production for building cloud services at Apple, with incredible results. Last year, the Password Monitoring service was rewritten in Swift, handling multiple billions of requests per day from devices all over the world. In comparison with the previous Java service, the updated backend delivers a 40% increase in performance, along with improved scalability, security, and availability._ The Passwords app, introduced in the fall of 2024, helps users manage their passwords, passkeys, and verification codes. It allows them to store, autofill, and generate strong passwords that can be shared across all their devices, as well as share passwords with trusted contacts. One security feature included in the app is Password Monitoring, which warns users if one of their saved passwords shows up in a data leak. This feature has a server component, running on Linux-based infrastructure, that is maintained by Apple. On a regular interval, Password Monitoring checks a user’s passwords against a continuously updated and curated list of passwords that are known to have been exposed in a leak. Importantly, this task is handled in a thoughtful, privacy-preserving way that never reveals users’ passwords to Apple. A detailed discussion of how this is done using the cryptographic private set intersection protocol is in the Password Monitoring section of the Apple Platform Security guide. The migration from Java to Swift was motivated by a need to scale the Password Monitoring service in a performant way. The layered encryption module used by Password Monitoring requires a significant amount of computation for each request, yet the overall service needs to respond quickly even when under high load. ## Choosing Swift for increased performance For years, our team relied on Java to power large-scale, mission-critical services because of its proven stability and performance. However, Java’s memory management approach no longer aligns with our growing demands and efficiency goals. Instead of simply expanding hardware resources, we were seeking a more-efficient language to support our growth while reducing server overhead. Prior to seeking a replacement language, we sought ways of tuning the JVM to achieve the performance required. Java’s G1 Garbage Collector (GC) mitigated some limitations of earlier collectors by introducing features like predictable pause times, region-based collection, and concurrent processing. However, even with these advancements, managing garbage collection at scale remains a challenge due to issues like prolonged GC pauses under high loads, increased performance overhead, and the complexity of fine-tuning for diverse workloads. One of the challenges faced by our Java service was its inability to quickly provision and decommission instances due to the overhead of the JVM. The Password Monitoring service runs globally, so service load can greatly fluctuate throughout the day, even with client-side techniques to smooth over the distribution of traffic. The peak and trough of a day differ by approximately 50% regionally. To efficiently manage this, we aim to scale down when demand is low and scale up as demand peaks in different regions. A faster bootstrap time is a crucial requirement to support this dynamic scaling strategy. Given the scale of our application and the volume of traffic we manage daily, the decision to transition from Java to another language was not made lightly. We evaluated our options, and found only a few languages that could help us achieve our goals. While you might expect that Apple would automatically choose Swift, we were pleasantly surprised by how well it fit the unique needs of a cloud-based service like ours. Swift has expressive syntax that was easy to learn, and could deliver the performance improvements necessary to meet the demands of our compute workloads. We decided to take a significant leap and started a rewrite of the Password Monitoring backend using Swift. ## Our experience developing with Swift We began rewriting our service using Vapor, a Swift web framework that provided Routing, Controller, and Content modules that we were able to build upon. Our service had additional requirements that led us to create a few custom packages with essential functionality: elliptic curve operations that are crucial for implementing password monitoring, auditing, configuration, error handling, and custom middleware. One of the most significant aspects of Swift that impressed us was its emphasis on protocols. In Java, we relied heavily on inheritance, which can lead to complex class hierarchies and tight coupling. Swift’s approach of protocols and generics promotes modularity and reusability by allowing classes, structs, and enums to share common protocols, enabling a more flexible and scalable codebase. This shift in mindset encouraged us to think in terms of behaviors rather than concrete classes, resulting in cleaner and more maintainable code. Safety is another area where Swift takes a distinctive approach compared to Java. For example, Swift’s optional type and safe unwrapping mechanisms eliminate the need for null checks everywhere, reducing the risk of null pointer exceptions and enhancing code readability. This safety-first approach ingrained throughout Swift’s language design, whether it is deterministic deallocation, copy-on-write (CoW), or value types, makes it inherently less prone to runtime errors. Swift’s async/await support is a nice addition, streamlining how we handle async tasks. Previously, managing async operations often involved complex callback patterns or external libraries. Swift’s async/await syntax simplifies this process, making it more intuitive and less error-prone. We can now write async code that reads like sync code, leading to more readable, testable, and maintainable concurrency handling—especially critical in high-load, multi-threaded environments. Overall, our experience with Swift has been overwhelmingly positive and we were able to finish the rewrite much faster than initially estimated. Swift allowed us to write smaller, less verbose, and more expressive codebases (close to 85% reduction in lines of code) that are highly readable while prioritizing safety and efficiency. Our service benefited from a diverse ecosystem of Swift packages, including logging frameworks, a Cassandra client, and crypto libraries that were readily available. In addition to an excellent support system and tooling, Swift’s inherent emphasis on modularity and extensibility helped future-proof and simplify the integration and customizations needed for our service-specific functions. ## Takeaways for future Swift on server development We benchmarked performance throughout the process of development and deployment, allowing us to discover the trait of the Swift programming language that delighted us the most — its efficiency. Swift’s deterministic memory management led to a much lower memory threshold for our service. Not only were our initial results heartening, but after a few iterations of performance improvements, we had close to 40% throughput gain with latencies under 1 ms for 99.9% of requests on our current production hardware. Additionally, the new service had a much smaller memory footprint per instance — in the 100s of megabytes — an order of magnitude smaller compared to the 10s of gigabytes our Java implementation needed under peak load to sustain the same throughput and latencies. The service runs on Kubernetes, and the migration’s efficiency improvements allowed us to release about 50% of its capacity for other workloads. Our Swift implementation has run smoothly and efficiently in production, making it worth the effort we put into this migration. In addition to outperforming our previous Java-based application, Swift delivered better performance consistency, enhanced safety features, and robust reliability — all while requiring fewer resources by utilizing memory and CPU efficiently. With fewer lines of boilerplate code and more flexible design patterns that we used, we look forward to simplified maintenance of our application. Swift was a powerful choice for building fast, resilient, and maintainable applications in our high-demand environment.
swift.org
October 30, 2025 at 11:43 AM
Redesigned Swift.org is now live
Over the past few months, the website workgroup has been redesigning Swift.org. On behalf of the website workgroup, I’m pleased to announce that we have merged the initial changes. Our goal with the site redesign has been to make Swift.org more approachable for newcomers to Swift, highlight the language’s technical strengths, and make it easy to get started. That led to a focus on the website’s appearance, improving the user experience, and emphasizing important features such as Swift’s multiplatform support. Today’s release includes refreshed home and install pages. Additionally, new pages have been designed to explore Swift use cases, including cloud services, command line tools, and embedded software. Looking forward, we plan to take an iterative approach to improving the website, including pushing changes live as we complete their design and implementation. ## Brand new design We explored several design options and found that the latest design conveys the fluidity and creativity of Swift through the splash of orange and the bird animation in the background. ## Curated content and examples The homepage now highlights Swift’s strengths alongside code examples that illustrate them. Additionally, we showcase various types of software that can be developed using Swift; these new use case pages provide information such as relevant packages, examples of Swift in action, code snippets, and links to resources for further learning. ## Next Steps We look forward to hearing your feedback on this first set of changes as we continue to redesign other sections of the site. There are several ways to offer feedback on the redesign and to get involved: * A forum announcement has been shared on the forums that can be used for discussion, and the website repository has GitHub issues. * The website itself is open source, and your contributions to the swiftlang/swift-org-website repository are welcome. * The Swift Information Architecture Project is an ongoing effort that has helped inform decisions related to the site redesign. Thank you to the website workgroup and community members for contributing to these improvements.
swift.org
October 30, 2025 at 11:43 AM
Swift 6.2 Released
We’re excited to announce Swift 6.2, a release aimed at making every Swift developer more productive, regardless of where or how you write code. From improved tooling and libraries to enhancements in concurrency and performance, Swift 6.2 delivers a broad set of features designed for real-world development at every layer of the software stack. Read on for a deep dive into changes to the language, libraries, workflows, platform support, and next steps for getting started with Swift 6.2. ## Approachable Concurrency Swift 6.2 lowers the barrier to concurrent programming with a set of changes designed to reduce boilerplate and let you write safe concurrent code more naturally: * **Single-threaded by default:** Run your code on the main thread without explicit `@MainActor` annotations using the new option to isolate code to the main actor by default. This option is ideal for scripts, UI code, and other executable targets. * **Intuitive`async` functions:** Write async code without concurrent access to mutable state. Previously, `nonisolated async` methods always switched to the global executor that manages the concurrent thread pool, which made it difficult to write async methods for class types without data-race safety errors. In Swift 6.2, you can migrate to an upcoming feature where `async` functions run in the caller’s execution context, even when called on the main actor. * **Opting into concurrency with`@concurrent`:** Introduce code that runs concurrently using the new `@concurrent` attribute. This makes it clear when you want code to remain serialized on actor, and when code may run in parallel. // In '-default-isolation MainActor' mode struct Image { // The image cache is safe because it's protected // by the main actor. static var cachedImage: [URL: Image] = [:] static func create(from url: URL) async throws -> Image { if let image = cachedImage[url] { return image } let image = try await fetchImage(at: url) cachedImage[url] = image return image } // Fetch the data from the given URL and decode it. // This is performed on the concurrent thread pool to // keep the main actor free while decoding large images. @concurrent static func fetchImage(at url: URL) async throws -> Image { let (data, _) = try await URLSession.shared.data(from: url) return await decode(data: data) } } Together, these improvements let you write data-race free code with less annotation overhead, provide more predictable behavior for async code, while still allowing you to introduce concurrency when you need it. ## Safe Systems Programming Swift 6.2 includes features designed to maximize performance without compromising safety. These features help you write safe, low-level code with predictable performance and minimal overhead. `InlineArray` is a new fixed-size array with inline storage for elements, which can be stored on the stack or directly within other types without additional heap allocation. You can introduce an inline array by writing the size in angle brackets before the element, or by using the `of` shorthand syntax: struct Game { // Shorthand for InlineArray<40, Sprite> var bricks: [40 of Sprite] init(_ brickSprite: Sprite) { bricks = .init(repeating: brickSprite) } } The new `Span` type offers safe, direct access to contiguous memory. Span maintains memory safety by ensuring the memory remains valid while you’re using it. These guarantees are checked at compile time with no runtime overhead, and define away the memory safety problems inherent to pointers, such as use-after-free bugs. Swift 6.2 enhances its capabilities for low-level and security-critical projects beyond new APIs: * **Embedded Swift:** Embedded Swift now includes Swift’s full `String` APIs, `any` types for class-constrained protocols, and the new `InlineArray` and `Span` types. * **Safe C++ interoperability:** Projects that mix Swift and C++ can take advantage of Swift’s safe abstractions like `Span` for C++ APIs through header annotations. * **Opt-in strict memory safety:** Swift has provided memory safety since its inception, while allowing use of unsafe constructs like unsafe pointers when needed, such as using a C API that accepts pointers. Swift 6.2 introduces _opt-in strict memory safety_ , which flags uses of unsafe constructs, so you can replace them with safe alternatives or explicitly acknowledge them in source code. It’s opt-in because the majority of projects don’t need this level of enforcement — strict memory safety is best left for projects with the strongest security requirements. ## Streamlined Workflows Beyond language improvements, Swift 6.2 smooths the day-to-day iteration cycle of editing, building, and debugging code. ### VS Code Swift extension The Swift extension for VS Code is now officially verified and distributed by Swift.org. The latest version of the extension includes: * **Background indexing by default:** Write code with fast, always-up-to-date editor features like jump-to-definition and code completion. * **Built-in LLDB debugging:** Step through Swift code, set breakpoints, and inspect state using LLDB right inside VS Code. * **Swift project panel:** Navigate your Swift project’s targets, dependencies, and tasks in the Explorer view. * **Live DocC preview:** Preview your rendered documentation side-by-side with your code, updated live as you type. These workflow improvements make it easier to work on Swift projects in your environment of choice with first-class tooling. ### Precise warning control Swift 6.2 enhances how you manage compiler warnings by allowing control at the _diagnostic group_ level. A diagnostic group is a category of warnings identified by a name. You can specify the desired behavior of warnings in a diagnostic group in a Swift package manifest using the `treatWarning` method on `SwiftSetting`, or promote all warnings to errors using the `treatAllWarnings` method. For example, you can promote all warnings to errors except for warnings about uses of deprecated APIs: .target( name: "MyLibrary", swiftSettings: [ .treatAllWarnings(as: .error), .treatWarning("DeprecatedDeclaration", as: .warning), ] ) ### Macro build performance Swift 6.2 significantly improves clean build times for projects that use macro-based APIs. Previously, the build system had to first fetch and build the swift-syntax package from source before building the macro project, which noticeably lengthened compile times, especially in CI environments. SwiftPM now supports pre-built swift-syntax dependencies, completely eliminating an expensive build step. ### Enhanced async debugging Swift 6.2 makes it much easier to follow what’s happening in concurrent code when debugging with LLDB: * **Robust`async` stepping:** Reliably step into asynchronous functions in LLDB, even when the async call requires switching threads. * **Surfacing task context:** See which task a piece of code is running on when stopped at a breakpoint and when viewing the backtrace for the current thread. * **Named tasks:** Assign human-readable names when creating tasks, which are surfaced in the task context in debugging and profiling tools. ### Migration to upcoming features Swift 6.2 includes _migration tooling_ to help you adopt upcoming language features: * **Identify source incompatibility:** Identify code patterns that will no longer compile or change behavior when the upcoming feature is enabled through warnings from migration tooling. * **Automate code changes:** Apply fix-its to update your code to preserve its existing behavior. This streamlines the process of enabling upcoming features by eliminating the tedious task of manual code changes. You can learn more about migration tooling in the Swift migration guide. ## Core Library Updates Whether you’re managing external processes, reacting to state changes, or writing test suites, the Swift 6.2 libraries are evolving to help you write cleaner and safer code. ### Subprocess Swift 6.2 introduces a new `Subprocess` package that offers a streamlined, concurrency‑friendly API for launching and managing external processes. This includes APIs built with async/await, fine-grained control over process execution, platform-specific configuration, and more—ideal for scripting, automation, and server‑side tasks: import Subprocess let swiftPath = FilePath("/usr/bin/swift") let result = try await run( .path(swiftPath), arguments: ["--version"] ) let swiftVersion = result.standardOutput Explore the full API surface for version 0.1 in the swift-subprocess repository, and feedback from your adoption will inform the API that is released in version 1.0. ### Foundation In Swift 6.2, the Foundation library includes a modern `NotificationCenter` API that uses concrete notification types instead of relying on strings and untyped dictionaries for notification names and payloads. This means you can define a notification struct with stored properties, and observers can use the type without error-prone indexing and dynamic casting. Notification types also specify whether they’re posted synchronously on the main actor or asynchronously through a conformance to `MainActorMessage` or `AsyncMessage`, which eliminates concurrency errors when working with main actor notifications. ### Observation Swift 6.2 enables streaming transactional state changes of observable types using the new `Observations` async sequence type. Updates include all synchronous changes to the observable properties, and the transaction ends at the next `await` that suspends. This avoids redundant UI updates, improves performance, and ensures that your code reacts to a consistent snapshot of the value. ### Swift Testing Swift Testing in Swift 6.2 adds new APIs for enhanced expressivity in your tests and test results: * **Exit testing** lets you verify that code terminates under specific conditions, such as a failed precondition. Your exit tests run in a new process and validate that the exit behavior is what you expect, making it possible to exercise critical failure paths like you would in any other test. * **Attachments** let you include additional context in test results, including strings, images, logs, and other artifacts, surfaced in test reports or written to disk. This makes it easier to diagnose failures with concrete evidence—whether that’s a screenshot of a UI state, a JSON payload, or a trace of steps leading up to the issue. * **Raw identifier display names** let you customize the names of test functions and suite types with less code: -@Test("square() returns x * x") -func squareIsXTimesX() { +@Test func `square() returns x * x`() { #expect(square(4) == 4 * 4) } ## WebAssembly Support Swift 6.2 gains support for WebAssembly, also known as Wasm. WebAssembly is a virtual machine platform focused on portability, security, and high performance. You can build both client and server applications for Wasm and deploy to the browser or other runtimes. Learn more about Wasm in the vision for WebAssembly support in Swift. ## Thank you Thank you to everyone who shared their experiences, frustrations, and insights that guided the design of Swift 6.2, especially the approachable concurrency model. Your feedback made it clear where the language could be friendlier, where safety needed to feel more natural, and where the tools could make you more productive. The improvements in Swift 6.2 are only possible because of your voices. If you’re excited about where Swift is headed, there’s no better time to get involved in the Swift community. From participating in Swift Evolution, to contributing code on GitHub, or sharing feedback on how the language feels in real-world projects, every voice helps shape Swift’s future. Whether you’re a seasoned programmer or just starting out, our community thrives on collaboration and welcomes new perspectives. Join in, learn from others, and help make Swift a better language. ## Next Steps You can find a complete list of language proposals that were accepted through the Swift Evolution process and implemented in Swift 6.2 on the Swift Evolution dashboard. Ready to upgrade? Install the latest toolchain using Swiftly `swiftly install 6.2` or Swift.org/install and start exploring Swift 6.2 today.
swift.org
October 30, 2025 at 11:42 AM
The Growth of the Swift Server Ecosystem
Nearly ten years ago, Swift was open sourced and an official runtime for Linux was released. I’ve been involved with Swift on the server since almost the very beginning, originally picking it up as a way to use a language I really enjoyed for backend development. In that time Swift has come a long way, with stability across platforms, a burgeoning ecosystem and many success stories. It’s matured into a great option for highly-scalable server applications, websites, and lambdas. In this post, I’ll cover how Swift: * is seeing a number of success stories of running critical production workloads * has evolved to be a powerful language for server development * has a thriving ecosystem of frameworks and libraries * has a growing and passionate community - including a dedicated server conference coming up in October! ## Running in Production There have been some really awesome success stories emerge over the last few years, reinforcing the strength of Swift on the server. The award-winning Things app explained how they migrated their backend from Python to Swift, seeing a 4x increase in performance, whilst costing a third of the original price! Apple’s Password Monitoring Service also underwent a similar transition migrating from Java to Swift. As well as an improved codebase from Swift’s ergonomics, they saw similar gains with a 40% increase in throughput, a 50% reduction in hardware utilization, and a **90% decrease** in memory usage that freed up server capacity for other workloads. From my vantage point working on Vapor, I’ve seen more and more companies adopt Swift on the server. I no longer get asked if Swift is “ready for production?”. All the questions are about what can it do and “how can I use Swift for my use case?”, which is fantastic to see. There are even a number of talks lined up for this year’s server conference with success stories of running Swift on the server. ## Language strengths and improvements Swift has grown a lot since Swift 3! The language has seen a huge number of changes heavily adopted, and in some cases driven, by the server world. Native UTF-8 strings, `Codable`, keypaths, and property wrappers all saw quick adoption by server packages. Swift Concurrency has been a game changer, making it significantly easier for developers to write asynchronous code, which is especially helpful in an environment where almost everything is asynchronous! Task local values make it simple to introduce distributed tracing to applications without the need to pass contexts around everywhere. More recently, features such as package traits, build plugins, and macros have already started to be adopted by server libraries that provide more performant and efficient code to end users. One of the big changes in recent years is the introduction of `Sendable`, which has eliminated many cases of data race issues. A great showcase of this is Vapor, which used to see one or two issues created a month reporting data race crashes that were impossible to reproduce and extremely hard to resolve. Since Vapor adopted `Sendable` there hasn’t been **a single report** of a data race crash! This just goes to show how using Swift makes it easier to write safe server applications. Foundation has also undergone a significant journey. Gone are the days of an entirely separate implementation for Linux. With Swift 6, the same Foundation code runs on Linux as on Apple platforms. This makes it far easier for developers to build on different platforms. Speaking of which, the recent cross-compilation SDKs make it super simple to build Linux binaries on macOS. Swift was introduced with great C interoperability and has since expanded to include C++ and Java, opening up possibilities from integrating with libraries written in those languages. Packages such as Swift Kafka have been quickly released because they can use existing, battle-tested libraries from C or C++ with little effort. The new Swift Java interop also makes it possible to work with existing Java libraries in Swift projects and begin to incrementally migrate large, existing Java codebases to Swift, without the need for major rewrites that are often risky. This was spoken about at the package’s introduction at ServerSide.swift 2024. Overall, Swift has evolved to be a great language for server development. Have a look at the Cloud Services page on swift.org for getting started tutorials, language benefits, and more information about the server ecosystem. ## The Ecosystem Swift on the server is nothing without an ecosystem. Over the last decade, Vapor continues to evolve and grow, newer frameworks like Hummingbird are taking advantage of modern Swift features, and a swathe of packages have been released to support all kinds of APIs, libraries and databases. I’m always amazed at the weird and wonderful ways people are using Swift in server environments and how much of the ecosystem is driven by the community. The areweserveryet.org website has a great list of different packages available, and the Swift Package Index has been instrumental in propelling the package ecosystem on Linux, with build results for every single package submitted, allowing anyone to quickly check platform support for packages. Swift is picking up more acceptance in the server world and the recent Valkey announcement for Swift is a testament to the efforts of the community in making Swift a first-class citizen on the server. > Fun addendum - the Swift Package Index is itself built using Swift on the server, as one of the biggest open source Vapor applications! Swift is also building an awesome observability ecosystem. It has API packages for each of the three pillars (logging, metrics, and tracing), that mean you can plug in any backend you want and all the packages in your dependency tree will work with it. And the growing list of backends already includes options for many popular open-source projects, such as Prometheus, Statsd and Open Telemetry. The entire server ecosystem has worked hard to ensure that all packages have adopted these core packages so there are no concerns around incompatibilities when choosing how to implement observability in your application, no matter the package you choose. The ecosystem continues to be an early adopter of Swift technologies. gRPC Swift 2 introduced earlier this year introduced first-class concurrency support was a particular highlight of the next generation of server packages emerging to take full advantage of structured concurrency. This has been heavily driven by the Swift Server Workgroup, which is comprised of members from across the ecosystem and industry and continues to work to ensure that the ecosystem works together as well as driving improvements to the language, and tooling, such as the recently adopted Swiftly CLI tool, originally developed by the workgroup. ## A growing community The last ten years has seen the community grow and grow at an ever accelerating pace and it feels great to know that the next ten years will be even more exciting and see an even bigger community. There’s even a dedicated conference! The ServerSide.swift conference I organize, is hosting its 5th year this year in London. The schedule has recently been announced and it’s packed with amazing talks on gRPC, containers, concurrency, and success stories. Previous years have seen really great talks, such as the success story of using Swift on the server by Cultured Code, the company behind Things. Other standout sessions include talks on the OpenAPI generator, the announcement of the new Swift Foundation, and technical language talks on structured concurrency. Tickets for this year’s conference are still available on the website. We even have a day of workshops, including a workshop from expert developers on how to get started with Swift on the server, which is a great opportunity for anyone wanting to learn more. The adoption of Swift on the server is ever-increasing as the language proves its benefits for safe, performant backends. The ecosystem continues to grow, with more frameworks, libraries, and tools being developed to support an expanding range of server applications. I can’t believe it’s _only_ been ten years since it started, and I’m excited to see how Swift on the server grows over the next decade!
swift.org
October 30, 2025 at 11:42 AM
Introducing Swift Profile Recorder: Identifying Performance Bottlenecks in Production
Swift Profile Recorder, an in-process sampling profiler for Swift services, is now available as an open source project. Profiling is a powerful technique for understanding the performance, resource usage, and behavior of your applications. With Swift Profile Recorder, profiling can now be added to your Swift services by simply adding a package dependency and no additional setup. Swift Profile Recorder enables you to: * **Adopt profiling without extra privileges or system dependencies** , allowing you to add profiling across a variety of compute environments with constrained permissions. * **Collect samples using`curl`**, allowing you to easily read profiler output via an HTTP endpoint without needing to learn specific tooling like perf, sample, DTrace, or eBPF (bpftrace). * **Integrate with existing tools for visualization and analysis** by supporting multiple industry-standard formats, including Linux perf script format, both the pprof file format as well as the `/debug/pprof/profile` endpoints, and also the collapsed format as used by the original FlameGraphs. Apple has used Swift Profile Recorder at scale for several years as a tool for operating and debugging Swift services in production. Alongside the recent announcement of swift-parca, the Swift server ecosystem now has multiple profiling tools and approaches. ## What is profiling and why does it matter? Profiling enables you to understand where your Swift application spends its time — whether it’s computing, waiting for a lock acquisition, or blocked in file I/O. Profiling is achieved by collecting samples of activity, which provide insight into how it’s being used. Modern operating systems have tooling available to profile your applications or even the whole system. Examples include Apple’s Instruments, `sample`, and Linux’s `perf`. Furthermore, there are kernel systems like DTrace or eBPF that can be used to profile your applications. The community recently contributed swift-parca, which plugs into Parca Agent, leveraging Parca Agent and eBPF on Linux to profile your application continuously. These samples are then aggregated on a centralized Parca server. This is a great tool which we hope many deployments can leverage today. But there are a few constraints which may impact wider adoption: * Special privileges are required to attach to another process or load an eBPF/DTrace program into the kernel * Linux distributions may require additional components to enable this functionality * The available profiling technologies differ significantly between operating systems To enable more teams to profile their applications, Swift Profile Recorder takes a different approach — it runs from within your process, implemented as a Swift Package. This means it can profile your code even in environments where external profiling tools can’t operate. You also won’t need to install other system components, you won’t need extra privileges, and the approach can work on different operating systems — right now Swift Profile Recorder supports macOS and Linux. ## Profiling Swift services at Apple Apple extensively uses Swift on server to build distributed systems providing storage and compute at a huge scale. These systems power the build and test infrastructure for the development of Apple’s operating systems. Our client workloads are latency-sensitive, so we soon found a need to further instrument the code to understand performance bottlenecks. This infrastructure runs in a sandboxed environment where we don’t have access to tools such as eBPF. Additionally, components of our infrastructure run atop macOS. So we built Swift Profile Recorder to give better insights into non-optimal code. We use Swift Profile Recorder in two ways for the above infrastructure use case: * To safely diagnose specific and isolated instances of performance regressions * To gather a large number of samples across all of our infrastructure to identify common patterns, also known as Continuous Profiling ## Getting started Adding Swift Profile Recorder to your application requires minimal setup: // In your Package.swift .package(url: "https://github.com/apple/swift-profile-recorder.git", .upToNextMinor(from: "0.3.0")) // In your target dependencies .product(name: "ProfileRecorderServer", package: "swift-profile-recorder") Then, in your application’s main function: import ProfileRecorderServer @main struct YourApp { func run() async throws { // Start the profiling server in the background async let _ = ProfileRecorderServer(configuration: .parseFromEnvironment()).runIgnoringFailures(logger: logger) // Your application code continues here } } Enable profiling through environment variables: Assuming you specified `configuration: .parseFromEnvironment()` you will have to set an environment variable to activate the profiling server: `PROFILE_RECORDER_SERVER_URL_PATTERN=unix:///tmp/my-app-samples-{PID}.sock ./my-app` Collect samples with a simple curl command: curl --unix-socket /tmp/my-app-samples-12345.sock \ -sd '{"numberOfSamples":1000,"timeInterval":"10ms"}' \ http://localhost/sample | swift demangle --compact > samples.perf ## Visualization and Integration The generated profiles work seamlessly with popular visualization tools: * Speedscope (speedscope.app): Drag and drop your `.perf` file for instant flame graph visualization * Firefox Profiler (profiler.firefox.com): Upload your profile for detailed timeline analysis (example profile) * Traditional FlameGraph tools: Use Brendan Gregg’s original FlameGraph scripts for custom visualizations * Many other tools compatible with the common `.perf`, `.pprof` or stack collapsed formats An example running Hummingbird’s `hello` example on macOS visualized in Speedscope can be seen below Swift Profile Recorder can also be used a source to send samples to Parca as well as Pyroscope. If your production environment allows you to install system-wide profiling using eBPF, we would recommend to use Parca Agent together with swift-parca. ## Community and feedback Swift Profile Recorder is an open source project and we’re eager to hear from the Swift community. Whether you’re running Swift applications in Kubernetes, investigating performance issues, or simply curious about where your application spends its time, we’d love to know how Swift Profile Recorder works for you. For example, it should be possible to integrate Swift Profile Recorder into a lambda function. We look forward to hearing how you use the profiler. The project is actively developed and we welcome contributions, bug reports, and feature requests. As with any profiling tool, different applications and environments present unique challenges, and community feedback is essential for improving the profiler’s effectiveness across diverse Swift codebases. Ready to start profiling? Visit the Swift Profile Recorder repository to get started. We also encourage you to discuss the project on the Swift forums, including asking questions about this post on the associated thread, and sharing your experiences in the Swift Profile Recorder category.
swift.org
October 30, 2025 at 11:42 AM
Announcing the Swift SDK for Android
Swift has matured significantly over the past decade — extending from cloud services to Windows applications, browser apps, and microcontrollers. Swift powers apps and services of all kinds, and thanks to its great interoperability, you can share code across platforms. The Android workgroup is an open group, free for anyone to join, that aims to expand Swift to Android. Today, we are pleased to announce nightly preview releases of the Swift SDK for Android. This milestone reflects months of effort by the Android workgroup, building on many years of grassroots community effort. With the SDK, developers can begin developing Android applications in Swift, opening new avenues for cross-platform development and accelerating innovation across the mobile ecosystem. The Swift SDK for Android is available today, bundled with the Windows installer or downloadable separately for use on Linux or macOS. ## Getting Started We’ve published a Getting Started guide to help you set up your first native Swift code on an Android device. The Swift for Android Examples help demonstrate end‑to‑end application workflows on Android. With the Swift SDK for Android, you can now start porting your Swift packages to Android. Over 25% of packages in the Swift Package Index already build for Android, and the Community Showcase now indicates Android compatibility. The swift-java project enables you to interoperate between Java and Swift. It is both a library and a code generator, enabling you to integrate Swift and Java in both directions by automatically generating safe and performant bindings. To learn about generating bindings to bring your business logic to Android, check out the recent Swift Server Side meetup talk by Mads Odgaard. ## Next Steps This preview release opens many new opportunities to continue improving these tools. We encourage you to share your experiences, ideas, tools and apps on the Swift forums. This post has been published on an associated thread for discussion, and new posts can be shared in the Android category. The Android workgroup is drafting a vision document, currently under review, for directing future work regarding Swift on Android. This vision will outline priority areas and guide community efforts to maximize impact across the ecosystem. In addition, we maintain a project board that tracks the status of major efforts, as well as official CI for the Swift SDK for Android. If you’re as excited as we are, join us and help make this ecosystem even better!
swift.org
October 30, 2025 at 11:42 AM
Introducing swiftly 1.0
Today we’re delighted to introduce the first stable release of swiftly, a Swift version manager that takes the pain out of installing, managing and updating your Swift toolchain. The latest version of Swift is bundled with Xcode for writing apps for Apple platforms. But perhaps you want to install Swift on a different platform like Linux, or use a different version of the toolchain for building services or command line tools. Downloading, extracting and installing a trusted build of Swift along with the relevant dependencies for your operating system can require quite a few manual and error-prone steps. swiftly has been around for some years as a community-supported tool for Swift developers using Linux. With this release, we’re officially supporting it as part of the core Swift toolchain, including hosting it as part of the Swift GitHub organization. We’ve also added macOS support to make it easier to install Swift separately from Xcode. ## Introducing swiftly swiftly is the best tool to install the standalone toolchain, providing commands to install Swift on a new system, update to the latest stable version, and experiment or test with nightly snapshots or older versions. It also makes it easy to switch effortlessly between multiple installed toolchains. You can even add a file to your project repository so swiftly will use the same toolchain version for all members of your development team. Naturally, swiftly itself is written in Swift, and is able to update itself to the latest version. ## Quick tour Let’s take a look at some of the features of swiftly! To get started, visit swift.org/install and install it. swiftly will provide directions after installation if there are any system packages, or shell commands needed for smooth operation of the new toolchain. The latest Swift toolchain is installed as the default, so you can immediately use it to start a new project. For example: $ swift package init The `swiftly use` command selects the default toolchain for Swift commands (e.g. `swift test`, `swift build`): $ swiftly use 6.0.3 $ swift --version -- Apple Swift version 6.0.3 (swiftlang-6.0.3.1.2 clang-1600.0.28.6) Target: arm64-apple-macosx15.0 At a later point, if there’s a new release of Swift you can install it alongside the existing toolchain with the `latest` command: $ swiftly install latest Pre-release of versions of Swift are available, including nightly “snapshot” toolchains. They can be easily listed using swiftly: $ swiftly list-available main-snapshot -- Available main development snapshot toolchains ---------------------------------------------- main-snapshot-2025-03-25 ... Once you’ve identified a snapshot toolchain, it can be installed using its name: $ swiftly install main-snapshot-2025-03-25 -- Installing main-snapshot-2025-03-25 Another way to temporarily use a specific version of Swift is to use the special ‘+’ selector. With this syntax, you don’t need to first switch to a different toolchain: $ swiftly run lldb +main-snapshot-2025-03-25 -- (lldb) _ If you’re building a SwiftPM project in a team setting and want to enforce a common version of the Swift toolchain on all contributors, simply create a `.swift-version` file in the root of your project folder with the desired version (e.g. “6.0.3”). As swiftly is updated with new features and bug fixes, you can run `swiftly self-update` to check and install new releases. ## How swiftly works By writing swiftly in Swift, we’re able to take advantage of the language’s features, support, and ecosystem of related projects. Swift comes with standard library features for working with the filesystem in its Foundation module. For network operations Async HTTP Client is there to work the HTTP requests. And to retrieve the latest Swift release, swiftly uses the Swift OpenAPI plugin to generate the code to interact with the swift.org website. Lastly, it takes advantage of Swift’s interoperability with C to use the existing libarchive library to work with archives. swiftly uses libarchive to extract the toolchains downloaded from the Swift website and the integration is simple. It can be challenging to build shell programs that work well across multiple platforms with minimal system dependencies; this motivated us to switch swiftly away from using a shell program to install it and become a self-installing binary application. swiftly has access to excellent argument parsing capabilities, beautiful `--help` screens, and the full standard library. The only remaining problem was being able to deliver the operating system and processor architecture specific binary to the users system with simplicity. The swift.org website helps with operating system detection, but it cannot reliably detect the Linux distribution. Luckily, there is the Swift Static Linux SDK that makes binaries that work with a wide range of distributions. The processor architecture can be determined on most unixes using `uname -m` . The result of all of this is the simplicity of a copy and paste from the website to your terminal and get started with Swift. ## Installing Swift, swiftly Moving forward, swiftly will become the default way to install Swift outside of Xcode. The initial version supports macOS and a variety of Linux distributions, including Ubuntu, Debian, Fedora, Red Hat Enterprise Linux and Amazon Linux. The swiftly documentation provides further information about using swiftly in a CI/CD environment, as well as setting proxy servers and custom install locations for enterprise environments. swiftly is an open source project, and so you can raise new issues or contribute pull requests at its GitHub repository. You can also ask questions or discuss swiftly on the Swift Forums. Special thanks to Patrick Freed for creating swiftly, contributing it to the Swift organization, and his continued contributions to this valuable tool. The community is what makes Swift amazing!
swift.org
October 28, 2025 at 9:44 AM
How Swift's server support powers Things Cloud
You might be familiar with Things, a delightful personal task manager that has won two Apple Design Awards and is available across Apple devices including iPhone, iPad, Mac, Apple Watch, and Apple Vision Pro. At Cultured Code, the team behind Things, we care about a great user experience across every aspect of the product. This extends to our server back end, and after a rewrite our Things Cloud service has transitioned entirely to Swift. Over the past year in production, Swift has consistently proven to be reliable, performant, and remarkably well-suited for our server-side need. Things Cloud serves as the backbone of the app’s experience, silently synchronizing to-dos across devices. The robustness of this work is ensured by a rigorous theoretical foundation, inspired by operational transformations and Git’s internals. After twelve years in production, Things Cloud has earned our users’ trust in its reliability. But despite the enduring strength of the architecture itself, the technology stack lagged behind. Things Cloud synchronizes to-dos across different devices. ## Switching to Swift Our legacy Things Cloud service was built on Python 2 and Google App Engine. While it was stable, it suffered from a growing list of limitations. In particular, slow response times impacted the user experience, high memory usage drove up infrastructure costs, and Python’s lack of static typing made every change risky. For our push notification system to be fast, we even had to develop a custom C-based service. As these issues accumulated and several deprecations loomed, we realized we needed a change. A full rewrite is usually a last resort, but in our case, it was the only viable path for Things Cloud. We explored various programming languages including Java, Python 3, Go, and even C++. However, Swift – which was already a core part of our client apps – stood out for its potential and unique benefits. Swift promised excellent performance, predictable memory management through ARC, an expressive type system for reliability and maintainability, and seamless interoperability with C and C++. While we initially had concerns that Swift’s server support wasn’t as mature as that found in other ecosystems, both Apple and the open-source community had shown strong commitment to its evolution. Swift had reliably compiled on Linux for a long time; the Swift Server workgroup had coordinated server efforts since 2016; the SwiftNIO library gave us confidence in the foundational capabilities, and Vapor provided all the tools to get us up and running quickly. Convinced by these benefits and the opportunity to use the same language for client and server development, we embarked on a three-year journey to rewrite Things Cloud. We’ve been using it internally for the past two years, and it has now been live in production for over a year. ## The new Swift-based service architecture We’ll outline the core components of our new service architecture, highlighting the Swift packages we use. We’ve found that these components work well together to provide reliability and stability, and we believe this serves as a valuable reference point for others considering a similar transition to Swift. Overview of our new Swift-based service architecture. ### Code * Our **Swift** server codebase has around 30,000 lines of code. It produces a binary of 60 MB, and builds in ten minutes. * It uses **Vapor** as an HTTP web framework, which uses **SwiftNIO** as its underlying network application framework. * We compile a single “monolith” binary from our Swift source code, but use it to run multiple services, each configured by passing different parameters at runtime. * We use **Xcode** for its robust suite of tools for development, debugging, and testing. It provides us with a familiar and consistent experience across both server and client environments. ### Deployment * **AWS** hosts our entire platform, and is entirely managed by **Terraform** , an infrastructure as code tool. * We use a continuous integration pipeline to automate tests and build our Swift code into a **Docker** image. This is then deployed in a **Kubernetes** cluster alongside other components. * The **HAProxy** load balancer is used to route client traffic to the appropriate Swift service in the cluster. ### Storage * Persistent data is stored in **Amazon Aurora MySQL** , a relational database, which we connect to with **MySQLKit**. * To keep the database small, we’re offloading less-used data to **S3** , which we access via the **Soto** package. * More ephemeral data, such as push notifications and caches, is stored in **Redis** , an in-memory key-value database, which we access via **RediStack**. ### Other Services * The **APNSwift** package is used to communicate with the Apple Push Notification service. * **AWS Lambda** , a serverless compute service, powers our **Mail to Things** feature. This process is written in Python 3 due to its mature libraries for the processing of incoming emails. The results are passed to Swift using **Amazon Simple Queue Service**. ### Monitoring * We take the resilience of Things Cloud seriously and go to great lengths to ensure it. * In Swift, we generate JSON logs using our own logger. To produce metrics, we’re using the **Swift Prometheus**. * We use **Amazon CloudWatch** to store and analyze logs and metrics. It triggers Incidents, which reach the responsible engineer via **PagerDuty**. * To test how well our service can recover from transient errors, we employ **chaos testing**. Each day, our self-written chaos agent performs random disruptive actions such as terminating a Swift service or restarting the database. We then verify that the system recovers as expected. ## Results We wanted to thoroughly test the performance and stability of the new Swift service architecture before it was deployed in production. So during the development phase, we deployed the new system alongside the existing legacy system. While the legacy system continued to be the operational service for all requests, the new system also processed them independently using its own logic and database. This approach enabled us to develop and test the new system under real-world conditions without any risk to the user experience. Thanks to the confidence we built in the new system’s robustness and reliability through evaluating it with production workloads, we were able to deploy a hardened system from the very beginning. Now, with over a full year in production, we’re pleased to report that Swift has fulfilled its promise for server-side development. It’s fast and memory-efficient. Our Kubernetes cluster comprises four instances, each with two virtual CPUs and 8 GB of memory, and has handled traffic peaks of up to 500 requests per second. Compared to the legacy system, this setup has led to a more than threefold reduction in compute costs, while response times have shortened dramatically. Comparison between our legacy service and new Swift-based one. And one extra win: Swift’s outstanding performance allowed us to replace our custom C-based push notification service with a Swift-based one; this significantly simplified our codebase and operations. ## Conclusions Swift turned out to be a great choice for server usage. It delivered on everything we had hoped for: We’re now using a modern and expressive programming language, the code runs and performs well, and the Swift ecosystem provides all the integrations we need. With a year of production use, we haven’t encountered a single operational issue. For more information on our journey and experiences, you might enjoy our recent talk at the ServerSide.Swift conference. We encourage other teams to consider using Swift for server-oriented projects. While we chose to undergo a complete rewrite, the gradual adoption of Swift is also an intriguing option, especially considering the recently announced initiative aimed at enhancing Java interoperability. As for us, we believe our server architecture is in its best shape ever, and we’re thrilled about the new features we can build upon this solid foundation.
swift.org
October 28, 2025 at 9:43 AM
Swift 6.1 Released
Swift 6.1 is now available! This release includes new language enhancements to improve productivity, diagnostics improvements, package traits, and ongoing work to improve data-race safety usability and compile times. Read on for an overview of the changes to the language, package manager, and next steps for getting started with Swift 6.1. ## Language and Standard Library ### Concurrency Swift’s concurrency model allows writing `nonisolated` on properties and functions to indicate that an API is safe to call from any concurrent context. Swift 6.1 extends `nonisolated` to types and extensions. This allows you to write `nonisolated` to prevent `@MainActor` inference on a type, or to apply `nonisolated` to all methods in an extension without having to annotate every method: @MainActor struct S { let id: Int let name: String // mutable state and MainActor methods } nonisolated extension S: CustomStringConvertible, Equatable { var description: String { "id: \(id), name: \(name)" } static func ==(lhs: S, rhs: S) -> Bool { lhs.id == rhs.id } } Swift 6.1 also improves type inference for task groups by inferring the child task result type of `withTaskGroup` and `withThrowingTaskGroup`. Previously, you always had to write the child task result type as an argument when creating the task group: let messages = await withTaskGroup(of: Message.self) { group in for id in ids { group.addTask { await downloadMessage(for: id) } } var messages: [Message] = [] for await message in group { messages.append(message) } return messages } In Swift 6.1, the child task result type can be inferred from the task group closure: // No need for `(of: Message.self)` like before. let messages = await withTaskGroup { group in for id in ids { group.addTask { await downloadMessage(for: id) } } var messages: [Message] = [] for await message in group { messages.append(message) } return messages } The approachability of data-race safety remains an area of active development; you can find an overview of the approach in the vision document for improving the approachability of data-race safety. Many Swift Evolution proposals implementing the features described in the vision document are under active review, and your feedback will help shape these improvements. ### Implementing Objective-C types in Swift Swift 6.1 includes a new attribute, `@implementation`, which can be used together with `@objc` to provide an implementation for a declaration that has been imported from Objective-C. You can write `@objc @implementation` on a Swift `extension` to replace an Objective-C `@implementation` block. You write headers as normal for an Objective-C class, but instead of writing an `@implementation` in an Objective-C file, you write an `@objc @implementation extension` in a Swift file. You can even port an existing class’s implementation to Swift one category at a time without breaking backwards compatibility. ### Productivity enhancements Swift allows including trailing commas in collection literals to make it easy to append, remove, reorder, or comment out the last element as any other element: let rank = [ "Player 1", "Player 3", "Player 2", ] Swift 6.1 extends trailing comma support to tuples, parameter and argument lists, generic parameter lists, closure capture lists, and string interpolations: let numbers = [1, 2, 0, 3, 4, 0, 0, 5] let subsequences = numbers.split( separator: 0, maxSplits: 1, ) In addition to improved development ergonomics, code generation tools like plugins and macros can be simplified, because generating a comma-separated list no longer needs a special condition for the last element. You can find a complete list of language proposals that were accepted through the Swift Evolution process and implemented in Swift 6 on the Swift Evolution dashboard. ## Package and build improvements Swift 6.1 introduces _package traits_ , a new configuration for packages that allows them to offer different APIs and features when used in specific environments, such as Embedded Swift and WebAssembly. Package authors can define a set of traits in their `Package.swift` that their package offers, which provide a way to express conditional compilation and optional dependencies. The package can specify a set of default traits that are enabled in clients, and clients can customize the traits they use when they declare the dependency: dependencies: [ .package( url: "https://github.com/Org/SomePackage.git", from: "1.0.0", traits: [ .default, // enable all of the package's default traits "Embedded" ] ), ] Many editing features, such as jump to definition for APIs in libraries you’re using, are powered by indexing. Before Swift 6.1, indexing occurred when you built your project, which meant that any additions or changes to the library were only surfaced by those editing features after you perform a build. Swift 6.1 enables background indexing by default for SwiftPM projects in SourceKit-LSP. Cross-module and global functionality stays updated as you make changes to your project. ## Swift Testing Swift 6.1 enables custom Swift Testing traits to perform logic before or after tests run in order to share set-up or tear-down logic. If you write a custom trait type which conforms to the new `TestScoping` protocol, you can implement a method to customize the scope in which each test or suite the trait is applied to will execute. For example, you could implement a trait which binds a task local value to a mocked resource: struct MockAPICredentialsTrait: TestTrait, TestScoping { func provideScope(for test: Test, testCase: Test.Case?, performing function: @Sendable () async throws -> Void) async throws { let mockCredentials = APICredentials(apiKey: "fake") try await APICredentials.$current.withValue(mockCredentials) { try await function() } } } extension Trait where Self == MockAPICredentialsTrait { static var mockAPICredentials: Self { Self() } } @Test(.mockAPICredentials) func example() { // Validate API usage, referencing `APICredentials.current`... } For more details, see ST-0007: Test Scoping Traits. Swift Testing in Swift 6.1 also includes refined versions of the `#expect(throws:)` and `#require(throws:)` macros which return their caught errors, making inspecting them in test functions more ergonomic (ST-0006). ## Swift-DocC Swift-DocC introduces a more human readable and human writable alternative for symbol link disambiguation based on parameter type and return type information. For example, consider these three function overloads with different parameter types and return types: func doSomething(first: String, second: Int) -> Double func doSomething(first: String?, second: Int) -> Float func doSomething(first: String?, second: Int) -> Double Previously, if you wrote a link to one of these overloads you needed to include a short hash of that symbol’s unique identifier to disambiguate the link and uniquely reference the specific overload. Swift-DocC’s warnings aided in writing these hashes but a person can’t decode the resulting hash suffix (`-3c5j`) to determine which overload the link is referring to. Now, you can use a combination of parameter types and return types—like `-(String,_)`, `->Float,` or `-(String?,_)->Double`—to disambiguate the link and uniquely reference a specific overload. You can discover the minimal combination of parameter types and return types for each overload from Swift-DocC’s warnings about ambiguous symbol links. For more details, see the Ambiguous Symbol Links section of Linking to Symbols and Other Content. ## Install Swift 6.1 You can try out these exciting new developments in Swift 6.1 today! If you’re building apps for Apple platforms, Swift 6.1 is included in Xcode 16.3, now available from the App Store. And the easiest way to install the standalone Swift 6.1 toolchain is using swiftly, the new Swift version manager that runs on macOS and Linux. Additional installation methods, including for Windows, are included on the Install Swift page.
swift.org
October 28, 2025 at 9:43 AM
Swift at Apple: Migrating the Password Monitoring service from Java
_Swift is heavily used in production for building cloud services at Apple, with incredible results. Last year, the Password Monitoring service was rewritten in Swift, handling multiple billions of requests per day from devices all over the world. In comparison with the previous Java service, the updated backend delivers a 40% increase in performance, along with improved scalability, security, and availability._ The Passwords app, introduced in the fall of 2024, helps users manage their passwords, passkeys, and verification codes. It allows them to store, autofill, and generate strong passwords that can be shared across all their devices, as well as share passwords with trusted contacts. One security feature included in the app is Password Monitoring, which warns users if one of their saved passwords shows up in a data leak. This feature has a server component, running on Linux-based infrastructure, that is maintained by Apple. On a regular interval, Password Monitoring checks a user’s passwords against a continuously updated and curated list of passwords that are known to have been exposed in a leak. Importantly, this task is handled in a thoughtful, privacy-preserving way that never reveals users’ passwords to Apple. A detailed discussion of how this is done using the cryptographic private set intersection protocol is in the Password Monitoring section of the Apple Platform Security guide. The migration from Java to Swift was motivated by a need to scale the Password Monitoring service in a performant way. The layered encryption module used by Password Monitoring requires a significant amount of computation for each request, yet the overall service needs to respond quickly even when under high load. ## Choosing Swift for increased performance For years, our team relied on Java to power large-scale, mission-critical services because of its proven stability and performance. However, Java’s memory management approach no longer aligns with our growing demands and efficiency goals. Instead of simply expanding hardware resources, we were seeking a more-efficient language to support our growth while reducing server overhead. Prior to seeking a replacement language, we sought ways of tuning the JVM to achieve the performance required. Java’s G1 Garbage Collector (GC) mitigated some limitations of earlier collectors by introducing features like predictable pause times, region-based collection, and concurrent processing. However, even with these advancements, managing garbage collection at scale remains a challenge due to issues like prolonged GC pauses under high loads, increased performance overhead, and the complexity of fine-tuning for diverse workloads. One of the challenges faced by our Java service was its inability to quickly provision and decommission instances due to the overhead of the JVM. The Password Monitoring service runs globally, so service load can greatly fluctuate throughout the day, even with client-side techniques to smooth over the distribution of traffic. The peak and trough of a day differ by approximately 50% regionally. To efficiently manage this, we aim to scale down when demand is low and scale up as demand peaks in different regions. A faster bootstrap time is a crucial requirement to support this dynamic scaling strategy. Given the scale of our application and the volume of traffic we manage daily, the decision to transition from Java to another language was not made lightly. We evaluated our options, and found only a few languages that could help us achieve our goals. While you might expect that Apple would automatically choose Swift, we were pleasantly surprised by how well it fit the unique needs of a cloud-based service like ours. Swift has expressive syntax that was easy to learn, and could deliver the performance improvements necessary to meet the demands of our compute workloads. We decided to take a significant leap and started a rewrite of the Password Monitoring backend using Swift. ## Our experience developing with Swift We began rewriting our service using Vapor, a Swift web framework that provided Routing, Controller, and Content modules that we were able to build upon. Our service had additional requirements that led us to create a few custom packages with essential functionality: elliptic curve operations that are crucial for implementing password monitoring, auditing, configuration, error handling, and custom middleware. One of the most significant aspects of Swift that impressed us was its emphasis on protocols. In Java, we relied heavily on inheritance, which can lead to complex class hierarchies and tight coupling. Swift’s approach of protocols and generics promotes modularity and reusability by allowing classes, structs, and enums to share common protocols, enabling a more flexible and scalable codebase. This shift in mindset encouraged us to think in terms of behaviors rather than concrete classes, resulting in cleaner and more maintainable code. Safety is another area where Swift takes a distinctive approach compared to Java. For example, Swift’s optional type and safe unwrapping mechanisms eliminate the need for null checks everywhere, reducing the risk of null pointer exceptions and enhancing code readability. This safety-first approach ingrained throughout Swift’s language design, whether it is deterministic deallocation, copy-on-write (CoW), or value types, makes it inherently less prone to runtime errors. Swift’s async/await support is a nice addition, streamlining how we handle async tasks. Previously, managing async operations often involved complex callback patterns or external libraries. Swift’s async/await syntax simplifies this process, making it more intuitive and less error-prone. We can now write async code that reads like sync code, leading to more readable, testable, and maintainable concurrency handling—especially critical in high-load, multi-threaded environments. Overall, our experience with Swift has been overwhelmingly positive and we were able to finish the rewrite much faster than initially estimated. Swift allowed us to write smaller, less verbose, and more expressive codebases (close to 85% reduction in lines of code) that are highly readable while prioritizing safety and efficiency. Our service benefited from a diverse ecosystem of Swift packages, including logging frameworks, a Cassandra client, and crypto libraries that were readily available. In addition to an excellent support system and tooling, Swift’s inherent emphasis on modularity and extensibility helped future-proof and simplify the integration and customizations needed for our service-specific functions. ## Takeaways for future Swift on server development We benchmarked performance throughout the process of development and deployment, allowing us to discover the trait of the Swift programming language that delighted us the most — its efficiency. Swift’s deterministic memory management led to a much lower memory threshold for our service. Not only were our initial results heartening, but after a few iterations of performance improvements, we had close to 40% throughput gain with latencies under 1 ms for 99.9% of requests on our current production hardware. Additionally, the new service had a much smaller memory footprint per instance — in the 100s of megabytes — an order of magnitude smaller compared to the 10s of gigabytes our Java implementation needed under peak load to sustain the same throughput and latencies. The service runs on Kubernetes, and the migration’s efficiency improvements allowed us to release about 50% of its capacity for other workloads. Our Swift implementation has run smoothly and efficiently in production, making it worth the effort we put into this migration. In addition to outperforming our previous Java-based application, Swift delivered better performance consistency, enhanced safety features, and robust reliability — all while requiring fewer resources by utilizing memory and CPU efficiently. With fewer lines of boilerplate code and more flexible design patterns that we used, we look forward to simplified maintenance of our application. Swift was a powerful choice for building fast, resilient, and maintainable applications in our high-demand environment.
swift.org
October 28, 2025 at 9:43 AM
ICYMI: Memory Safety, Ecosystem Talks, and Java Interoperability at FOSDEM 2025
The Swift community had a strong presence at FOSDEM 2025, the world’s largest independently run open source conference, held every year in Brussels, Belgium. FOSDEM highlighted a range of Swift-related talks related to memory safety, a broad ecosystem around Swift including using it to develop web services and embedded projects, and new areas of the project including Java interoperability. In case you missed it, here are a few highlights from the event: ## Memory Safety in Swift The main track of the conference featured a talk presented by Doug Gregor on memory safety: “Incremental Memory Safety in an Established Software Stack: Lessons Learned from Swift.” If you’re interested in learning more about Swift’s memory safe features, this talk is a great place to start; it walks through the different dimensions of memory safety in Swift, the language’s safe interoperability with C(++), and reflects on lessons learned for both programming language design and adopting Swift in an established software codebase. To learn more about memory safety in Swift, see the Swift documentation page on memory safety, as well as the vision document on memory safety. ## Swift DevRoom FOSDEM is primarily organized into DevRooms, volunteer-organized conference tracks around technical communities and topics. This year Swift celebrated its inaugural DevRoom organized by a local community member, Steven Van Impe, with contributions from a large group of volunteers including proposal reviewers, speakers, and day-of-operations support. Swift’s first Swift DevRoom was a hit! 🎉 The room was packed with 12 talks, covering a wide range of topics and demos from the Swift ecosystem: talks related to running Swift on Linux, showcasing various IDEs like VS Code, and a whole hour dedicated to embedded content. A few talks to highlight from the event: * Building a Ferrofluidic Music Visualizer with Embedded Swift * Building container images with swift-container-plugin * Distributed Tracing in Server-Side Swift Check out the complete lineup to learn more! ## Java Interoperability In the Free Java DevRoom, Konrad ‘ktoso’ Malawski presented on Java interoperability in Swift: “Foreign Function and Memory APIs and Swift/Java interoperability.“ Konrad’s talk was a technical deep dive into the Java interoperability effort that launched in 2024, demonstrating the bridges and bindings needed to integrate systems written in Swift and Java while still maintaining great performance. Catch up on this talk to see how you can leverage existing libraries without complete rewrites. Work in early development has been released on GitHub for feedback and contributions, and your feedback is welcome on the forums.
swift.org
October 28, 2025 at 9:43 AM
Redesigned Swift.org is now live
Over the past few months, the website workgroup has been redesigning Swift.org. On behalf of the website workgroup, I’m pleased to announce that we have merged the initial changes. Our goal with the site redesign has been to make Swift.org more approachable for newcomers to Swift, highlight the language’s technical strengths, and make it easy to get started. That led to a focus on the website’s appearance, improving the user experience, and emphasizing important features such as Swift’s multiplatform support. Today’s release includes refreshed home and install pages. Additionally, new pages have been designed to explore Swift use cases, including cloud services, command line tools, and embedded software. Looking forward, we plan to take an iterative approach to improving the website, including pushing changes live as we complete their design and implementation. ## Brand new design We explored several design options and found that the latest design conveys the fluidity and creativity of Swift through the splash of orange and the bird animation in the background. ## Curated content and examples The homepage now highlights Swift’s strengths alongside code examples that illustrate them. Additionally, we showcase various types of software that can be developed using Swift; these new use case pages provide information such as relevant packages, examples of Swift in action, code snippets, and links to resources for further learning. ## Next Steps We look forward to hearing your feedback on this first set of changes as we continue to redesign other sections of the site. There are several ways to offer feedback on the redesign and to get involved: * A forum announcement has been shared on the forums that can be used for discussion, and the website repository has GitHub issues. * The website itself is open source, and your contributions to the swiftlang/swift-org-website repository are welcome. * The Swift Information Architecture Project is an ongoing effort that has helped inform decisions related to the site redesign. Thank you to the website workgroup and community members for contributing to these improvements.
swift.org
October 28, 2025 at 9:43 AM
The Growth of the Swift Server Ecosystem
Nearly ten years ago, Swift was open sourced and an official runtime for Linux was released. I’ve been involved with Swift on the server since almost the very beginning, originally picking it up as a way to use a language I really enjoyed for backend development. In that time Swift has come a long way, with stability across platforms, a burgeoning ecosystem and many success stories. It’s matured into a great option for highly-scalable server applications, websites, and lambdas. In this post, I’ll cover how Swift: * is seeing a number of success stories of running critical production workloads * has evolved to be a powerful language for server development * has a thriving ecosystem of frameworks and libraries * has a growing and passionate community - including a dedicated server conference coming up in October! ## Running in Production There have been some really awesome success stories emerge over the last few years, reinforcing the strength of Swift on the server. The award-winning Things app explained how they migrated their backend from Python to Swift, seeing a 4x increase in performance, whilst costing a third of the original price! Apple’s Password Monitoring Service also underwent a similar transition migrating from Java to Swift. As well as an improved codebase from Swift’s ergonomics, they saw similar gains with a 40% increase in throughput, a 50% reduction in hardware utilization, and a **90% decrease** in memory usage that freed up server capacity for other workloads. From my vantage point working on Vapor, I’ve seen more and more companies adopt Swift on the server. I no longer get asked if Swift is “ready for production?”. All the questions are about what can it do and “how can I use Swift for my use case?”, which is fantastic to see. There are even a number of talks lined up for this year’s server conference with success stories of running Swift on the server. ## Language strengths and improvements Swift has grown a lot since Swift 3! The language has seen a huge number of changes heavily adopted, and in some cases driven, by the server world. Native UTF-8 strings, `Codable`, keypaths, and property wrappers all saw quick adoption by server packages. Swift Concurrency has been a game changer, making it significantly easier for developers to write asynchronous code, which is especially helpful in an environment where almost everything is asynchronous! Task local values make it simple to introduce distributed tracing to applications without the need to pass contexts around everywhere. More recently, features such as package traits, build plugins, and macros have already started to be adopted by server libraries that provide more performant and efficient code to end users. One of the big changes in recent years is the introduction of `Sendable`, which has eliminated many cases of data race issues. A great showcase of this is Vapor, which used to see one or two issues created a month reporting data race crashes that were impossible to reproduce and extremely hard to resolve. Since Vapor adopted `Sendable` there hasn’t been **a single report** of a data race crash! This just goes to show how using Swift makes it easier to write safe server applications. Foundation has also undergone a significant journey. Gone are the days of an entirely separate implementation for Linux. With Swift 6, the same Foundation code runs on Linux as on Apple platforms. This makes it far easier for developers to build on different platforms. Speaking of which, the recent cross-compilation SDKs make it super simple to build Linux binaries on macOS. Swift was introduced with great C interoperability and has since expanded to include C++ and Java, opening up possibilities from integrating with libraries written in those languages. Packages such as Swift Kafka have been quickly released because they can use existing, battle-tested libraries from C or C++ with little effort. The new Swift Java interop also makes it possible to work with existing Java libraries in Swift projects and begin to incrementally migrate large, existing Java codebases to Swift, without the need for major rewrites that are often risky. This was spoken about at the package’s introduction at ServerSide.swift 2024. Overall, Swift has evolved to be a great language for server development. Have a look at the Cloud Services page on swift.org for getting started tutorials, language benefits, and more information about the server ecosystem. ## The Ecosystem Swift on the server is nothing without an ecosystem. Over the last decade, Vapor continues to evolve and grow, newer frameworks like Hummingbird are taking advantage of modern Swift features, and a swathe of packages have been released to support all kinds of APIs, libraries and databases. I’m always amazed at the weird and wonderful ways people are using Swift in server environments and how much of the ecosystem is driven by the community. The areweserveryet.org website has a great list of different packages available, and the Swift Package Index has been instrumental in propelling the package ecosystem on Linux, with build results for every single package submitted, allowing anyone to quickly check platform support for packages. Swift is picking up more acceptance in the server world and the recent Valkey announcement for Swift is a testament to the efforts of the community in making Swift a first-class citizen on the server. > Fun addendum - the Swift Package Index is itself built using Swift on the server, as one of the biggest open source Vapor applications! Swift is also building an awesome observability ecosystem. It has API packages for each of the three pillars (logging, metrics, and tracing), that mean you can plug in any backend you want and all the packages in your dependency tree will work with it. And the growing list of backends already includes options for many popular open-source projects, such as Prometheus, Statsd and Open Telemetry. The entire server ecosystem has worked hard to ensure that all packages have adopted these core packages so there are no concerns around incompatibilities when choosing how to implement observability in your application, no matter the package you choose. The ecosystem continues to be an early adopter of Swift technologies. gRPC Swift 2 introduced earlier this year introduced first-class concurrency support was a particular highlight of the next generation of server packages emerging to take full advantage of structured concurrency. This has been heavily driven by the Swift Server Workgroup, which is comprised of members from across the ecosystem and industry and continues to work to ensure that the ecosystem works together as well as driving improvements to the language, and tooling, such as the recently adopted Swiftly CLI tool, originally developed by the workgroup. ## A growing community The last ten years has seen the community grow and grow at an ever accelerating pace and it feels great to know that the next ten years will be even more exciting and see an even bigger community. There’s even a dedicated conference! The ServerSide.swift conference I organize, is hosting its 5th year this year in London. The schedule has recently been announced and it’s packed with amazing talks on gRPC, containers, concurrency, and success stories. Previous years have seen really great talks, such as the success story of using Swift on the server by Cultured Code, the company behind Things. Other standout sessions include talks on the OpenAPI generator, the announcement of the new Swift Foundation, and technical language talks on structured concurrency. Tickets for this year’s conference are still available on the website. We even have a day of workshops, including a workshop from expert developers on how to get started with Swift on the server, which is a great opportunity for anyone wanting to learn more. The adoption of Swift on the server is ever-increasing as the language proves its benefits for safe, performant backends. The ecosystem continues to grow, with more frameworks, libraries, and tools being developed to support an expanding range of server applications. I can’t believe it’s _only_ been ten years since it started, and I’m excited to see how Swift on the server grows over the next decade!
swift.org
October 28, 2025 at 9:43 AM
Introducing Swift Profile Recorder: Identifying Performance Bottlenecks in Production
Swift Profile Recorder, an in-process sampling profiler for Swift services, is now available as an open source project. Profiling is a powerful technique for understanding the performance, resource usage, and behavior of your applications. With Swift Profile Recorder, profiling can now be added to your Swift services by simply adding a package dependency and no additional setup. Swift Profile Recorder enables you to: * **Adopt profiling without extra privileges or system dependencies** , allowing you to add profiling across a variety of compute environments with constrained permissions. * **Collect samples using`curl`**, allowing you to easily read profiler output via an HTTP endpoint without needing to learn specific tooling like perf, sample, DTrace, or eBPF (bpftrace). * **Integrate with existing tools for visualization and analysis** by supporting multiple industry-standard formats, including Linux perf script format, both the pprof file format as well as the `/debug/pprof/profile` endpoints, and also the collapsed format as used by the original FlameGraphs. Apple has used Swift Profile Recorder at scale for several years as a tool for operating and debugging Swift services in production. Alongside the recent announcement of swift-parca, the Swift server ecosystem now has multiple profiling tools and approaches. ## What is profiling and why does it matter? Profiling enables you to understand where your Swift application spends its time — whether it’s computing, waiting for a lock acquisition, or blocked in file I/O. Profiling is achieved by collecting samples of activity, which provide insight into how it’s being used. Modern operating systems have tooling available to profile your applications or even the whole system. Examples include Apple’s Instruments, `sample`, and Linux’s `perf`. Furthermore, there are kernel systems like DTrace or eBPF that can be used to profile your applications. The community recently contributed swift-parca, which plugs into Parca Agent, leveraging Parca Agent and eBPF on Linux to profile your application continuously. These samples are then aggregated on a centralized Parca server. This is a great tool which we hope many deployments can leverage today. But there are a few constraints which may impact wider adoption: * Special privileges are required to attach to another process or load an eBPF/DTrace program into the kernel * Linux distributions may require additional components to enable this functionality * The available profiling technologies differ significantly between operating systems To enable more teams to profile their applications, Swift Profile Recorder takes a different approach — it runs from within your process, implemented as a Swift Package. This means it can profile your code even in environments where external profiling tools can’t operate. You also won’t need to install other system components, you won’t need extra privileges, and the approach can work on different operating systems — right now Swift Profile Recorder supports macOS and Linux. ## Profiling Swift services at Apple Apple extensively uses Swift on server to build distributed systems providing storage and compute at a huge scale. These systems power the build and test infrastructure for the development of Apple’s operating systems. Our client workloads are latency-sensitive, so we soon found a need to further instrument the code to understand performance bottlenecks. This infrastructure runs in a sandboxed environment where we don’t have access to tools such as eBPF. Additionally, components of our infrastructure run atop macOS. So we built Swift Profile Recorder to give better insights into non-optimal code. We use Swift Profile Recorder in two ways for the above infrastructure use case: * To safely diagnose specific and isolated instances of performance regressions * To gather a large number of samples across all of our infrastructure to identify common patterns, also known as Continuous Profiling ## Getting started Adding Swift Profile Recorder to your application requires minimal setup: // In your Package.swift .package(url: "https://github.com/apple/swift-profile-recorder.git", .upToNextMinor(from: "0.3.0")) // In your target dependencies .product(name: "ProfileRecorderServer", package: "swift-profile-recorder") Then, in your application’s main function: import ProfileRecorderServer @main struct YourApp { func run() async throws { // Start the profiling server in the background async let _ = ProfileRecorderServer(configuration: .parseFromEnvironment()).runIgnoringFailures(logger: logger) // Your application code continues here } } Enable profiling through environment variables: Assuming you specified `configuration: .parseFromEnvironment()` you will have to set an environment variable to activate the profiling server: `PROFILE_RECORDER_SERVER_URL_PATTERN=unix:///tmp/my-app-samples-{PID}.sock ./my-app` Collect samples with a simple curl command: curl --unix-socket /tmp/my-app-samples-12345.sock \ -sd '{"numberOfSamples":1000,"timeInterval":"10ms"}' \ http://localhost/sample | swift demangle --compact > samples.perf ## Visualization and Integration The generated profiles work seamlessly with popular visualization tools: * Speedscope (speedscope.app): Drag and drop your `.perf` file for instant flame graph visualization * Firefox Profiler (profiler.firefox.com): Upload your profile for detailed timeline analysis (example profile) * Traditional FlameGraph tools: Use Brendan Gregg’s original FlameGraph scripts for custom visualizations * Many other tools compatible with the common `.perf`, `.pprof` or stack collapsed formats An example running Hummingbird’s `hello` example on macOS visualized in Speedscope can be seen below Swift Profile Recorder can also be used a source to send samples to Parca as well as Pyroscope. If your production environment allows you to install system-wide profiling using eBPF, we would recommend to use Parca Agent together with swift-parca. ## Community and feedback Swift Profile Recorder is an open source project and we’re eager to hear from the Swift community. Whether you’re running Swift applications in Kubernetes, investigating performance issues, or simply curious about where your application spends its time, we’d love to know how Swift Profile Recorder works for you. For example, it should be possible to integrate Swift Profile Recorder into a lambda function. We look forward to hearing how you use the profiler. The project is actively developed and we welcome contributions, bug reports, and feature requests. As with any profiling tool, different applications and environments present unique challenges, and community feedback is essential for improving the profiler’s effectiveness across diverse Swift codebases. Ready to start profiling? Visit the Swift Profile Recorder repository to get started. We also encourage you to discuss the project on the Swift forums, including asking questions about this post on the associated thread, and sharing your experiences in the Swift Profile Recorder category.
swift.org
October 28, 2025 at 9:43 AM