SKIE: making a Kotlin Multiplatform library pleasant to call from Swift

The problem starts after you have already decided to share code

SKIE stands for Swift Kotlin Interface Enhancer, and it is a tool for Kotlin Multiplatform development that enhances the Swift API published from Kotlin.

The scope is narrow and that is the point. This is not a framework for sharing code between platforms. It is a step in a journey that has already been taken, the journey where a team has decided that some logic should be written once in Kotlin and consumed from an iOS codebase.

The interesting detail is the direction of the enhancement. Kotlin Multiplatform lets you publish an Objective-C API from a Kotlin library, because Objective-C is what the iOS toolchain can consume. But the generated Objective-C surface is not what a Swift developer would write by hand. The names are mechanical, the optionality is expressed in an Objective-C idiom rather than a Swift one, and a caller ends up writing adapter code to make the Kotlin API feel natural in Swift. SKIE enhances the published Swift API so that the natural Swift expression is the direct one.

So the tool sits exactly on the seam between two languages, and it does not try to move the seam. The Kotlin is still Kotlin and the Swift is still Swift, and what changes is the shape of the boundary.

The project is published from Touchlab, a company whose stated focus is the iOS developer experience, and the README says Touchlab has been helping teams adopt KMP since KMP was launched and has been dedicated to improving the iOS developer experience. That is the context the tool sits in, and the README points at their KMP iOS resource hub for background.

The project is written in Kotlin, the licence is Apache-2.0, and the current release is 0.10.15 from 2026-09-25 with the last push on 2026-10-08. A version in the zero tens over a long run of releases is a project that is actively evolving its output format rather than a stable tool with a settled surface.

Why the boundary problem shows up at all

It is worth being precise about the mechanics behind the problem, because the reason SKIE exists is a specific chain of technical decisions rather than a general taste for nicer APIs.

Kotlin Multiplatform publishes a shared library to several targets. On the Apple side, what iOS can consume is the Objective-C interface that the Kotlin compiler generates for the framework, and the Swift side then calls that Objective-C surface through the Swift importer.

The generated Objective-C is mechanical. Names are derived from Kotlin declarations by a set of rules, and optionality, defaults, collections and sealed hierarchies all get expressed in idioms that are correct for Objective-C and awkward for Swift. A sealed class becomes a class hierarchy that Swift code has to navigate. The result works, and calling it from Swift is verbose in a way that a Swift developer immediately notices.

The usual response is an adapter layer, hand written on the Swift side, wrapping the generated API in something nicer to use. That works too, and it is where the hundreds of lines of boilerplate in the Mapbox account come from. The cost is that the adapter is code someone has to write, keep in step with the Kotlin side, and test, and it is duplicated for every module.

SKIE's answer is to generate that nicer shape instead. The enhancement happens on the published Swift API rather than in a hand written layer, so the result is a Swift API that a developer would have written, without the per module adapter to maintain.

That distinction is the whole value proposition, and it is also why the tool has to be a build-time component rather than a library. To produce a different Swift API you have to intervene between the Kotlin compilation and the Objective-C generation, which is a place in the build that a normal dependency cannot reach.

What the repository layout says about how it works

The top level of the repository is a description of the mechanism, even without reading a line of the source.

There is a `SKIE/` directory, which is the tool itself. Then there are three directories that tell you the tool is not a single binary you run once. `build-setup-gradle-settings/` and `build-setup/` are the pieces that configure a project to use SKIE, in one case at the Gradle settings level, and `common-gradle/` holds shared Gradle configuration. A `dev-support/` directory holds the tooling for working on SKIE itself, and an `internal-docs/` directory holds documentation that is not published to the website.

The build setup directories are the significant part. A tool that enhances a published API has to be part of the compilation of the module that publishes it, and it has to run early enough in the build to rewrite the generated interface before the Swift side is generated. That is a compiler plugin, a Gradle plugin, or a build step, and the fact that the setup is split across a settings level directory and a general one suggests both are involved.

The `test-runner/` directory then explains how the output is checked. An interface enhancer that changes what Swift code compiles against needs its own tests, and the presence of a dedicated runner rather than a set of Gradle test tasks suggests the tests exercise the generated output rather than the Kotlin implementation.

The rest of the top level is small and conventional. There is a `README.md`, a `LICENSE` file, an `.editorconfig` and a `.gitignore`, a `skie-header.jpg` image, and a `.github/` directory for the workflows. There is no `src/` directory and no `docs/` directory at the top level, which is consistent with the documentation living in the separate `internal-docs/` directory and being published to the website by a different mechanism.

