晚报

• Swift.org · rss:a76d8c3e94eba61fc46b5cc05fc51e5f6df1d0f46d901d32e9c27bb251f155ae:swift-blog:19 · swift.org ↗ · 发布：2026-09-11T15:30:00+00:00 · 采集：2026-09-17T07:07:56.208180+00:00

When your Swift program hits a breakpoint and stops so you can inspect it, the debugger’s expression evaluator has to find the exact Swift module your code was built from. Until now, that lookup wasn’t always precise. The upcoming Swift 6.4 release will include changes, begun in Swift 6.3, that address this by updating how the Swift compiler references explicitly-built Swift modules in debug info. The majority of developers will automatically benefit from faster, more reliable debugging and smaller build products, without any modifications to their SwiftPM or Xcode projects. For developers who maintain their own build systems using, for example, Bazel, Buck, or CMake, some adjustments may be necessary to take advantage of these changes. This article explains how the debugger uses Swift modules. Next, it describes how Swift 6.3 changes the way modules are tracked in debug info to solve several problems with the previous representation. Finally, it shows how to adjust build systems to take advantage of the new representation and eliminate some build steps that are no longer necessary. Swift modules and expression evaluation LLDB’s standout feature is its powerful expression evaluator. Because LLDB embeds the Clang and Swift compilers, it can JIT-compile any valid source code and run it in the context of your application while stopped at a breakpoint. This includes not just calling code in your application, but also defining new data types, functions, and closures. Debugging features that are usually reserved for interpreted or JIT-compiled languages like JavaScript become available to ahead-of-time-compiled languages like C++ and, of course, Swift! In order to JIT-compile user expressions that make use of data types defined in the debugged program, LLDB’s embedded Swift compiler needs to import the Swift modules defining those types. In a world before explicitly-built modules, LLDB would find the base name of the main module at the current breakpoint in the debug info and then kick off an implicit import of a module with that name. With a cold module cache this would launch an expensive compilation of that module and all its dependencies. To illustrate this, let’s walk through a simple example: (lldb) p myObj Here myObj is just a local variable: LLDB can find its location in the debug info and resolve its type via reflection metadata. No need to bother the Swift compiler. Let’s make it more complex: (lldb) p myObj.myComputedProperty In this case, myComputedProperty is really a function call; in order to evaluate this, LLDB needs the expression evaluator to run code in the target. In order to initialize a Swift compiler instance with the state of the current module, LLDB finds the name of the current function’s Swift module in debug info. We can visualize what LLDB does using the dwarfdump utility: $ dwarfdump Foo.o ... DW_TAG_module DW_AT_name ("Foo") Conceptually, LLDB then wraps the expression in a function that can be compiled: (lldb) log enable lldb expr (lldb) p myObj.myComputedProperty ... import Foo func lldb_expr(_ $__lldb_arg : UnsafeMutablePointer<Any>) { let myObj: MyObject = /* some LLDB magic */ // Expression begins here: myObj.myComputedProperty ... One problem with this is that import Foo is quite imprecise: Even though the Swift language doesn’t allow multiple modules to have the same name, even the most stringently engineered application may have more than one copy of the same module. For example, there might be a private version of a module containing all of its private declarations (which would be great for LLDB) and also a Swift interface file that only contains the public interface for the module. Or there might be macOS and Mac Catalyst variants of the same module in the same process. Swift modules, debug info, and the build system Let’s look at where those modules are found next. In order to communicate the location of Foo.swiftmodule to LLDB, Swift build systems rely on some cooperation from the linker. On Darwin the system linker accepts an option called -add_ast_path and build systems are expected to specify this option to list every binary Swift module when linking. # Linker invocation on macOS ld -add_ast_path /path/to/Foo.swiftmodule Foo.o -o MyApplication The linker translates these options into symbol table entries. The debug info linker dsymutil then collects all Swift modules and stores them in a special __swift_ast section in the dSYM bundle, where LLDB can find them by name. Alternatively, when debugging without dSYM bundles, LLDB reads the symbol table entries in the binary to collect a list of all binary Swift modules. Such an approach would not work on platforms where the linker isn’t aware of Swift. For these platforms, which include Windows, Linux, and FreeBSD, the Swift compiler provides a -modulewrap action that takes a binary Swift module and outputs an object file with a .swift_ast section holding the contents of the module. This object file can then be passed to any linker to get added to the binary, where LLDB can find it. # Modulewrap and linker invocation on Linux swift-frontend -modulewrap Foo.swiftmodule -o Foo.swiftmodule.o lld Foo.o Foo.swiftmodule.o -o MyApplication This can create scalability issues, especially for large applications: Module files can get large and for an entire application you can often end up with a large portion of the SDK in the resulting binary. That can be quite problematic for the binary size. As mentioned above, the chances of LLDB finding the right module in a Swift AST section or symbol table just by its base name diminish as the application gets more complex. Binary Swift modules are version-locked to the precise compiler that created them. This is at odds with the intent of dSYM bundles, which are meant for long-term archival serialization of debug info. If a matching explicit module cannot be found, LLDB falls back to an implicit module import which may involve recompiling parts of the SDK from source. This can be very slow. Precise module tracking To evaluate expressions, the debugger needs to be able to find and import Swift modules. Until now, this relied either on special linker support or additional compilation steps, with a high cost for binary size. On top of that the debugger was imprecisely locating Swift modules by name. Starting in Swift 6.3 and continuing since, we have been making changes to the Swift compiler, the Swift driver, and LLDB that improve performance, reliability, and scalability. These changes are built on top of explicitly-built modules. What’s new Explicitly-built modules track their explicit Swift dependencies: Explicitly-built binary Swift modules have always kept track of their explicitly-built Clang module dependencies. This is why LLDB can import explicit modules so much faster than implicit modules, which may need to recompile their dependencies from source. In Swift 6.3, explicitly-built binary Swift modules also keep track of their Swift module dependencies. This makes importing an explicitly-built module fast and unambiguous because no module needs to be looked up by name. This happens automatically. Users don’t need to make any changes. Users with distributed build systems will already be familiar with the Swift frontend’s path remapping options, which now also affect Swift module paths. Debug info stores path of object file’s own Swift module: Once LLDB finds the top-level module it can precisely import it and all of its dependencies. But how can LLDB find precisely the module that belongs to the Swift file at the current breakpoint? In Swift 6.3, the Swift compiler can store the path to it in the debug info. Because a Swift file’s own Swift module is not an input to an object file compilation, there is a new -debug-module-path compiler option to communicate the path to each object file compilation action. This path is also subject to the standard path remapping options used by users with distributed build systems. Swift driver passes module path to compile jobs: Users of swiftpm or Xcode do not need to think about this, because the Swift driver also knows about the new -debug-module-path option and automatically passes the path to the object file’s own Swift module to the compiler. However, users maintaining their own third-party build system to orchestrate Swift compilations with explicitly-built modules that are calling the Swift frontend directly and bypassing the Swift driver need to make sure to communicate the path to the top-level module to each object file compilation job. What’s deprecated Beginning in Swift 6.4, you can safely make the following changes. swiftc -modulewrap and ld -add_ast_path: Because the module paths are now communicated via debug info and the module headers themselves, third-party build systems doing explicit module builds can now remove all -modulewrap actions on Linux and Windows; and remove the use of the -add_ast_path linker option on Darwin (macOS, iOS, etc…). Binary Swift modules in dSYM bundles: As a consequence, dsymutil will no longer process binary Swift modules. This is a good thing, because binary Swift modules—which can only be parsed by the exact toolchain that produced them—were always at odds with dSYM bundles being a long-term archival format. Moreover, Swift modules often depend on Clang modules, and these Clang modules also were never included in dSYM bundles. By removing the binary Swift modules, dSYM bundles will get smaller. But don’t we need them for debugging? Since Swift 1.0, binary Swift modules were included in dSYM bundles because they were needed to resolve the types of local variables. However, starting with Swift 5.6, LLDB could perform this operation by reading the reflection metadata in the binary. The absence of binary Swift modules in dSYM bundles does not affect LLDB’s ability to inspect the contents of variables or dump object descriptions with po. Binary Swift modules are still needed to evaluate complex expressions like function calls or computed getters. Expression evaluation continues to work as long as LLDB finds all binary modules in their original (or remapped) location. This is always the case when debugging a just-built binary on the same machine. If the absence of binary Swift modules in dSYM bundles creates an unforeseen problem with your workflow, please let us know, either on the Swift LLDB forum or by creating an issue on the bug tracker. When compiling with caching enabled, all paths pointing to Swift modules and module debug info are content-addressable storage references, identified by content rather than file location, so everything described here also works transparently with compilation caching. Coming in Swift 6.4: Faster bridging header import in LLDB Beyond more reliable path tracking, Swift 6.4 will also speed up importing bridging headers, a step common enough across Swift projects that most developers will feel the difference. Up to and including Swift 6.3, LLDB always compiles a bridging header from source, a step that can add noticeable time to debugging sessions that use one. In recent nightly development toolchains, LLDB can use the new precise explicit module information to import precompiled bridging headers and their explicit module dependencies directly. This makes debugging explicitly-built projects with bridging headers as fast and reliable as debugging fully modularized projects. Summary With these changes for explicitly-built modules: Binaries built with debug info on Windows and Linux, and dSYM bundles on Darwin will get dramatically smaller, since they no longer contain any binary Swift modules (6.4+) Contextual module imports in LLDB become more reliable due to precise tracking instead of by-name lookups Certain performance cliffs around module importing in LLDB are eliminated (such as SDK module dependencies in dSYMs triggering implicit imports) Developers maintaining their own build systems can remove support for -modulewrap actions and remove -add_ast_path from the linker flags, but may need to pass -debug-module-path to the compiler if they are not letting the Swift driver handle the frontend options Finally, static archives were easy to overlook: projects that didn’t use -add_ast_path when linking them often had confusing debugging issues inside those archives as a result. This entire class of issues has been designed away. tl;dr: -modulewrap and -add_ast_path are replaced by -debug-module-path. Debug info gets smaller and more precise.

• Swift.org · rss:a76d8c3e94eba61fc46b5cc05fc51e5f6df1d0f46d901d32e9c27bb251f155ae:swift-blog:18 · swift.org ↗ · 发布：2026-09-04T16:30:00+00:00 · 采集：2026-09-17T07:07:56.208180+00:00

Welcome to “What’s new in Swift,” a curated digest of releases, videos, and discussions in the Swift project and community. Here’s an update from guest contributor Simon Leeb on Swift’s progress as a language for web scenarios: Hi, Simon here! I am the creator of the elementary-swift project, a collection of packages born from a simple wish: I want to build web UIs in Swift and ultimately help Swift become a first-class choice for the web. This journey began after I started using Swift for backend services. The web frontend, however, still lived in a separate ecosystem, and I really wanted it to feel as ergonomic, safe, and efficient as the Swift I was writing everywhere else. That led to the creation of Elementary: a modern and efficient HTML rendering library with a familiar declarative API, built for the web. It integrates easily with frameworks like Vapor and Hummingbird, and has become a practical option for server-rendered web UIs. Around that same time, years of community work in the swift-wasm project made compiling Swift to WebAssembly increasingly viable, while Embedded Swift was taking its first experimental steps. This made me wonder: “How hard can it be to use Embedded Swift and build a state-driven web UI framework that produces tiny WebAssembly binaries?” Turns out: quite hard, actually! But it was too late. Despite my better judgment, I was in the middle of creating what is now known as ElementaryUI. Where Elementary renders HTML on the server, ElementaryUI runs in the browser itself. You can watch my talk at Swift@FOSDEM 2026 if you want to know more about the why, what, and how. To showcase where the project is heading, I recently posted a small Full-Stack Swift on Cloudflare demo. It features Swift in the browser communicating with a Swift backend on an edge worker through shared message types. I hope it gives people a concrete sense of how much the core technologies and the surrounding tooling have advanced. ElementaryUI is still young, with plenty left to build. Visit elementary.codes to try it, share feedback, contribute, or sponsor its development. Let’s work together and make Swift a first-class choice for the web! Now on to other news about Swift: Videos to watch Saleem Abdulrasool joined the Empower Apps podcast to discuss Swift on Windows, server-side Swift, SwiftWin32, Swift’s C++ interop, and how to get started. Building memory-safe software? Write security-sensitive code in Swift covers how Swift guarantees safety across bounds, lifetimes, types, initialization, and concurrency, with primitives like Span and non-copyable types, plus how to audit unsafe code with strict memory safety and incrementally migrate existing C modules. Two short videos about running Embedded Swift on Raspberry Pi Pico: a video on getting started on macOS called Let it blink! and Fun with traffic lights in 60 seconds. Community highlights Building scalable backend apps in Swift shares an approach to structuring server-side Swift codebases, separating business logic from database and framework details so the code stays easier to test and change over time. The Swift Package Index blog explains what a package registry actually is, how it fits alongside SwiftPM and package indexes, and walks through an example of switching a dependency managed from Git to a Swift registry. Embedded Swift Improvements Coming in Swift 6.4 rounds up what’s ahead for Swift on microcontrollers and other constrained environments. The Browser Company’s Swift on Windows: A year of refinement reflects on a year of work making Swift on Windows more predictable. New package releases Write an interface once with SwiftTUI using a declarative, state-driven syntax, then ship it as a terminal app, as a native macOS or iOS app, as an Android app, or as a WASI build for the browser. Tired of hand-writing RawRepresentable and LosslessStringConvertible conformances? lexic generates them for you via macros, and runs the same on Linux as on Apple platforms. StructuredQueries, Point-Free’s SQLite query builder, now has fully type-safe support for JSON and JSONB columns, including a json_each table function, so nested data can be queried and updated by key path without leaving Swift’s type system. Swift Evolution The Swift project adds new language features through the Swift Evolution process. These are some of the proposals currently under review or recently accepted for a future Swift release. Under active review: ST-0029 Include additional issue metadata in event stream - Today, Swift Testing’s JSON event stream reports only bare-bones details when an issue occurs, making it hard to tell a thrown error apart from a manual Issue.record call. This proposal adds structured fields, including error, confirmationMiscount, exceededTimeLimit, and expression, so tools like Xcode and VS Code can show richer, more specific failure information. Recently accepted: SE-0544 Mutation and consumption in non-copyable type deinits - Non-copyable types that manage a resource, like a file handle or buffer, often need to run the same cleanup logic in their deinit that they use elsewhere, but until now self inside a deinit could only be borrowed, not mutated or consumed. This proposal lets a deinit mutate or consume its own stored properties directly, so existing cleanup methods can be reused instead of duplicated. ST-0028 Revise Swift Testing’s Attachment/Encodable interop - Swift Testing lets you attach extra data, like a screenshot or JSON snapshot, to a test for inspecting after a failure, but attaching custom types previously required extra setup code and offered no way to choose the encoding format. This proposal adds new Attachment initializers that let you attach Encodable or NSSecureCoding values directly, picking the format or supplying your own encoder. Recently accepted with modifications: SE-0536 Package Registry Search - To use a package from a registry today, you already have to know its exact identifier, since there’s no standard way to discover packages within a registry the way other package ecosystems allow. This proposal adds an optional /search endpoint to the registry specification and a swift package-registry search subcommand, letting you find packages by name, scope, author, and other criteria, with support for qualifiers like author:"Mona Lisa Octocat" and searches that span every configured registry at once. SE-0516 Iterable - Looping over a collection in Swift traditionally means copying out one element at a time, which doesn’t work for newer types that can’t be copied, like Span and InlineArray. This proposal introduces Iterable, a new way to loop over data without copying, and was renamed from BorrowingSequence and given support for typed throws before acceptance. ST-0026 TaskLocal test trait - Task-local values are like settings, such as a feature flag, that apply only within a single task. Overriding one in a test previously meant writing a custom trait from scratch, but this proposal adds a .taskLocal(_:_:) trait that does it in one line, like @Suite(.taskLocal(FeatureFlags.$isEnabled, true)).

• Swift.org · rss:a76d8c3e94eba61fc46b5cc05fc51e5f6df1d0f46d901d32e9c27bb251f155ae:swift-blog:4 · swift.org ↗ · 发布：2026-03-02T14:05:00+00:00 · 采集：2026-09-17T07:07:56.208180+00:00

Welcome to this edition of “What’s New in Swift,” where we share interesting projects and updates in the Swift community that deserve visibility to a broader audience. FOSDEM is the largest open source conference in the world, and this year Swift was featured in talks across multiple tracks and a dedicated pre-conference event. Here’s a report from the Swift community: Hey there! Karen Chu here. 👋 I help grow and support the Swift open source community, and one of my favorite things has been increasing Swift’s participation in open source events. As a follow-up to Swift’s presence at FOSDEM last year, this year we expanded our approach by running our own Pre-FOSDEM fringe event, which included 11 talks across multiple platforms, in addition to four Swift talks across various devroom tracks. Though it was my first year at FOSDEM, it was delightful to meet several people who attended the Swift devroom last year and also came through again this year. With the vast array of attendee backgrounds (I met recent grads, former Swift mentees, Swift workgroup members, folks from the Swift Core Team, and more) and talks covering different platforms (embedded, server, BSD, Android, and more), that weekend showed me just how much momentum Swift has gained as a general purpose language that can benefit everyone. I wanted to highlight Simon Leeb’s talk, Swift in the Browser with ElementaryUI, as a popular talk from the event which showed how to run Swift applications natively in the browser with WebAssembly. FOSDEM may be over (for now), but I’m already excited about how the Swift community will show up next year! To catch up on all the talks at the Pre-FOSDEM event, check out the YouTube playlist. Now on to other news about Swift: New package releases Originally developed for searching financial databases for strings like stock tickers, FuzzyMatch brings high-performance fuzzy string matching to Swift. Now you can expose GraphQL APIs in your applications with new Vapor and Hummingbird packages. Using Microsoft SQL Server? SQLClient-Swift is a native client for iOS, macOS, and Linux that’s built using modern Swift concurrency. Developers now have more options to create terminal-based Swift applications with TuiKit, a declarative, SwiftUI-like framework for building Terminal User Interfaces. TuiKit joins Noora, which provides themeable components for CLIs. Lastly, Swift System Metrics 1.0 was announced, making the collection of process-level metrics easy. Videos to watch Interested in writing Swift using agents? At Swift Barcelona, a talk on Building Agentic Apps with MCP in Swift demonstrated several open source tools. And if you’re an Xcode user, check out a recent code-along covering coding intelligence in Xcode 26. Introducing the Swift SDK for Android covered the current state of Swift on Android, how to call Java and Kotlin APIs from Swift, UI strategies, and what’s actively being worked on. SwiftCrossUI: Swift apps, everywhere presented a UI solution for Swift applications that run on Android, Linux, and Windows, using native UI components on each platform. The project also recently published a development update in video form, covering contributions and recent changes. Ever wanted to control microcontrollers in Swift? CoreAVR + ArduinoKit: Swift on the Arduino, the Swift way introduces ArduinoKit, which acts as the Arduino standard library for Swift, and CoreAVR, a hardware abstraction layer for AVR microcontrollers written in Swift. Community highlights Swift is participating in Google Summer of Code 2026! 🎉 A recent forums post announced the process and outlined key dates to learn more. This is a great opportunity if you’re a student interested in contributing to Swift! A community member recently blogged about their experience profiling Swift applications on Windows and macOS with Tracy, covering how to visualize and analyze their application performance. Swift Evolution The Swift project adds new language features through the Swift Evolution process. These are some of the proposals currently under review or recently accepted for a future Swift release. Under active review: SE-0514 Hashable Conformance for Dictionary.Keys, CollectionOfOne and EmptyCollection - Three standard library collection types can’t currently be used in sets or as dictionary keys. This proposal adds Hashable conformance to all three, for consistency with the rest of the standard library. SE-0513 API to get the path to the current executable - There’s currently no portable, reliable way to get the path to the currently running executable in Swift. This proposal adds CommandLine.executablePath, a new property in the standard library that provides a consistent way to get this value across all platforms Swift supports. Recently accepted: SE-0506 Advanced Observation Tracking - @Observable types automatically track when their properties change. However, advanced use cases like developing middleware infrastructure or widget systems require more control and features. This proposal adds options to the existing withObservationTracking to control when/which changes are observed, and a continuous variant that re-observes automatically after coalesced events. SE-0502 Exclude private initialized properties from memberwise initializer - When you define a struct in Swift, the compiler automatically generates an initializer that takes each property as an argument. Currently, adding a private property with a default value to a struct forces that auto-generated initializer to become private, which breaks callers outside of the type. This proposal fixes that behavior. Have any suggestions for a future issue? Drop them in the Community Showcase on the Swift Forums. See you next time!

• Swift.org · rss:a76d8c3e94eba61fc46b5cc05fc51e5f6df1d0f46d901d32e9c27bb251f155ae:swift-blog:9 · swift.org ↗ · 发布：2026-05-01T10:30:00+00:00 · 采集：2026-09-17T07:07:56.208180+00:00

Welcome to “What’s new in Swift,” a curated digest of releases, videos, and discussions in the Swift project and community. The 1.0 release of valkey-swift was recently announced on the Valkey blog. We’ve invited one of the authors to be this month’s guest contributor: Hi, I’m Adam Fowler, an open source developer working in the Swift on server ecosystem. I am excited to announce the 1.0 release of valkey-swift - a production-grade Swift client for Valkey. Valkey is a high-performance datastore commonly used as a caching layer or message broker in server applications. It is an open source fork of Redis. Valkey-swift is a client library targeted at Valkey servers but is equally capable of working with Redis. It is built from the ground up with Swift 6 and structured concurrency. Every Valkey command returns typed responses checked at compile time, and strict concurrency checking is enabled throughout so that data races are caught by the compiler, not in production. Connections and subscriptions are all scoped through structured concurrency, so resources clean up automatically. The client covers every standard Valkey command, auto-generated from Valkey’s own command specifications to stay in sync as the server evolves. Previously, the de facto client library for Redis was RediStack, which was built on top of pre-concurrency concepts. Retrofitting structured concurrency would have been awkward and some of the new features in valkey-swift infeasible. Around the same time Redis changed its licensing structure and the open source fork Valkey was created. So it felt like a good time to make a clean break and build a new library. If you’re building server-side Swift and need a fast key-value store, add valkey-swift via Swift Package Manager, and you’re ready to go. If you are using RediStack to connect with a Redis server, we have a guide to help you migrate to valkey-swift. Complete documentation is available, and contributions are welcome on GitHub. Now on to other news about Swift: Videos to watch The try! Swift Tokyo 2026 conference featured not one, but two exciting talks about Embedded Swift: Getting started with Embedded Swift is a short and accessible introductory talk. Learn about writing Swift using embedded simulators, along with code examples to run Swift code on devices including the Game Boy Advance! Learn by Building: Bare-Metal Programming with Embedded Swift is a deeper look at Embedded Swift. Follow along by trying the sample code for five bare-metal Raspberry Pi Pico examples that are featured in the talk. Want to learn more about Swift concurrency from engineers who have designed and used its features? Check out this live online Q&A on Swift concurrency. Nil Coalescing published a new video on some of the lesser known options for working with optionals in Advanced Techniques for Working with Optionals in Swift. New package releases IndustrialKit is a framework for designing, programming, and controlling robotic systems that was recently discussed on the Swift forums. swift-tar is a pure Swift library for reading, writing, and extracting TAR archives. swift-tar is cross-platform, works without requiring any system framework or Foundation, and supports GNU & PAX extensions. Xylem is a pure Swift XML parser with zero dependencies, covering SAX, DOM, and XPath 1.0. Swift Evolution The Swift project adds new language features through the Swift Evolution process. These are some of the proposals currently under review or recently accepted for a future Swift release. Under active review: SE-0529 Add FilePath to the Standard Library - FilePath in the swift-system package parses platform-specific path syntax on the developer’s behalf, provides a normalized view of path components, and enables filesystem resolution. However, shipping in an external package means the standard library, Swift runtime, and toolchain libraries such as Foundation cannot depend on it. This proposal adds FilePath and its associated types to the Swift module, alongside essential functionality for construction, decomposition, resolution, and C interoperability. Recently accepted: Vision for Networking - Swift’s networking ecosystem is getting an overhaul. This vision document proposes three initial areas of focus: evolve HTTP APIs including new HTTP client and server implementations, define currency types to reduce duplicated effort and integration friction, and define a unified networking stack. SE-0517 UniqueBox - Sometimes in Swift it’s necessary to manually put something on the heap that wouldn’t otherwise live there. This proposal introduces a new type in the standard library, UniqueBox, which is a smart pointer type that uniquely owns a value on the heap. ST-0022 Custom reflection during testing - When a test fails, Swift Testing reflects the values involved to help diagnose the failure, but types have no way to customize what appears in that output. This proposal adds a customization point, CustomTestReflectable, for developers to specify exactly what should be included in test output, whether they want to simplify, obscure, extend, or reformat that information. One more thing Have you recently looked at the Swift.org community page? It includes updated content, plus a new How we work page that describes opportunities to get involved.

• Swift.org · rss:a76d8c3e94eba61fc46b5cc05fc51e5f6df1d0f46d901d32e9c27bb251f155ae:swift-blog:17 · swift.org ↗ · 发布：2026-08-20T13:45:00+00:00 · 采集：2026-09-17T07:07:56.208180+00:00

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. Following our updates on Embedded Swift improvements in Swift 6.3 late last year, this post describes a number of additional improvements made in the upcoming Swift 6.4 release. You can try them out today with a Swift development snapshot. Language improvements Embedded Swift continues to expand its subset of the language to include more aspects of “full” Swift, making it easier than ever to bring compatibility with Embedded Swift to existing Swift code bases. Many of these features have some dynamic aspect to them, meaning that they have an impact on runtime performance (for example, due to indirect calls) and code size (due to requiring additional metadata). However, this impact only occurs where these dynamic language features are actually used: code that is highly sensitive to code size and performance can choose to avoid them, for example by enabling warnings in the PerformanceHints diagnostic group. Generalized support for existential (any) types any) types section" href="#generalized-support-for-existential-any-types"> Embedded Swift previously only supported existential (any) types that had an AnyObject constraint, meaning they could only be used with class instances. Now, all any types are available in Embedded Swift, including Any itself. For example: protocol P { func method() } extension Int: P { func method() { print("\(self) is here") } } let a: any P = 17 a.method() // prints "17 is here" The Embedded Swift generics compilation model, which requires that all generic functions and types eventually be specialized, implies some limitations on the use of any types. Specifically, a generic function cannot be called on an any type: extension P { func genericMethod<T: P>(_ other: T) { ... } } let a: any P = 17 a.genericMethod(a) // error: cannot use generic instance method 'genericMethod' on a value of type 'any P' in Embedded Swift Untyped throws Embedded Swift previously only allowed throwing specific error types, like this: func parseRecord() throws(ParsingError) -> Record { ... } “Untyped” throws, which can throw any Error-conforming instance, was previously disallowed in Embedded Swift: func loadImage() throws -> Image { ... } // previously disallowed in Embedded Swift Untyped throws is equivalent to throwing a value of type any Error. With the generalization of any types, Embedded Swift now fully supports untyped throws. Throwing a value of any Error typically requires a heap allocation, so typed throws should still be preferred for code bases that want to avoid heap allocations. Metatypes Embedded Swift has traditionally allowed metatypes (e.g., Int.self) only in very narrow places, for example when using them to specify argument types for generic functions: rawPointer.bindMemory(to: Value.self, capacity: 1) Swift 6.4 introduces complete support for metatypes in Embedded Swift: one can create and use instances of metatypes, including existential types like any (DefaultInitializable.Type). For example, this is now permitted and works in the same way as full Swift: protocol DefaultInitializable { init() } extension Int: DefaultInitializable { } let factory: any (DefaultInitializable.Type) = Int.self let aValue: any DefaultInitializable = factory.init() Library improvements Additional features in the Swift standard library and associated libraries from full Swift are now available in Embedded Swift. Floating point parsing Swift floating point values can be parsed from a string, like this: let inputText: String = getInputText() if let value = Double(inputText) { // value is a Double } As part of a reimplementation of this functionality in Swift, these floating-point parsing APIs are now available in Embedded Swift as well. Concurrency error handling The Embedded Swift concurrency library now supports throwing operations, such as throwing tasks and task groups. For example: let task = Task { if badThing { throw MyError.badThingHappened } return "ok" } print(try await task.value) 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 · rss:a76d8c3e94eba61fc46b5cc05fc51e5f6df1d0f46d901d32e9c27bb251f155ae:swift-blog:2 · swift.org ↗ · 发布：2026-01-30T15:15:00+00:00 · 采集：2026-09-17T07:07:56.208180+00:00

