Forem: Ben Whitley

Swift Closures in KMP

Ben Whitley — Thu, 11 Jun 2020 14:09:06 +0000

When working on the iOS side of Kotlin Multiplatform (KMP) projects, you'll probably find yourself using Swift closures to update your UI. At Touchlab, we find doing so to be best practice for most use cases. However, if you're not familiar with closures in Swift, they can pose a risk of creating strong reference cycles.

Opening the ARC

Before diving into an explanation of strong reference cycles and how to avoid them, first some broader context on the subject. The first thing to note is that Automatic Reference Counting (ARC) is what manages memory in Swift and Objective-C. For each object instance, it keeps count of the number of references to that instance, incrementing and decrementing it when references are created or destroyed, and ultimately reclaiming the memory when that count is zero.

ARC is a huge topic all on its own, but know that it handles almost all of the work for you, almost all of the time, so that you don't have to worry about it. However, ARC isn't perfect, and we're here to go over one of the times that you do need to worry about it.

Getting Closures

When writing Swift code that's calling a shared Kotlin library, closures are probably where developers are most likely to accidentally create a strong reference cycle. According to the official Swift documentation, "Closures can capture and store references to any constants and variables from the context in which they are defined." What this means is that any captured constant or variable will create a strong reference that ARC will maintain for the duration of the life of the closure, which could create a strong reference cycle.

The most common risk is creating a strong reference to self inside of a closure. For instance, in Kamp Kit iOS, we pass closures into the BreedModel. We use these closures to update the view when the data changes. In a larger, more complex app, a situation might arise where we want to deinitialize the ViewController, but not the BreedModel. The problem is that the closure captures self - meaning the ViewController - so the ViewController cannot be deinitialized without specifying that the reference to self is weak.

Weak References

You can tell ARC that inside of your closure you want weak references to self instead of strong ones. You do this by declaring [weak self] at the very beginning of your closure, before any parameter name declarations or anything else. THAT's how important it is. This essentially makes self optional (Swift for nullable) inside of your closure.

Escape from Current Context

For those wondering how or why Swift has these language features that can lead to reference cycles, a brief moment in Swift's defense. Swift has a concept of escaping vs non-escaping closures.

An escaping closure is one that is passed as an argument to a function, but may be called after that function returns. These are the types of closures you have to be careful with, and they're used frequently in KMP projects.

Non-escaping closures are the default behavior in Swift, and tend to be more straightforward. Because they cannot escape their current context, they're more associated with synchronous code and code that doesn't capture references outside of its own scope. The sort(by:) and filter(_:) functions contain good examples of non-escaping closures.

The Swift compiler will try to ensure that you know you're working with an escaping closure by forcing you to mark them with the @escaping as a prefix to their type declaration. If you're working on a KMP project and you're not yet comfortable navigating Xcode, it can be difficult to confirm whether or not the closures you originally wrote in Kotlin are escaping or not, but you can check. Opt + Click one of the constructor's parameter names to see its Swift declaration for yourself.

In KaMPKit, we pass in viewUpdate(for:) and errorUpdate(for:) closures into the BreedModel's constructor. The constructor is going to return/complete before those closures are ever called. Consequently, these closures must be escaping and require [weak self].

Guardians of the Nullability

In Swift, like in Kotlin, nullability is represented with a ?. So after declaring [weak self] at the beginning of your closure, all of the references to self inside of the closure are nullable and must be checked or unwrapped before use. Some developers accomplish this by immediately declaring guard let self = self else { return } as the first line of a closure that declares [weak self].

Without going too much into Swift guard statements (which are super cool), just know that this makes your reference to self into a strong reference for everything after it in its current scope IF self is not nil. If self is nil then the else statement is executed and the closure returns. Nothing after the else is executed.

If the self = self statement makes you uneasy, know that it's an officially supported Swift language feature, not a loophole or hack. You could also always do something more like this, to be as absolutely safe as possible:

Many, if not most, native iOS developers would probably find that excessive. The print statement in particular is the Swift equivalent of driving with two hands on the wheel, leaning forward, 5 mph under the limit.

The difference between unwrapping self and using optionals is more than just personal preference. If self is nil and you use a guard statement, then no code after the else statement will be executed. However, if you use self optionally in your closure, the lines of code in your closure without references to self will still be executed.

Conclusion

Swift is an essential part of the Kotlin Multiplatform mobile environment, so it's in your and your multiplatform mobile project's best interests to learn some of the finer points and best practices of Swift. Familiarity with concepts such as escaping closures and ARC will help you avoid some of the most common iOS-side mistakes in KMP projects. Those concepts are great jumping off points for learning more Swift. It's a truly fantastic language, capable of producing some of the most elegant and readable code that's out there.

