Adopt FoundationEssentials guards to enable Foundation-free deployments on Linux

[sebsto]

Describe the feature

The AWS SDK for Swift unconditionally imports Foundation across many generated and hand-written files (e.g. AWSBedrockRuntime/BedrockRuntimeClient.swift, AWSBedrockRuntime/Models.swift, and similar files in every service module). On Linux, this transitively links libFoundation.so (and libFoundationInternationalization.so / lib_FoundationICU.so) into any executable that consumes the SDK — even if the consuming application has carefully guarded its own Foundation usage with #if canImport(FoundationEssentials).

Please consider adopting the FoundationEssentials opt-in pattern across the SDK so that downstream packages can produce binaries free of the full Foundation/ICU runtime on Linux.

The recommended pattern is:

#if canImport(FoundationEssentials)
import FoundationEssentials
#else
import Foundation
#endif

…applied to every generated and hand-written source file that does not depend on the Foundation-only types (e.g. URLSession, XMLParser, NSRegularExpression, NumberFormatter, etc.).

Use Case

We maintain swift-bedrock-library (build-on-aws/swift-bedrock-library), a high-level Swift client built on top of aws-sdk-swift. The library sources guard their Foundation imports with the FoundationEssentials pattern, but our CI cannot enforce a Foundation-free build because the AWS SDK pulls in libFoundation.so transitively.

Foundation-free builds matter for several scenarios:

• AWS Lambda / serverless: smaller deployment packages, faster cold starts, fewer ICU-related runtime surprises.
• Embedded / size-constrained environments: where every megabyte of libFoundation.so (and its ~30 MB ICU dependency) counts.
• Static linking: enables fully static binaries with --static-swift-stdlib without dragging in ICU symbols that conflict with system ICU.

The Swift Server ecosystem (e.g. SwiftNIO, swift-log, swift-collections, swift-crypto) has been migrating to FoundationEssentials for these reasons.

Proposed Solution

1. Audit per file which Foundation symbols are actually used. The vast majority of generated SDK code uses only Data, URL, Date, JSONEncoder/Decoder, String/Int extensions — all of which are available in FoundationEssentials.
2. Update the Smithy code generator to emit the #if canImport(FoundationEssentials) guard at the top of every generated file.
3. Refactor hand-written files (in AWSClientRuntime, AWSSDKIdentity, AWSSDKChecksums, etc.) the same way.
4. Identify the modules that genuinely need full Foundation (likely a subset that uses URLSession, FileManager, XMLParser) and isolate those behind separate targets so consumers who don't need them can avoid the dependency.
5. Add a CI job that links a representative example and runs ldd / otool -L to assert the absence of libFoundation.so / libFoundationInternationalization.so / lib_FoundationICU.so. (Happy to share the exact CI script once we get one working downstream.)

Other Information

• Downstream tracking: build-on-aws/swift-bedrock-library#84 (history of the broken/repaired check, surfaced this).
• Related: #817 — Provide a Foundation-based HTTP Client (the inverse direction; suggests the Foundation pull was a deliberate dependency rather than an accidental one — so this work needs explicit buy-in from the team).
• Background on the Swift Foundation split: https://www.swift.org/blog/foundation-preview/ and https://github.com/swiftlang/swift-foundation.
• The pattern in practice: https://github.com/swiftlang/swift-nio/blob/main/Sources/NIOCore/Channel.swift and similar files in the swift-server ecosystem.

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

SDK version used

aws-sdk-swift 1.7.x (latest as of November 2026)

Operating System and version

Linux (Ubuntu 22.04, Amazon Linux 2023) — symptom is most visible there. macOS already statically links Foundation into the runtime.

[dayaffe]

@sebsto Thanks for this suggestion!

We are going to investigate how feasible this is. We'll provide an update here as soon as we have one.