Skip to content

Swift/Objective-C との相互運用

DANGER

Objective-Cライブラリのインポートは実験的です。

cinterop ツールによってObjective-Cライブラリから生成されるすべてのKotlin宣言には、@ExperimentalForeignApi アノテーションを付加する必要があります。

Kotlin/Nativeに同梱されているネイティブプラットフォームライブラリ(Foundation、UIKit、POSIXなど)は、一部のAPIでのみオプトインが必要です。

Kotlin/Nativeは、Objective-Cを介してSwiftとの間接的な相互運用を提供します。このドキュメントでは、Kotlin宣言をSwift/Objective-Cコードで使用する方法と、Objective-C宣言をKotlinコードで使用する方法について説明します。

その他に役立つリソースは以下のとおりです。

Swift/Objective-CライブラリのKotlinへのインポート

Objective-Cフレームワークおよびライブラリは、ビルドに適切にインポートされていれば(システムフレームワークはデフォルトでインポートされます)、Kotlinコードで使用できます。 詳細については、以下を参照してください。

Swiftライブラリは、そのAPIが@objcでObjective-Cにエクスポートされていれば、Kotlinコードで使用できます。 純粋なSwiftモジュールはまだサポートされていません。

Swift/Objective-CでのKotlinの使用

Kotlinモジュールは、フレームワークにコンパイルされていれば、Swift/Objective-Cコードで使用できます。

Kotlin宣言をObjective-CおよびSwiftから非表示にする

DANGER

@HiddenFromObjC アノテーションは実験的であり、オプトインが必要です。

KotlinコードをよりSwift/Objective-Cフレンドリーにするには、@HiddenFromObjC アノテーションを使用してKotlin宣言をObjective-CおよびSwiftから非表示にします。これにより、関数またはプロパティのObjective-Cへのエクスポートが無効になります。

あるいは、internal 修飾子でKotlin宣言をマークして、コンパイルモジュールでの可視性を制限することもできます。他のKotlinモジュールに対して可視性を保ちつつ、Objective-CおよびSwiftからKotlin宣言を非表示にしたい場合は、@HiddenFromObjC を使用してください。

Kotlin-Swift interopediaの例を参照してください

Swiftでの洗練の使用

DANGER

@ShouldRefineInSwift アノテーションは実験的であり、オプトインが必要です。

@ShouldRefineInSwift は、Kotlin宣言をSwiftで書かれたラッパーに置き換えるのに役立ちます。このアノテーションは、生成されたObjective-C APIで関数またはプロパティをswift_privateとしてマークします。そのような宣言には __ 接頭辞が付けられ、Swiftからは見えなくなります。

これらの宣言は引き続きSwiftコードでSwiftフレンドリーなAPIを作成するために使用できますが、Xcodeのオートコンプリートでは提案されません。

宣言名の変更

DANGER

@ObjCName アノテーションは実験的であり、オプトインが必要です。

Kotlin宣言の名前変更を避けるには、@ObjCName アノテーションを使用します。これにより、Kotlinコンパイラは、アノテーションが付けられたクラス、インターフェース、またはその他のKotlinエンティティにカスタムのObjective-CおよびSwift名を使用するように指示されます。

kotlin
@ObjCName(swiftName = "MySwiftArray")
class MyKotlinArray {
    @ObjCName("index")
    fun indexOf(@ObjCName("of") element: String): Int = TODO()
}

// Usage with the ObjCName annotations
let array = MySwiftArray()
let index = array.index(of: "element")

Kotlin-Swift interopediaの別の例を参照してください

KDocコメントによるドキュメントの提供

ドキュメントは、APIを理解するために不可欠です。共有Kotlin APIのドキュメントを提供することで、そのユーザーと使用方法、すべきこと、すべきでないことなどについてコミュニケーションをとることができます。

デフォルトでは、KDocsコメントは、Objective-Cヘッダーの生成時に対応するコメントに変換されません。たとえば、KDocを含む次のKotlinコードは、

kotlin
/**
 * Prints the sum of the arguments.
 * Properly handles the case when the sum doesn't fit in 32-bit integer.
 */