A Reddit thread earlier this month asked about building web apps with Swift. For this edition of “What’s new in Swift,” we invited a developer to share their experience: Hi, I’m Nick Sloan. I’m the head of engineering at Studioworks, a platform that makes it easy and fun to run your creative studio, agency or freelance business. We chose Swift for Studioworks because of how easy it is to write safe and reliable code with great performance. Our Swift project makes use of Hummingbird 2, Soto (for its incredible DynamoDB Codable support), Hummingbird MacroRouting, and Elementary. Studioworks is a big and growing project. We are the largest Elementary codebase, and I suspect we are among the biggest projects using Hummingbird as well. We’ve already processed millions of dollars in invoices for our customers, and after 20 years of shipping web applications, I have never seen fewer crashes and bugs make it to production. Performance has also been excellent, especially after moving our templates to Elementary. Our heaviest pages make it to the browser in less than 100ms. We’ve been deploying web applications with PHP and Python for decades, and getting started with a Swift web project was certainly a bit slower. We had to recreate some of the build, deployment and chat tooling we had been relying on in our Python projects for years, and it took us a bit of experimenting to realize that Elementary was the best choice for templating. Once we got past those hurdles we’ve been able to build about as fast as we ever did with Python, and the quality is much better. Swift on the web has been a resounding success for us, and I hope we’ll see this part of the community continue to grow! — Nick Sloan Learn more about Swift on Linux and server-based use cases by checking out our October edition, which featured highlights from the Server-Side Swift Conference. The swift.org website also has a use case page dedicated to cloud services, including a tutorial to get started. And now for what’s new in Swift this month. Videos to watch On Progressive Disclosure in Swift - Doug Gregor’s must-watch talk explores how Swift lets you progressively use more language features as your experience and codebase evolves. A new episode of NSScreencast dives into livecoding the Billion Row Challenge, with Matt Massicotte as a guest. New package releases Want to build 3D models with code? Cadova is a programmable alternative to traditional CAD tools, with a focus on 3D printing. Feather Database provides a database-agnostic layer that can be shared by multiple database drivers. And it’s designed for modern Swift concurrency. Miguel de Icaza has ported the .NET Foundation mail stack, originally created by Jeffrey Stedfast (MailKit/MimeKit), to Swift. Hello MailFoundation and MimeFoundation! Community highlights Introduction to Building Swift for Yocto - Check out this embedded Linux guide to using meta-swift to build Swift for a Raspberry Pi Zero 2. Registration is open for several Swift community conferences, including SwiftCraft and try! Swift Tokyo. The Call for Proposals (CFP) is still open for try! Swift Tokyo. Swift Evolution The Swift project adds new language features through the Swift Evolution process. These are some of the proposals currently under review or recently accepted for a future Swift release. Under active review: SE-0506 Advanced Observation Tracking - @Observable types automatically track when their properties change. However, advanced use cases like developing middleware infrastructure or widgeting systems require more control and features. This proposal adds options to the existing withObservationTracking to control when/which changes are observed, and a continuous variant that re-observes automatically after coalesced events. SE-0507 Borrow and Mutate Accessors - When you read or write a Swift property, the code that handles that access currently either makes a copy of the value or uses coroutines, which have performance overhead. This proposal adds new borrow and mutate keywords that let properties provide direct access to their stored values and enables properties that hold values that can’t be copied. Recently accepted: SE-0498 Expose demangle function in Runtime module - The Swift compiler uses name mangling, turning Swift symbols into strings like $sSS7cStringSSSPys4Int8VG_tcfC which show up in backtraces and profiling tools. There are times, however, when a human-readable format is preferable. This proposal introduces a new API that allows calling out to the Swift runtime’s demangler, without leaving the process.