Credit Where It's Due

Closures, escaping, and preventing reference cycles in general are highly visible discussion topics in the S/O Swift community. There are too many posts and answers to link here, but I strongly recommend that community at large as a resource.
https://docs.swift.org/swift-book/LanguageGuide/Closures.html
https://docs.swift.org/swift-book/LanguageGuide/AutomaticReferenceCounting.html#ID56
https://medium.com/flawless-app-stories/you-dont-always-need-weak-self-a778bec505ef
https://www.swiftbysundell.com/articles/capturing-objects-in-swift-closures/
https://medium.com/@bestiosdevelope/what-do-mean-escaping-and-nonescaping-closures-in-swift-d404d721f39d
https://fuckingclosuresyntax.com/
Wholesome version: http://goshdarnclosuresyntax.com/

Debug Kotlin with Xcode References

Ben Whitley — Wed, 13 May 2020 14:54:32 +0000

I’m going to share a very (very) simple, helpful, little trick if you want to debug a Kotlin shared framework within an iOS application. Adding Xcode references to the Kotlin files in your shared library will enable you to do frequently used development practices, such as setting breakpoints or opening files from a memory debugger.

Before getting started though, it’s important to note that your shared Kotlin framework needs to be dynamic for these file references to be useful. If it isn’t, then any breakpoints you set in your Kotlin files in Xcode will not be hit. Other debugging tools and practices will not yield useful results such as function names and line numbers.

If you don’t know how to get your shared Kotlin library to produce a dynamic framework, we’re using Touchlab’s fork of the Kotlin Multiplatform Cocoapods plugin.

Double or right click in the Project Navigator, which is the left side pane of Xcode that shows the project’s structure (shown below).

First select New Group from the dropdown and create a directory (“Kotlin Debug” in the example below). This is where we’re going to put the references.

Next, double or right click your new directory in the Project Navigator and select Add Files to [Directory Name].

In the Finder window that appears, navigate to your shared Kotlin library. Feel free to add as many of the library files as you like, but I recommend just [Shared Kotlin Library]/src/commonMain/ and [Shared Kotlin Library]/src/iosMain/. Together, those two directories contain all of the Kotlin files you may need to debug from your iOS application.

If you’re using Instruments to debug memory issues in your shared Kotlin library, then you may need to close and reopen Xcode before Instruments is able to open your Kotlin files in the Xcode window containing your iOS project.

Kotlin in iOS: Memory Debugging with Xcode and Instruments

Ben Whitley — Wed, 13 May 2020 14:54:00 +0000

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!

Kotlin Multiplatform: Expect/Actuals in Less Than Five Minutes

Ben Whitley — Wed, 11 Sep 2019 18:31:20 +0000

If you're reading this you've probably heard a lot about Kotlin Multiplatform, but aren't sure where to start. The platform is evolving fast, which means a lot of the docs are out of date, and/or can be a little overwhelming. But nobody likes reading the directions, so I'm writing a series of posts that take about 5 minutes each to run through, and introduce the basics on Kotlin Multiplatform.

Part 1 gets you starting from nothing. This is part 2, which focuses on expect/actual statements. Kotlin's native interop is one of its most distinguishing features. Unlike other "cross platform" ecosystems, Kotlin is designed to embrace the native platform it is integrating with. expect/actual statements are one of the main mechanisms it provides to do that.

Five minutes? Well, yes, if you've already gone through the previous Kotlin Multiplatform article and completed it. We're starting where Part 1 left off.

One area that requires platform-specific logic is dealing with dates. We're going to create a simple expect class, KMPDate, which takes a date format string and lets you create a formatted string representing today's date.

First, open /app/src/commonMain/kotlin/sample/Sample.kt. Underneath the Greeting class, create a new expect class:

expect class KMPDate(formatString: String) {
    fun asString(): String
}

The expect keyword declares that the common code can expect different actual implementations for each platform. In this case, expect applies to a class. However, it can also apply to functions, objects, annotations, etc. See here for more.

Go to /app/src/main/java/sample/SampleAndroid.kt to create the actual Android implementation. Underneath the MainActivity class, add the following:

actual class KMPDate actual constructor(formatString: String) { // 1

    private val dateFormat = SimpleDateFormat(formatString) // 2

    actual fun asString(): String {
        return dateFormat.format(Date()) // 3
    }
}

