استخدام أطر Apple من Kotlin

Kotlin/Native ships with ready-made bindings for Apple platforms. From iosMain you can call Foundation, UIKit and more directly in Kotlin. 🍎

Every Apple framework lives under a platform package. Import platform.Foundation, platform.UIKit, or platform.CoreLocation just like any Kotlin package.

Try NSDate. Creating one gives you the current moment, exactly as Swift would, but the code stays in your shared iosMain source set.

Need the device name or OS version? UIDevice.currentDevice hands it over so platform code reads naturally in Kotlin.

These bindings exist only on iOS targets. Put any Apple-framework call in iosMain, never in commonMain, or the Android build breaks.

The Kotlin/Native compiler reads Apple headers and generates Kotlin signatures. An Objective-C class arrives as a normal Kotlin class you can construct.

Objective-C selectors turn into Kotlin functions. A long selector like stringWithFormat: becomes a tidy named function you call the usual way. ✨

Apple nullability annotations map to Kotlin types. A nullable Objective-C value becomes a Kotlin nullable type, so the compiler still guards you.

Framework constants and enums come across too. An NSError domain string or an enum case is reachable straight from Kotlin code.

Bindings track an iOS SDK version. Newer Apple APIs only appear if your deployment target and SDK are recent enough to expose them.

Call Apple APIs in a small iosMain wrapper, then expose a clean Kotlin result. Hiding platform detail behind one function keeps shared code tidy.

A quick one on where Apple framework calls belong.

You saw that Kotlin/Native exposes Apple frameworks under platform packages, callable from iosMain with familiar Kotlin syntax. Keep them behind a thin wrapper. 🎉