February 18, 2026
No Strings Attached
Ladybird: Closing this as we are no longer pursuing Swift adoption
Ladybird dumps Swift: C++ crowd cheers, Apple skeptics say 'told ya'
TLDR: Ladybird dropped its plan to use Swift after messy build and toolchain issues, then removed Swift from the code. Commenters mostly applauded a return to C++, called Swift too Apple-centric, accused the announcement of sounding AI-written, and asked whether Ladybird’s own language Jakt will get the spotlight next.
Ladybird just broke up with Swift, and the comments came in hot. The project says they hit a wall of toolchain drama: a clang module mess that loops when a certain header is included, a build system that ignores settings and screams warnings, and a surreal “String” identity crisis that crashes the Swift compiler. Some fixes exist, but not in the current Swift releases (6.0.0 and 6.0.1), and a CMake fix is still rolling out. Their commit bluntly says: “After making no progress… remove it.” The vibe? “Told ya.”
One camp cheered: “Swift is too tied to Apple,” and “every real browser is C++,” said drnick1. WCSTombs shrugged: just ship on Linux and they’ll test. Incognitojam surfaced the breakup note, while tomcam poked at the wording: “This reads like an AI response.” The biggest plot twist: losvedir asked if Ladybird’s own language, Jakt, is stepping back into the spotlight. Memes flew about “No Strings Attached,” riffing on compiler crash over which “String” to use. Expect a classic internet split: pragmatists pushing C++, explorers dreaming of Jakt, and everyone dunking on toolchain chaos.
Key Points
- •Ladybird ended its effort to adopt Swift, citing unresolved blockers to making Swift 6.0 support non-experimental.
- •Including the C++ <execution> header in libstdc++ caused cycles in Swift’s clang module map; upstream disabled the header for libstdc++ ≥ 11 (PR #75662; backport #75971).
- •The Swift-side fix is present in swift’s main and release/6.0 branches but not in versions 6.0.0 or 6.0.1.
- •CMake/Ninja builds ignored CMAKE_OSX_DEPLOYMENT_TARGET, producing LC_BUILD_VERSION mismatches; another issue with CMP0157 prevented swiftc from setting install_name to “@rpath”.
- •CMake MR 9692 (merged Aug 2, 2024) addresses the install_name issue; a Ladybird Swift file also triggered a frontend crash due to AK.String vs Swift.String ambiguity, requiring an upstream bug report.