Split SDK into feature-based modules

[armcknight]

Description

Customers should be able to selectively integrate separate SDK modules depending on the features they'd like to use. This would optimize the SDK footprint in each app, as instead of still shipping binary for unused features, they wouldn't be present at all.

This would be things like UIKit-specific features, or private API defined in ObjC that we want to be able to access in Swift without exposing to customers, which is where all the @_implementationOnly import and module.modulemap hacks are coming from.

This has other knock on benefits, like improved build times, enforcing cleaner APIs, installed SDK size and reducing app bloat, and supporting server-side swift.

See for instance the customer request at https://github.com/getsentry/sentry-cocoa/issues/3181#issuecomment-1653248686

Proposed module list:

• session replay (a lot of the new swift code introduced was for this)
• user feedback (most of the remainder of the swift in the codebase)
• profiling
• crash reporting
• performance
  • this could really be an umbrella for yet more separate modules, we could have one per “integration”:
    • watchdogs
    • anrs
    • TTID/TTFD
    • app starts
    • database tracking
    • file i/o tracking
    • network tracking
• errors (nonfatal errors–so, separate from crashes; exceptions)
• sdk infra (logging, file management, swizzling, tracing/spans, envelopes/serialization/networking)

Might need a separate module that delivers just the public interfaces (the Sentry Protocol) separate from any implementation, for things like SentryId and SentrySpan.

[bruno-garcia]

How does this affect installation steps and other SDKs that depend on the cocoa SDK?

[armcknight]

We can keep the current package as one that includes everything, and then have subpackages like sentry-core (which would do error/crash reporting), sentry-performance and sentry-UIKit, among other things, that could all be automatically included in the top-level Sentry package. So it shouldn't break anybody.

[bruno-garcia]

That makes sense. We did that on Android. sentry-android is a meta-package that includes sentry-android-core (actualy has the Android specific core), sentry-android-ndk (native stuff) and sentry-java the core Java-only which is used also by backend Java/Kotlin/JVM.

So users who don't want the additional 1MB or whatever NDK support, could go straight to sentry-android-core but that's rare tbqh. We did need to have two packages for Android and Java (reusable) which is the reason we ended up with this design. All while allowing a simple installation method: Add sentry-android.

[armcknight]

It's soundung more like this is going to be needed for the long term health of the package. We more recently looked at SDK size, and splitting it up can really reduce the footprint for the average customer who may not want every single feature we offer. It would also help with the ongoing challenges around a UIKitless offering.