So the repository is small because most of the documentation was deliberately moved out of it, and the code is a compiler or build-time tool with a test runner of its own.

The Mapbox account, and the modularization test

The README carries one testimonial, and it is worth reading closely because of the specific conditions it describes.

SKIE, the open-source tool by Touchlab, has been invaluable for Kotlin Multiplatform development at Mapbox. It provided a solution for integrating Kotlin into Swift-based projects without friction. Thanks to SKIE's compile-time magic, we've removed hundreds of lines of boilerplate code, making our codebase cleaner and more maintainable. Remarkably, SKIE continues to perform flawlessly even after modularizing our project and integrating Compose Multiplatform.

The attribution is to Alex Azarov, Senior iOS Engineer at Mapbox, and Mapbox has a logo block in the README's users section alongside the quote.

Two claims in that quotation are worth separating, because they are different in kind.

The first is that the tool removes boilerplate, and the measure given is hundreds of lines. That is a claim about the size of the adapter layer, and it is the claim a team adopting the tool would care about most, because the adapters are the code that sits between the two languages and the code that has to be maintained when either side changes.

The second is about robustness, and it is the more interesting one. The claim is that the tool keeps working after the project was modularized and after Compose Multiplatform was integrated. Both of those are structural changes to the consuming project, and both are the kind of thing that breaks a build-time tool, because the tool has to find the right module in a graph that has just been rearranged,.

The phrase compile-time magic is doing real work in that quote too. It is the user's description of the mechanism, and it is consistent with what the repository layout implies. Whatever SKIE does, it does it during the build, not afterwards, which is why the result is a plain Swift API that a Swift developer consumes without thinking about the tool at all.

The README also lists the ways to support the project, starring the repository and providing a testimonial or logo, with a link to a discussions thread for the latter. That is how a project with a small number of visible users tries to make the usage visible, and it means the users section is a list of teams rather than a list of companies that shipped something similar.

What a reader has to go to the website for

The README is unusually short, and the reason is stated in the first paragraph of the tool description: see the documentation website for more info.

That means the repository does not answer the questions someone evaluating it would want answered. It does not say how the tool is wired into a Gradle build, which Gradle plugin to apply, what the configuration options are, what the generated Swift looks like, or what happens when a Kotlin declaration has a shape the tool cannot handle. The `internal-docs/` directory probably holds some of it, and the website at skie.touchlab.co holds the rest.

For a tool of this kind that is a defensible choice, because the documentation is a large body of reference material and it changes with the Kotlin version, and a README that goes stale is worse than one that points elsewhere. But it does mean you cannot evaluate SKIE from the repository alone, which is a real friction for anyone deciding whether to try it.

The topic tags give a narrower picture of the scope than the description does: ios, kotlin and kotlin-multiplatform. So the tool is aimed at the iOS side of a Kotlin Multiplatform project, which is consistent with everything else about Touchlab's focus and with the Mapbox quote.

The release cadence is the other thing visible from the repository alone, and it is steady. The recent releases are 0.10.13 on 2026-06-24, 0.10.14 on 2026-07-27 and 0.10.15 on 2026-09-25, with the last push on 2026-10-08. So roughly every six to eight weeks through the summer, with a push after the last release, which is the pattern of a tool that tracks the Kotlin releases it has to support rather than one that changes on its own schedule.

The practical consequence for an adopter is that you should expect to move with Kotlin releases, and you should check whether the version of SKIE you pick supports the Kotlin version your project is on. The version number being tied to a minor line rather than to the tool's own feature set is a signal of that dependency, whether or not the mapping is documented in the repository.

Editorial conclusion

SKIE fits a team that has already committed to Kotlin Multiplatform and is now fighting the friction of calling Kotlin from Swift, because the value of the tool is removing that friction rather than replacing the language boundary, and the Mapbox account describes it as having removed hundreds of lines of boilerplate. Skip it if you are still deciding whether to share code across platforms, since the problem it solves comes after that decision, and note that the README is deliberately short and points to the documentation site, so the details you need are not in the repository itself. Before you adopt it, read the documentation website and check the current release, since the version is 0.10.15 and the last push was on 2026-10-08, and put a spike in front of your team with a real module rather than a toy, since the Mapbox account specifically mentions that it kept working after the project was modularized and Compose Multiplatform was integrated.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. touchlab/SKIE on GitHub