From 1647c75bca683ca967a650e7134b758a7fee4451 Mon Sep 17 00:00:00 2001 From: Itay Brenner Date: Wed, 10 Dec 2025 14:20:37 -0500 Subject: [PATCH 1/3] docs: Add documentation regarding HybridSDK target removal --- develop-docs/DECISIONS.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/develop-docs/DECISIONS.md b/develop-docs/DECISIONS.md index 997b1ec4a5..f6dd18320f 100644 --- a/develop-docs/DECISIONS.md +++ b/develop-docs/DECISIONS.md @@ -569,3 +569,24 @@ This is a wild idea, but we have to double check if using `canImport(SwiftLog)` Needs a POC to confirm this is possible + +## Remove HybridSDK target + +Date: December 10, 2025 +Contributors: @itaybre, @philprime, @philipphofmann + +Until v9.1.0, we maintained a separate variant of the SDK with additional public headers and APIs intended for downstream SDKs (React Native, Flutter, .NET, and our SwiftUI variant). This meant any change that affected our distribution system required maintaining at least one extra variant of the SDK, which increased the team's workload significantly. + +However, there was nothing stopping users from using these APIs. They could simply change their dependency to the HybridSDK variant and access any of the "internal" APIs, so the separation provided no real protection. + +Given these drawbacks with no tangible benefits, we decided to remove the HybridSDK submodule and subspec, merging all APIs into the regular target. Moving forward, we will treat Hybrid SDKs as first-class citizens by: + +- Exposing required APIs in a documented manner +- Avoiding breaking changes to these APIs in minor versions +- Using naming conventions or namespaces (TBD) to clearly distinguish internal APIs from user-facing ones, discouraging direct usage by end users + +Steps: + +1. Consolidate Headers into the main target and remove `HybridSDK` subspec +2. Update downstream SDKs +3. Align on an API naming convention (ask other maintainers for input regarding what they need) From 0a4f16a127e210fe9e6d82fa476f8d2ce4562f3b Mon Sep 17 00:00:00 2001 From: Itay Brenner Date: Thu, 11 Dec 2025 11:51:54 -0500 Subject: [PATCH 2/3] Update develop-docs/DECISIONS.md Co-authored-by: Philipp Hofmann --- develop-docs/DECISIONS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/develop-docs/DECISIONS.md b/develop-docs/DECISIONS.md index f6dd18320f..1637fdddfb 100644 --- a/develop-docs/DECISIONS.md +++ b/develop-docs/DECISIONS.md @@ -577,7 +577,7 @@ Contributors: @itaybre, @philprime, @philipphofmann Until v9.1.0, we maintained a separate variant of the SDK with additional public headers and APIs intended for downstream SDKs (React Native, Flutter, .NET, and our SwiftUI variant). This meant any change that affected our distribution system required maintaining at least one extra variant of the SDK, which increased the team's workload significantly. -However, there was nothing stopping users from using these APIs. They could simply change their dependency to the HybridSDK variant and access any of the "internal" APIs, so the separation provided no real protection. +However, there is nothing stopping users from using these APIs. They could simply change their dependency to the HybridSDK variant and access any of the "internal" APIs, so the separation provided no real protection. Given these drawbacks with no tangible benefits, we decided to remove the HybridSDK submodule and subspec, merging all APIs into the regular target. Moving forward, we will treat Hybrid SDKs as first-class citizens by: From 9214f84c4a4f7f6bbe742d4f9391f493beae7d9f Mon Sep 17 00:00:00 2001 From: Itay Brenner Date: Thu, 11 Dec 2025 12:15:34 -0500 Subject: [PATCH 3/3] Add examples of team workload --- develop-docs/DECISIONS.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/develop-docs/DECISIONS.md b/develop-docs/DECISIONS.md index 1637fdddfb..8c3f756394 100644 --- a/develop-docs/DECISIONS.md +++ b/develop-docs/DECISIONS.md @@ -575,7 +575,12 @@ Needs a POC to confirm this is possible Date: December 10, 2025 Contributors: @itaybre, @philprime, @philipphofmann -Until v9.1.0, we maintained a separate variant of the SDK with additional public headers and APIs intended for downstream SDKs (React Native, Flutter, .NET, and our SwiftUI variant). This meant any change that affected our distribution system required maintaining at least one extra variant of the SDK, which increased the team's workload significantly. +Until v9.1.0, we maintained a separate variant of the SDK with additional public headers and APIs intended for downstream SDKs (React Native, Flutter, .NET, and our SwiftUI variant). This meant any change that affected our distribution system required maintaining at least one extra variant of the SDK, which increased the team's workload significantly: + +- Extra linting jobs +- Additional integration tests +- More complex header management (Public, HybridPublic, modulemap) +- Additional SDK variants if we want to migrate CocoaPods to XCFrameworks However, there is nothing stopping users from using these APIs. They could simply change their dependency to the HybridSDK variant and access any of the "internal" APIs, so the separation provided no real protection.