• Swift.org · rss:a76d8c3e94eba61fc46b5cc05fc51e5f6df1d0f46d901d32e9c27bb251f155ae:swift-blog:7 · swift.org ↗ · 发布：2026-03-31T14:30:00+00:00 · 采集：2026-09-17T07:07:56.208180+00:00

Welcome to “What’s new in Swift,” a curated digest of releases, videos, and discussions in the Swift project and community. Swift 6.3 has been released, expanding Swift into new domains and improving developer ergonomics. A highlight of its release is work to improve cross-platform build tooling. Owen Voorhees shares an update on that effort: Hi! I’m Owen, a lead engineer on the Core Build team at Apple. Last year we shared our goal to bring Swift Build to Swift Package Manager, in an effort to deduplicate build technologies within the Swift ecosystem and deliver a consistent build experience across all platforms that Swift supports. Since the announcement, we’ve been working in the open, landing hundreds of patches to improve Swift Build’s support across various platforms including Linux and Windows, and to integrate it deeply in Swift Package Manager. With Swift 6.3, developers have the option to enable this integration and try it out with their packages. To validate parity with the previous build system, we’ve used the package list from swiftpackageindex.com, testing thousands of open source packages with Swift Build. Most recently, the main branch of Swift started using Swift Build as its default build system, paving the way for Swift Build to be the out-of-the-box option for Swift developers in a future Swift release. Over the coming months, we’ll continue sharing our progress and driving down the remaining bugs to bring the build system to parity. We encourage you to give it a try and file bugs that you encounter. We’re excited by this progress, and look forward to building future tooling improvements across all platforms and project models that will benefit from this build system. Now on to other news about Swift: Videos to watch Interested in Swift for systems programming? The -ization of Containerization, presented at SCaLE, covers the Containerization project and their experience adopting Swift. Swift community meetup #8 featured two talks: real-time computer vision on NVIDIA Jetson, and a production AI data pipeline built with Vapor. A new interview with Matt Massicotte on the Swift Academy podcast goes in-depth on Swift Concurrency. Community highlights How can you gradually deprecate APIs ahead of a major release? Point-Free blogged Hard Deprecations and Soft Landings with SwiftPM Traits, a clever approach to solving a common API deprecation problem. Daniel Jilg shared TelemetryDeck’s adoption story on the Swift blog, including how they use Swift and Vapor for backend services. The March 2026 Swift for Wasm updates are out, highlighting a new JavaScriptKit release with BridgeJS improvements, and continued work in WasmKit. Swift Evolution The Swift project adds new language features through the Swift Evolution process. These are some of the proposals currently under review or recently accepted for a future Swift release. Under active review: SE-0522 Source-Level Control Over Compiler Warnings - Swift lets you configure warning behavior at the module level using compiler flags, but that’s an all-or-nothing approach. This proposal adds fine-grained warning control: a @warn attribute that lets you override warning behavior for a specific diagnostic group within the scope of a single declaration, with support for escalating it to an error, downgrading it to a warning, or suppressing it entirely, without affecting the rest of your module. Recently accepted: SE-0509 Software Bill of Materials (SBOM) Generation for Swift Package Manager - An SBOM is a standardized inventory of all the software components in a project, increasingly required for security auditing and regulatory compliance. This proposal adds native SBOM generation to SwiftPM as both a --sbom-spec flag on swift build, and a separate swift package generate-sbom subcommand, with support for the CycloneDX and SPDX formats. ST-0021 Targeted Interoperability between Swift Testing and XCTest - When migrating from XCTest to Swift Testing, it’s common to call existing XCTest helper functions from new Swift Testing tests. Today, an XCTAssert failure inside a Swift Testing test is silently ignored. This proposal fixes that: XCTest APIs will work as expected when called in Swift Testing, and Swift Testing APIs will work as expected when called in XCTest, if XCTest already provides similar functionality. SE-0515 Allow reduce to produce noncopyable results - Swift’s reduce currently requires its initial value to be copyable, making it incompatible with noncopyable types. This proposal updates reduce to support noncopyable initial values and results, and changes it to consume rather than borrow the initial value, eliminating an unnecessary copy even for copyable types.

• Swift.org · rss:a76d8c3e94eba61fc46b5cc05fc51e5f6df1d0f46d901d32e9c27bb251f155ae:swift-blog:15 · swift.org ↗ · 发布：2026-07-02T16:00:00+00:00 · 采集：2026-09-17T07:07:56.208180+00:00

Welcome to “What’s new in Swift,” a curated digest of releases, videos, and discussions in the Swift project and community. June was an exciting month for Swift, featuring announcements at WWDC and community events around the globe. We invited the organizers of one of them to share with us: Hey, it’s Mikaela and Adrian. We are organizers of CommunityKit, a community-organized conference that takes place the same week as WWDC, and iOSDevHappyHour, a monthly online meetup that keeps the community connected year-round. This is our fifth year coming out to Cupertino, and we love being able to create a place for the community to thrive, no matter where developers live. CommunityKit brought together over 250 developers in real life to geek out over the announcements, stay for the community and vibes, see what everyone is creating, and learn from each other. Some of the highlights from this year’s event were the Indie Fair, where developers showcased their apps; the Watch Party, our annual gathering to watch the keynotes together; and Make Something, Ship Nothing, a hands-on postcard-making hangout to close the week. This year we also introduced workshops, including “Inclusive by Design” by Danielle Lewis, and for the Swift community: “Write Faster, Smarter Swift” by Paul Hudson. We can’t wait to hear about what everyone builds and brings to next year’s Indie Fair, and hope to see you at CommunityKit and iOSDevHappyHour! Now on to other news about Swift: WWDC26 highlights At its WWDC26 conference, Apple provided an update on its adoption of Swift and made a variety of new Swift-related announcements. Some highlights: During the Platforms State of the Union, Apple announced that parts of the core operating system kernel are being written in Swift for upcoming releases. What’s new in Swift featured changes in Swift since last year, including a preview of what’s coming in Swift 6.4, like up to 4x faster URL parsing and support for async code in defer blocks. The QUIC transport layer in Apple’s networking stack was rewritten in Swift. The project has been open sourced and is available for cross-platform use through SwiftNIO integration. A new Swift package, Foundation Models framework utilities, was released with tools for working with LLMs, including custom skills and context management helpers. It runs on Apple platforms and select Linux distributions. The Foundation Models framework itself will be open sourced in the future, meaning the same Swift APIs you use in your app could run on your server. Container Machine is a new tool that provides a lightweight, persistent Linux environment on a Mac. Unlike a container, which is modeled after an application, a container machine is modeled after the environment itself. Container machines share the host environment, including the home directory and configuration. It’s written in Swift and open source. Videos to watch Build real-time apps and services with gRPC and Swift walks through integrating an iOS app and gRPC service using live race data from a go-karting league. See if you can spot where the track is located. 👀 Want to learn about Swift macros with hands-on tutorials? Stewart Lynch published two videos with sample code to follow along: Swift Macros Demystified: Build a Freestanding Expression Macro, and Swift Attached Macros: Build a Real-World Member Macro from Scratch. A new 10-minute Embedded Swift demo uses an accelerometer and the XIAO ESP32-C6 to control a Swift bird that glides across a mini OLED screen. No soldering required! Community highlights Swift Package Index joined Apple and remains open source. The team says they’re working together to build a comprehensive package registry for the Swift community. Yeo Kheng Meng blogged about bringing Swift to the Apple II, complete with a REPL, compiler, file browser, and editor. It’s a subset of Swift and was built with AI assistance. Apple shared an adoption story on the Swift blog: Migrating the TrueType Hinting Interpreter, covering how the TrueType hinting interpreter in macOS and iOS was rewritten in Swift from C. It runs 13% faster on average. The Swift Ecosystem Steering Group announced the creation of the Networking workgroup. This group will work on a unified networking stack for Swift, layered from low-level I/O primitives, through common protocols, to a modern HTTP client and server API. New package releases New Swift bindings for the OkHttp Java library were released. If you’re using Swift on Android and looking for an HTTP client this may be useful. The project was generated with swift-java. Kiln is a new documentation engine written in Swift. Built to replace MkDocs-based documentation sites, it gives more options for the Swift community to render docs, in addition to the DocC project which is used for the official Swift documentation. You can see Kiln in action at the Vapor documentation. Version 0.4.0 of Elementary UI was released, a frontend framework for running Swift applications natively in the browser. Swift Evolution The Swift project adds new language features through the Swift Evolution process. These are some of the proposals currently under review or recently accepted for a future Swift release. Under active review: SE-0526 withDeadline - Asynchronous operations in Swift can run indefinitely, and implementing time limits manually using task groups and clock sleep operations is verbose and error-prone. This proposal adds withDeadline, a function that executes an async operation with a composable absolute time limit specified as a clock instant, canceling the operation if it hasn’t completed in time. It also allows multiple nested operations to share the same deadline, avoiding the drift that accumulates when relative durations are passed through call layers. Recently accepted: SE-0474 Yielding Accessors - When you call a mutating method on a computed property, Swift creates the illusion of in-place mutation by getting a copy, mutating it, then setting it back. This causes unnecessary copy-on-write buffer duplication for types like String, and is impossible for noncopyable types, which can’t be copied out at all. This proposal adds yielding borrow and yielding mutate, two new ways to implement computed properties and subscripts that instead lend the caller direct access to the underlying value without copying it. Recently accepted with modifications: SE-0529 Add FilePath to the Standard Library - FilePath in the swift-system package parses platform-specific path syntax on the developer’s behalf, provides a normalized view of path components, and enables filesystem resolution. However, shipping in an external package means the standard library, Swift runtime, and toolchain libraries such as Foundation cannot depend on it. This proposal adds FilePath and its associated types to the Swift module, alongside essential functionality for construction, decomposition, resolution, and C interoperability. SE-0527 UniqueArray - Swift’s Array can’t store noncopyable elements without compromising its copy-on-write semantics or performance predictability. This proposal adds two new types to a new Containers module: RigidArray, a fixed-capacity array that traps on overflow, and UniqueArray, a dynamically growing array that enforces unique ownership by being noncopyable itself.

• Swift.org · rss:a76d8c3e94eba61fc46b5cc05fc51e5f6df1d0f46d901d32e9c27bb251f155ae:swift-blog:10 · swift.org ↗ · 发布：2026-06-01T12:00:00+00:00 · 采集：2026-09-17T07:07:56.208180+00:00

