Foundation's Swift preview removes conversion work from common types

Foundation's cross-platform problem includes the implementation beneath an API. Matching type names do not guarantee matching behavior when separate implementations evolve on different platforms. Conversion between Swift values and older representations also imposes work that a Swift caller cannot see in the declaration it uses.

The April 26 preview announcement makes the first parts of a unified Swift implementation available on GitHub. This is an incomplete package intended for early testing and contributions. It depends on the under-development Swift 5.9 toolchain, so it is not a library that every user of the current stable compiler can immediately substitute into an application.

I find Swift's value semantics one of its strongest design choices. Foundation's preview is interesting because it applies those semantics within the implementation of widely used types. The benefit depends on how the library performs its work, even when an application's visible model stays familiar.

The original portability strategy

Tony Parker's December 2022 design announcement describes the history behind the rewrite. The swift-corelibs-foundation project helped bring Foundation to open-source Swift in 2016 by placing a Swift layer around an existing open-source C implementation. That approach gave the language an important part of its supporting library ecosystem.

The new project changes that strategy. Its stated goals include avoiding wrapped C code, permitting smaller packages, and establishing a canonical implementation across platforms. It also seeks to make the implementation easier for Swift developers to inspect and modify.

Those goals are related, but they solve different problems. A Swift implementation can reduce representation conversions in a hot operation. Shared implementation code can reduce behavioral divergence. Smaller library divisions can reduce dependencies for applications that need only a subset of Foundation. None of those outcomes follows merely from publishing the same public type names on multiple platforms.

The preview is the point at which contributors can begin evaluating that design in code. The December announcement described the intended structure. April provides the first available building blocks, while making clear that the replacement is not yet complete.

What is present in the first preview

The April announcement lists core types including Data, Date, DateInterval, AttributedString, UUID, and JSON encoding and decoding. Predicate and String extensions are also among the available pieces. The internationalization portion includes Calendar, TimeZone, Locale, and DateComponents, together with formatting and parsing facilities.

Several implementations are new Swift code, including JSONEncoder, Calendar, TimeZone, and Locale. FormatStyle and ParseStyle are becoming available as open source for the first time, according to the announcement. That makes the preview relevant to both runtime behavior and the ability to study or contribute to the implementation.

The scope limits are just as concrete. Porting URL, Bundle, FileManager, FileHandle, Process, and sorting-related APIs is work planned for later in the year. An application that needs those types cannot infer completeness from the Foundation name. The available subset defines what this preview can exercise.

This is why I regard it as an implementation preview with a specific technical audience. Library maintainers and contributors can inspect common operations and help refine the package. An application developer needs to distinguish those experiments from replacing all Foundation dependencies in an existing program.

Smaller dependencies require library boundaries

The December plan separates FoundationEssentials from internationalization. The essentials package is intended to supply the important basic types without system dependencies. FoundationInternationalization handles localized content such as date and time formatting.

That division follows an actual difference in required behavior. Storing a date value and producing a localized representation of that date do not require the same supporting data. A program may need to pass basic values through a computation without needing the internationalization machinery used to present those values to a person.

The earlier plan also describes separate support for XML and networking, and a compatibility package for legacy Objective-C APIs. These are architectural intentions in the design announcement, not a statement that every planned package or API is finished in April.

Keeping that distinction visible matters for interpreting the preview. Smaller packages are useful when their dependencies correspond to real application needs. The package names alone cannot establish the final binary size of a particular program, and the announcement does not provide such a universal size claim.

Internationalization includes shared data

For non-Darwin internationalization, the project introduces FoundationICU. The April announcement says it contains the required ICU implementation and data from Apple's open-source distribution. Sharing a common ICU version is intended to produce more reliable and consistent formatting of dates, times, and numbers.

This addresses a portability problem beyond translating library source. Formatting behavior depends on the supporting internationalization implementation and its data. If two platforms use different underlying inputs, a common Swift wrapper cannot by itself guarantee that their formatted results agree.

The project's response is to control more of that dependency explicitly. Shared Foundation code and the common ICU version work together toward the consistency goal across the supported platforms. The announcement does not claim that the preview has already eliminated every cross-platform difference.

For an API consumer, this is a useful explanation of why a formatting library carries more than algorithms. Its data is part of observable behavior. A shared implementation needs a strategy for that data as well as for the methods that call into it.

Where the performance improvements come from

The preview announcement attributes improvements in Locale, TimeZone, and Calendar partly to removing Objective-C bridging. A fixed Locale lookup is one example where the announcement reports an order-of-magnitude improvement for Swift clients. The relevant mechanism is avoiding conversion work that the previous implementation required.

Calendar calculations also use value semantics to avoid intermediate allocations. The announcement reports improvements above 20 percent in some benchmarks. That result describes the tested calendar operations, so it should not be treated as the expected gain for every program that happens to import Foundation.

Date formatting through FormatStyle has its own reported benchmark improvement. That is a separate operation with a separate measurement. The announcement's measurements show promising consequences of the design, but they are not interchangeable estimates for an application's total execution time.

JSON encoding and decoding provide another clear mechanism. The new implementation removes round trips through Objective-C collection types. It also integrates Swift JSON parsing more closely with initialization of Codable types.

That second change matters because representation conversion is only part of decoding. Parsing has to produce the values that the decoding protocol expects. Integrating those steps gives the implementation opportunities that a pipeline through intermediate collections may not have.

The announcement reports substantial decode-time improvements on its linked test data. It does not establish an equivalent improvement for every payload shape or every custom Codable implementation. The defensible conclusion is narrower and more informative, since these particular intermediate representations and conversions are no longer required in the new implementation.

A public process for changing the library

The project also creates a Foundation Workgroup to review proposed APIs and coordinate community needs with Apple engineering. The April announcement describes Foundation as an independent project in early incubation. Its contribution process includes community proposals for new functionality.

That process is part of the portability design. A library intended for Swift developers across platforms needs a way to discuss requirements outside any single platform's implementation. Open code permits fixes, but an API proposal process permits discussion about which capabilities belong in the shared library.

The initial request is for focused proposals that complete existing functionality. The project aims to accept a small number during 2023, with corresponding Swift implementations, and use that experience to refine the review process. Larger expansion is therefore not the immediate priority.

Quality and performance work come first. The announcement identifies refinement of core APIs, more unit and performance tests, and expansion to additional platforms where possible. It also anticipates reusing relevant code from swift-corelibs-foundation.

The existing corelibs project has not been retired by this announcement. Exploring how to sunset it and migrate to the new implementation remains future work. That leaves an explicit transition problem alongside the code already available in the preview.

For the current preview, the most useful contributions connect a specific behavior to the shared implementation. A report about a date calculation, JSON decoding path, or internationalization result can help refine the code that is actually present. Proposed additions can follow the new review process while the project completes the foundational APIs still missing from this first package.