SKIE vs Swift Export: How I’d Choose for a Production KMP Project

My answer was yes. I’ve used SKIE, tested it, and know what to expect from it. That familiarity matters when I’m responsible for delivering a client’s application.

But I also like trying new technology, and Swift Export is something I’d be interested in exploring on a completely new project. Whether I’d actually choose it would depend on the application, the team, and how much room the client has for experimentation.

That is where the SKIE vs Swift Export discussion becomes useful: understanding what each approach means for the Swift code your team will write, the architecture you will maintain, and the delivery commitments you have already made.

Key Takeaways

• SKIE would still be my starting point for a project where predictable delivery is the priority, because I have experience using it.
• I’d consider Swift Export for a new project after validating the application’s actual Kotlin–Swift boundary and agreeing on the risks with the client.
• Feature support is only part of the comparison. Generated APIs, cancellation, error handling, build integration, and upgrade compatibility need attention.
• A working SKIE integration needs a concrete reason to migrate. Cleaner syntax alone may not justify changes across an existing iOS codebase.
• Before choosing either approach, I’d review what the shared module exposes and whether that API serves the iOS application well.

Why Kotlin-Swift Interoperability Is an Architecture Decision

When a team decides to share business logic with Kotlin Multiplatform, it also needs to decide how the iOS application will consume that logic.

Consider a shared checkout feature. Kotlin might expose a state stream, functions for submitting an order, and models representing validation failures. The Swift application needs to observe those states, display errors, and manage the work when the user leaves the screen.

The boundary between those layers determines how much adaptation the iOS team has to maintain. It also determines where developers investigate problems when a request keeps running, a state update arrives unexpectedly, or a new Kotlin type changes the generated Swift API.

Start with the API the iOS Team Actually Uses

I’d begin by looking at the public surface of the shared module. Does Swift need access to repositories, database types, and internal dependency-injection objects, or could it work with a smaller feature-facing API?

A Kotlin API can be convenient for Android developers while creating unnecessary work for Swift consumers. Exporting more implementation detail increases the number of places where language differences can affect the application.

For teams evaluating Kotlin Multiplatform development, defining this boundary should be part of the architecture discussion before the iOS team builds screens around it.

How SKIE and Swift Export Approach the Problem

SKIE improves Kotlin–Swift interoperability through the existing Objective-C export path. It generates Swift-facing enhancements for features including enums, sealed hierarchies, suspend functions, and Flows. Its default-argument support generates overloads and is disabled by default because excessive use can increase generated code.

Swift Export takes a different export path, exposing Kotlin declarations through a Swift interface without relying on Objective-C headers. The current Kotlin documentation describes support for suspend functions, Flow-to-AsyncSequence conversion, and enum and sealed-hierarchy mappings.

Swift Export is still Alpha, and JetBrains warns that breaking changes are expected. Its documentation also lists integration and type-system constraints, including direct Xcode integration and generic type erasure.

That makes a feature checklist useful as an initial filter. I’d still need to see how the selected versions handle the application’s real API.

Compare the Generated Swift, Not Just the Kotlin Declarations

I’d take a representative feature and inspect the Swift code required to use it.

Can an iOS developer understand the available states? Are conversions concentrated in one adapter, or repeated throughout the UI? When a new result type appears in Kotlin, does the Swift compiler help identify the affected screens?

These questions connect interoperability to maintenance. A small inconvenience repeated across dozens of screens becomes an ongoing cost, while a clear boundary makes changes easier to review and contain.

Why SKIE Would Still Be My Starting Point

My preference for SKIE comes from having used and tested it. I can plan around a tool more confidently when I know how it behaves and understand the integration work it requires.

For an enterprise client with committed releases, that experience has practical value. The team needs to understand the likely work, identify problems early, and avoid introducing uncertainty without a clear benefit.

This is also how I think about Kotlin Multiplatform for enterprise projects: the technology decision has to account for the people maintaining the application and the commitments surrounding it.

Familiarity Still Needs Technical Validation

Choosing SKIE would not remove the need to check Kotlin, Swift, and Xcode compatibility. Touchlab documents a supported-version policy, so I’d include the project’s upgrade requirements in the assessment.

I’d also review the specific features the application relies on. For example, SKIE’s Flow documentation describes two-way cancellation, but also warns that custom exceptions escaping a Flow can cause a runtime crash.

