Hello. I've just noticed there are crashes on my i...
# multiplatform
a
Hello. I've just noticed there are crashes on my iOS app, and Firebase Crashlytics reporting tells me almost nothing when I look at the stacktrace. How does one debug a crash on iOS that occured in KMM to figure out what went wrong ?! Is there some sort of best practice for this, specifically for iOS ? If there a third party service or something i could use to help out in ?!
r
Unfortunately there isn’t much to figure out from such stacktrace. The only thing it tells you is that there was an unhandled exception in your Kotlin code. There are some tools to help log the actual exception though: • https://github.com/rickclephas/NSExceptionKthttps://crashkios.touchlab.co/https://kermit.touchlab.co/
a
Will any of these tools help with pinpointing the actual stacktrace in Kotlin?
r
Yeah once integrated they will intercept the unhandled Kotlin exception and log it to a service like Firebase. They won’t be able to help for existing crash reports though.
a
that's fine, i can do a new release and let it crash some more 😄 Thank you very much for these !
Ah, one last thing. Which one of these would you recommend? Which one's the most stable one, etc ?! Any idea ?
r
It depends on your requirements. CrashKiOS is using NSExceptionKt and Kermit uses CrashKiOS. They both add additional features. E.g. Kermit isn’t just fixing the crash exception handling but also provides a logging API.
a
Yeah, i noticed. I also noticed you were a contributor on NSExceptionKt 😄 that's awesome !
l
Note that this isn't really an exception. There's something going wrong inside the GC, causing it to abort.
r
Ah right uncaught exception would have a line with
TerminateWithUnhandledException
.
l
You can also see an abort in your code if you are running code on a background thread and the user puts the app in the background. You'll see an abort with a really confusing stack trace after 5 seconds.
l
So it might be unrelated to GC after all?
l
There's a GC method in the trace right before abort, so there's a good indication it's to blame in this specific case. My point was more that when you get signals instead of exceptions, there's more going on. Are you using cinterop at all? More importantly, have you found a way to replicate it?
a
Hello everyone. hah! i completely missed the rest of this thread. No, i am not using cinterop. Unless some dependency that I included might use it ?!?! And no, unfortunately I am unable to replicate it. I can't even tell what's going on while the app is crashing, what screen the user was on.. I was hoping integrating what Rick said above would at least point me in the right direction.
Regarding that, @Rick Clephas any ideas why I'm getting this? I'm trying to build the iOS module but ... I just can't wrap my head around what the fix might be. I ended up using NsException
Btw ... there are 300 threads ... I've never seen so many before. Why would that be I wonder ?!
One of them ...
r
@Rick Clephas any ideas why I’m getting this?
Are you adding the Firebase dependency in your iOS project or in the shared module? I see you are using CocoaPods, so I think you’ll need to add the Firebase dependency to the shared module via CocoaPods. (normally the shared module needs to be static, since the Firebase dependency is then added to the iOS project).
a
no, i am not. I guess that's the reason for it. I'll give it a try, thank you very much
in the iOS project yes, but this fails before I even include it in the iOS project, so I guess i need to add it to the shared module ...
r
Yeah correct. I am not that familiar with CocoaPods, but the error message basically means the Firebase dependency isn’t present.
l
@Rick Clephas Should it be a dynamic actually?
r
@louiscad when adding the dependency to your final application (instead of the shared module) the shared module needs to be static. When it’s dynamic it will fail to compile due to the missing dependency which it will try to link against. There are some workaround that do allow the usage of a dynamic shared module, however those will fail once app-thinning is applied (see KT-58461)
l
Ah yes, for the final module, static for sure.
a
So ... yeah. Unfortunately I have absolutely no idea how to add the Firebase dependency to the shared module. I throught it would just be a simple line of code, adding an implementation "xxxx" to iosMAin or commonMain ... but no. The thing is ... i use
./gradlew shared:createXCFramework
... i don't really distribute it as a cocoapod. I push it to a repo, iOS team downloads it from the repo and uses it that way. I do have a shared.podspec file in the project, but I think that's a fail attempt of using cocoapods. I'm still unable to make this work...any pointers by any chance, point me in the right direction on how to actually add Firebase to the shared module ? I've searched the web for a solution but ... absolutely no luck. I'm really, really stuck 😞
r
Ah alright. In that case you would just need to make the framework static. Then there is no need to add the dependency to the shared module. https://github.com/rickclephas/NSExceptionKt/blob/013445897bcf16a7ff376cc9e59ca55c781bcee7/sample/shared/build.gradle.kts#L18
l
Making a framework static doesn't mean that frameworks it depends on are also static. If Firebase is missing, you should tell your iOS team to add the Firebase pods to their podfile.
r
True but in this case the issue occurs while building the Kotlin framework. Which can be solved by adding the Firebase dependency to CocoaPods in the shared module. But that won't work if CocoaPods isn't used to for the shared module. As far as I know the only other way is to make the shared framework static.
r
The Kotlin cocoapods plugin does it's magic by cloning the dependency into the build folder and then running cinterop against that. So you could probably run a similar process manually if you had to. But generally much easier to deal with if you make things static.
386 Views