fun printSum(a: Int, b: Int) = println(a.toLong() + b)

コメントのないObjective-C宣言を生成します。

objc
+ (void)printSumA:(int32_t)a b:(int32_t)b __attribute__((swift_name("printSum(a:b:)")));

KDocコメントのエクスポートを有効にするには、build.gradle(.kts) に次のコンパイラオプションを追加します。

kotlin
kotlin {
    targets.withType<org.jetbrains.kotlin.gradle.plugin.mpp.KotlinNativeTarget> {
        compilations.get("main").compilerOptions.options.freeCompilerArgs.add("-Xexport-kdoc")
    }
}
groovy
kotlin {
    targets.withType(org.jetbrains.kotlin.gradle.plugin.mpp.KotlinNativeTarget) {
        compilations.get("main").compilerOptions.options.freeCompilerArgs.add("-Xexport-kdoc")
    }
}

その後、Objective-Cヘッダーには対応するコメントが含まれます。

objc
/**
 * Prints the sum of the arguments.
 * Properly handles the case when the sum doesn't fit in 32-bit integer.
 */
+ (void)printSumA:(int32_t)a b:(int32_t)b __attribute__((swift_name("printSum(a:b:)")));

たとえばXcodeで、オートコンプリート時にクラスやメソッドのコメントを見ることができます。関数の定義(.hファイル)に移動すると、@param@returnなどのコメントが表示されます。

既知の制限事項:

DANGER

生成されたObjective-CヘッダーにKDocコメントをエクスポートする機能は実験的です。

いつでも削除または変更される可能性があります。

オプトインが必要であり(詳細は下記を参照)、評価目的でのみ使用してください。

YouTrackでのフィードバックをお待ちしております。

  • 依存関係のドキュメントは、それ自体が-Xexport-kdocでコンパイルされない限りエクスポートされません。この機能は実験的なため、このオプションでコンパイルされたライブラリは他のコンパイラバージョンと互換性がない場合があります。
  • KDocコメントはほとんどそのままエクスポートされます。@propertyなどの多くのKDoc機能はサポートされていません。

マッピング

以下の表は、Kotlinの概念がSwift/Objective-Cに、またその逆方向でどのようにマッピングされるかを示しています。

"->"と"<-"は、マッピングが一方向のみであることを示します。

KotlinSwiftObjective-C注記
classclass@interface
interfaceprotocol@protocol
constructor/createInitializerInitializer
PropertyPropertyProperty注1注2
MethodMethodMethod注1注2
enum classclass@interface
suspend ->completionHandler:/ asynccompletionHandler:注1注2
@Throws funthrowserror:(NSError**)error
ExtensionExtensionCategory member
companion member <-Class method or propertyClass method or property
nullnilnil
Singletonshared or companion propertyshared or companion property
Primitive typePrimitive type / NSNumber
Unit return typeVoidvoid
StringStringNSString
StringNSMutableStringNSMutableString
ListArrayNSArray
MutableListNSMutableArrayNSMutableArray
SetSetNSSet
MutableSetNSMutableSetNSMutableSet
MapDictionaryNSDictionary
MutableMapNSMutableDictionaryNSMutableDictionary
Function typeFunction typeBlock pointer type
Inline classesUnsupportedUnsupported

クラス

名前変換

Objective-Cクラスは、元の名前でKotlinにインポートされます。 プロトコルは、Protocol という名前のサフィックスを持つインターフェースとしてインポートされます(例: @protocol Foo -> interface FooProtocol)。 これらのクラスとインターフェースは、ビルド構成で指定されたパッケージ(事前設定されたシステムフレームワークの場合はplatform.*パッケージ)に配置されます。

Kotlinのクラスとインターフェースの名前は、Objective-Cにインポートされる際に接頭辞が付けられます。 接頭辞はフレームワーク名から派生します。

Objective-Cはフレームワーク内のパッケージをサポートしていません。Kotlinコンパイラが同じフレームワーク内で、同じ名前だが異なるパッケージを持つKotlinクラスを見つけた場合、それらの名前を変更します。このアルゴリズムはまだ安定しておらず、Kotlinのリリース間で変更される可能性があります。これを回避するには、競合するKotlinクラスの名前をフレームワーク内で変更します。