For a checkout flow, I’d want expected failures represented deliberately in the boundary contract, with explicit handling for validation, connectivity, and cancellation. Installing an interoperability tool does not define that contract for the team.

When I’d Consider Swift Export for a New KMP Project

A new project gives us an opportunity to design the shared API and Swift integration together. There are fewer existing call sites to change, and we can evaluate assumptions before they become dependencies throughout the application.

That makes Swift Export worth exploring, provided the project has room for a bounded evaluation.

Client agreement matters, but I’d need to explain what we are asking the client to accept: which questions remain unanswered, how we will investigate them, and what happens if the approach does not meet the requirements.

Test One Complete Feature Before Committing

I’d choose a feature containing the boundary behaviors the application will depend on: asynchronous work, observable state, expected failures, and a platform-specific dependency if one is relevant.

For the checkout example, I’d test leaving the screen during submission, returning to it, losing connectivity, and receiving a response after the original UI task has ended. I’d inspect task cancellation, state ownership, and whether UI updates reach the appropriate execution context.

I’d then run the feature through the actual build and CI setup. A successful local demo is useful evidence, but the team also needs repeatable builds and a release process it can maintain.

Before the evaluation starts, I’d agree on its duration, acceptance criteria, and fallback. That turns interest in a new tool into a decision the client can assess.

SKIE vs Swift Export: What I’d Evaluate Before Choosing

These are the questions I’d use to structure the assessment.

I’d also measure build time or runtime behavior if the application has a relevant constraint. I would not recommend either tool on the assumption that its architecture automatically makes the product faster.

Would I Migrate an Existing SKIE Project to Swift Export?

If SKIE is working well, I’d first ask what problem the migration would solve.

There may be a worthwhile reason: an export limitation affecting the API, recurring adapter maintenance, or an integration requirement the current approach cannot satisfy cleanly. That gives us something concrete to evaluate.

I’d trace the affected Kotlin declarations through the generated interface to their Swift consumers. Existing wrappers, state observation, imports, error handling, and tests all belong in the scope.

Look for a Smaller Architecture Change First

Suppose the iOS team struggles with a deeply generic repository interface. Changing the export approach might still leave them consuming a contract designed around Kotlin implementation details.

A smaller feature-facing facade could be worth evaluating first. It may reduce the adaptation burden while keeping the existing integration intact.

The same reasoning applies to team coordination. I discussed this in Why iOS Teams Become the Bottleneck in KMP Projects: interoperability tooling improves how Swift consumes shared code, but teams still need clear ownership of the shared layer.

If every boundary change requires the iOS team to wait for another team, I’d investigate API ownership and review practices alongside the tooling.

Choosing an Approach for Your KMP Project

As an engineer, I’d like to try Swift Export. As the person responsible for delivery, I’d first want to understand what it changes for the application and whether the client is comfortable with the remaining uncertainty.

For a project where predictable delivery is the priority, I’d still start with SKIE because I have experience using it. For a new project with room to investigate, I’d be interested in testing Swift Export against a representative feature.

If you’re making this decision for your application, I can review the Kotlin–Swift boundary with your team: what the shared module exposes, how Swift consumes it, where adapters or ownership create friction, and which approach fits your build and release constraints.

The result would be a concrete recommendation on whether to keep the current setup, adjust the architecture, or evaluate a different export path, together with the changes and checks needed to move forward.

Talk to me about your KMP architecture. Share your current setup and the decision you’re trying to make, and mention that you’d like to discuss Kotlin-Swift interoperability with Aleksa.

Frequently Asked Questions About SKIE and Swift Export

Should I Use SKIE or Swift Export for a New Project?

I’d start with the application’s API, integration constraints, and delivery requirements. SKIE would be my starting point because I have experience with it. I’d explore Swift Export where the project allows a defined evaluation and the results support adoption.

Is Swift Export Ready for Every Production KMP Project?

I would assess it against the requirements of the particular project. Alpha status introduces uncertainty around future changes; acceptance should depend on validated behavior, maintenance capacity, and a fallback the team understands.

Does Switching Export Tools Mean Rewriting Shared Business Logic?

The first area I’d inspect is the exported API and its Swift consumers. Some projects may need boundary adjustments; others may expose types or behaviors that require broader changes. I’d estimate that scope from the code.