iOS 프레임워크 프로파일링과 축소

Your Kotlin code ships to iOS as a binary framework. A bloated one slows app launch and eats download size, so trimming it pays off.

You cannot shrink what you have not measured. Check the built .framework file size so every later change has a number to compare against.

Always profile the release framework. Debug builds skip optimization and carry extra symbols, giving you misleading, much larger sizes.

Symbol tables help debugging but bloat the binary. Stripping them for production shrinks the framework with no effect on behavior.

Every library you pull into commonMain rides along to iOS. Each dependency adds bytes, so drop ones you do not truly need.

The Kotlin/Native compiler prunes unreachable code. Keeping your public API small helps it strip more of what iOS never calls.

Mark internal helpers as internal, not public. Exported declarations cannot be removed, so a tight surface means a leaner binary.

Size is one thing, speed another. Use Xcode Instruments to see how long loading and initializing the framework actually takes.

Code that runs at framework load adds launch lag. Keep initialization lazy so work happens only when the feature is first used.

Apple dropped bitcode, so you no longer carry it. Make sure old build settings are not still bloating your framework for nothing.

Sizes creep up quietly. Record the framework size in CI so a sudden jump flags the commit that added the weight.

Recall which build configuration gives a trustworthy size reading.

You measured the release framework, stripped symbols, trimmed dependencies and the public API, profiled launch in Instruments, and tracked size in CI. 📉