Currently if someone wants to use SPM or (native, not kotlin) Cocoapods with our SDK it is only possible when making the shared libary static (dynamic is the default), e.g:
kotlin {
listOf(
iosX64(),
iosArm64(),
iosSimulatorArm64()
).forEach {
it.binaries.framework {
baseName = "shared"
isStatic = true // Using SPM is only available when creating a static framework
}
}
Why the current solution is not ideal
The sure way to get dynamic framework to work is by using the kotlin cocoapods plugin to pull in the sentry-cocoa dependency, however that is inefficient as it runs through c-interop which also creates extra compile time and overhead in the final binary (also probably a lot of dead code)
Advantages of having it work as a dynamic library
SwiftUI previews don't work with static libraries. There might be some workaround but that adds extra layers of complexity for the user.
Why it doesn't work
On iOS only the definitions for Sentry are added when compiling the Kotlin code and building the framework. The binary (the actual Sentry Cocoa library) isn't added until later when you build the iOS app. When building a dynamic framework, the Kotlin compile expects to be able to resolve everything and it ends up with this error:
ld: symbol(s) not found for architecture x86_64 which basically tells us it cannot find the binary.
Solution
~Crashkios has solved this by basically telling the linker to treat the listed symbols as undefined. That means the linker will not try to find these symbols during the linking process and assumes these symbols will be provided by other means.~
kahest
commented
9 months ago
Description
Currently if someone wants to use SPM or (native, not kotlin) Cocoapods with our SDK it is only possible when making the shared libary static (dynamic is the default), e.g:
Why the current solution is not ideal
Advantages of having it work as a dynamic library
Why it doesn't work
On iOS only the definitions for Sentry are added when compiling the Kotlin code and building the framework. The binary (the actual Sentry Cocoa library) isn't added until later when you build the iOS app. When building a dynamic framework, the Kotlin compile expects to be able to resolve everything and it ends up with this error:
ld: symbol(s) not found for architecture x86_64which basically tells us it cannot find the binary.Solution
~Crashkios has solved this by basically telling the linker to treat the listed symbols as undefined. That means the linker will not try to find these symbols during the linking process and assumes these symbols will be provided by other means.~
The solution might not be viable since it can lead to problems if the app has app thinning enabled. See https://youtrack.jetbrains.com/issue/KT-58461
An alternative solution would be to properly link it to the framework
Essentially this means creating a KMP gradle plugin.