強参照リンク

KotlinソースでObjective-Cクラスを使用するたびに、それは強参照リンクされたシンボルとしてマークされます。結果として生成されるビルド成果物には、関連するシンボルが強力な外部参照として記載されます。

これは、アプリが起動時にシンボルを動的にリンクしようとし、利用できない場合はアプリがクラッシュすることを意味します。 クラッシュは、シンボルが一度も使用されなかった場合でも発生します。シンボルは特定のデバイスやOSバージョンで利用できない場合があります。

この問題を回避し、「Symbol not found」エラーを避けるには、クラスが実際に利用可能かどうかをチェックするSwiftまたはObjective-Cのラッパーを使用してください。Compose Multiplatformフレームワークでこの回避策がどのように実装されたかを参照してください

イニシャライザ

Swift/Objective-Cのイニシャライザは、Kotlinにはコンストラクタまたはcreateという名前のファクトリメソッドとしてインポートされます。 後者は、Kotlinに拡張コンストラクタの概念がないため、Objective-CカテゴリまたはSwift拡張で宣言されたイニシャライザで発生します。

TIP

SwiftのイニシャライザをKotlinにインポートする前に、@objcでアノテーションを付けることを忘れないでください。

Kotlinのコンストラクタは、Swift/Objective-Cにイニシャライザとしてインポートされます。

セッタ

スーパークラスの読み取り専用プロパティをオーバーライドする書き込み可能なObjective-Cプロパティは、プロパティfooに対するsetFoo()メソッドとして表現されます。これは、可変として実装されるプロトコルの読み取り専用プロパティにも当てはまります。

トップレベル関数とプロパティ

トップレベルのKotlin関数とプロパティは、特殊なクラスのメンバとしてアクセスできます。 各Kotlinファイルは、そのようなクラスに変換されます。例えば、

kotlin
// MyLibraryUtils.kt
package my.library

fun foo() {}

次に、Swiftからfoo()関数をこのように呼び出すことができます。

swift
MyLibraryUtilsKt.foo()

Kotlin-Swift interopediaには、トップレベルのKotlin宣言にアクセスする例が多数掲載されています。

メソッド名の変換

一般的に、Swiftの引数ラベルとObjective-Cのセレクタピースは、Kotlinのパラメータ名にマッピングされます。これら2つの概念は意味が異なるため、Swift/Objective-Cメソッドが競合するKotlinシグネチャでインポートされることがあります。 この場合、競合するメソッドは、名前付き引数を使用してKotlinから呼び出すことができます。例えば、

swift
[player moveTo:LEFT byMeters:17]
[player moveTo:UP byInches:42]

Kotlinでは、次のようになります。

kotlin
player.moveTo(LEFT, byMeters = 17)
player.moveTo(UP, byInches = 42)

kotlin.Any関数がSwift/Objective-Cにどのようにマッピングされるかを以下に示します。

KotlinSwiftObjective-C
equals()isEquals(_:)isEquals:
hashCode()hashhash
toString()descriptiondescription

Kotlin-Swift interopediaのデータクラスの例を参照してください

Kotlin宣言を名前変更する代わりに、@ObjCNameアノテーションを使用して、SwiftまたはObjective-Cでよりイディオム的な名前を指定できます。

エラーと例外

すべてのKotlin例外は非チェック例外であり、エラーは実行時にキャッチされます。しかし、Swiftはコンパイル時に処理されるチェック例外のみを持ちます。したがって、SwiftまたはObjective-Cコードが例外をスローするKotlinメソッドを呼び出す場合、そのKotlinメソッドには、"予期される"例外クラスのリストを指定する@Throwsアノテーションを付ける必要があります。

Swift/Objective-Cフレームワークにコンパイルする場合、@Throwsアノテーションを持つ、または継承する非suspend関数は、Objective-CではNSError*を生成するメソッドとして、Swiftではthrowsメソッドとして表現されます。 suspend関数の表現には、常にcompletion handlerにNSError*/Errorパラメータが含まれます。

Swift/Objective-Cコードから呼び出されたKotlin関数が、@Throwsで指定されたクラスのいずれかのインスタンス、またはそのサブクラスの例外をスローした場合、その例外はNSErrorとして伝播されます。 Swift/Objective-Cに到達するその他のKotlin例外は未処理と見なされ、プログラムの終了を引き起こします。

@Throwsのないsuspend関数は、CancellationExceptionのみを伝播します(NSErrorとして)。 @Throwsのない非suspend関数は、Kotlin例外をまったく伝播しません。

なお、逆方向の変換はまだ実装されていません。Swift/Objective-Cのエラースローメソッドは、Kotlinに例外スローとしてインポートされません。

Kotlin-Swift interopediaの例を参照してください

列挙型

Kotlinの列挙型は、Objective-Cには@interfaceとして、Swiftにはclassとしてインポートされます。 これらのデータ構造には、各列挙値に対応するプロパティがあります。このKotlinコードを考えてみましょう。

kotlin
// Kotlin
enum class Colors {
    RED, GREEN, BLUE
}

この列挙型クラスのプロパティには、Swiftから次のようにアクセスできます。

swift
// Swift
Colors.red
Colors.green
Colors.blue

Swiftのswitch文でKotlin列挙型の変数を使用するには、コンパイルエラーを防ぐためにデフォルトの文を提供します。

swift
switch color {
    case .red: print("It's red")
    case .green: print("It's green")
    case .blue: print("It's blue")
    default: fatalError("No such color")
}

Kotlin-Swift interopediaの別の例を参照してください

Suspend関数

DANGER

Swiftコードからsuspend関数をasyncとして呼び出すサポートは実験的です。

いつでも削除または変更される可能性があります。

評価目的でのみ使用してください。YouTrackでのフィードバックをお待ちしております。

Kotlinのサスペンド関数 (suspend) は、生成されたObjective-Cヘッダーではコールバックを持つ関数として、Swift/Objective-Cの用語ではcompletion handlerを持つ関数として表現されます。

Swift 5.5以降、Kotlinのsuspend関数は、completion handlerを使用せずにSwiftからasync関数として呼び出すことも可能です。現在、この機能は非常に実験的であり、特定の制限があります。詳細については、このYouTrackの問題を参照してください。

拡張機能とカテゴリメンバ

Objective-CカテゴリとSwift拡張のメンバは、一般的にKotlinには拡張としてインポートされます。そのため、これらの宣言はKotlinでオーバーライドできず、拡張イニシャライザはKotlinコンストラクタとしては利用できません。

NOTE

現在、2つの例外があります。Kotlin 1.8.20以降、NSViewクラス(AppKitフレームワークから)またはUIViewクラス(UIKitフレームワークから)と同じヘッダーで宣言されたカテゴリメンバは、これらのクラスのメンバとしてインポートされます。これは、NSViewまたはUIViewをサブクラス化するメソッドをオーバーライドできることを意味します。

「通常の」KotlinクラスへのKotlin拡張は、SwiftとObjective-Cにそれぞれ拡張とカテゴリメンバとしてインポートされます。他の型へのKotlin拡張は、追加のレシーバパラメータを持つトップレベル宣言として扱われます。これらの型には以下が含まれます。

  • Kotlin String
  • Kotlinコレクション型とそのサブタイプ
  • Kotlin interface
  • Kotlinプリミティブ型
  • Kotlin inlineクラス
  • Kotlin Any
  • Kotlin関数型とそのサブタイプ
  • Objective-Cクラスとプロトコル

Kotlin-Swift interopediaの例集を参照してください

Kotlinシングルトン

Kotlinシングルトン(object宣言、companion objectを含む)は、単一インスタンスのクラスとしてSwift/Objective-Cにインポートされます。

インスタンスはsharedおよびcompanionプロパティを通じて利用できます。

以下のKotlinコードの場合:

kotlin
object MyObject {
    val x = "Some value"
}

class MyClass {
    companion object {
        val x = "Some value"
    }
}

これらのオブジェクトには次のようにアクセスします。

swift
MyObject.shared
MyObject.shared.x
MyClass.companion
MyClass.Companion.shared

NOTE

Objective-Cで[MySingleton mySingleton]、SwiftでMySingleton()を通じてオブジェクトにアクセスすることは非推奨になりました。

Kotlin-Swift interopediaでさらに多くの例を参照してください。

プリミティブ型

Kotlinのプリミティブ型ボックスは、特殊なSwift/Objective-Cクラスにマッピングされます。たとえば、kotlin.Intボックスは、SwiftではKotlinIntクラスインスタンスとして表現されます(またはObjective-Cでは${prefix}Intインスタンスとして、ここでprefixはフレームワークの名前接頭辞です)。 これらのクラスはNSNumberから派生しているため、インスタンスは対応するすべての操作をサポートする適切なNSNumberです。

NSNumber型は、Swift/Objective-Cのパラメータ型または戻り値として使用される場合、Kotlinのプリミティブ型に自動的に変換されません。その理由は、NSNumber型がラップされたプリミティブ値の型に関する十分な情報を提供しないためです。たとえば、NSNumberByteBoolean、またはDoubleであることが静的に不明な場合があります。したがって、Kotlinのプリミティブ値は、手動でNSNumberへキャストしたり、NSNumberからキャストしたりする必要があります。

文字列

KotlinのStringがSwiftに渡されると、まずObjective-Cオブジェクトとしてエクスポートされ、その後SwiftコンパイラがSwift変換のためにもう一度コピーします。これにより、追加のランタイムオーバーヘッドが発生します。

これを避けるには、Kotlinの文字列をSwiftで直接Objective-CのNSStringとしてアクセスします。 変換例を参照してください

NSMutableString

NSMutableString Objective-CクラスはKotlinからは利用できません。 NSMutableStringのすべてのインスタンスは、Kotlinに渡されるときにコピーされます。

コレクション

Kotlin -> Objective-C -> Swift

KotlinのコレクションがSwiftに渡されると、まずObjective-Cの同等物に変換され、その後Swiftコンパイラがコレクション全体をコピーし、マッピング表に記載されているようにSwiftネイティブコレクションに変換します。

この最後の変換はパフォーマンスコストにつながります。これを防ぐには、SwiftでKotlinコレクションを使用する際に、明示的にそれらをObjective-Cの対応する型(NSDictionaryNSArray、またはNSSet)にキャストします。

変換例を参照

たとえば、次のKotlin宣言:

kotlin
val map: Map<String, String>

Swiftでは、次のようになるかもしれません:

Swift
map[key]?.count ?? 0

ここでは、mapは暗黙的にSwiftのDictionaryに変換され、その文字列値はSwiftのStringにマッピングされます。 これにより、パフォーマンスコストが発生します。

変換を避けるには、mapを明示的にObjective-CのNSDictionaryにキャストし、代わりに値をNSStringとしてアクセスします。

Swift
let nsMap: NSDictionary = map as NSDictionary
(nsMap[key] as? NSString)?.length ?? 0

これにより、Swiftコンパイラが追加の変換ステップを実行しないように保証されます。

Swift -> Objective-C -> Kotlin

Swift/Objective-Cコレクションは、マッピング表に記載されているようにKotlinにマッピングされますが、NSMutableSetおよびNSMutableDictionaryは例外です。

NSMutableSetはKotlinのMutableSetに変換されません。オブジェクトをKotlin MutableSetに渡すには、この種類のKotlinコレクションを明示的に作成します。これを行うには、たとえばKotlinのmutableSetOf()関数、またはSwiftのKotlinMutableSetクラスとObjective-Cの${prefix}MutableSetprefixはフレームワーク名のプレフィックス)を使用します。 MutableMapについても同様です。

Kotlin-Swift interopediaの例を参照してください

関数型

Kotlinの関数型オブジェクト(例えばラムダ)は、Swiftでは関数に、Objective-Cではブロックに変換されます。 Kotlin-Swift interopediaのラムダを持つKotlin関数の例を参照してください

ただし、関数と関数型の変換では、パラメータと戻り値の型のマッピング方法に違いがあります。後者の場合、プリミティブ型はボックス化された表現にマッピングされます。KotlinのUnit戻り値は、Swift/Objective-Cでは対応するUnitシングルトンとして表現されます。このシングルトンの値は、他のKotlinのobjectと同様の方法で取得できます。上記の表のシングルトンを参照してください。

次のKotlin関数を考えてみましょう。

kotlin
fun foo(block: (Int) -> Unit) { ... }

これはSwiftで次のように表現されます。

swift
func foo(block: (KotlinInt) -> KotlinUnit)

そして、次のように呼び出すことができます。

kotlin
foo {
    bar($0 as! Int32)
    return KotlinUnit()
}

ジェネリクス

Objective-Cは、クラスで定義された「軽量ジェネリクス」をサポートしており、機能セットは比較的限定的です。Swiftは、クラスで定義されたジェネリクスをインポートして、コンパイラに追加の型情報を提供するのに役立ちます。

Objective-CとSwiftのジェネリクス機能サポートはKotlinとは異なるため、変換は必然的に一部の情報を失いますが、サポートされている機能は意味のある情報を保持します。

SwiftでKotlinジェネリクスを使用する方法の具体的な例については、Kotlin-Swift interopediaを参照してください。

制限事項

Objective-Cジェネリクスは、KotlinまたはSwiftのすべての機能をサポートしていないため、変換時に一部の情報が失われます。

ジェネリクスはクラス上でのみ定義でき、インターフェース(Objective-CとSwiftのプロトコル)や関数上では定義できません。

Null許容性

KotlinとSwiftはどちらも型指定の一部としてnull許容性を定義しますが、Objective-Cは型のメソッドとプロパティでnull許容性を定義します。したがって、次のKotlinコードは、

kotlin
class Sample<T>() {
    fun myVal(): T
}

Swiftでは次のように見えます。

swift
class Sample<T>() {
    fun myVal(): T?
}

null許容型をサポートするには、Objective-CヘッダーでmyValをnull許容の戻り値で定義する必要があります。

これを軽減するには、ジェネリッククラスを定義する際に、ジェネリック型が_決して_nullであってはならない場合は、非nullの型制約を提供します。

kotlin
class Sample<T : Any>() {
    fun myVal(): T
}

これにより、Objective-CヘッダーがmyValを非nullとしてマークするよう強制されます。

共変性/反変性

Objective-Cでは、ジェネリクスを共変または反変として宣言できます。Swiftには共変性/反変性のサポートはありません。Objective-Cから来るジェネリッククラスは、必要に応じて強制キャストできます。

kotlin
data class SomeData(val num: Int = 42) : BaseData()
class GenVarOut<out T : Any>(val arg: T)
swift
let variOut = GenVarOut<SomeData>(arg: sd)
let variOutAny : GenVarOut<BaseData> = variOut as! GenVarOut<BaseData>

制約

Kotlinでは、ジェネリック型に上限を提供できます。Objective-Cもこれをサポートしていますが、より複雑なケースではそのサポートが利用できず、現在のKotlin-Objective-C相互運用ではサポートされていません。ここでの例外は、非nullの上限がObjective-Cのメソッド/プロパティを非nullにするという点です。

無効化

ジェネリクスなしでフレームワークヘッダーを書き込むには、ビルドファイルに次のコンパイラオプションを追加します。

kotlin
binaries.framework {
    freeCompilerArgs += "-Xno-objc-generics"
}

前方宣言

前方宣言をインポートするには、objcnames.classes および objcnames.protocols パッケージを使用します。例えば、library.package を持つ Objective-C ライブラリで宣言された objcprotocolName 前方宣言をインポートするには、特殊な前方宣言パッケージである import objcnames.protocols.objcprotocolName を使用します。

2つのobjcinteropライブラリを考えます。一方は objcnames.protocols.ForwardDeclaredProtocolProtocol を使用し、もう一方は別のパッケージに実際の実装を持っています。

ObjC
// First objcinterop library
#import <Foundation/Foundation.h>

@protocol ForwardDeclaredProtocol;

