If you’re working on an iOS app that’s using a shared Kotlin library, you might be skeptical about your ability to debug memory issues. Not only is it possible, it’s actually really easy. And not only is it really easy, there’s a myriad of different ways to go about it, so you can choose whatever you like the most.
I’m only going to focus on the way that I like to do it, but if you play around in Instruments, you might find a workflow you like even more.
Two Points on Project Configuration
Before getting started, there are two configuration points to note. KaMPKit, the project in the accompanying video, comes fresh out of the box with these two points already in place.
First: the iOS app will need a dynamic framework. If you need help producing one from your shared Kotlin library, checkout this fork of the KMP Cocoapods plugin.
Second: Xcode should have references to the Kotlin library files that are relevant to the iOS side. This point is optional, but recommended for debugging shared Kotlin libraries in general. Without Xcode references, the Kotlin files we find in Instruments will open in separate Xcode windows. If you don’t care about that, feel free to skip this one. Otherwise, for further explanation and help, go here.
Kotlin in Instruments
In Xcode, go to Product → Profile (or CMD + I), which will launch Instruments. From all the options that appear, choose the Allocations tool. Make sure your target app is selected at the top. Click the red Record button in the upper left.
Reproduce the behavior that causes the memory issue, then stop recording. You’ll probably see a spike in activity in the Allocations line graph. Make sure that the lower view is set to Allocations → Call Trees → Call Tree, like so:
You can inspect the call trees any number of different ways. One is to find the line containing your memory issue by going through the stacks and paying attention to the Bytes Used column, but that’s inefficient and time consuming.
Another option is the Involves Symbol search bar at the bottom. Search for “kfun” (“Kotlin function”), which is a prefix for Kotlin functions that are exposed to the iOS side. That will narrow your search.
One more option is the Heaviest Stack Trace side view on right, which is highly likely to contain the memory issue you’re looking for.
When you do finally find the symbol name you’re looking for in the call trees, right (or double) click it. In the dropdown that appears, select Reveal in Xcode, which will pull up the relevant Kotlin file and line number in Xcode.
As I said earlier, these are just a few ways that I found useful while exploring KaMPKit’s iOS project via Instruments. In exploring Instruments, you may well find a workflow you prefer.
Future Research
This is just the beginning of our exploration at Touchlab into debugging Kotlin for iOS. We’ve already created an Xcode plugin for basic code highlighting and setting breakpoints. We’re also considering the possibility of creating a custom Instruments tool for Xcode projects consuming Kotlin libraries, unless we find another solution that we like even more. Either way, keep an eye out, because we’ll be sure to share what we find!
Top comments (1)
hi