https://kotlinlang.org logo
Join Slack
Powered by
In my cmp ios app I'm getting a crash on startup a...
# compose-ios
c
In my cmp ios app I'm getting a crash on startup after backgrounding the app for a few minutes. im new to ios, but i dont get this crash on android after simulating process death. I asked chatgpt on how to test process death on ios, but it gave me this. Is this true? should i disable state restoration on ios for cmp apps?
h
hell no, what’s the trace? can you also share some code as well if applicable, at least of the part of your cmp hierarchy?
c
app is too big to tell what the root cause might be. currently trying to peel back layers to see where I can get the smallest repro.
trying to get a stacktrace has also proven to be a complete nightmare. lol
l
I saw this before when I launched a coroutine on Dispatchers.Default. The stack trace was useless (sigabrt with two stack entries, both in the iOS stdlib). You can register a callback for when the app backgrounds, and cancelling my coroutines fixed my case.
c
Hm. Let me look to see if I have anything random using dispatchers.default. But yeah the stacktraces aren't too helpful at the moment. nothing that points to my code.
r
Is there something being worked on to improve the stack traces? Because iOS dev definitely doesn't look stable for me. In fact it's a big no go for me if it wasn't for the fact I do 95% of my dev for desktop/android and just mostly assume iOS works out.
a
> Hm. Let me look to see if I have anything random using dispatchers.default. But yeah the stacktraces aren't too helpful at the moment. nothing that points to my code. @Colton Idle They look quite informative (At least the least couple of them). Please feel free to get full stack traces and create issues in our YouTrack for the crashes you believe caused by the CMP.
c
Yeah, I'm just trying to nail down a more minimal repro case at the moment. its unfortunately not a fast feedback loop so its taking some time
I removed all of my UI this morning and now have an empty composable with a few launched effects (no UI though) and it's still happening lol
CleanShot 2025-05-28 at 09.41.06@2x.png
@Landry Norris i think you might be onto something. seems like as I've removed all of my UI code but my LaunchedEffects etc still exist I get a stacktrace with compose UI in it, and some dispatcher stuff đź‘€
l
Do any of your LaunchedEffects create a sort of background thread, or are they one-off events? If any create background tasks, try storing the Job and cancelling when the app is backgrounded.
c
I have a connection service to a piece of hardware that is long-lived yes. I start it on resume, but I don't kill it when I background it because reconnection takes like 3 seconds. and if you just background the app I dont want to kill the connection since when if you come back within a few seconds it would be good for it to already be connected. my thought process is that if the connection dies while backgrounded (which typically happens within like a minute) then coming back into the app restarts just fine. So all of that works perfectly now. Works fine on android. Leave app for 3 seconds and come back. everything is fine. leave app for a long time and come back. it works fine and reconnects.... but like 10% of the time I get this obscure issue instead... only on ios.
t
On iOS you need to stop the connection when it goes to background or it could cause issues. See “Listening Socket” at https://developer.apple.com/library/archive/technotes/tn2277/_index.html. In my case, the open file descriptor would cause errors when returning from background. On Android no issue, but on iOS it is best to just close it.
And you should use CrashKiOS or something similar to get the actual stack trace, it will be very helpful for you, I am sure.
Using that library you will get Kotlin stacktraces which actually point to your code.
c
Interesting. I've been using sentry and I thought with a pure CMP app the stacktraces will be kotlin stacktraces? do i really need crashkios? thank you for the link thomas! let me try to read a bit more. thanks for teaching.
t
Oh Sentry? I think it should already do this by default actually, if you are using the kotlin sdk. Then you don’t need crashkios and you should already get good stack traces.
❤️ 1
c
Cool. Yeah in this case it just seems that the stacktraces just aren't really that helpful.
"In my case, the open file descriptor would cause errors when returning from background" Very interesting! indeed I basically have to open up a socket communication to my hardware device. so maybe that's the culprit. I'll try to figure out the best way to shut it down gracefully in compose. again. i would love to have like a 5 second buffer or something before fully disconnecting. but lets see what i can come up with.
t
If I remember correctly there should be like a 5 second limit before iOS suspends your app when going to background, but you can extend it.
c
Interesting. Okay. Maybe I can delay the disconnect for at least 5 seconds. I don't necessarily want to extend it... i just want to prevent backgrounding the app and coming back right away causing a reconnection
5 Views
Open in Slack
PreviousNext
Powered by