Skip to content

Conversation

@itaybre
Copy link
Contributor

@itaybre itaybre commented Dec 10, 2025

This decision documents the removal of the HybridSDK subspec and module, consolidating all hybrid APIs into the main Sentry target.

Background

Until v9.1.0, we maintained a separate SDK variant with additional public headers/APIs for downstream SDKs (React Native, Flutter, .NET, SwiftUI). This separation:

  • Required maintaining multiple distribution variants
  • Increased CI complexity and team workload
  • Provided no real protection (users could still access "internal" APIs by switching dependencies)

Decision

Remove the HybridSDK submodule and subspec, treating hybrid SDK consumers as first-class citizens by:

  • Exposing required APIs in a documented manner
  • Avoiding breaking changes to these APIs in minor versions
  • Using naming conventions to distinguish internal APIs from user-facing ones

Next Steps

  1. Consolidate headers into the main target and remove HybridSDK subspec, done in chore: Removes HybridSDK subspec #7019
  2. Update downstream SDKs
  3. Align on an API naming convention (gather input from other SDK maintainers)


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)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I don't have a strong preference - as long as we can call it from hybrids I don't think it matters much to us. perhaps SentrySDK.internal.xyz?

I'd go for whatever the team feels more natural for cocoa

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would not even mention it in the SentrySDK, because then it surfaces to our users, and it could confuse them. I would put it into an extra API. InternalSentrySDK. could work, or we could just keep PrivateSentrySDKOnly. Then it's easier for Hybrid to switch.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I would try to avoid using SentrySDK.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've been using InternalSentrySdk for Android as well

might make sense to align here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, seems like a good oportunity to align

Copy link
Member

@philipphofmann philipphofmann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks


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)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would not even mention it in the SentrySDK, because then it surfaces to our users, and it could confuse them. I would put it into an extra API. InternalSentrySDK. could work, or we could just keep PrivateSentrySDKOnly. Then it's easier for Hybrid to switch.

@itaybre itaybre added the ready-to-merge Use this label to trigger all PR workflows label Dec 12, 2025
@itaybre itaybre marked this pull request as ready for review December 12, 2025 16:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ready-to-merge Use this label to trigger all PR workflows

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants