I have an issue with the documentation / setup on iOS of CrashKiOS and Bugsnag. The documentation sa...

# touchlab-tools

[ribesg]

I have an issue with the documentation / setup on iOS of CrashKiOS and Bugsnag.
The documentation says to call startBugsnag, which takes an empty co.touchlab.crashkios.bugsnag.BugsnagConfiguration and seems to start its own co.touchlab.crashkios.bugsnag.Bugsnag instance.
Meanwhile, following the documentation, I already have a proper call to cocoapods.Bugsnag.startWithConfiguration with a correct configuration of type cocoapods.BugsnagConfiguration which can actually contain configuration values.
Is this supposed to work that way? Calling startBugsnag with a dummy config? This is weird

[kpgalligan]

Meanwhile, following the documentation

Which documentation?

[ribesg]

https://crashkios.touchlab.co/docs/bugsnag

[kpgalligan]

Meanwhile, following the documentation, I already have a proper call to cocoapods.Bugsnag.startWithConfiguration

I meant which docs for a "proper call" with the cocoapods cinterop.
Anyway, I think I get it.

On iOS, there's a few more things to do at startup for Bugsnag to work. These are all wrapped in a helper function startBugsnag(config: BugsnagConfiguration).

It's a helper function. Internally it does this:

public fun startBugsnag(config: BugsnagConfiguration){
    configureBugsnag(config)
    Bugsnag.startWithConfiguration(config)
    setBugsnagUnhandledExceptionHook()
    enableBugsnag()
}

For context, that's what's happening under the hood.

The documentation says to call startBugsnag, which takes an empty co.touchlab.crashkios.bugsnag.BugsnagConfiguration

From the docs:

If you don't need to do any other config for Bugsnag you can create an empty config

"If" is the key there. You can use a non-empty one.

and seems to start its own co.touchlab.crashkios.bugsnag.Bugsnag instance

It does not. It calls the static instance.

[kpgalligan]

If you have your own startWithConfiguration call, just copy/paste the steps in the helper function.

configureBugsnag(yourconfig)
    Bugsnag.startWithConfiguration(yourconfig)
    setBugsnagUnhandledExceptionHook()
    enableBugsnag()

If you're doing your own cinterop with cocoapods, you'll have to cast it (I think, just got up), but they both delegate to ObjC instances. Those should match fine below the Kotlin layer.

[kpgalligan]

Or just use the Bugsnag.startWithConfiguration from CrashKiOS's cinterop

[kpgalligan]

All of crashkios is getting a rework because of changes to Kotlin over time. The linking is a mess. For example, enableBugsnag() used to do something useful, but test exe's are dynamic now, so it's pointless.

[ribesg]

I meant that co.touchlab.crashkios.bugsnag.BugsnagConfiguration is an empty class, but I do need to configure stuff so I can't use it.

If you can cast back and forth between cocoapods.Bugsnag* and co.touchlab.crashkios.bugsnag.Bugsnag*, then I should be able to make it work

[kpgalligan]

You should be able to. It's odd, but it should work fine.

co.touchlab.crashkios.bugsnag.BugsnagConfiguration is an empty class

Like most open source, the design was a bit too informed by our use case. We generally pass the config in from Swift.

[kpgalligan]

OK. Rushed morning (live stream in 30 minutes). Anyway, the Kotlin compiler used to compile static kexe files to run tests. To avoid linking issues, you could essentially just not enable Bugsnag or Crashlytics in test setup, and the compiler would drop that code. Now the Kotlin compiler compiles dynamic kexe's to do this, and they include everything in your project. It's been difficult. Sentry's "official" client has the same problem, along with similarly painful solutions. For Crashlytics, we went so far as to call all ObjC dynamically and dropped cinterop (https://github.com/touchlab/CrashKiOS/pull/71). Bugsnag has one actual "C" call that needs to be made, so the same solution won't work. Painful situation. But, anyway, hope you got it working.