iOS 프레임워크가 빌드되는 방식

The iOS app ran, but how did Kotlin become something Swift can call? Let's follow the framework build step by step. 🔍

For iOS, Kotlin is not turned into JVM bytecode. The Kotlin/Native compiler produces real native machine code for Apple devices.

That native code is packaged as an Apple framework bundle. Xcode treats it just like any other linked framework in your project.

Alongside the binary, the compiler writes an Objective-C header. That header is what makes your Kotlin API visible to Swift.

Swift cannot read Kotlin directly. It reads the Objective-C header, so every shared class and function arrives through the interop layer.

A Gradle task assembles the framework on demand. The Xcode build phase simply invokes the right task for the current configuration.

The convenient task is embedAndSignAppleFrameworkForXcode. It builds, embeds, and code-signs the framework for the target Xcode picked.

Simulators and real devices use different CPUs, so the framework is built per architecture. Xcode passes the target so Gradle picks the right one.

Debug frameworks build fast and keep symbols. Release frameworks optimize and shrink, which is what you ship to the App Store.

Your shared build.gradle.kts sets the framework name. Swift then imports it under exactly that baseName.

Knowing this pipeline makes iOS feel less magical. Kotlin compiles native, wraps in a framework, and Swift calls it through a generated header.

Let's confirm how Swift can see your Kotlin API.

You saw the iOS pipeline: Kotlin/Native compiles to machine code, packages a framework with an Obj-C header, and Gradle's embedAndSign task wires it into Xcode. 🎉