Goodnotes has been helping millions of users take handwritten notes on iPad for over a decade, earning recognition as Apple’s iPad App of the Year in 2022. Today, the same Swift code that powers our iOS app also runs seamlessly in web browsers through WebAssembly, delivering the exact same ink rendering and note-taking experience users love. This journey demonstrates that Swift excels as a cross-platform language, running high-performance applications while sharing the same codebase. Every bug fix and improvement to Goodnotes benefits all our users simultaneously, regardless of which platform they use. After two years of development and over two years in production at Goodnotes, we’ve shown that Swift on WebAssembly is a viable, powerful approach for building complex, performance-critical web applications. Why we chose Swift for the web When we decided to bring Goodnotes to the web in 2021, we faced a critical decision. After more than 10 years of development, we had accumulated millions of lines of Swift code that implemented countless refinements and optimizations for digital ink rendering, document synchronization, conflict resolution using Conflict-Free Replicated Data Types (CRDTs), and content search and document indexing. We need to maintain more than 60 Frames Per Second (FPS) for real-time ink rendering, which makes performance critical. A JavaScript rewrite, Flutter, or Kotlin Multiplatform would all require rewriting our entire rendering engine from scratch, a substantial undertaking that would have delayed our web launch by years and inevitably introduced behavioral differences between platforms. SwiftWasm emerged as the solution. This community-driven project allows Swift code to compile to WebAssembly, running in browsers with good performance. We started experimenting with SwiftWasm, building prototypes to validate the approach. Our first experiment focused on our handwriting component, a performance-critical part of Goodnotes that would serve as a good indicator of WebAssembly’s capabilities. The results were promising enough that we committed to this path. The most compelling benefit wasn’t just code reuse, but the guarantee of behavioral consistency. When users draw a stroke on their iPad and later open the same document on the web, they see exactly the same curves, the same pressure sensitivity, the same ink flow. This isn’t because we carefully reimplemented the same algorithms twice: it’s because it’s literally the same Swift code running on both platforms. Technical architecture Goodnotes Architecture: Shared Swift code between iOS and Web platforms. Our architecture is built around a clear separation between platform-specific UI components and shared business logic. This design enables us to maintain behavioral consistency while leveraging platform-native capabilities where appropriate. Shared core components The heart of our application consists of three main parts: Content Rendering Engine: This handles the real-time rendering of notebook content and interactive ink strokes. We use a custom rendering engine built on low-level graphics APIs: Metal on iOS and WebGL on the web. The rendering logic is almost entirely shared, with only platform abstraction layers implemented separately for each platform. Business Logic Layer: Document modeling, handwriting recognition, and document indexing are all implemented in shared Swift packages. View Models: Core view models that handle tool interactions and user gestures are shared across platforms. Code sharing metrics Our codebase demonstrates significant code reuse: Total Web Swift codebase: 2.2 million lines of code Shared Swift code: 1.47 million lines (66% of the web app, 34% of the iOS app) While lines of code isn’t the best metric, these numbers reflect the substantial business logic and rendering engine that we successfully share between platforms. Binary size and loading The final WebAssembly binary is approximately 50 MB, which compresses to 12 MB with Brotli compression. We use Service Workers for efficient caching and fast load times for users. JavaScript interoperability We use JavaScriptKit for seamless interoperability between Swift and JavaScript. This allows us to integrate with the existing web ecosystem while keeping our core logic in Swift. Platform compatibility considerations When sharing code between iOS and WebAssembly targets, we encountered several important considerations: Concurrency Model: libdispatch APIs are unavailable on WebAssembly targets. We migrated from direct libdispatch usage to Swift Concurrency’s async/await and actors, for better cross-platform compatibility. Architecture Differences: On wasm32, Swift’s Int has a 32-bit width. Some code assumed Int only held 64-bit values, so it had to be updated to use Int64 explicitly. Dependency Injection: Network access and other I/O operations are abstracted through dependency injection, allowing us to provide platform-specific implementations while keeping the core logic shared. Multithreading with WASI threads One of the most significant technical achievements was implementing true parallelism using WebAssembly System Interface (WASI) Threads with Web Workers and SharedArrayBuffer. This allows us to: Run handwriting recognition in background Web Workers Perform document indexing without blocking the main thread Maintain smooth rendering at more than 60 FPS while processing complex operations Swift Concurrency’s Custom Actor Executors (SE-0392) were crucial for managing the web platform’s constraints. JavaScript objects are isolated to their originating thread, so we needed precise control over where our Swift actors execute. JavaScriptKit provides several APIs to create a SerialExecutor for a dedicated Web Worker, enabling us to pin specific actors to specific Web Workers. This architecture ensures that computationally-intensive tasks like handwriting recognition run in the background while UI operations stay on the main thread, while still allowing access to JavaScript objects inside background threads. Performance Impact: This multithreading approach delivered a greater than 2x improvement in Interaction to Next Paint (INP), significantly enhancing the UI responsiveness during complex operations. Security Considerations: Modern browser security policies require Cross-Origin Isolation to use SharedArrayBuffer. While this adds some complexity to the application, it’s a necessary trade-off for the performance benefits of true parallelism. For applications that can’t meet these requirements, single-threaded cooperative concurrent execution remains a viable option. Development experience One of the most significant aspects of our Swift on WebAssembly experience was the development workflow. The tooling ecosystem is mature and powerful, providing a solid development experience. IDE support We can develop using either Xcode or VS Code with SourceKit-LSP, providing full language server support including autocomplete, error checking, and refactoring capabilities. Xcode doesn’t currently have WebAssembly platform support, so code completion and other features are limited for WebAssembly-specific APIs. SourceKit-LSP, however, has Swift SDK support, so by properly configuring .sourcekit-lsp/config.json, you can get code completion for WebAssembly targets as well. Debugging and development tools You can debug Swift code directly in Chrome DevTools: set breakpoints, inspect variables, and step through your Swift code as naturally as JavaScript. We developed a Chrome DevTools extension library that enables Swift-specific variable reflection and source-level debugging, building upon the existing WebAssembly debugging capabilities. For more details on the enhanced DWARF extension for Swift, see the Swift on WebAssembly debugging guide. Debugging Swift code in Chrome DevTools with full source code visibility and variable inspection. Performance profiling The existing web ecosystem provides powerful performance profiling tools. Chrome’s Performance tab shows exactly where time is spent, down to individual Swift functions, and the Memory tab gives us good insight into memory usage patterns. For most performance optimization tasks, these standard tools are quite effective. For more advanced cases requiring specialized memory profiling capabilities and detailed heap analysis, the growing WebAssembly ecosystem provided the foundation for building custom tools. We developed wasm-memprof for detailed heap profiling when optimizing memory usage. This tool provides insights into memory allocation patterns that aren’t easily visible through standard web profiling tools. Performance profiling with wasm-memprof showing memory allocation patterns and optimization opportunities. Contributing back to the community As part of our journey, we’ve been able to contribute back to the Swift community in meaningful ways. All WebAssembly-related changes have been upstreamed, and the WebAssembly platform has been supported since Swift 6.2! This means that other teams can now benefit from the same tooling and language features that made our project successful. Lessons learned Our experience has shown that Swift on WebAssembly is production-ready for complex applications. The language’s safety features, performance characteristics, and modern concurrency model translate well to the web platform. For teams considering this path, here are our key recommendations: Start with a performance-critical component to validate the approach. Invest in proper platform abstraction layers early. Leverage Swift Concurrency for cross-platform compatibility. Plan for the security requirements of SharedArrayBuffer if multithreading is needed. Consider gradual adoption rather than complete rewrites for existing projects. Consider using Swift for your web projects. The growing WebAssembly ecosystem and improved tooling support make this an increasingly viable option for teams looking to share code across platforms. Get involved with Swift on WebAssembly Swift has fulfilled its promise as a powerful, expressive language that works everywhere. From mobile devices to servers to web browsers, Swift code can run efficiently while maintaining the safety and performance characteristics that developers appreciate. The Swift on WebAssembly ecosystem is more accessible than ever. Here’s how you can get involved: For Developers: Try out the Swift on WebAssembly getting started guide and build your first web application. Explore the JavaScriptKit Hello World tutorial for hands-on learning. Use the WebAssembly debugging guide to set up your development environment. For SwiftWasm Contributors: Participate in discussions with the #webassembly tag on the Swift forums. Open issues and contribute to improve the toolchain. Share your experiences and help build the community. With Swift’s official WebAssembly support, we’ve entered a new era of cross-platform development. The same language that powers iOS applications can now create web experiences that are fast, safe, and maintainable. Swift’s future is increasingly cross-platform, and we’re excited to see what the community builds next.

• Swift.org · rss:a76d8c3e94eba61fc46b5cc05fc51e5f6df1d0f46d901d32e9c27bb251f155ae:swift-blog:16 · swift.org ↗ · 发布：2026-08-07T15:30:00+00:00 · 采集：2026-09-17T07:07:56.208180+00:00

