Repository navigation
[BridgeJS] Support Foundation.URL as parameter/return type #496
Description
Activity
- added a parent issue
on Jan 15, 2026 However this is implemented, it should be configurable for users building with Embedded Swift, where Foundation is unavailable.
I was thinking about working on implementing some Foundation types support in BridgeJS, starting with
UUID(which could simplify interface a bit in our project) and designing the mechanism that could also coverURLProposed approach:
Add a new
BridgeType.foundationType(FoundationTypeKind)case whereFoundationTypeKindis a closed enum of recognized Foundation types (uuid,url, extensible todateetc.). Each kind declares its wire type (e.g., both UUID and URL usestringon the wire), Swift type name, and TypeScript type.This means:
- ABI: Foundation types reuse existing wire encodings (UUID/URL → string)
- Swift side: Auto-generated lift/lower code converts between the Foundation type and its wire representation (
UUID(uuidString:)!/.uuidString,URL(string:)!/.absoluteString) - TypeScript side: Maps to
string - Embedded Swift: All Foundation bridging gated behind
#if canImport(Foundation)inBridgeJSIntrinsics.swift, following approach similar toJavaScriptFoundationCompat
The single
foundationTypecase keeps changeset manageable, most switch statements overBridgeTypecan delegate to the wire type's existing handling rather than needing per-type branches.I could start on this early next week, happy to discuss the design before I start coding 🙏🏻
Reacted by Max DesiatovThanks @krodak for sharing your idea
TBH I'm a bit concerned about adding more BridgeType cases before we pay down some of the existing complexity debt in the code generator. In particular, the current ad-hoc handling for container types should probably be moved out of the code generator and into something that leverages Swift's generic type system more directly.
I think we should limit the set of types that the code generator needs to recognize to only those that truly require specialized, performance-critical handling. For everything else, I've been wondering whether we could adopt a more generic ABI approach (similar in spirit to a stack-based ABI), so that extending supported types wouldn't require invasive changes to the code generator.
Reacted by Krzysztof Rodak@kateinoigakukun let me think on this for a bit, I think we could introduce something that could allow us to just have a set of pairs of Swift <-> TS types bridging defined and generalize code gen logic for them similarly to stack based types and also address ad-hoc handling