The expect declaration of KMPDate stated that it takes a formatString, so an actual constructor implementation accompanies the actual class implementation.
Create a SimpleDateFormat object using the formatString. iOS has an NSDateFormatter class, which is similar to SimpleDateFormat, but we'll get to later. There is currently no common Kotlin implementation, but for most things, Android and iOS have equivalent features available.
The SimpleDateFormat object formats Date() - which produces a Date object representing today's date - into a string.

Next, go to app/src/iosMain/kotlin/sample/SampleIos.kt, which is currently empty. Paste in the following:

actual class KMPDate actual constructor(formatString: String) { // 1

    private val dateFormatter = NSDateFormatter().apply { // 2
        this.dateFormat = formatString
    }

    actual fun asString(): String {
        return formatter.stringFromDate(NSDate()) // 3 
    }
}

Identical to the actual class declaration on the Android side.
Pass formatString into an iOS NSDateFormatter object, which - as mentioned earlier - achieves the same result as SimpleDateFormat on Android.
The NSDateFormatter object formats a string based on NSDate() - which produces an NSDate object representing today.

Finally, go back to /app/src/commonMain/kotlin/sample/Sample.kt. Inside of the Greeting class, create a KMPDate object that takes "MMM dd" as its date format:

private val date = KMPDate("MMM dd")

And last but not least, use string interpolation to insert the formatted date string from each platform into the value of hello():

fun hello(): String =  "Hello, Android and iOS worlds, today is ${date.asString()}!"

All done! Run you Android and iOS apps and see the dates displayed on each platform!

If you come from an iOS background and want a deeper explanation of how to use Kotlin Multiplatform to make a more involved app, then you might want to check out this article I wrote.

As you can see, it's all about starting small with Kotlin Multiplatform. We recently launched The Touchlab Refactory; an incremental refactoring service with KMP which focuses on a single feature at a time with no disruption to your current development workflow. Learn more here.

We're hiring!

Two Apps in Less than Five Minutes with Kotlin Multiplatform

Ben Whitley — Wed, 04 Sep 2019 15:53:29 +0000

If you’re reading this you’ve probably heard a lot about Kotlin Multiplatform, but aren’t sure where to start. The platform is evolving fast, which means a lot of the docs are out of date, and most of the tutorials seem to walk you through setting up projects and tools from scratch. But nobody likes reading the directions! We’re going to walk you through setting up some shared code in less than five minutes.

Prerequisite: We’ll cheat and not start the clock until you have Xcode 10.3+ and Android Studio 3.4.2 installed, and have an emulator installed and running for Android. For Xcode, find it on the Mac App Store here and install it. Not on a Mac? Well, none of this will work (you need a Mac).

For Android Studio, go here to get the app, follow instructions here to set it up, and the instructions to setup an Android emulator here. Ready? OK, now start the clock.

Clone this repository and open it in Android Studio. The project currently contains two separate Hello World applications: one for Android and iOS each. Run the Android app to see it display “Hello, Android world!”

Now, open /iosApp/iosApp.xcworkspace and run iosApp in the iOS simulator to see it display “Hello, iOS world!” Although they share a folder structure, these iOS and Android apps are separate from one another. Now we’ll join them together with Kotlin Multiplatform.

First, open /app/src/commonMain/kotlin/sample/Sample.kt, which contains the following common code:

class Greeting {
    fun hello(): String = "Hello, Android and iOS worlds!"
}

Next, open /app/src/main/java/sample/SampleAndroid.kt in Android Studio. It contains the Android version of the Hello World app. To make it into a KMP app, replace the value being assigned to textView.text — which is currently “Hello, Android world!” — and replace it with Greeting().hello().

Finally, go back to Xcode and open ViewController.swift. Underneath import UIKit, add import app, which is the name of the KMP library. Then, just like in the Android app, change the value being assigned to label.text from “Hello, iOS world!” to Greeting().hello(). Rerun both applications, and see them both displaying the same string!

“Hello, Android and iOS worlds!”

All done! Stop the clock! You’re a Kotlin Multiplatform developer now!

What are some good next steps? Try calling out to some native code with expect/actual statements, then add an existing multiplatform library like Ktor and do some networking.

If you come from an iOS background and want a deeper explanation of how to use Kotlin Multiplatform to make a more involved app, then you might want to check out this article I wrote.

As you can see, it’s all about starting small with Kotlin Multiplatform. We recently launched The Touchlab Refactory; an incremental refactoring service with KMP which focuses on a single feature at a time with no disruption to your current development workflow. Learn more here.