For what it's worth, there might be a 2GB limit on the iOS side.
https://github.com/swiftlang/swift-corelibs-foundation/blob/...
In Show HN: Minimalist editor that lives in browser, stores everything in the URLswiftlang
swift-corelibs-foundation
C2015–2025
swiftlang / swift-corelibs-foundation
swift-corelibs-foundation
The Foundation Project, providing core utilities, internationalization, and OS independence
36Distinct people
40Mentions
0Explicit recommenders
5.4KGitHub stars
What to know before exploring
What it is
The Foundation Project, providing core utilities, internationalization, and OS independence
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- swiftlang/swift · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year40 dated mentions
Observed mentions: 2015-12-03 22:31:05 UTC to 2025-12-24 21:10:16 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 12, 2026.
Read the project’s introduction
Foundation
The Foundation framework defines a base layer of functionality that is required for almost all applications. It provides primitive classes and introduces several paradigms that define functionality not provided by either the Objective-C runtime and language or Swift standard library and language.
It is designed with these goals in mind:
Provide a small set of basic utility classes and data structures.
Make software development easier by introducing consistent conventions.
Support internationalization and localization, to make software accessible to users around the world.
Provide a level of OS independence, to enhance portability.
There is more information on the Foundation framework here.
This project, swift-corelibs-foundation, provides a compatibility implementation of the Foundation API for platforms where there is no Objective-C runtime. On macOS, iOS, and other Apple platforms, apps should use the Foundation that comes with the operating system.
Project Navigator
Foundation builds in different configurations and is composed of several projects.
graph TD;
FF[Foundation.framework]-->SF
subgraph GitHub
SCLF[swift-corelibs-foundation]-->SF
SF[swift-foundation]-->FICU[swift-foundation-icu]
SF-->SC[swift-collections]
end
Loading
Swift Foundation
A shared library shipped in the Swift toolchain, written in Swift. It provides the core implementation of many key types, including URL, Data, JSONDecoder, Locale, Calendar, and more in the FoundationEssentials and FoundationInternationalization modules. Its source code is shared across all platforms.
swift-foundation depends on a limited set of packages, primarily swift-collections and swift-syntax.
Swift Corelibs Foundation
A shared library shipped in the Swift toolchain. It provides compatibility API for clients that need pre-Swift API from Foundation. It is written in Swift and C. It provides, among other types, NSObject, class-based data structures, NSFormatter, and NSKeyedArchiver. It re-exports the FoundationEssentials and FoundationInternationalization modules, allowing compatibility for source written before the introduction of the swift-foundation project. As these implementations are distinct from those written in Objective-C, the compatibility is best-effort only.
swift-corelibs-foundation builds for non-Darwin platforms only. It installs the Foundation umbrella module, FoundationXML, and FoundationNetworking.
Foundation ICU
A private library for Foundation, wrapping ICU. Using a standard version of ICU provides stability in the behavior of our internationalization API, and consistency with the latest releases on Darwin platforms. It is imported from the FoundationInternationalization module only. Clients that do not need API that relies upon the data provided by ICU can import FoundationEssentials instead.
Foundation Framework
A framework built into macOS, iOS, and all other Darwin platforms. It is written in a combination of C, Objective-C, and Swift. The Foundation framework compiles the sources from swift-foundation into its binary and provides one Foundation module that contains all features.
Using Foundation
Here is a simple main.swift file which uses Foundation. This guide assumes you have already installed a version of the latest Swift binary distribution.
import Foundation
// Make a URLComponents instance
let swifty = URLComponents(string: "https://swift.org")!
// Print something useful about the URL
print("\(swifty.host!)")
// Output: "swift.org"
You will want to use the Swift Package Manager to build your Swift apps.
Working on Foundation
swift-corelibs-foundation builds as a standalone project using Swift Package Manager. Simply use swift build in the root of the checkout to build the project.
swift-corelibs-foundation also builds as part of the toolchain for non-Darwin platforms. Instructions on building the toolchain are available in the Swift project.
Building swift-corelibs-foundation on Windows
When building Foundation as a standalone project, it requires you to provide some dependencies that it will link during the build. SwiftPM already fetches most of these dependencies and on Linux the remaining dependencies (dispatch, zlib, curl, libxml) are found in the Swift toolchain or on the host OS. However, Windows does not ship with zlib/curl/libxml on the host OS. In order to build swift-corelibs-foundation as a package on Windows, you must first checkout and build these dependenies before running swift build as recommended above. To do this, you can build the provided CMake target which (instead of building Foundation via CMake) will checkout and build these 3 dependencies via CMake and provide environment variables that will connect the SwiftPM build to these dependencies. To build these targets, run the following commands:
cmake -G Ninja -B <build folder> -DFOUNDATION_SWIFTPM_DEPS=YES
cmake --build <build folder> --target --target WindowsSwiftPMDependencies
After running these commands, the output will include a list of environment variables to set. After setting these environment variables, you can run swift test/swift build just like on Linux in order to build swift-corelibs-foundation with an existing Swift toolchain.
Contributions
We welcome contributions to Foundation! Please see the known issues page if you are looking for an area where we need help. We are also standing by on the mailing lists to answer questions about what is most important to do and what we will accept into the project.
Read the full README on GitHubWhat Hacker News says
40 sourcesRe Safari’s networking code being closed source, a good substitute might be the Swift port of Foundation. You can see checks for control and delete characters here: https://github.com/swiftlang/swift-corelibs-foundation/blob/...
In Handling cookies is a minefieldI'm not deep in Swift, but this would make it seem a reimplementation of Foundation is open source: https://github.com/apple/swift-corelibs-foundation/tree/main
In The Swift compiler is slow due to how types are inferreda : https://github.com/apple/swift-corelibs-foundation/blob/main...
I wouldn't want to be the guy relying on this table advancement for his own project. The fact that they're rewriting it in pure swift probably says a lot about the quality of the current approach.
b: makes absolutely no difference from a developer perspective. if you want to run threads in swift you're going to use gcd.
c: my take with all apple software tech has been to wait until they've dogfooded their own tech long enough to make it useable. Worked very well for me so far, thank you very much.
In Mixing Swift and C++The repo for anyone interested: https://github.com/apple/swift-corelibs-foundation
In Thoughts on Swift and Objective-C (2022)Correction: rewrite of PARTS of Foundation
There already was an open-source project to rewrite ALL of foundation, but it had stalled on the shores of having to re-implement everything:
https://github.com/apple/swift-corelibs-foundation
The news is actually that Apple is now instead trying to define the bits/parts to support via Swift on all platforms (the original API's will always be supported on Darwin).
The announcement:
https://www.swift.org/blog/future-of-foundation/
The discussion, with hairy details about which bits, esp. for async:
https://forums.swift.org/t/what-s-next-for-foundation/61939/103
The plan is to divide up Foundation into more- and less-essential parts, to get more-essential parts locked down so people can rely on them.
What's Foundation? Swift's most-core library is the stdlib, tightly coupled to the compile
Read the rest
r/language version, providing things like arrays, dictionary, etc., and available wherever Swift is. Beyond that, Foundation is the library with core API's for common features, e.g., for dates and concurrency. Stdlib is fully cross-platform and Swift-specific, but Foundation is a beast with API's dating to NExT with support for 20 years of API's.
Microsoft famously arrived at porridge for an operating system by maintaining backwards compatibility. Apple has cracked open Swift by developing in the open, but it's still Apple-funded and Apple-driven. Library and some integration support for other platforms has always had to come from community (notably compnerd's heroic effort to make-things-work on windows, and a revolving cast wanting Linux support for their server API's).
But there's no good reason to impose the whole Foundation history on other platforms. And there may be a movement inside Apple to migrate internal code to newer async API's, designed after the recent Apple-silicon generation.
For developers with server experience and some free time in a tech lull, it could be a good opportunity to help rebuild a new, er, foundation for computing on all devices, that's native but type- and memory-safe. The community is large and mature, but there is plenty of room for others.
Sigh... The traditional argument is that every dependency is of the same quality and trustworthiness of the language Standard Library.
If I use the SL, then I should also have no problem using some lashed-up chimera that has a dependency hierarchy that spans three continents.
Like I said, I'll do things my way.
For the record, here's the Swift Foundation Library: https://github.com/apple/swift-corelibs-foundation (I mostly write in Swift).
It has plenty of open issues: https://github.com/apple/swift-corelibs-foundation/issues?q=...
Also, for the record, here's a peek at some of the "worthless" packages that I use in my own work: https://github.com/RiftValleySoftware
If every dependency chain can match these, then I'll be open to considering them.
As it is, I do use the occasional external package, but I'm picky.
In There is no “software supply chain”CF was always (approximately) a multiplatform and open source subset of foundation (which is the thing this isn't). I think this is a superset and extension of the original core foundation under more favorable license terms though.
The "original" CF can be found here in various revisions tied to macos versions, complete with theoretically useful Linux makefiles and apple public source license files: https://opensource.apple.com/source/CF/
Compare, for example, these two versions of CFBase.c:
https://opensource.apple.com/source/CF/CF-1153.18/CFBase.c.a...
https://github.com/apple/swift-corelibs-foundation/blob/main...
(Credentials: I worked on the swift Linux port and made an effort to use these very libraries before the swift project itself took on the task of porting CF to swift. While I was working on it we mostly just ifdef'd out ever
Read the rest
ything to do with foundation when targeting Linux)
CoreFoundation is (partially?) open-source and cross-platform now: https://github.com/apple/swift-corelibs-foundation
In Achieving an open-source implementation of Apple Code Signing and notarizationPartly this is doable because although RFC 2616 (HTTP/1.1) specifies a max URL length of 2048 bytes, all the major browsers will process URLs which are much longer, with Safari allowing URL strings up to 2GB in size![1]
In 2021 probably one of the bigger blockers of giant URLs is CDNs, which impose various limits on URL size. e.g. Cloudflare limits URLs to 16kb.
[1] https://github.com/apple/swift-corelibs-foundation/blob/b23d...
In Show HN: Particles – the URL contains the whole program codeSwift itself works on most platforms. The problem with using Swift cross platform is that Apple only bothered to make their GUI toolkit available for their platform in the same way Microsoft only makes their dotnet GUI platforms available for Windows (without resorting to "official" replacements that are owned by the same company but not built into the system, like Xamarin).
As a consequence, many Swift libraries only focus on macOS, just like many dotnet libraries focus on Windows (though recent efforts have improved that situation). You can probably get a lot of them working on Linux as well and if you use Swift for command line tools or web applications. I suppose you can probably run the most important tools cross platform, but the non-native ecosystem is clearly a second class citizen.
The big difference between XCode and VSCode is t
Read the rest
hat Apple doesn't claim XCode is open source; also, XCode is more comparable to Visual Studio than VSCode in terms of SDK integration and preconfigured tooling.
Huge parts of the Darwin kernel are actually publicly accessible while Microsoft only provides kernel sources under NDA in things like education projects. Unless you count the WinXP source code leak, that is.
C# is sort-of mostly open source-ish except that debugger features are closed and the community has little say in its development.
Apple did in fact put effort into making Swift cross platform, as outlined here[1]; though their intention is that Swift programs use the system runtime on macOS/iOS/iPadOS, they put the effort into making a base layer freely available for other operating systems to gain some portability.
I'd personally argue that Apple and Microsoft are similarly if not equally open in their development, but Microsoft advertises itself much more "open source" than Apple. Apple's approach of "you can look but you can't touch" is a lot more explicit and their supposed openness comes up in fewer marketing materials.
[1]: https://github.com/apple/swift-corelibs-foundation
Foundation is not the standard library of Swift. Swift has its own standard library that is bundled with the language on all platforms that are supported.
And Foundation itself isn't written in Swift, a good portion is written in C.
> A significant portion of the implementation of Foundation on Apple platforms is provided by another framework called CoreFoundation (a.k.a. CF). CF is written primarily in C and is very portable. Therefore we have chosen to use it for the internal implementation of Swift Foundation where possible. As CF is present on all platforms, we can use it to provide a common implementation everywhere.
https://github.com/apple/swift-corelibs-foundation/blob/main...
In Apple’s use of Swift and SwiftUI in iOS 15The Foundation library on non-Apple platforms is open source: https://github.com/apple/swift-corelibs-foundation and intended to reach parity with the Apple version.
> Our primary goal is to achieve implementation parity with Foundation on Apple platforms. This will help to enable the overall Swift goal of portability.
In Apple’s use of Swift and SwiftUI in iOS 15> The fact the Foundation library is closed source is a complete joke in this day and age.
Foundation is open source https://github.com/apple/swift-corelibs-foundation
In Apple’s use of Swift and SwiftUI in iOS 15"Technologies like objective C, C sharp, Azure or swift are designed so you can not escape the company platform. So easy to get in, so hard to move your code to other platforms once you have been programming for years on them."
FYI, Swift is available on Linux and Windows along with a significant chunk of its core libraries (e.g. https://github.com/apple/swift-corelibs-foundation) and app frameworks such as Vapor (used for writing web apps and APIs).
In The web is swallowing the desktop whole (2017)Showing the 15 most recent of 40 sources. Enable JavaScript to search and browse every indexed mention.