the short version on CrashKiOS is that Kotlin has changed how some of its native builds work, which has made this kind of dependency increasingly difficult to add. There are also issues on the iOS/Apple side with app-thinning and deployment. It's an active topic internally on how to ultimately resolve this in a way that makes sense.
Sentry has the same basic problem. I call them "delayed dependencies". Kotlin expects the symbols to be available, but we don't really want to bundle the binaries in Kotlin but rather link to them later, when the app is ultimately built in Xcode. When building dynamic frameworks, Kotlin expects to resolve everything referenced, but those dependencies aren't available at that point, which is what the gradle plugin was addressing with linker flags that essentially say "don't worry about these". For Kotlin test builds, the compiler used to build test exes statically, so as long as you didn't pull Bugsnag into the tests, the compiler would just ignore it, but some versions ago, they started building test exes as dynamic, which then builds "everything", and that expects all symbols. Using CocoaPods to add Bugsnag, with "link only", does solve the problem, but it's obviously not an ideal solution. It shouldn't impact the outcome, as
linkOnly
doesn't generate bindings (from Sentry docs):
pod("Sentry") {
version = "~> 8.25"
linkOnly = true
extraOpts += listOf("-compiler-option", "-fmodules")
}
The cocoapods integration wires the Bugsnag binary into the places it needs to be.
Now in an ideal world, there would be a separate "Dependency importer" that could use CocoaPods or SPM to grab binaries and do what the current Kotlin CocoaPods plugin does, but just for importing. However, the Kotlin CocoaPods plugin was designed with the expectation that you'd be using CocoaPods generally. "Automagically" it declares framework outputs, which we don't want. I'm on a tight deadline for something else today, so I can't deep dive back into this right now, but do intend to get back to it asap.