NSString* consumeProtocol(id<ForwardDeclaredProtocol> s) {
    return [NSString stringWithUTF8String:"Protocol"];
}
ObjC
// Second objcinterop library
// Header:
#import <Foundation/Foundation.h>
@protocol ForwardDeclaredProtocol
@end
// Implementation:
@interface ForwardDeclaredProtocolImpl : NSObject <ForwardDeclaredProtocol>
@end

id<ForwardDeclaredProtocol> produceProtocol() {
    return [ForwardDeclaredProtocolImpl new];
}

2つのライブラリ間でオブジェクトを転送するには、Kotlinコードで明示的なasキャストを使用します。

kotlin
// Kotlin code:
fun test() {
    consumeProtocol(produceProtocol() as objcnames.protocols.ForwardDeclaredProtocolProtocol)
}

NOTE

objcnames.protocols.ForwardDeclaredProtocolProtocolへのキャストは、対応する実際のクラスからのみ可能です。

そうしないと、エラーが発生します。

マッピングされた型間のキャスト

Kotlinコードを記述する際、オブジェクトをKotlin型から対応するSwift/Objective-C型に(またはその逆に)変換する必要がある場合があります。この場合、通常のKotlinキャストを使用できます。例えば、

kotlin
val nsArray = listOf(1, 2, 3) as NSArray
val string = nsString as String
val nsNumber = 42 as NSNumber

サブクラス化

Swift/Objective-CからのKotlinクラスとインターフェースのサブクラス化

Kotlinのクラスとインターフェースは、Swift/Objective-Cのクラスとプロトコルによってサブクラス化できます。

KotlinからのSwift/Objective-Cクラスとプロトコルのサブクラス化

Swift/Objective-Cのクラスとプロトコルは、Kotlinのfinalクラスでサブクラス化できます。finalではないKotlinクラスがSwift/Objective-C型を継承することはまだサポートされていないため、Swift/Objective-C型を継承する複雑なクラス階層を宣言することはできません。

通常のメソッドは、override Kotlinキーワードを使用してオーバーライドできます。この場合、オーバーライドするメソッドは、オーバーライドされるメソッドと同じパラメータ名を持つ必要があります。

UIViewControllerをサブクラス化する際など、イニシャライザをオーバーライドする必要がある場合があります。Kotlinコンストラクタとしてインポートされたイニシャライザは、@OverrideInitアノテーションでマークされたKotlinコンストラクタによってオーバーライドできます。

swift
class ViewController : UIViewController {
    @OverrideInit constructor(coder: NSCoder) : super(coder)

    ...
}

オーバーライドするコンストラクタは、オーバーライドされるコンストラクタと同じパラメータ名と型を持つ必要があります。

競合するKotlinシグネチャを持つ異なるメソッドをオーバーライドするには、クラスに@ObjCSignatureOverrideアノテーションを追加できます。このアノテーションは、Objective-Cクラスから同じ引数型だが異なる引数名を持つ複数の関数が継承される場合に、Kotlinコンパイラに競合するオーバーロードを無視するように指示します。

デフォルトでは、Kotlin/Nativeコンパイラは、非指定Objective-Cイニシャライザをsuper()コンストラクタとして呼び出すことを許可していません。指定されたイニシャライザがObjective-Cライブラリで適切にマークされていない場合、この動作は不便なことがあります。これらのコンパイラチェックを無効にするには、ライブラリの.defファイルdisableDesignatedInitializerChecks = trueを追加します。

C機能

ライブラリがunsafeポインタ、構造体などの一部のプレーンC機能を使用する例については、Cとの相互運用を参照してください。

未サポート

Kotlinプログラミング言語の一部の機能は、Objective-CまたはSwiftのそれぞれの機能にまだマッピングされていません。 現在、以下の機能は生成されたフレームワークヘッダーで適切に公開されていません。

  • インラインクラス(引数は基となるプリミティブ型またはidにマッピングされます)
  • 標準Kotlinコレクションインターフェース(ListMapSet)およびその他の特殊なクラスを実装するカスタムクラス
  • Objective-CクラスのKotlinサブクラス