Welcome to “What’s new in Swift,” a curated digest of releases, videos, and discussions in the Swift project and community. Swift is built by contributors working on far more than the language and compiler. Alexander Sandberg reflects on what that kind of contribution looks like, and why there’s a place for you too: Hi, I’m Alex. Four years ago I joined the Swift Website Workgroup to help care for the website you’re reading this on. I was still fairly new to the Swift community then, but I wanted to get involved somehow and make a difference. Contributing to Swift sounds like it should involve working on the compiler or writing and reviewing language evolution proposals, but there’s a lot going on around the language itself too. What I actually spent my time doing was helping improve the site’s content and navigation, taking part in the big redesign, writing release blog posts, reviewing pull requests, and answering issues and forum posts. All of it is work anyone can learn to do, and all of it ends up in front of everyone who comes to Swift.org—which made even the smallest fixes feel worth doing. The Website Workgroup happened to be my way in, but there are groups like it across the project—server, testing, Windows, Android, and more—each a handful of people looking after their part of the ecosystem. Whatever you’re good at or curious about, there’s probably a corner of Swift that could use your help. The community page is a good place to start looking, and the people you’ll meet are some of the friendliest I’ve come across in open source. After four years, I’ve stepped away to focus on other things in life. Thank you to everyone I got to work with over these years! I’m leaving the workgroup, but not the community, and I’ll still be around helping push Swift forward where I can. For more information about workgroups, the How we work page lists all workgroups. And on the Swift forums you’ll often see workgroups sharing open meetings if you’re looking to get involved! Now on to other news about Swift: Videos to watch Balancing High and Low-Level Programming in Swift, presented by John McCall at PLDI 2026, digs into the ongoing work to bring explicit ownership and lifetime features to Swift for systems programming, and the tricky balance of fitting them into a language built around simple, low-friction application development without breaking source compatibility or ABI stability. Speaking of low-level Swift: I Built a Timer for the Playdate in Swift and I Built a 3D Renderer for the Playdate (in Swift) are a fun pair of videos on building for the handheld game console in Swift. Melbourne CocoaHeads has been uploading a great back catalog of past event talks to their YouTube channel, including Christian Mitteldorf’s 2023 talk on running Swift on the server. Recent project changes Google Summer of Code contributions are underway: Ege Kaya is building a Task Registry for the Swift Concurrency runtime (PR #90547), Filip Sakellariou is contributing to swift-syntax (PR #3378, PR #3390), and Padmashree S S is working in sourcekit-lsp (PR #2698, PR #2729). Task Stealers, a new primitive in Swift Concurrency’s runtime, recently merged after generating the liveliest discussion of any PR in July. They change how work gets distributed across the cooperative thread pool, an under-the-hood change worth watching if you write concurrency-heavy code. SwiftPM landed a reference implementation of the package registry service, along with basic auth support, a solid starting point if you’re exploring self-hosting a registry. Small but welcome fixes landed across tooling: the VS Code extension now fails loudly when a Swift installation is broken, and gained a clean build folder command, while Swift Testing’s event stream gained an ABI.Context API that produces human-readable output for CI tooling and dashboards. New package releases Need to tokenize text fast? swift-gigatoken is a zero-copy tokenizer hitting up to 670 MB/s, inspired by Marcel Roed’s gigatoken, with NEON/CRC32 support and compatibility across WebAssembly and Embedded Swift. any-error-swift takes a different approach to error handling, offering a concrete, value-semantic, Hashable type that erases any Swift error, no Foundation required, and works on every platform Swift runs on. Swift Evolution The Swift project adds new features through the Swift Evolution process. These are some of the proposals recently accepted for a future Swift release. Recently accepted: ST-0025 Tag-based Test Execution Filtering - Swift Testing lets you annotate tests with named tags, and separately lets you include or exclude tests by regex using the --filter and --skip options, but there’s no way to combine the two and filter by tag. This proposal adds a tag: prefix to those options, so you can run commands like swift test --skip tag:uiTest to selectively run or skip tests based on their tags rather than relying on a consistent naming scheme. SE-0513 API to get the path to the current executable - There’s currently no portable, reliable way to get the path to the currently running executable in Swift. This proposal adds CommandLine.executablePath, a new property in the standard library that provides a consistent way to get this value across all platforms Swift supports. Recently accepted with modifications: SE-0526 withDeadline - Asynchronous operations in Swift can run indefinitely, and implementing time limits manually using task groups and clock sleep operations is verbose and error-prone. This proposal adds withDeadline, a function that executes an async operation with a composable absolute time limit specified as a clock instant, canceling the operation if it hasn’t completed in time. It also allows multiple nested operations to share the same deadline, avoiding the drift that accumulates when relative durations are passed through call layers.

• Swift.org · rss:a76d8c3e94eba61fc46b5cc05fc51e5f6df1d0f46d901d32e9c27bb251f155ae:swift-blog:14 · swift.org ↗ · 发布：2026-06-23T14:00:00+00:00 · 采集：2026-09-17T07:07:56.208180+00:00

Since its launch, Swift Package Index has become an essential part of the Swift ecosystem, helping developers discover quality packages, evaluate compatibility, and make informed decisions about dependencies. Started by Dave Verwer and Sven A. Schmidt, the project currently indexes thousands of packages and serves as a central hub for package documentation. Recently, Swift Package Index has grown alongside the Swift project’s multi-platform expansion, extending its compatibility testing to encompass Linux, Android, and WebAssembly. Today, Swift Package Index announced that it has joined Apple and continues its mission: Together, we’re building a comprehensive package registry to serve the Swift community’s evolving needs. Learn more by reading the Swift Package Index announcement.

• Swift.org · rss:a76d8c3e94eba61fc46b5cc05fc51e5f6df1d0f46d901d32e9c27bb251f155ae:swift-blog:1 · swift.org ↗ · 发布：2026-01-26T12:00:00+00:00 · 采集：2026-09-17T07:07:56.208180+00:00

We are excited to announce the creation of the Windows workgroup! The primary goal is to ensure ongoing support for Swift on Windows, enabling users to develop Windows applications using the Swift programming language and its associated tools. The new Windows workgroup joins a growing list of Swift workgroups, including the Android workgroup, Build and Packaging workgroup, and Testing workgroup which were all added in the past year. Swift workgroups are community-led efforts, formally recognized by the project, to help move forward key areas. Windows has been an officially supported platform since 2020, and there’s been great progress since then. The VS Code extension supports Windows, and we’ve seen the community take advantage of Swift’s features on Windows, some of which are described in a 2023 blog post about Using Interoperability to Build on Windows. The workgroup will build upon these efforts and focus on work to: Improve and maintain Windows support for the official Swift distribution. Recommend enhancements to core Swift packages such as Foundation and Dispatch to work better with Windows idioms. Make recommendations to the Swift Project about the direction of future Windows support in Swift. Identify and recommend best practices for bridging between Swift and the Windows API, and for shipping Swift libraries with Windows applications. To learn more and get involved: Discuss this announcement on the forums, and share ideas in the Windows category. Learn more about the Windows workgroup by reading its charter. Join the Windows workgroup’s meetings every other Wednesday at 9:00 AM PT (Pacific Time Zone). Workgroup membership and meetings are open to those who wish to participate, and contributors are welcome! To receive an invite, send a message to @windows-workgroup on the Swift forums.

• Swift.org · rss:a76d8c3e94eba61fc46b5cc05fc51e5f6df1d0f46d901d32e9c27bb251f155ae:swift-blog:11 · swift.org ↗ · 发布：2026-06-03T21:45:00+00:00 · 采集：2026-09-17T07:07:56.208180+00:00

Welcome to “What’s new in Swift,” a curated digest of releases, videos, and discussions in the Swift project and community. To start, we’re focusing on some of the many local meetup groups sharing Swift content: Around the world, local meetup groups and conferences bring Swift developers together, and some even predate Swift itself! Many have YouTube channels where they share videos from their events, so you can tune in remotely. Let’s highlight a few. In May the SF Swift meetup hosted a talk by Dan Federman, Agentify Your Swift Repo, which covers building an agent for CI and review feedback. Swift Barcelona has a dedicated YouTube presence, while some groups, like the new MLX India meetup, post event playlists, including a recent talk about using MLX Swift in iOS apps that’s worth checking out. And there’s even a community-organized Swift Community Meetups YouTube channel, which hosts meetups online and is home to a series of cross-platform Swift talks. These groups support developers in a few ways worth calling out: Local community: they’re building local connections among Swift developers and organizations. Room for experimentation: by being less formal and sometimes featuring works in progress, meetups create space to share ideas, get feedback, and learn from one another. I encourage more folks to get involved in their local Swift meetup. And if your group starts publishing content and videos, please share on the Swift Forums in the Community Showcase category. — Dave Lester Now on to other news about Swift: Videos to watch Interested in using Swift for backend server development? Mohammad Azam posted a livestream recording of Introduction to Hummingbird, a walkthrough of the web framework covering installation and development basics. Meet the Temporal Swift SDK, from Replay 2026, introduces the SDK that brings Temporal’s durable workflows (long-running processes that survive crashes, retries, and restarts without losing state) to Swift. The SDK recently reached its 1.0.0 release. Sébastien Stormacq shares a great introduction to what’s possible with AWS Lambda and Swift, presenting Swift, Server-side, & Serverless on the DevStandup YouTube channel. Community highlights Swift and WebAssembly continues to be an exciting part of the project, with regular activity shared on the Swift forums, including the most recent Swift for Wasm May 2026 Updates. And if you missed it, check out the new blog post by Goodnotes about how they brought Goodnotes to the web with Swift and WebAssembly. The 2026 Swift Mentorship Program was announced, and there’s still time until June 15, 2026, to complete the interest survey to be a mentee. Working on contributions is a rewarding way to learn. And on that note, three Swift projects were accepted for GSoC 2026. Training an LLM in Swift, Part 1 - Matt Gallagher takes handwritten matrix multiplication for a Swift port of llm.c from 2.8 Gflop/s to 1.1 Tflop/s, a 382x speedup, using Swift 6.2’s MutableSpan and InlineArray, Relaxed.multiplyAdd from Swift Numerics, DispatchQueue.concurrentPerform, and finally AMX and Metal. A thorough tour of performance optimization in modern Swift. Members of the community using and contributing to the VS Code Swift Extension met in May during the Swift Extension Community Office Hours, featuring demonstrations of using Kiro and more. New package releases Want to build an AI agent in Swift? The Swift Bedrock Library gives you a Swift library for Amazon Bedrock foundation models. SwiftOSC is an Open Sound Control (OSC) toolkit written in Swift which recently became cross-platform, now supporting Apple platforms, Linux, and Android. It’s music to our ears! Steffan Andrews, who developed SwiftOSC, has also released other music-related Swift packages including SwiftMIDI and SwiftTimecode. Ordo One shipped version 1.33.0 of Benchmark, a package for creating sophisticated Swift performance benchmarks for a wide variety of metrics. Swift Evolution The Swift project adds new language features through the Swift Evolution process. These are some of the proposals currently under review or recently accepted for a future Swift release. Under active review: SE-0532 Optional noncopyable improvements and generalizations - Swift’s Optional can wrap noncopyable types, but unwrapping with if let consumes the optional, leaving it unusable afterward. This proposal adds borrow() and mutate() to Optional, returning Ref<Wrapped>? and MutableRef<Wrapped>? to inspect or modify the payload without consuming it, and generalizes map, flatMap, and unsafelyUnwrapped to support noncopyable wrapped types. Recently accepted: SE-0528 Continuation Safe and Performant Async Continuations - When bridging callback-based APIs to Swift’s structured concurrency, developers today must choose between UnsafeContinuation, where misuse is silent and undefined, and CheckedContinuation, which catches mistakes at the cost of allocation and atomic operations. This proposal adds Continuation<Success, Failure>, a ~Copyable type that makes double-resume a compile-time error and a missing resume a runtime trap, with no overhead on the fast path. SE-0519 Ref and MutableRef types for safe, first-class references - Storing a reference to part of a data structure in Swift today requires either a class, which adds heap allocation and reference-counting overhead, or UnsafePointer, which is unsafe and requires extreme care to use properly. This proposal adds Ref<T> and MutableRef<T> to the standard library: safe types that hold shared and exclusive references to a value, usable as local variables, struct members, and generic type parameters. ST-0024 Test case repetition - Swift Testing can repeat tests for a set number of iterations, or until a specific failure/success condition is reached, which is useful for tracking down flaky failures. Currently, if any single test case triggers the condition, all tests in the target are re-run, even ones that passed. This proposal changes repetition to apply per test case and adds --maximum-repetitions and --repeat-until flags to swift test.

• Swift.org · rss:a76d8c3e94eba61fc46b5cc05fc51e5f6df1d0f46d901d32e9c27bb251f155ae:swift-blog:6 · swift.org ↗ · 发布：2026-03-24T10:00:00+00:00 · 采集：2026-09-17T07:07:56.208180+00:00

Swift is designed to be the language you reach for at every layer of the software stack. Whether you’re building embedded firmware, internet-scale services, or full-featured mobile apps, Swift delivers strong safety guarantees, performance control when you need it, and expressive language features and APIs. Swift 6.3 makes these benefits more accessible across the stack. This release expands Swift into new domains and improves developer ergonomics across the board, featuring: More flexible C interoperability Improvements to cross-platform build tooling Improvements for using Swift in embedded environments An official Swift SDK for Android Read on for an overview of the changes and next steps to get started. Language and Standard Library C interoperability Swift 6.3 introduces the @c attribute, which lets you expose Swift functions and enums to C code in your project. Annotating a function or enum with @c prompts Swift to include a corresponding declaration in the generated C header that you can include in your C/C++ files: @c func callFromC() { ... } // Generated C header void callFromC(void); You can provide a custom name to use for the generated C declaration: @c(MyLibrary_callFromC) func callFromC() { ... } // Generated C header void MyLibrary_callFromC(void); @c also works together with @implementation. This lets you provide a Swift implementation for a function declared in a C header: // C header void callFromC(void); // Implementation written in Swift @c @implementation func callFromC() { ... } When using @c together with @implementation, Swift will validate that the Swift function matches a pre-existing declaration in a C header, rather than including a C declaration in the generated header. Module name selectors Swift 6.3 introduces module selectors to specify which imported module Swift should look in for an API used in your code. If you import more than one module that provides API with the same name, module selectors let you disambiguate which API to use: import ModuleA import ModuleB let x = ModuleA::getValue() // Call 'getValue' from ModuleA let y = ModuleB::getValue() // Call 'getValue' from ModuleB Swift 6.3 also enables using the Swift module name to access concurrency and String processing library APIs: let task = Swift::Task { // async work } Performance control for library APIs Swift 6.3 introduces new attributes that give library authors finer-grained control over compiler optimizations for clients of their APIs: Function specialization: Provide pre-specialized implementations of a generic API for common concrete types using @specialize. Inlining: Guarantee inlining — a compiler optimization that expands the body of a function at the call-site — for direct calls to a function with @inline(always). Use this attribute only when you’ve determined that the benefits of inlining outweigh any increase in code size. Function implementation visibility: Expose the implementation of a function in an ABI-stable library to clients with @export(implementation). This allows the function to participate in more compiler optimizations. For a full list of language evolution proposals in Swift 6.3, see the Swift Evolution dashboard. Package and Build Improvements Swift 6.3 includes a preview of Swift Build integrated into Swift Package Manager. This preview brings a unified build engine across all supported platforms for a more consistent cross-platform development experience. To learn more, check out Preview the Swift Build System Integration. We encourage you to try it in your own packages and report any issues you encounter. Swift 6.3 also brings the following Swift Package Manager improvements: Prebuilt Swift Syntax for shared macro libraries: Factor out shared macro implementation code into a library with support for swift-syntax prebuilt binaries in libraries that are only used by macros. Flexible inherited documentation: Control whether inherited documentation is included in command plugins that generate symbol graphs. Discoverable package traits: Discover the traits supported by a package using the new swift package show-traits command. For more information on changes to Swift Package Manager, see the SwiftPM 6.3 Release Notes. Core Library Updates Swift Testing Swift Testing has a number of improvements, including warning issues, test cancellation, and image attachments. Warning issues: Specify the severity of a test issue using the new severity parameter to Issue.record. You can record an issue as a warning using Issue.record("Something suspicious happened", severity: .warning). This is reflected in the test’s results, but doesn’t mark the test as a failure. Test cancellation: Cancel a test (and its task hierarchy) after it starts using try Test.cancel(). This is helpful for skipping individual arguments of a parameterized test, or responding to conditions during a test that indicate it shouldn’t proceed. Image attachments: Attach common image types during a test on Apple and Windows platforms. This is exposed via several new cross-import overlay modules with UI frameworks like UIKit. The list of Swift Testing evolution proposals included in Swift 6.3 are ST-0012, ST-0013, ST-0014, ST-0015, ST-0016, ST-0017, and ST-0020. DocC Swift 6.3 adds three new experimental capabilities to DocC: Markdown output: Generate Markdown versions of your documentation pages alongside the standard rendered JSON covering symbols, articles, and tutorials. Try it out by passing --enable-experimental-markdown-output to docc convert. Per-page static HTML content: Embed a lightweight HTML summary of each page — including title, description, availability, declarations, and discussion — directly into the index.html file within a <noscript> tag. This improves discoverability by search engines and accessibility for screen readers without requiring JavaScript. Try it out by passing --transform-for-static-hosting --experimental-transform-for-static-hosting-with-content to docc convert. Code block annotations: Unlock new formatting annotations for code blocks, including nocopy for disabling copy-to-clipboard, highlight to highlight specific lines by number, showLineNumbers to display line numbers, and wrap to wrap long lines by column width. Specify these options in a comma-separated list after the language name on the opening fence line: ```swift, nocopy let config = loadDefaultConfig() ``` ```swift, highlight=[1, 3] let name = "World" // highlighted let greeting = "Hello" print("\(greeting), \(name)!") // highlighted ``` ```swift, showLineNumbers, wrap=80 func example() { /* ... */ } ``` DocC validates line indices and warns about unrecognized options. Try out the new code block annotations with --enable-experimental-code-block-annotations. Platforms and Environments Embedded Swift Embedded Swift has a wide range of improvements in Swift 6.3, from enhanced C interoperability and better debugging support to meaningful steps toward a complete linkage model. For a detailed look at what’s new in embedded Swift, see Embedded Swift Improvements coming in Swift 6.3. Android Swift 6.3 includes the first official release of the Swift SDK for Android. With this SDK, you can start developing native Android programs in Swift, update your Swift packages to support building for Android, and use Swift Java and Swift Java JNI Core to integrate Swift code into existing Android applications written in Kotlin/Java. This is a significant milestone that opens new opportunities for cross-platform development in Swift. To learn more and try out Swift for Android development in your own projects, see Getting Started with the Swift SDK for Android. Thank You Swift 6.3 reflects the contributions of many people across the Swift community — through code, proposals, forum discussions, and feedback from real-world experience. A special thank you to the Android Workgroup, whose months of effort — building on many years of grassroots community work — brought the Swift SDK for Android from nightly previews to an official release in Swift 6.3. If you’d like to get involved in what comes next, the Swift Forums are a great place to start. Next Steps Try out Swift 6.3 today! You can find instructions for installing a Swift 6.3 toolchain on the Install Swift page.

• Swift.org · rss:a76d8c3e94eba61fc46b5cc05fc51e5f6df1d0f46d901d32e9c27bb251f155ae:swift-blog:12 · swift.org ↗ · 发布：2026-06-04T10:00:00+00:00 · 采集：2026-09-17T07:07:56.208180+00:00

The Swift Ecosystem Steering Group is excited to announce the creation of the Networking workgroup! Workgroups are community-led efforts, formally recognized by the project, to advance key areas of Swift. The primary goal is to guide the evolution of networking libraries, protocols, and APIs in the Swift ecosystem, making networking in Swift excellent everywhere: high-level and safe by default, modular and interoperable, cross-platform, and observable. Networking is one of the most common entry points for Swift developers, and the ecosystem has matured significantly over the years. Foundational libraries like SwiftNIO, AsyncHTTPClient, and swift-http-types, alongside platform stacks such as URLSession and Network.framework, power networking across apps, servers, and beyond. The workgroup will build upon these efforts and pursue the long-term directions outlined in the Networking vision, focusing on work to: Define a unified networking stack with a coherent layered architecture, from shared I/O primitives at the foundation, through common protocol implementations, to ergonomic client and server APIs at the top. Define currency types that let libraries interoperate without coupling to specific implementations, such as IP addresses, hostnames, ports, and HTTP requests and responses. Evolve HTTP APIs by designing and guiding a modern, unified HTTP client and server API built on structured concurrency. Guide the evolution of shared protocol implementations (TLS, HTTP/1.1, HTTP/2, HTTP/3, QUIC, WebSockets) so improvements benefit the entire ecosystem rather than being duplicated across libraries. The new Networking workgroup joins a growing list of Swift workgroups, including the Android workgroup, Windows workgroup, and Build and Packaging workgroup, which were all added in the past year. To learn more and get involved: Discuss this announcement on the forums, and share ideas in the Networking category. Learn more about the Networking workgroup by reading its charter. The workgroup meets biweekly. A regular meeting time is being finalized and will be announced on the forums ahead of the first public meeting. Workgroup membership and meetings are open to those who wish to participate, and contributors are welcome! To receive an invite, send a message to @networking-workgroup on the Swift forums.

• Swift.org · rss:a76d8c3e94eba61fc46b5cc05fc51e5f6df1d0f46d901d32e9c27bb251f155ae:swift-blog:13 · swift.org ↗ · 发布：2026-06-12T10:00:00+00:00 · 采集：2026-09-17T07:07:56.208180+00:00

TrueType is a widely used vector font standard for rendering text in web pages, PDFs, operating systems, and applications. Familiar fonts like Helvetica, Garamond, and Monaco are all built on TrueType outlines. The format specifies a hinting interpreter intended to help outlines rasterize faithfully on low-resolution displays. Modern high-resolution displays enable beautiful typography from outlines alone, but TrueType fonts that need hinting to render legibly remain in use and we continue to support them. Font parsers process data from untrusted sources, making the TrueType hinting interpreter a security-critical attack surface. To make the format more resilient on Apple platforms, we rewrote its hinting interpreter from C to memory-safe Swift for the Fall 2025 releases. In addition to memory safety, we also improved performance: on average, our Swift interpreter runs 13% faster than the C interpreter it replaced. To accompany this post, we’ve also published the source code of the Swift TrueType hinting interpreter. We hope sharing our experience helps others doing similar work in Swift. TrueType and the hinting engine Apple developed TrueType in the late 1980s and released it with the launch of System 7 in 1991. TrueType was a major breakthrough for the time: it gave font developers enormous control over how glyphs are displayed, with an advanced grid-fitting algorithm and a sophisticated hinting engine built around a special-purpose bytecode interpreter. TrueType did all this on computers that were vastly less powerful than today’s, so it had to be extremely well-tuned for performance. Then the internet revolutionized how fonts were used. TrueType became embeddable in PDF files in 1994 and in web pages in 2008, and it remains as relevant as ever. However, these new use cases brought additional risk: TrueType could now be exposed to untrusted fonts from anywhere on the internet. TrueType fonts may contain programs the hinting engine runs through a bytecode interpreter. This interpreter involves input-driven control flow, complex data structures, and careful memory management—exactly the kind of code that’s hard to make perfect and where memory errors are easier to exploit. This high inherent complexity also makes correctness especially important. Rewriting in Swift A rewrite required a memory-safe language that could integrate into the existing codebase and provide an equivalent level of performance to the implementation it was replacing. Swift was the obvious choice for the task. Binary compatibility was crucial for this project to succeed: existing programs had to continue to function the same as they did before, effectively unaware that a new implementation was in place. This means not just interface compatibility but pixel-identical glyph rendering as well, relative to the C implementation. Hinting can radically change the on-screen appearance of glyphs, so a small change in the interpreter’s behavior could result in substantial user-visible changes. For this project, we defined correctness to mean exact compatibility with the C implementation’s outputs. Validating correctness To ensure correctness, we developed two test suites. The first was a unit test suite that can target both implementations, providing exhaustive (99.7%) code coverage for both. This suite is included with the open source release of the Swift interpreter. Then, to represent real-world workloads, we used a fuzzer to minimize a corpus of 10 million PDF files down to 4,200 without any loss of code coverage. The documents in the minimized corpus embedded 25,572 fonts with a total of 27 million glyphs that we rendered using four different transformations each, comparing the resulting bitmaps against the reference interpreter. This gave us confidence in the new interpreter’s compatibility. By the end of the project, we wrote nearly four times as many lines of test code as we wrote for the Swift interpreter itself. Achieving high performance Once our new implementation passed all its tests, we turned our attention to performance. We assessed performance at a high level using PDF render time, and then iterated on improvements guided by benchmarks that rendered all of the glyphs from three different fonts. These improvements fell into four main categories. Minimizing runtime overhead Swift uses automatic reference counting for managing the lifetime of shared reference types, and runtime exclusivity checking for preventing overlapping access to data structures. These sources of overhead are often exacerbated by aliasing, an irreducible amount of which existed in the interpreter’s specification by design. These sources of overhead can be eliminated by giving up the convenience of copyability, adopting ~Copyable value types (see also: struct instead of class) throughout the architecture, reserving reference types for high-level abstractions. Span, introduced in Swift 6.2 with back-deployment support all the way back to macOS 10.14.4 and iOS 12.2, allowed us to efficiently operate on sequences of these types. Moving data around Sometimes we want to change the “shape” of structured data when crossing language boundaries to better match the idioms on the other side. In Swift, glyph outlines are represented by a sequence of points, each of which carries a flag for whether it’s ‘on a curve’, flags for whether it’s been ‘touched’ on each axis, and three coordinate pairs: original (in the font’s base units), scaled (to the desired point size), and hinted (the interpreter program’s output). The original C code stored these points in one struct with eight arrays. This is good from a performance perspective because it’s cache-friendly: you can operate on a dimension of many points in long runs, which is fast. But exposing the data in Swift as a collection of point elements resulted in source code that was easier to follow. The initial cross-language bridging code we wrote prioritized expediency, safety, and simplicity by copying the glyph’s data from its C struct into Swift and then back after the program completed. Initially, those copies accounted for around 20% of the new interpreter’s runtime. In the end we wound up using projection types that provide safe access to the underlying C structure. Swift thus gives us readability without copying or otherwise transforming the underlying data structure. Following WebKit’s Safer Swift Guidelines, the example below demonstrates how to wrap a bridged structure from C in a projection type that uses Ref for lifetime safety, brokers bounds-safe access to the underlying data, and returns idiomatic Swift types to its callers. All unsafe expressions bear // SAFETY: comments that document the safety invariants and the reasoning which guarantees that they are true. @safe struct Zone: ~Copyable, ~Escapable { let _element: Ref<fnt_ElementType> @_lifetime(copy element) init(wrapping element: Ref<fnt_ElementType>) { // SAFETY: the `fnt_ElementType` passed by the caller must satisfy: // * `sp`, `ep` point at arrays of length ≥ `maxContourCount`. unsafe _element = element } func readContour(index: Int) -> ClosedRange<Int> { precondition(0..<contourCount ~= index) // SAFETY: `index` is bounds checked above; `_element.pointee.sp` and `_element.pointee.ep` // are live arrays of length `maxContourCount` per `init(wrapping:)` premises. return unsafe Int(_element.value.sp[index])...Int(_element.value.ep[index]) } } Short-lived allocations While runtime overhead imposes its costs in aggregate, and copying data across the language border showed up as a specific hot spot, the costs of short-lived memory allocations can show up in both ways. Operations like filter and map allocate memory, but that allocation is only necessary if the value escapes. The Swift standard library provides .lazy.map and .lazy.filter, but they don’t work in every case. For logic that only iterates over the filter or map, it’s much more efficient to loop with continue (or use for … in … where) and transform elements into local variables as necessary. Allocations that exist exclusively to pass results to a function’s caller can be elided too. For example, we often needed to pop the last n elements from the interpreter’s stack. The obvious implementation of this operation has to allocate space for the elements it returns (because the function simultaneously removes them) and looks something like: mutating func pop( count n: Int ) -> [Element] { defer { items.removeLast(n) } return Array(items.suffix(n)) } Optimizing this operation without compromising safety eventually led us to a continuation-passing approach where the caller passes a block that can operate on a slice of stack elements before they are removed. Swift’s compile-time exclusivity checking ensured that the stack could not be modified from inside the block, and the interface structurally eliminated any need for heap allocations or element copying. mutating func pop<R, E: Error>( count n: Int, _ op: (borrowing Span<Element>) throws(E) -> R ) throws(E) -> R { defer { items.removeLast(n) } return try op(items.span.extracting(last: n)) } Dynamic dispatch Abstraction mechanisms like protocols, generics, and inheritance are very powerful, but they introduce method-call indirection that may manifest at runtime as dynamic dispatch. This overhead can often be eliminated by the optimizer, but that is not possible in all conditions. In our case, not making abstractions more generic than necessary and encouraging the toolchain to inline were sufficient for the optimizer to hoist bounds checks and specialize all of our generic contexts. When you’re profiling your code, if you see unspecialized generics or protocol witness tables in hot paths, that’s a sign that the optimizer does not have sufficient visibility to optimize the call sites and that your implementation may benefit from inlining. Zero-cost abstractions At this point, anyone accustomed to grinding out performance improvements in a project might reasonably expect that our optimizations could come at the cost of readability, but in reality Swift’s type system and optimizer enabled us to employ abstractions that resulted in highly legible code. For example: FixedPoint types provided the same ergonomics as integral types, encapsulating complex rounding and shifting arithmetic. StackElement provided access to 32-bit values with built-in conversions for all eight of its supported numeric types. Our projection types provided safe and natural access to data that was not structured with those considerations in mind. Swift’s type system makes it possible to define powerful and expressive abstractions. When built with optimizations, all of our abstractions added zero cost while substantially improving readability. Memory-safe and faster than C Our goal for this project was to make the TrueType hinting interpreter fully memory-safe, to have the same observable rendering behavior as the C implementation, and to achieve a level of performance that did not regress any user-visible benchmarks. We met these goals. The Swift interpreter includes a small number of thoroughly verified unsafe statements at the language interop boundary; there have been no bugs reported against it since it was enabled; and it’s faster. On average, the Swift interpreter runs 13% faster than the C interpreter it replaced. Here is a chart showing the average CPU megacycles spent per glyph in the Swift implementation versus the C implementation for all of the hinted fonts that ship on macOS, plus a sampling of non-system fonts: ● System font · ● Non-system font · below the line: Swift faster · above: C faster Despite the overall performance improvement, we did not optimize everything! All of the new interpreter’s internal state was written in terms of noncopyable structures that were borrowed by its operations, but the top-level type itself is an @objc class that gets called across a module boundary from an Objective-C++ file. The hot paths are fast, and the cold paths are convenient. Swift in practice The Swift language made this project possible. Swift is memory-safe, has great ergonomics, and can be as fast as carefully written C. This makes it an excellent language for both application and systems development. Code using noncopyable types, value types, and Span is both safe and fast by default, and module-private types can be used to collectively define an architecture at no additional cost. Together with exhaustive test coverage, these well-defined internal interface boundaries make refactoring substantially easier, which in turn accelerates the measure-and-fix optimization loop while minimizing the risk of introducing bugs. This migration effort has deepened our Swift expertise and given us a foundation to build on. After completing the migration, we distilled what we learned into instructions for LLM coding assistants, and have since used them successfully in other projects. LLMs have improved the efficiency of our team’s work converting C/C++ to Swift, and have proven valuable in performing the kind of code transformations used in this effort. To accompany this post, we’ve published the source code for the Swift TrueType hinting interpreter on GitHub. This is production code, intended as a reference implementation rather than an ongoing open source project. We hope seeing how these techniques work in practice helps others achieve similar results.

• Swift.org · rss:a76d8c3e94eba61fc46b5cc05fc51e5f6df1d0f46d901d32e9c27bb251f155ae:swift-blog:8 · swift.org ↗ · 发布：2026-04-08T10:00:00+00:00 · 采集：2026-09-17T07:07:56.208180+00:00

You can now write Swift in a broader range of popular IDEs, including Cursor, VSCodium, AWS’s Kiro, and Google’s Antigravity. By leveraging VS Code extension compatibility, these editors tap directly into the Open VSX Registry, where the official Swift extension is now live. Swift has long supported development using multiple IDEs including VS Code, Xcode, Neovim, and Emacs. Swift is also compatible with editors that implement the Language Server Protocol (LSP). This growing ecosystem of editor support is particularly significant as Swift continues to show its versatility across platforms and development environments, including agentic IDEs. Swift on Open VSX The Swift extension for VS Code is now officially available on the Open VSX Registry, the vendor-neutral, open source extension registry hosted by the Eclipse Foundation. The extension adds first-class language support for projects built with Swift Package Manager, enabling seamless cross-platform development on macOS, Linux, and Windows. This milestone brings Swift support, including code completion, refactoring, full debugging support, a test explorer, as well as DocC support, to a broader ecosystem of compatible editors and allows agentic IDEs like Cursor and Antigravity to automatically install Swift, with no manual download required. Swift in Cursor, powered by the Swift extension on Open VSX. Get Started To start using the Swift extension in any Open VSX-compatible editor, simply open the Extensions panel, search for ‘Swift’ and install the extension. If you’re using Cursor, getting started is easier than ever. Check out our new dedicated guide: Setting up Cursor for Swift Development. It walks you through the setup, features and includes how to configure custom Swift skills for your AI workflows. Swift now has support for a wider range of modern editors and IDEs to meet developers where they are. Download the extension, try it out in your editor of choice, and don’t forget to share your feedback!

• Swift.org · rss:a76d8c3e94eba61fc46b5cc05fc51e5f6df1d0f46d901d32e9c27bb251f155ae:swift-blog:3 · swift.org ↗ · 发布：2026-02-20T10:00:00+00:00 · 采集：2026-09-17T07:07:56.208180+00:00

We are excited to announce the 1.0 release of Swift System Metrics, a Swift package that collects process-level system metrics like CPU utilization time and memory usage. Swift System Metrics runs on both Linux and macOS, providing a common API across platforms. Swift System Metrics visualized in Grafana, demonstrating what's possible with real-time monitoring. Monitoring process metrics enables you to detect performance issues, optimize resource usage, and ensure your service remains reliable and cost-effective under varying loads. You can integrate Swift System Metrics into your service in just a few lines of code, making observability accessible to every developer and ensuring that even the smallest services can have production-grade visibility from day one. Swift System Metrics is part of a larger set of packages that provide an end-to-end solution for integrating metrics into your Swift applications and services. Once system metrics are collected, they’re reported to Swift Metrics, a backend-agnostic metrics API that can work with popular backends like Prometheus and OpenTelemetry. Swift System Metrics also leverages Swift Service Lifecycle to handle process bootstrapping and resource cleanup. With the 1.0 milestone, the API is now stable and ready for use. Note that this package was previously swift-metrics-extras, and renamed to better reflect its purpose. Highlights Collects and reports: CPU utilization time Virtual and resident memory usage Open and maximum available file descriptors Process start time API-stable public interface Support on both Linux and macOS musl libc compatibility The package includes an example Grafana dashboard configuration to start visualizing metrics immediately. Get Started Add the dependency to your Package.swift: .package(url: "https://github.com/apple/swift-system-metrics", from: "1.0.0") Add the library dependency to your target: .product(name: "SystemMetrics", package: "swift-system-metrics") Import and use in your code: import SystemMetrics import ServiceLifecycle import Logging import OTel @main struct Application { static func main() async throws { // Create a logger, or use one of the existing loggers let logger = Logger(label: "Application") // Setup MetricsSystem, for example using swift-otel var otelConfig = OTel.Configuration.default otelConfig.serviceName = "Application" let otelService = try OTel.bootstrap(configuration: otelConfig) // Setup your service let service = FooService() // Create the monitor let systemMetricsMonitor = SystemMetricsMonitor(logger: logger) // Create the service let serviceGroup = ServiceGroup( services: [otelService, service, systemMetricsMonitor], gracefulShutdownSignals: [.sigint], cancellationSignals: [.sigterm], logger: logger ) try await serviceGroup.run() } } The complete documentation is available on Swift Package Index. Get Involved We’re looking for contributions to grow the list of process metrics collected and to expand platform support. PRs are welcome - our contribution guidelines describe how to get started. By reaching 1.0, this project will maintain a backwards-compatible API as it continues to evolve. Thanks to everyone who contributed to this release.

• Swift.org · rss:a76d8c3e94eba61fc46b5cc05fc51e5f6df1d0f46d901d32e9c27bb251f155ae:swift-blog:5 · swift.org ↗ · 发布：2026-03-06T11:00:00+00:00 · 采集：2026-09-17T07:07:56.208180+00:00

TelemetryDeck is an app analytics service specifically for developers, designed to manage usage analytics that are anonymized, privacy-focused, and really easy to use. TelemetryDeck is managing the data of over 16 million people every month, helping thousands of app publishers improve their products, and we’re doing it all with a Swift-based infrastructure. The decision to go with Swift brought a lot of unexpected advantages for us. We come from a world of iOS in the frontend, Python, Node, or Ruby in the backend for server-based applications. Compared to these languages and frameworks, Swift is just as easy to use, and its compiled nature allows us to catch a lot of possible errors at compile time instead of runtime, making it ideal for a hardened, high-performance web service. Let me share our journey and history with you. Adopting Swift for backend services TelemetryDeck is built on Vapor, a web framework written in Swift, for building scalable APIs and services. Similar to other Vapor-based projects like Things, TelemetryDeck runs on containers hosted in Kubernetes. Our metadata lives in Postgres, and our analytics data is stored in Apache Druid. We use Swift-native connectors to access APIs for these services. Some of those come from the Swift community, others we’ve written ourselves and are giving back to the open source ecosystem. In the very beginning, when TelemetryDeck was just a little exploratory hobby project, we wanted to go with Swift on the server simply because we love Swift, and we’re pretty decent at it. Vapor was new, and we figured, let’s try this out and learn a new way to apply and combine our skills. In the end, this decision turned out to be exactly the right one and resulted in a lean architecture that is highly performant, stable, and allows us to develop and iterate quickly. Swift’s performance characteristics are remarkable, especially in multithreading. Python’s Global Interpreter Lock has long constrained true parallelism, though recent versions have improved this. Swift doesn’t face that same challenge. Our infrastructure handles 16 million users per month with resources that would buckle other architectures. The efficiency gains aren’t just theoretical — they translate directly to lower infrastructure costs and a better user experience. Swift’s Codable protocol In an API-based application, you spend an enormous amount of time encoding and decoding JSON. Swift’s Codable protocol turns what’s traditionally error-prone boilerplate into straightforward, type-safe operations. When a request comes in with malformed data, Swift’s type system rejects it immediately with no manual validation required. This isn’t just convenient; it’s a security feature that prevents entire classes of vulnerabilities. struct Notebook: Codable, Content { let appID: UUID var snapshots: [NotebookSnapshot] let createdAt: Date let title: String } With just these few lines, we get parsing, validation, and type safety. Just like the postal system – which only accepts letters addressed in a specific format – the API endpoint described in the above bit of code will reject any data that doesn’t fit into this Codable. We don’t have to check for types, additional properties, or JSON validity, something that lets us trust our APIs more when developing and sleep easy after deploying. “Just lick the stamp and send it,” as a friend of mine once encouraged me. Sharing Data Transfer Objects between Client and Server For a long time, TelemetryDeck offered a SwiftUI-based desktop application for interacting with analytics data, displaying dashboards, and exploring correlations. This meant we could use the same structs for encoding data on the server and decoding it on the client – these are called Data Transfer Objects or DTOs. We kept a separate package “SwiftDTOs” that was shared between both clients and the server code. However, we ran into trouble when we updated our APIs to new versions with slightly different inputs and outputs. We always have the API version in our paths, which helps us continuously develop them while keeping compatibility with clients that take a while to update. This pattern made it hard to update Data Transfer Objects quickly because changing a struct for one API version could break another. For our newest API version, we abandoned this approach. DTOs now live directly in their controllers as inline structs: extension V3QueryController { struct QueryRequest: Codable { let query: QueryDefinition let timeRange: TimeRange } struct QueryResponse: Codable { let results: [QueryResult] let metadata: ResponseMetadata } } The lesson? Keep your DTOs close to your controllers. It’s simpler, more maintainable, and makes changes easier. Sometimes the obvious solution is the right one. Developer experience matters One underappreciated aspect of Swift on the server is the development experience. Swift services can be developed using your favorite IDE, including VS Code, Cursor, Xcode, and editors supporting the Language Server Protocol (LSP). We chose to develop in Xcode, our favorite IDE, with full debugging capabilities. Under the hood, a Swift Vapor project is just a Swift Package with some dependencies. You open it in Xcode, you press Cmd+U to run the tests, you run it and set breakpoints and step through them when you’re following a bug through the stack. Our web API services usually have a database attached to them, so when we’re developing, we can either run PostgreSQL on our machines right next to the code, or we can ask Swift Vapor’s database layer (Fluent) to use a different database for development, such as a local SQLite file. The end result is a very comfortable experience that allows us to use an IDE specifically built for Swift development, without needing to spin up containers. This flexibility matters when you’re building a business. We can onboard new developers quickly because the tooling is familiar. We can iterate rapidly because the feedback loop is tight. And we can maintain high code quality because Swift’s type system catches errors at compile time, not in production. Building the ecosystem we want to use We love the open source ecosystem around Swift on the server. There are Swift packages for external services like payment providers and transactional emails. There are tools like Imperial for Single Sign-On, and Swift Crypto for standards-compliant cryptography. Whenever a piece of the puzzle is missing, we try to give back as much as possible. That is partly because the Swift developer community is fantastic in coming up with SDKs for various services, and we try to contribute to existing projects like StripeKit (where we added support for a lot of APIs that Stripe released) or even release our own new SDKs like BrevoKit. Lessons learned Building a production service teaches you things that tutorials never will. Here are some hard-won lessons from our journey: Use the Swift Package system. A package is a fantastic way to structure and isolate code. Since our services are packages anyway, it’s natural to further subdivide them where it makes sense. Your Swift Vapor service is almost never the bottleneck. Although profiling Swift code is easy, most slowdowns in a web service will arise from a combination of database, storage, and traffic load. You’ll migrate the way you store and access data frequently as you gain experience. Embrace Vapor’s built-in features. Queues and jobs, migrations, and middleware. Vapor has mature solutions for common patterns. We use Fluent almost exclusively over raw SQL, and Vapor’s queue system handles everything from data processing to billing tasks. Version your API URLs from day one. You’ll thank yourself later when you need to evolve your API without breaking existing clients. Always set cache expiration times. It sounds obvious, but that Redis cache that “will never grow too large” absolutely will. Set reasonable TTLs on everything that you cache. Monitor errors and performance. When you build an iPhone app, you automatically get crash logs that help you find out where things are going wrong for your users. On the server, you’ll have to collect those yourself. Before we started doing that, our customers would discover problems before we did, and that never feels good or professional. Now we use a combination of Swift Distributed Tracing and our own analytics-based middleware to find performance bottlenecks and errors that are predictors of service crashes, and we can right the ship before most of our customers notice. Where we are now TelemetryDeck proves that Swift isn’t just for apps — it’s a legitimate choice for building scalable, performant backend services. We’re processing millions of events, serving thousands of developers, and doing it all with Swift and Vapor. The language that powers apps on billions of iOS devices is equally capable of powering the services behind them. The performance gains are real: we can crunch and encode tens of thousands of data points in milliseconds. The development velocity is fantastic: we work in Xcode and write tests for behaviour and not for data parsing. And the type safety prevents entire categories of bugs that dynamically typed languages like Python or JavaScript need additional code to guard against. Perhaps most importantly, the joy of writing Swift makes the long hours of building a business more bearable. If you’re considering Swift for your next server-side project, take it from someone who’s built an entire business on it: Swift delivers on its promise of safe, fast, and expressive code—whether that code runs on an iPhone or in a data center.

• chatgpt · x:chatgpt:user:chatgpt:2098457932438577407 · x.com ↗ · 发布：2026-09-11T17:05:33+00:00 · 采集：2026-09-17T07:53:54.198192+00:00

An interactive visual story about AI, emotional connection, and whether an encounter can feel meaningful. 
https://t.co/g8gjwUVt1G https://t.co/G6VtbQb1YF

• moondustkk · x:x-following:following:moondustkk:2100523900194955737 · x.com ↗ · 发布：2026-09-17T09:54:58+00:00 · 采集：2026-09-17T10:00:33.310291+00:00

Ninth woman's body found as South African police investigate string of deaths https://t.co/rIntfNdh6B

• moondustkk · x:x-following:following:moondustkk:2100522808824447372 · x.com ↗ · 发布：2026-09-17T09:50:38+00:00 · 采集：2026-09-17T10:00:37.828489+00:00

Investors have been betting the Federal Reserve is at the start of a series of interest-rate increases. On Wednesday, Chairman Kevin Warsh gave them little reason to think otherwise. https://t.co/mCeYzo7ACY

• moondustkk · x:x-following:following:moondustkk:2100519414974083258 · x.com ↗ · 发布：2026-09-17T09:37:08+00:00 · 采集：2026-09-17T10:00:42.408090+00:00

The Defense Department issued a legal waiver authorizing current and former personnel to share unidentified anomalous phenomena–related classified information, but it doesn’t extend to other agencies. https://t.co/vXBiYBQ9hO

• moondustkk · x:x-following:following:moondustkk:2100518975268393211 · x.com ↗ · 发布：2026-09-17T09:35:24+00:00 · 采集：2026-09-17T10:00:47.084728+00:00

Controversy around OpenAI’s claim to have solved the Navier–Stokes problem highlights how researchers could be inadvertently sharing — and absorbing— ideas through chatbots.

https://t.co/jLBE5nI8P5

• moondustkk · x:x-following:following:moondustkk:2100518972504322232 · x.com ↗ · 发布：2026-09-17T09:35:23+00:00 · 采集：2026-09-17T10:00:51.253984+00:00

Indonesia faces reckoning over maritime safety after deadly ferry disaster https://t.co/E0yripQTK7

• moondustkk · x:x-following:following:moondustkk:2100517655824179594 · x.com ↗ · 发布：2026-09-17T09:30:09+00:00 · 采集：2026-09-17T10:00:55.890701+00:00

Here is an early look at the front page of today's Wall Street Journal https://t.co/Dd6hDFtvQ7 https://t.co/QUeOpdyhFi

• moondustkk · x:x-following:following:moondustkk:2100513984302530822 · x.com ↗ · 发布：2026-09-17T09:15:34+00:00 · 采集：2026-09-17T09:20:04.225754+00:00

RT @Plinz: I wish people would notice that the safety scare is not driven by people outside of the big labs, but directly from their leader…

• moondustkk · x:x-following:following:moondustkk:2100513896050114708 · x.com ↗ · 发布：2026-09-17T09:15:13+00:00 · 采集：2026-09-17T09:20:08.483352+00:00

RT @stevesi: Our framework for reporting model misalignment https://t.co/o1gVtyTWkk // if you scrape away all the anthropomorphic language,…

• moondustkk · x:x-following:following:moondustkk:2100513670719508510 · x.com ↗ · 发布：2026-09-17T09:14:19+00:00 · 采集：2026-09-17T09:20:12.824227+00:00

Hyrox Beijing athletes get full refund, new rule on hygiene risks comes into force https://t.co/4o18CFeFlU

• moondustkk · x:x-following:following:moondustkk:2100513440640962649 · x.com ↗ · 发布：2026-09-17T09:13:24+00:00 · 采集：2026-09-17T09:20:17.233095+00:00

Hyrox Beijing athletes get full refund, new rule on hygiene risks comes into force https://t.co/i8YM2581XM

• moondustkk · x:x-following:following:moondustkk:2100511286979170498 · x.com ↗ · 发布：2026-09-17T09:04:51+00:00 · 采集：2026-09-17T09:20:21.704992+00:00

Flock reveals little about where its license plate readers are assembled, but the answer could have geopolitical and cybersecurity implications. https://t.co/gIx0Tf4Bso

• moondustkk · x:x-following:following:moondustkk:2100511255299489996 · x.com ↗ · 发布：2026-09-17T09:04:43+00:00 · 采集：2026-09-17T09:20:25.590710+00:00

Taipei donates coastguard vessel to Manila amid South China Sea tensions https://t.co/kUMBMqCG1d

• moondustkk · x:x-following:following:moondustkk:2100508056249327648 · x.com ↗ · 发布：2026-09-17T08:52:00+00:00 · 采集：2026-09-17T09:20:29.944510+00:00

This ingenious experiment shows how a virus's protein shell is assembled

https://t.co/K8iJiXJelz

• moondustkk · x:x-following:following:moondustkk:2100505776145997956 · x.com ↗ · 发布：2026-09-17T08:42:57+00:00 · 采集：2026-09-17T09:20:34.376560+00:00

Algae bloom that crippled Israel's desalination plants raises water security concerns https://t.co/thrO8vwUAY

• moondustkk · x:x-following:following:moondustkk:2100505213815673143 · x.com ↗ · 发布：2026-09-17T08:40:43+00:00 · 采集：2026-09-17T09:20:38.777744+00:00

One dead after torrential rain and flash floods hit Barcelona region https://t.co/ItY3ROSX1N

• moondustkk · x:x-following:following:moondustkk:2100502653977407679 · x.com ↗ · 发布：2026-09-17T08:30:32+00:00 · 采集：2026-09-17T09:20:43.109148+00:00

The tragic Qing politician whose legacy lives on in descendant’s new novel https://t.co/a2EKmnGVMe

• moondustkk · x:x-following:following:moondustkk:2100502521487741153 · x.com ↗ · 发布：2026-09-17T08:30:01+00:00 · 采集：2026-09-17T09:20:47.421508+00:00

Nature research paper: Mitochondrial fission factor senses and governs ferroptosis

https://t.co/WsvgjYyRI1

• moondustkk · x:x-following:following:moondustkk:2100502419079586052 · x.com ↗ · 发布：2026-09-17T08:29:36+00:00 · 采集：2026-09-17T09:20:51.563390+00:00

Trump presses Xi on fentanyl precursors ahead of Washington summit https://t.co/PZdOos5gRf

• moondustkk · x:x-following:following:moondustkk:2100501808451821705 · x.com ↗ · 发布：2026-09-17T08:27:11+00:00 · 采集：2026-09-17T09:20:56.013571+00:00

EU announces plan to restrict social media access for children https://t.co/MH2DZ6Xrym

• moondustkk · x:x-following:following:moondustkk:2100501250009686419 · x.com ↗ · 发布：2026-09-17T08:24:58+00:00 · 采集：2026-09-17T09:21:02.584504+00:00

True

• moondustkk · x:x-following:following:moondustkk:2100499084029112669 · x.com ↗ · 发布：2026-09-17T08:16:21+00:00 · 采集：2026-09-17T09:21:06.806685+00:00

‘Depraved’ Singaporean paedophile who abused daughter, granddaughters, jailed https://t.co/cpMX6LCpUc

• moondustkk · x:x-following:following:moondustkk:2100498967670767936 · x.com ↗ · 发布：2026-09-17T08:15:53+00:00 · 采集：2026-09-17T09:21:11.117011+00:00

India's biggest stock exchange launches mega share sale https://t.co/ECX5tcJ8NE

• moondustkk · x:x-following:following:moondustkk:2100486538777837835 · x.com ↗ · 发布：2026-09-17T07:26:30+00:00 · 采集：2026-09-17T09:21:19.431423+00:00

Philippines’ Teodoro draws 2028 election buzz after China clash https://t.co/Rkt1OKC45h

• moondustkk · x:x-following:following:moondustkk:2100484237929406710 · x.com ↗ · 发布：2026-09-17T07:17:22+00:00 · 采集：2026-09-17T09:21:24.286664+00:00

Trump threatens 'serious tariffs' on EU over proposal to make Canada 'associate member' https://t.co/ztDaUohAvL

• chatgpt · x:chatgpt:user:chatgpt:2098535078573875646 · x.com ↗ · 发布：2026-09-11T22:12:06+00:00 · 采集：2026-09-17T07:53:30.962545+00:00

RT @adamhfry: This week's ChatGPT feature drop - Sept 11:

1/ We upgraded ChatGPT Images: it's much faster, more precise at edits, and bett…

• chatgpt · x:chatgpt:user:chatgpt:2098533675050672134 · x.com ↗ · 发布：2026-09-11T22:06:31+00:00 · 采集：2026-09-17T07:53:37.794355+00:00

Your pet has a job now.

Pets help you keep track of your chats while you’re away from the desktop app. Now, you can start a new chat right from your pet, too.

Not a pet person? Meet Mini: the same shortcuts and updates, taking up less space on your screen.

Pick your pet—or go Mini—in the ChatGPT desktop app settings.

• chatgpt · x:chatgpt:user:chatgpt:2098519342530920488 · x.com ↗ · 发布：2026-09-11T21:09:34+00:00 · 采集：2026-09-17T07:53:44.185733+00:00

GPT-VI ASTRA https://t.co/qtCb31sUhc

• chatgpt · x:chatgpt:user:chatgpt:2098457925459349913 · x.com ↗ · 发布：2026-09-11T17:05:31+00:00 · 采集：2026-09-17T07:54:28.692562+00:00

A browser-based 3D coloring experience where you can rotate, paint, and personalize models directly on their surfaces.

https://t.co/BHpTLtJWcs https://t.co/nUJbXmb3Cc

• chatgpt · x:chatgpt:user:chatgpt:2098457921676083585 · x.com ↗ · 发布：2026-09-11T17:05:30+00:00 · 采集：2026-09-17T07:54:34.013986+00:00

Here are some ways to get started with Sites if you’re  looking for inspiration:

- Launch dashboards to track and share results

- Personal portfolios to help your work stand out

- Onboarding hubs to help new teammates get up to speed

- Games (like trivia!) for your friend’s birthday party

- Maps of your favorite local spots for out-of-town visitors

- Trip itineraries to get everyone on the same page

• chatgpt · x:chatgpt:user:chatgpt:2098457920291946894 · x.com ↗ · 发布：2026-09-11T17:05:30+00:00 · 采集：2026-09-17T07:54:40.439714+00:00

Three months ago, we launched ChatGPT Sites – an easy way for anyone to build and host fully functional, interactive web apps. Since then, people have created over 5M sites.

We’ve been listening to your feedback and ICYMI, we’ve launched a few Sites updates:

🫂 Build together: Invite teammates to edit, save, and publish to your shared Site

🔐 Share privately: Invite specific people to a private Site without making it public

🚀 Launch faster: Go from prompt to deployment in half the time

👀 Explore your data: Ask ChatGPT to inspect your Site’s database. Editors can view it, too

🌐 Add your own custom domain

• chatgpt · x:chatgpt:user:chatgpt:2098457929091580020 · x.com ↗ · 发布：2026-09-11T17:05:32+00:00 · 采集：2026-09-17T07:54:04.600190+00:00

A theatrical calculator that turns arithmetic into a spectacle of dramatic effects and sound. 

https://t.co/9C0XjWB1kL https://t.co/XWaCs5trGi

• chatgpt · x:chatgpt:user:chatgpt:2098457927195758950 · x.com ↗ · 发布：2026-09-11T17:05:31+00:00 · 采集：2026-09-17T07:53:59.413974+00:00

A live-style change log that brings together earthquakes, space weather, and regional alerts. 
https://t.co/t6xx1qBAjD

• chatgpt · x:chatgpt:user:chatgpt:2098457930807091480 · x.com ↗ · 发布：2026-09-11T17:05:32+00:00 · 采集：2026-09-17T07:53:49.379620+00:00

A shared Japanese word-chain game where each new word continues the previous word’s ending.

https://t.co/pv1XjGyhss

• chatgpt · x:chatgpt:user:chatgpt:2098457923475411241 · x.com ↗ · 发布：2026-09-11T17:05:31+00:00 · 采集：2026-09-17T07:54:23.410304+00:00

We love what you've been building, here a few you've shared with us:

A cozy pixel-art game for exploring small worlds, collecting creatures, and caring for virtual pets. 
https://t.co/r3AC4XpcHk https://t.co/GBLHSeJS73

• chatgpt · x:chatgpt:user:chatgpt:2098141242911785452 · x.com ↗ · 发布：2026-09-10T20:07:08+00:00 · 采集：2026-09-17T07:54:45.265254+00:00

RT @ebloch: Stock watchlist rolling out in ChatGPT + Finances for US Plus/Pro! 

Tell Chat what stocks to follow. It’ll keep an eye on what…

• chatgpt · x:chatgpt:user:chatgpt:2098135108092076424 · x.com ↗ · 发布：2026-09-10T19:42:45+00:00 · 采集：2026-09-17T07:54:50.388166+00:00

RT @thsottiaux: To make sure our current users have an incredible experience and continued access to Astra, we are going to pause subscript…

• chatgpt · x:chatgpt:user:chatgpt:2098127115791294703 · x.com ↗ · 发布：2026-09-10T19:11:00+00:00 · 采集：2026-09-17T07:54:56.348305+00:00

And starting today, @Dropbox, @Box, and Sharepoint are now natively integrated into the ChatGPT Library across both ChatGPT and ChatGPT Work.

Rolling out this week to paid users. https://t.co/qeWFv9PSwG

• chatgpt · x:chatgpt:user:chatgpt:2098065296968011853 · x.com ↗ · 发布：2026-09-10T15:05:21+00:00 · 采集：2026-09-17T07:55:03.220333+00:00

Now everyone can put data to work.

We’re introducing a new Data agent in ChatGPT Work so you can turn your company’s data into answers, interactive dashboards, and action—just by asking.

Just add the Data Plugin in ChatGPT Work, connect to the data sources and context you already use, and start the conversation. https://t.co/EG1nQFZfEU

• chatgpt · x:chatgpt:user:chatgpt:2097791572909687068 · x.com ↗ · 发布：2026-09-09T20:57:40+00:00 · 采集：2026-09-17T07:55:08.450399+00:00

RT @athyuttamre: 🌌 ChatGPT Voice can now use GPT-5.6 Sol and GPT-6 Astra

We’re updating how intelligence works in voice. Now, you can sele…

• chatgpt · x:chatgpt:user:chatgpt:2097776711853109252 · x.com ↗ · 发布：2026-09-09T19:58:37+00:00 · 采集：2026-09-17T07:55:14.074690+00:00

RT @nickbaumann_: Images 2.5 & Astra are a wonderful combination

(sound on) https://t.co/VFK7wqXgH9

• chatgpt · x:chatgpt:user:chatgpt:2097726297996705977 · x.com ↗ · 发布：2026-09-09T16:38:17+00:00 · 采集：2026-09-17T07:55:19.339552+00:00

RT @michpokrass: following up after astra launch week and the navier-stokes announcement i wanted to share a little bit about how we think…

{
  "event": "Perry Metzger质疑AI灭绝概率的计算依据",
  "facts": [
    "该内容是用户moondustkk转发的@perrymetzger推文。",
    "推文称，若有人表示AI有X%的概率毁灭人类，应要求对方说明得出该数字的计算过程。",
    "来源在“num”处截断，未给出具体概率、算式或进一步结论。"
  ],
  "new_information": [
    "这是一条针对AI灭绝风险概率声明的怀疑性评论，强调需要可检验的数学依据。",
    "原文被截断，因此无法确认作者后续是否给出了具体论证或案例。"
  ],
  "importance": 20,
  "personal_relevance": "它属于宏观AI风险讨论，不涉及AI coding agents或Apple开发工具，直接相关性较低。",
  "worth_monitoring": false
}

按冻结快照重建的来源文本，包含实际字符截断；不代表请求已成功送达。系统指令不在此展示，也没有逐句引用标注。

x:x-following:following:moondustkk:2100514258941276503
RT @perrymetzger: Any time someone tells you that AI has an X% chance of wiping out humanity, ask them for their math that got them the num…

兴趣配置

{
  "interests": {
    "very_high": [
      "AI coding agents",
      "Codex",
      "SwiftUI",
      "Swift",
      "Apple developer platform",
      "developer tools"
    ],
    "high": [
      "AI",
      "independent development",
      "productivity",
      "cognitive science"
    ],
    "low": [
      "generic AI hype",
      "cryptocurrency",
      "celebrity news"
    ]
  }
}

• moondustkk · x:x-following:following:moondustkk:2100514258941276503 · x.com ↗ · 发布：2026-09-17T09:16:39+00:00 · 采集：2026-09-17T09:19:59.780031+00:00

RT @perrymetzger: Any time someone tells you that AI has an X% chance of wiping out humanity, ask them for their math that got them the num…

{
  "event": "转发帖称Dario认同AI有逾10%概率发生某事",
  "facts": [
    "moondustkk转发了ArthurMacwaters的一条推文。",
    "原帖称Dario同意一名被描述为“ngo-coded physiognomy ‘whistleblower’”者的观点。",
    "可见原文为“AI has >10% chance of e…”，内容在“e”后截断，具体所指无法确认。"
  ],
  "new_information": [
    "社交媒体有帖称Dario认同AI相关事件概率超过10%。",
    "帖文对相关人士使用带立场色彩的描述，且关键句被截断。"
  ],
  "importance": 12,
  "personal_relevance": "与AI兴趣相关，但只是截断的转述，缺乏可核实的技术或产品信息。",
  "worth_monitoring": false
}

按冻结快照重建的来源文本，包含实际字符截断；不代表请求已成功送达。系统指令不在此展示，也没有逐句引用标注。

x:x-following:following:moondustkk:2100489640255869414
RT @ArthurMacwaters: Just to recap the last week 

- Dario agreed with a ngo-coded physiognomy “whistleblower” that AI has >10% chance of e…

兴趣配置

{
  "interests": {
    "very_high": [
      "AI coding agents",
      "Codex",
      "SwiftUI",
      "Swift",
      "Apple developer platform",
      "developer tools"
    ],
    "high": [
      "AI",
      "independent development",
      "productivity",
      "cognitive science"
    ],
    "low": [
      "generic AI hype",
      "cryptocurrency",
      "celebrity news"
    ]
  }
}

• moondustkk · x:x-following:following:moondustkk:2100489640255869414 · x.com ↗ · 发布：2026-09-17T07:38:50+00:00 · 采集：2026-09-17T09:21:15.311879+00:00

RT @ArthurMacwaters: Just to recap the last week 

- Dario agreed with a ngo-coded physiognomy “whistleblower” that AI has >10% chance of e…

{
  "event": "ChatGPT账号转发站点功能问询",
  "facts": [
    "来源为X上的一条转发，原帖作者为@simpsoka。",
    "转发内容询问：“我们在ChatGPT站点缺少哪些功能？应该添加什么？”",
    "来源未给出具体功能建议、官方回应、发布计划或产品决策。",
    "无法据此判断“ChatGPT sites”的具体范围，也无法确认相关账号是否代表官方。"
  ],
  "new_information": [
    "该内容属于开放式功能征集，而非功能上线或官方公告。",
    "来源未涉及AI编程代理、Codex、SwiftUI或Apple开发者工具的具体信息。"
  ],
  "importance": 15,
  "personal_relevance": "虽与AI和开发者工具兴趣弱相关，但没有具体可跟进的产品信息。",
  "worth_monitoring": false
}

按冻结快照重建的来源文本，包含实际字符截断；不代表请求已成功送达。系统指令不在此展示，也没有逐句引用标注。

x:chatgpt:user:chatgpt:2100299088847855819
RT @simpsoka: What features are we missing in ChatGPT sites? What should we add?

兴趣配置

{
  "interests": {
    "very_high": [
      "AI coding agents",
      "Codex",
      "SwiftUI",
      "Swift",
      "Apple developer platform",
      "developer tools"
    ],
    "high": [
      "AI",
      "independent development",
      "productivity",
      "cognitive science"
    ],
    "low": [
      "generic AI hype",
      "cryptocurrency",
      "celebrity news"
    ]
  }
}

• chatgpt · x:chatgpt:user:chatgpt:2100299088847855819 · x.com ↗ · 发布：2026-09-16T19:01:39+00:00 · 采集：2026-09-17T07:53:18.601309+00:00

RT @simpsoka: What features are we missing in ChatGPT sites? What should we add?

{
  "event": "巴西 Porto Feliz AMS 住宅项目",
  "facts": [
    "项目位于巴西 Porto Feliz 的原生林地环境中。",
    "建筑由三个顺应地势布置的体块组成。",
    "中央社交体块通过大幅玻璃板面向花园和泳池打开。",
    "夯土墙用于提供隐私并增强热稳定性。",
    "项目由 Jacobsen Studio 设计。",
    "来源带有 #ArchitizerAwards 标签并附详情链接，但未说明项目是否获奖。"
  ],
  "new_information": [
    "住宅以三个顺应地势的体块组织空间，中央社交区用大玻璃面连通花园与泳池。",
    "夯土墙被用于兼顾隐私与热稳定，设计方为 Jacobsen Studio。"
  ],
  "importance": 5,
  "personal_relevance": "该建筑项目与你关注的 AI 编程、Codex、SwiftUI 和开发者工具没有直接关联。",
  "worth_monitoring": false
}

按冻结快照重建的来源文本，包含实际字符截断；不代表请求已成功送达。系统指令不在此展示，也没有逐句引用标注。

x:x-following:following:moondustkk:2100525213326672225
#ArchitizerAwards

Set against native forest in Porto Feliz, AMS House is organized as three volumes stepping with the terrain. The central social block opens through large glass panels toward the garden and pool, while rammed-earth walls provide privacy and thermal stability.

📍 Porto Feliz, Brazil
Project by: Jacobsen Studio
Details: https://t.co/8VZHtbqD9G

兴趣配置

{
  "interests": {
    "very_high": [
      "AI coding agents",
      "Codex",
      "SwiftUI",
      "Swift",
      "Apple developer platform",
      "developer tools"
    ],
    "high": [
      "AI",
      "independent development",
      "productivity",
      "cognitive science"
    ],
    "low": [
      "generic AI hype",
      "cryptocurrency",
      "celebrity news"
    ]
  }
}

• moondustkk · x:x-following:following:moondustkk:2100525213326672225 · x.com ↗ · 发布：2026-09-17T10:00:11+00:00 · 采集：2026-09-17T10:00:24.061406+00:00

#ArchitizerAwards

Set against native forest in Porto Feliz, AMS House is organized as three volumes stepping with the terrain. The central social block opens through large glass panels toward the garden and pool, while rammed-earth walls provide privacy and thermal stability.

📍 Porto Feliz, Brazil
Project by: Jacobsen Studio
Details: https://t.co/8VZHtbqD9G

{
  "event": "南瓜香料消费省钱建议帖",
  "facts": [
    "社交来源中的帖子建议保持每日南瓜香料消费习惯，同时避免在星巴克过度消费。",
    "帖子附有一个短链接，但来源未展示链接目标的具体内容，无法确认实际省钱方式。"
  ],
  "new_information": [
    "该帖将日常南瓜香料消费与替代星巴克的省钱建议联系起来。",
    "具体方案、价格或优惠信息未在可见文案中提供。"
  ],
  "importance": 5,
  "personal_relevance": "属于生活消费内容，与你关注的AI、开发工具和独立开发等方向无关。",
  "worth_monitoring": false
}

按冻结快照重建的来源文本，包含实际字符截断；不代表请求已成功送达。系统指令不在此展示，也没有逐句引用标注。

x:x-following:following:moondustkk:2100525202274738597
Keep your daily pumpkin spice habit going without overspending on Starbucks. https://t.co/mtusi7KLL1

兴趣配置

{
  "interests": {
    "very_high": [
      "AI coding agents",
      "Codex",
      "SwiftUI",
      "Swift",
      "Apple developer platform",
      "developer tools"
    ],
    "high": [
      "AI",
      "independent development",
      "productivity",
      "cognitive science"
    ],
    "low": [
      "generic AI hype",
      "cryptocurrency",
      "celebrity news"
    ]
  }
}

• moondustkk · x:x-following:following:moondustkk:2100525202274738597 · x.com ↗ · 发布：2026-09-17T10:00:08+00:00 · 采集：2026-09-17T10:00:28.777722+00:00

Keep your daily pumpkin spice habit going without overspending on Starbucks. https://t.co/mtusi7KLL1