Foundation plans a shared Swift implementation with dependency boundaries

Splitting a library into one module per type can make each import look smaller while creating a larger set of public relationships to maintain. Foundation's proposed rewrite takes a different organizing principle. Its module boundaries follow external dependencies, so applications can avoid functionality that brings substantial additional runtime requirements without exposing every internal relationship as a public interface.

Tony Parker's December 9 announcement proposes an open-source Foundation written in Swift, with a shared implementation across platforms. It describes smaller packages and a contribution process for new APIs. The project launch is still ahead. Today's announcement establishes a direction and invites discussion, rather than supplying a replacement package ready to substitute into an existing application's dependencies.

I find Swift's language design coherent, particularly the explicit treatment of values and absence. Foundation's cross-platform story should support that coherence. A shared API whose behaviour depends on which implementation happens to run makes it harder to understand what a portable program actually promises.

The existing implementation has a different mandate

The swift-corelibs-foundation README in Swift 5.7 describes a Foundation implementation for platforms without an Objective-C runtime. On Apple platforms, applications use the operating system's Foundation. Corelibs aims for implementation parity and matching APIs, with documented differences where platform constraints make them necessary.

That arrangement has a historical reason. The README explains that Darwin Foundation is primarily Objective-C, while CoreFoundation is portable C code that does not require the Objective-C runtime. The open-source offering can use that C implementation beneath its Swift code. Parker's announcement describes corelibs as a Swift layer around preexisting open-source C functionality.

The new proposal changes that architecture. A Swift implementation would avoid the conversions involved in the wrapped C model, and the announcement identifies performance as a goal. It also aims to make the implementation easier for Swift developers to inspect and contribute to as a package. Neither statement supplies a benchmark for a particular application today.

The portability goal is also more specific than sharing declarations. Parker identifies divergent behaviour between separate implementations as a source of cross-platform bugs. A canonical implementation would give platforms common underlying code for the relevant functionality. That can reduce one reason that equivalent API calls behave differently, even though operating-system interactions still need their own contracts.

Essentials is defined by what it brings with it

Parker's same-day module proposal expands on the announcement. It explicitly calls the breakdown preliminary and asks for community input. FoundationEssentials would contain broadly useful types without additional system dependencies, while considering dependencies on Swift packages individually against the package's size goals.

The proposed list includes Data, URL and UUID, together with Date and DateInterval. It also includes JSON and property-list serialization and coding types. These are useful distinctions for an application that needs to represent data or exchange a machine-readable payload without formatting it for a particular user's locale.

Essentials is not merely a list of small value containers. Parker also proposes file and process APIs, Bundle and several other facilities. Some entries have open scope questions, such as which user-default domains would belong. The list describes a proposed boundary for discussion, not a completed guarantee that every listed API has identical behaviour on every platform.

The forum post specifically suggests that APIs such as Process deserve reconsideration through async/await. It also acknowledges that existing APIs remain useful to current projects. This leaves room for advancing a useful operation without claiming that the first rewrite must simultaneously replace every familiar interface with a new design.

Internationalization is a separate dependency decision

FoundationInternationalization would contain locale and calendar functionality, including TimeZone, DateComponents and formatting APIs. The blog announcement describes it as the package for localized content such as formatted dates and times. The distinction separates representing a point in time from interpreting or displaying it through calendar and locale rules.

That boundary gives a server application a more deliberate dependency choice. A component processing stored dates may have different needs from a component producing user-facing output. The proposed architecture lets the latter bring in internationalization functionality without making the former's basic date representation imply the same dependency set.

Character-related APIs also raise design questions. Parker places CharacterSet in the internationalization proposal and notes that it may be redesigned or augmented to fit Swift strings better. That is an identified area for investigation. It is not an announced change to existing character matching semantics.

I consider the dependency boundary more useful than a promise that every import will become smaller. It connects package selection to a program's actual requirements. The benefits depend on the implementation and final contents, but the architectural criterion is clear enough to discuss before those details are finished.

Networking and XML retain their own scope

The proposal notes that FoundationNetworking and FoundationXML have already been separated from Foundation. Networking would continue to provide APIs including URLSession, URLRequest and response types. Unifying that implementation in Swift is described as future work after stabilizing essential types, especially URL.

XML follows a later stage in that plan. Its existing parsing APIs continue, with unification described as work after Essentials and networking. This sequencing matters because the top-level goal of one Foundation implementation does not mean that every subsystem is being replaced at once.

For a project that depends on networking or XML, today's plan therefore provides architectural context without establishing an immediate migration instruction. The detailed discussion still has to determine the transition from corelibs to the new implementation. Parker explicitly leaves that ecosystem transition for future discussion.

The boundaries also show why external dependencies are the organizing concern. Networking and internationalization can introduce requirements that simple data representation does not need. Selecting modules along those lines gives consumers a way to control transitive requirements, which the proposal identifies as a source of size growth and conflicts.

More modules can expose more permanent interfaces

The forum post directly considers splitting each Foundation type into a separate package. Parker argues that interfaces among the resulting modules would have to be public and stable. A relationship intended only for cooperating library components might then become something external callers use and depend on.

That constrains future changes. An internal refactoring inside one module can stay internal. Once another independently compiled module requires a public declaration, the library may have to preserve that declaration for callers it never intended to support. Granularity therefore has an API maintenance cost as well as a possible dependency benefit.

The proposed balance groups functionality where it can share implementation details, while separating areas with significant external requirements. This is a concrete reason to avoid using module count as the measure of a successful redesign. The relevant question is which dependencies an application can exclude without turning all library cooperation into a public contract.

Darwin compatibility remains explicit

The proposed FoundationObjCCompatibility package would hold types useful for legacy code and compatibility with Darwin Foundation, including NSObject, NSNumber and NSError. That creates a named place for compatibility concerns rather than treating all inherited APIs as equally central to a new Swift implementation.

Parker also distinguishes the new package's goals from corelibs' goal of complete source compatibility. Several existing APIs are not planned for the unified package. The list includes NS-prefixed collections and keyed archiving facilities, alongside older scheduling and synchronization-related types. These are plans for the new package's scope, not permission to remove them from Darwin Foundation.

The post states that Darwin must maintain compatibility for existing APIs and will continue implementing the excluded types through a mixture of C, Objective-C and Swift. That distinction protects the meaning of the announcement. A shared Swift core and a continuing compatibility framework can coexist, with different responsibilities for code that still needs historical interfaces.

The older corelibs README explains why such compatibility once shaped its collection support. NS-prefixed collections supplied reference semantics and subclassing, and could occur in archived data. Omitting them from the proposed new package does not erase those existing uses. It changes which use cases the unified implementation intends to prioritize while Darwin continues supporting its established contracts.

The open questions remain substantial. Module contents are preliminary, some APIs may change, and the migration process has not been specified. The published proposal nevertheless supplies a clear architectural criterion. Keep common portable functionality together where useful, separate significant external dependencies, and retain explicit compatibility obligations for applications that depend on existing Darwin APIs.