@ObjCName وواجهات API الملائمة لـ Swift

Your shared API should read naturally in Swift. A few annotations and habits make the bridge feel native, not bolted on.

The @ObjCName annotation lets you give a type or function a different name on the Swift side without renaming the Kotlin one.

Use @ObjCName on functions too, so a verbose Kotlin name becomes a short, idiomatic Swift call site that reads well.

Kotlin allows overloads that Obj-C cannot express. Renaming with @ObjCName prevents the mangled names Swift would otherwise see.

Mark internal helpers with @HiddenFromObjC so they never appear in the framework, keeping the Swift surface small and clean.

Kotlin default arguments do not cross the bridge, so Swift sees one full signature. Provide overloads if Swift needs choices.

Expose plain data classes and primitives at the boundary. Deep generics and sealed hierarchies get awkward for Swift callers.

A Kotlin isActive boolean reads great in Swift, but odd getter names can look clumsy, so name properties with Swift in mind.

Add KDoc on exported members. Some of it surfaces in Xcode, helping iOS devs use your shared API without guessing.

Open the generated header or a Swift file and actually read how your API looks. If it feels clunky, refine the annotations.

Thoughtful naming and hiding turn shared Kotlin into an API Swift devs enjoy, making cross-team work smooth and friendly.

Shape exports with @ObjCName and @HiddenFromObjC, favor simple types, and read the real Swift call sites. A friendly bridge wins. 🎉