Open armcknight opened 1 year ago
How does this affect installation steps and other SDKs that depend on the cocoa SDK?
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.
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
.
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
andmodule.modulemap
hacks are coming from.This has other knock on benefits, like improved build times and enforcing cleaner APIs.
See for instance the customer request at https://github.com/getsentry/sentry-cocoa/issues/3181#issuecomment-1653248686