Swift用にObjective-Cフレームワークを洗練させる

Swift用にObjective-Cフレームワークを洗練させる

Objective-CのヘッダーをSwift内で美しく動くよう、洗練させましょう。扱いの難しいObjective-Cフレームワークを、使い心地の良いAPIに転換する方法をお伝えします。より豊富な型情報、慣用名、Swiftへのより良いエラーを提供するために使うことのできる注釈の置き場についてご説明します。まだあなたが気がついていないかもしれないSwift APIを正しく動かすためのカギを握るObjective-Cのコンベンションについてもご紹介します。このセッションを最大限に活用するには、SwiftとObjective-Cに慣れていることが望ましいです。 SwiftとObjective-Cでできることについてのさらなる情報は、Developer Documentationでご確認ください。またWWDC18 の “Behind the Scenes of the Xcode Build Process”も合わせてご覧ください。

リソース
- Objective-C and C Code Customization
- - HDビデオ
  - SDビデオ
ダウンロード

こんにちは WWDCへようこそ “Swift用にObjective-Cフレームワークを洗練させる” Swift Compilerチームのブレントですこのセッションでは― Swift用にObjective-Cフレームワークを洗練させる方法についてお話しします私たちは６年前のこの月に初めて Swiftを導入しましたそれ以来すごいことが起こっています大勢がSwiftのデベロッパになったのですただしAppleのプラットフォームが長い間― Objective-C限定プラットフォームとして使われていたため多くのユーザーは Swiftをすぐには導入できませんでした多くのユーザーが今でも使っている Objective-Cコードを― 使うSwiftクライアントは増え続けています
Appleは同じ状況を共有しているからだと思います Appleは世界一多くのObjective-C フレームワークを持っているでしょう Objective-Cフレームワークをインポートするだけでなく― より“こなれた”Swift APIに変換するように設計しましたマクロとキーワードをヘッダーファイルに追加し変換をカスタマイズする方法で設計しました
カスタムSwiftコードを使ってObjective-C フレームワークを拡張する機能を構築し既存のAPIをラップするか Objective-Cでは表現できない新しいAPIを追加しています
何よりもこのすべて設計は弊社のためだけでなく皆様のためでもありますこれが今日の私のトピックです AppleのObjective-Cフレームワークの技術により Swiftへのインポートがどのように改善されたかを説明しますそれには私がSpaceKitと呼んでいる小さなフレームワークを使います見てみましょう
SpaceKitは NASAの初期の粗い宇宙計画を記述するモデルAPIが― いくつか含まれた Objective-Cフレームワークです宇宙飛行士ミッションロケットなどを記述することができますヘッダーを見ると Objective-Cフレームワークが #importディレクティブ @interfaceブロックセレクタを持つメソッドでいっぱいですしかしSwiftにインポートされる際コンパイラで自動的にSwift APIに変換されるためヘッダーの生成されたインターフェイスを見れば Xcodeで適切な外観を持つAPIだと分かりますよってエディタの左上にある “関連項目”メニューの― 下にあるサブメニュー “生成インターフェイス”を開き Swift 5インターフェイスを要求します Xcode12のSwiftバージョンが5.3だからです Swiftのヘッダーファイルがあれば結果的にそれを確認しますここにはクラスやイニシャライザプロパティメソッドなどがありますしかしこれは表示のボディではなくただのインターフェイスですこのフレームワークをインポートする時に Swiftが確認する内容を知るのに役立ちます
このセッションでは SpaceKitの生成インターフェイスやこのような擬似ヘッダーの例を紹介します
詳細を見ればSwiftではすでにすばらしいことが実行されていると分かるでしょう例えばこれらのパラメータはすべて Objective-CのNSStringおよびNSDateでしたしかしコンパイラはSwiftで使う構造体への橋渡しとなっています
イニシャライザとしてインポートされた initメソッドであり― メソッド名を“Swift”に近いスタイルに書き換えられていますそしてObjective-Cエラー処理変換の規則に従うメソッドがスローメソッドに変換されたものですただしこのフレームワークには改善の余地もあります APIには暗黙にラップ解除しないオプションが多数あります “AnyHashable”型の“Any”はこれらのコレクションでは本当に曖昧です
このスローメソッドでは時々スローすべきでないものもスローしますし
このメソッド名は完璧ではないかもしれません
他と見比べるとこの２つのイニシャライザはやたらと冗長に見えますしこのNSエラー情報は try-catchで使うのは難しいでしょう
オブジェクトから離れて SpaceKitのよりCスタイルの部分を見てみるともっと手を加えるべきだと分かります
この種類では NS_Enumが使われているのでそれは非常に優れたNS_Enumとして示されますしかしストリング定数のコレクションでは同じ処理を使用できますそしてこれらの定数の１つが完全に消えています
このフリーフローティングユーティリティ関数は Swiftには理想的ではなくこのUIntリザルトは厄介ですこれらの問題をすべて改善する方法を紹介します APIの型をより正確に指定すれば Swiftクライアントがフレームワークを正しく使えるようになります SwiftがAPIが従うことを前提としている Objective-Cの規則で大事な点は２つあります Objective-Cがアクセス可能な重要なものを Swiftがインポートしていない可能性がある時の対処法も紹介しますフレームワークの最後の仕上げが上手くできれば善良なSwift市民になったように感じられるでしょうでは始めましょう暗黙的にラップ解除されず APIのどこにでも現れるオプションを使いますそれはフレームワークの機能が非表示といった重要な側面が残されますこれらのオプションができた経緯や削除する方法とは？ idタイプとブロックを含む Objective-Cポインタ型には有効な値の場合と “null”または“nil”を呼び出すゼロ値を含む場合がありますこれはSwiftのオプションの種類に非常に似ています実際にはObjective-C以外のすべてのポインタ型はオプションでありすべての非ポインタ型はオプションではありませんもちろん多くの場合プロパティやメソッドは実際にはnil入力を処理しないか nilの結果を返しませんよってSwiftがObjective-Cポインタ型をインポートするとデフォルトでは暗黙的にラップ解除されたオプションとしてマークされますこの値がnilである可能性があると示すためですが本当にそうかは不明です
幸いなことにObjective-Cは null以外 null許容の２つのnull許容注釈を提供しますこれによって nilが特定のプロパティの実用的な値か― メソッドパラメータかメソッドリザルトであると言えます
Objective-Cはこれらの注釈を適用せずあなたの意図をドキュメント化するのみですしかしSwiftはこの情報を考慮した上で型をオプションにするかどうかを決定します
Objective-Cヘッダーファイルを編集しこれらの注釈を適用します
プロパティの場合注釈はプロパティの属性リストに入りますメソッドパラメータまたはリザルト型の場合型の名前の直前に移動します
この名前プロパティを使用して始めてみましょうこのクラスのインスタンスには名前が含まれていないこともあるため Null許容注釈と型をオプションに変化する生成されたインターフェイスに追加しますすばらしいですねしかしその後“ビルド”を実行すると新しい警告が表示されます大丈夫何も壊していません Xcodeはヘッダーのnull許容注釈が使われ始めたのを認識し― まだ入力する必要のある場所をすべて教えてくれているのです
それを参照しながら進めましょう最初の注釈をヘッダーのどこかに追加した後一度に１つずつ警告を潰しながら “nullable”または“nonnull”のいずれかを入力します
これが完了したらもう１つのクリーンアップ手順があります “NS_ASSUME_NONNULL_BEGIN”マクロをファイルの先頭に追加し “NS_ASSUME_NONNULL_END”マクロを最後に追加することですその後２つの間にある非NULLをすべて削除しますこのようにファイルを少しクリーンアップするだけでこれらのキーワードの１つを見るたびに常にSwiftでオプションを受け取りますこれらを追加した場合この定数のようにこのような注釈が機能しない場合があります null以外の注釈をこの前に置こうとするとコンパイラエラーが発生し生成されたインターフェイスが全く表示されないでしょう私が示した注釈はメソッドとプロパティで機能しますしかし定数やグローバル関数やブロックといった他の場所では― これらの注釈の限定子のバージョンを代わりに使う必要があります “_Nonnull”とすればObjective-Cのどの場所でもどのポインタ型にも機能しますこれらは“ポインタのポインタ”型でも必要ですその場合はキーワードをポインタの各レベルに対して１つ指定します内側のポインタはnilですが外側のポイントはそうではありません Swiftはオプションと安全でない可変ポインタ型を正しくネストしますグローバルに戻ります適用したアンダースコア限定子は Swiftでオプションではなくなります希望どおりですこれを実行する時は注釈が正しいか確認する必要があります例えばこのヘッダーを一瞬見たら次のように思うでしょう “すべてのミッションにカプセルが含まれるからカプセルプロパティを非nullに使おう” しかし後でカプセルをローンチしなかったミッションの存在に気づきカプセルをnilに設定することによってそれをモデル化しますつまり非null以外の注釈が間違っていたのですではSwiftがオプションにできないと考える値に対してObjective-Cが“nil”を返す場合は？ Objective-C側のNSストリングまたは NSアレイなら特別なケースとなります空のSwift文字列または配列を受け取ります
これは問題となる可能性があります SpaceKitはこの文字列が SKCapsule定数の１つと等しい文字列でありどの同じ空の文字列とも等しくないと予想しているためですよって正しく処理できない可能性を持つ値で終了するでしょう
他の型の場合それよりもずっと奇妙な結果にもなりえます
通常安全でない操作でしか見ないような無効なオブジェクトで終了する可能性があります
Objective-Cオブジェクトの場合は気づかないかもしれませんなぜならObjective-Cメソッドの呼び出しで nilが無視されるからですしかしnullポインタの参照を解除したりその他の予期しない動作を取得する場合はクラッシュしますコンパイラへの影響は予測不能なのでリリースモードに切り替えたり Xcodeバージョンを変更したりするとこの種のバグの現象が変わるかもしれません
要はヘッダーに何かがnilになれないと書けば Swiftでは強制的にラップ解除されず nilを返した場所でクラッシュは見られないでしょう
SwiftはObjective-Cヘッダーの情報を疑うことなく信じ実行します幸い Objective-Cコンパイラと Clang静的アナライザもNULL許容注釈を参照し Objective-Cコードで多くの違反コードを指摘することができますよって何かがnilになれないと言ってもそれをnilにするObjective-Cコードがある場合これらのツールが間違いを指摘してくれるのです nullを代入し注釈追加を完了したら新しい警告または静的アナライザの結果をフレームワークでの実装ファイルとアクセス権の付与されたObjective-C クライアントの両方で探すといいでしょうこれらの結果によりあなたの注釈に誤りがあったのか未知の微妙なバグがあったのかが分かるでしょう警告やアナライザの結果として表示された内容が実際に起こるかどうか分からない時やとても複雑な古いコードがnilを返すエッジケースを把握することができない時は― どうすればよいのでしょうか先ほど非nullとnull許容注釈について言及しました実際には“null unspecified”と呼ばれる第三の選択肢があり暗黙的にラップ解除されたオプションとして Swiftに値をインポートさせます Swiftで暗黙的にラップ解除されたオプションを使うすべての場所でこれを使う必要がありますオブジェクトのライフサイクルのとても早い段階でnilにしかならない値と同様です APIがnilを返すことに確信が持てない場合もこれを使えば― Swiftクライアントは引き続きラップを解除せずに結果を使うことができますフレームワークが本当にnilを返すことになれば確実に使用サイトでクラッシュしますが起こりそうにない不正行為を後になって受け取ることは回避できます
プロジェクトを通じてすべての null許容注釈を追加してきましたすばらしいですね次にこの“Any”の配列と他のコレクションに対処したいと思います Objective-Cは Swiftのような一般的な構文をサポートしています Objective-CのSKAstronautsの NSアレイにする場合は SwiftのSKAstronautsの Swift配列を受け取りますこれはNSSetとNSDictionaryでも機能するので多くのAPIを改善できます次はプロジェクトの別の領域を見てみましょうここにあるSKRocketStageCountと呼ばれる関数は― 名前から予想されるとおりカウントを返しますカウントは負の数になれないので NSUIntegerとして返します SwiftではこれがUIntを返すということでありこの関数がSwiftの規約を破ることになります従来からObjective-CとSwiftの両方で符号なし型を使ってきたのは― 整数がビットのコレクションを表しそれに対してビット単位の演算を実行する場合や符号付き算術演算が邪魔になる可能性のある他の計算を行う場合です通常このレベルで作業している時は値に含まれる正確なビット数に配慮します NSUIntegerのサイズはアーキテクチャによって異なるためこのやり方でこれを使う人はほぼいませんむしろユーザーがObjective-Cで NSUIntegerを使う主な目的は― 数値の値が負の値になりえないことを示すためです Objective-Cがこのスタイルを有効にできるのは自動変換と注意深く設計されたオーバーフロー動作のおかげですしかしこれらの特徴は深刻なセキュリティバグを生じさせる可能性があるため Swiftには含まれていませんその代わりSwiftでは明示的に符号なし型から符号付き型へ変換しなければ符号付き算術演算ができません符号なしの算術演算が負の結果を生成する場合実行を停止しますこれにより SwiftでIntとUIntを混合するのに NSIntegerとNSUIntegerをObjective-Cで混合する方法をとることはより困難になりますよって慣習的なSwiftスタイルではその方法はとらず― 決して負にならない値であったとしても代わりにIntを使用します
Appleのフレームワークの場合 Swiftがそれらをインポートする時にすべてのNSUIntegerをIntに変換するというブランケットルールを適用していました皆さんのフレームワークの場合にNSIntegerを使うようにヘッダーを更新するかどうかは皆さん次第ですが更新することをお勧めします Objective-Cにはほぼ影響を与えませんが Swiftには大きな影響を与えます
より広いコンテキストから見るとこの機能にはそれよりも大きな問題がありますクライアントがそれを誤用しやすいという点です SKRocketStageCount機能はこれらの SKRocket定数での使用が想定されていますそれは名前からも明らかです
しかしSwiftはこの関数が文字列を取るのを見ているのでそれを理解していませんこれらの定数はすべて文字列ですがかなりたくさんの文字列が入っていますその１つをSKRocketStageCountに渡してもいいことは何もないでしょう純粋なSwiftのフレームワークではこれを防ぐことができますこれらの定数をString型の生の値を持つ列挙型または構造体に変換し― その関数を変更してその型だけを取ります SpaceKitに対してそれを行う場合これらのAPIを手作業でラップする方法もありますがもっと簡単な方法があります
まず新しいtypedefを導入して定数をまとめてグループ化しそれを使用する定数を含むすべての場所を変更します実質的にはそれ自体では何も実行されません typedefは型エイリアスとして Swiftにインポートされますそして両方の言語でそれはちょうど元の型の正確な同義語となっていますしかしそれは単なる準備段階です
次は typedefの後に NS_STRING_ENUMマクロを追加しますこれはSwiftのtypedefを劇的に再形成します次に定数が入れ子になった構造体としてインポートし生の文字列値を持って列挙型のように見えたり感じたりするものを作ります
これはステージカウント関数が任意の文字列を取らなくなったことを意味します SKRocketのインスタンスしか取り入れていないのでミッションは達成されましたこの機能でユーザー固有のカスタム文字列列挙型を定義しますが Appleのフレームワークではその多くを定義していますここにFoundationから一般的なものをいくつか挙げていますが iOS SDKだけでも最低50は存在します APIのNSStringパラメータまたは定数を探すことをお勧めしますどちらか１つは本当に存在しているべきであり一致するように更新する必要があります Swiftの想定と違い Objective-Cの規則に誤って従わなかったためにトラブルに巻き込まれてしまう例を見てみましょう SKAstronautの生成されたインターフェイスを見ると何か面白いものが見えますこのクラスでは２つのイニシャライザが見られますどちらも人名が渡されますがその形式は異なります１つはPersonNameComponentという― 与えられた名前や姓などに関するプロパティを持つFoundationの型を取りますもう一方は“name”というラベルの付いた文字列を取りますこれらのイニシャライザの１つが他方を呼び出すのは明らかですただし SKAstronautをサブクラス化する場合 Swiftはどちらも上書きしますこれは少々無駄骨のように思えますしかし実際はこのクラスのイニシャライザに関する第二の問題があります生成されたインターフェイス内の可視化されないイニシャライザです SKAstronautのコード補完を見るとパラメータのない３番目のイニシャライザが表示されますこのinitは生成されたインターフェイスには存在せず元のヘッダーにも含まれていません宇宙から来たもののように思えますが実際にはここスーパークラスから生じたものです SKAstronautは NSObjectからそれを受け継ぎクライアントが呼び出すのですが実際には正しく動作しない場合がありますこれら２つの問題の根本原因は同じです Objective-Cではイニシャライザの規則によって常に正しく初期化されるサブクラスの記述方法をクライアントが把握している状態になります
この規則ではイニシャライザを２つのカテゴリに分けます指定と利便性です指定されたイニシャライザをすべてオーバーライドすることで利便性の高いイニシャライザを安全に継承する必要があります “これは聞き覚えがあるな”と思っている人もいるでしょうその記憶は正解です Swiftクラスはイニシャライザに同一の基本モデルを使用していますからね細かい点では違いがあります例えば指定されたinitを片方の言語でマークしもう一方の言語で利便性を示します Swiftクラスには同じイニシャライザから成る２つのカテゴリが存在し基本的に同じように動作します
残念ながら言語には大きな違いがあり Objective-Cの指定されたイニシャライザが言語の規則になっていないのです各クラスは少なくとも１つのイニシャライザを指定どおりにマークして従う選択が必要です Objective-Cクラスの多くはオプトインしないためクラスをサブクラス化する方法をクライアントが知らないことになりますこれはクラスにとってよくないことですが特にフレームワークにとっては最悪ですクライアントがソースコードを読み取るかあなたの行動をリバースエンジニアリングするか単に推測しなければならないからですバグ付きのサブクラスで終わるならすべていい方法ですとても悪い状況ですが必要なことをオーバーライドし忘れた場合にフレームワークのメンテナンス担当者が警告を受け取らないということです
オーバーライドをし忘れたイニシャライザをクライアントが使用する場合初期化中にクラスがスキップされることになりますその代わりにいつも参照しているivarが nilになります
必要なことをすべてオーバーライドしたとしても間違いが日常茶飯事なのでクライアントはそれを本当に確信することはできませんですからこの問題を修正する最初のステップはヘッダーに指定されたイニシャライザをマークしてこの規則にオプトインすることです指定する必要があるのか不明な場合は実装を見てみましょう通常指定されたイニシャライザは “super”クラスでinitを１つ呼び出し― 便利なイニシャライザは“self”で１つを呼び出しますそのボディを見れば initWithNameComponentsを指定し initWithNamesをconvenienceにすべきであることが分かります
それを念頭に置いてヘッダーファイルに戻り NS_DESIGNATED_INITIALIZERで指定されたイニシャライザをマークしてください convenienceイニシャライザは変更されないままになります SpaceKitでは initWithNameComponentを指定してマークする一方で initWithNameは単独でそのままにしておきます
修了後 init(name:)がconvenienceイニシャライザであることをSwiftが認識しキーワード“convenience”でマークします
この時点で Objective-C実装ファイルで警告が表示され始めるかもしれませんオーバーライドの必要があるスーパークラス指定イニシャライザに関する警告ですこれらは潜在的なバグです誰かがその１つを使っていたらオブジェクトは正しく初期化されなかったでしょう
ご自分のクラスでこれらのイニシャライザのいずれかをサポートしたい場合は普通に実装してくださいそうでない場合はdoesNotRecognizeSelectorを呼び出すオーバーライドを実装してください
そしてヘッダーファイルに戻り NS_UNAVAILABLE属性によって宣言しますその後スーパークラスのconvenience イニシャライザに同じことを行いますあなたが無効にしたものを呼び出す可能性があるためですこれらのイニシャライザを使用不可としてマークすることは継承しないことと同じです指定されたイニシャライザをオーバーライドしなければ Swiftが自動的に行いますこれらの変更により SwiftとObjective-C クライアントはどのイニシャライザが動作し― またどれをサブクラス内でオーバーライドする必要があるか把握できるようになりますいいこと尽くしです
次にObjective-Cエラー処理規約についてご説明します先ほどは投げるべきではない時に投げることがあると言いました
むしろ説明する行動がその理由です
多くのObjective-C開発者がエラー処理の規則を誤解しています彼らはメソッドで失敗が通知される場合は “false”を返してエラーをnon-nil値に設定する必要があると考えています
falseは単独で戻ってくると考えたり失敗ではなく単なるfalseかまたはnilかと彼らは考えたりします
しかし実際にはそのような規則はありませんこの規則はメソッドがfalse値を返した場合偽の値やエラー値が“nil”であってもそれはfalseです呼び出し元では問題になっていることが分からないので実際にはエラーnilを残すことはお勧めしませんしかしもしそうするなら falseの戻り値はやはりfalseです SwiftがスローでインポートしたObjective-C メソッドへの呼び出しを生成する時にメソッドがこの規則に正しく従うことを前提としています従ってそれはメソッドが falseを返す場合常に投げます Swiftではnilを投げることができませんエラーがない場合はSwiftが非公開の Foundationエラー型を投げます型はパブリックではないのでそれに対するステートメントを書くことはできませんしかしこの型のタイプとケースがログに表示された場合はデバッガまたはエラーメッセージが表示されますこれは一部のObjective-Cコードが失敗でなかったのにfalseを返したか失敗した理由が不明であったということです
それではSpaceKitメソッドの場合で考えてみましょうドキュメントには作業はスキップしたものの実際には失敗していない場合に falseを返すことがあると書いてあります
Swiftでは戻り値falseはエラーを投げることを想定していますそしてメソッドはエラーを設定しなかったので今お話している内部Foundation “nilのエラー”の１つになります何ができるでしょうか？いくつかのオプションがあります最も簡単なのはfalseが常に失敗を意味しかつメソッドが適切に規則を遵守するように特別なケースをただ削除する方法ですこれはクライアントが実際にこのケースを検出する必要がある場合おそらく機能しません別の方法としてNS_SWIFT_NOTHROWを使用しエラー規則を遵守しない Swiftに伝えることができます Swiftはメソッドを通常の方法でインポートしエラー処理コードを手動で記述しますこれはまだbreakの種類を残しますがメソッドを廃止する場合はよい解決策かもしれませんよりよい代替物を書いてください
原本を非推奨の形式で保持したかどうかに関わらず置換を改善する場合は error handling規則を遵守し別の方法で追加情報を返せるようにメソッドのシグネチャを変更する必要があります例えばブール値のoutパラメータを追加してファイルが実際に保存されたかどうかを示すことができますその後戻り値をエラー規則で指定した方法で使用します完璧ではないですが Objective-Cから可能なベストプラクティスですもし Swiftコードをもう少し書きたい場合はこのメソッドから完璧なSwiftインポートを受け取りますその方法をご覧ください
それではSKMissionのヘッダーを見てみましょう進行中に私が更新していたのがお分かりいただけると思います今古い非推奨のメソッドと余分なパラメータを持つ新しいメソッドがあり規則に従っています
すばらしいですさてもっと優れたSwiftバージョンを書きましょうまずSwiftメソッドが含まれるようにプロジェクトにSwiftファイルを追加します自分がObjective-Cファイルを追加したのと同じようにするつもりでしたが代わりにSwiftテンプレートを選択します
このファイルはSpaceKitをインポートする必要はありませんこれはフレームワークの一部だからですしかしSpaceKitのObjective-Cのビットがすべて自動的に表示される訳ではありません SwiftがSpaceKitのアンブレラヘッダーにすべてを自動的にインポートしますアンブレラヘッダーの名前はフレームワークと同じですがこのフレームワークの場合は SpaceKit.hになっています
このヘッダーはこのフレームワーク内ですべてのパブリックヘッダーをインポートしますそのためSwiftファイルにはこれらのヘッダーの宣言がすべて表示されますフレームワーク内にアンブレラヘッダーが含まれるのは常にグッドプラクティスですが Swiftから使用されるフレームワークであることが重要ですアプリとテストのターゲットにはアンブレラヘッダーがないので Xcodeはこの関数を提供するターゲットに特別なブリッジングヘッダーの追加を提供しますつまりアンブレラヘッダーにインポートすべきでない― パブリックヘッダーが１つあるのです
これが生成されたヘッダーです Swift内で@objcでマークしたものを宣言するSpaceKit-Swiftヘッダーです問題はここで循環依存が生じていることです Swiftでは生成されたヘッダーを作る際必ず最初にアンブレラヘッダーにすべてをインポートしますそのため生成されたヘッダーをアンブレラヘッダーにインポートした場合 Swiftはまだ生成されていないファイルを読み込もうとしますそれであなたの１日は無駄になってしまいます
生成されたヘッダーを他のヘッダーにインポートしないでください
アンブレラヘッダーに含まれていない場合でもモジュールを有効にしている Objective-Cクライアントはどちらにしても自動的にそれをインポートしますそれで上手くいきます今抱えているタスクに戻ります
私はSKミッションを拡張しsave(to:)と呼ばれる新しいメソッドを追加すると両方ともブールを投げて返します Objective-Cエラー規則が戻り値を引き継ぐため Objective-Cで“Bool”を返せませんでしたしかしそれはObjective-Cの規則です
Swiftメソッドでは戻り値はメソッドがエラーを投げたかどうかは関係がないので問題はありませんそれではこれを実装しましょうまずwasDirty値を受け取るには Bool変数が必要です
次にObjective-Cメソッドを呼び出します
そして最後にwasDirtyを返します “ビルド”を実行すると… 型エラーですねどうしたのでしょう
当社のプラットフォームのいくつかでは SwiftのBoolとObjective-CのBoolはメモリ表現が実際には少し異なっているのです通常Swiftではこの動作をスムーズにするために少しコンバージョンを挿入しますしかしここではSwiftブールへのポインタを取り Objective-Cにそれを渡してみましょう Objective-Cが直接読み取り書き込むようにするためです Swiftがそこに変換を挿入する方法がないので代わりにObjCBoolと呼ばれる型を使用しますそしてObjective-CのBool表現と一致しますこれを動作させるためには…
変数の型をObjCBoolに変更する必要があります
そしてReturnステートメントで―
そのboolValueプロパティを使用して Swiftブールを返します
ビルドしそして…
よし　機能しますしかしさらに改善できます
Swiftユーザーのためにこの優れた新しいメソッドを用いたにも関わらず Objective-Cはなお利用可能です Swiftクライアントは混乱してどちらを使うべきか迷うこともありますので非表示とする方がいいでしょう
しかしObjective-Cクライアントには使用をやめてほしくないですし Swiftも完全にブロックしたくありませんなぜならこのメソッドはまだ使う必要があるからですそこで私がすることは SKMissionヘッダーの見直しと
メソッドに注釈を付けることです NS_REFINED_FOR_SWIFTでこれを行います
NS_REFINED_FOR_SWIFTは非常に簡単ですメソッドの Swift名の先頭にアンダースコアが２つ追加されます Xcodeにリーディングアンダースコア付きの何らかの記載があると通常Xcodeではこれをコード補完や生成されたインターフェイスなどのエディタ機能で非表示になりますそのため今プロジェクトをビルドしたら Swiftコードにエラーが発生しますそれでは見てみましょう
保存先にwasDirtyパラメータが含まれていないというエラーが出ますこれはNS_REFINED_FOR_SWIFTのマクロが機能しているということです呼び出しているメソッドが save(to:)という名前ではなく __save(to:)だと認識していますコード補完を使用する場合メソッドのwasDirtyバージョンがあったという形跡もありませんしかしコード補完にメソッドが表示されない場合でも名前の前に２つのアンダースコアを追加し再度ビルドすると― 機能するようになります
さてSwiftクライアントでは優れたラッパーが使用されますやはりObjective-Cメソッドを呼び出し Objective-Cだけでは達成できなかったインターフェイスを渡します SwiftでAPIをより上手く表現できる場合はいつでもこのテクニックを使ってください次にフレームワークに表示される可能性のある問題を見てみましょう Swiftはヘッダーから可能な限りすべてのものをインポートできますしかしインポートする方法が理解できない場合スキップして次に進みます通常Objective-Cの機能を Swiftに自動的に変換するようなよい方法や自然な方法がない場合にこの動作が発生します例えばSwiftは関数またはサイズが不明なC配列を宣言する― Cの可変パラメータと構造体メンバーのメソッドをスキップします
セミコロン付きの@class または @protocolのような前方宣言の場合ヘッダーファイルに表示されますしかしクラスやプロトコルは完全には宣言されません Swiftにはインポートするのに十分な型情報を含んでいませんそしてこれらの型のいずれかを使用しようとするメソッドやプロパティまたはカテゴリ全体を最後に落とすことになる可能性があります
Swiftが同一のものに対する矛盾した２つの宣言を表示した場合にどちらを使うべきかを推測するのではなく両方をスキップすることがよくあります Xcode 12ではこれらの競合を検出する上で Clangはより優れたものになっていますアップグレードの時に突然型やメソッドが消えた場合それは調査対象になる場合があります
最後に SwiftはいくつかのマクロをインポートしますがすべてではありませんただSpaceKitがトラブルに遭遇する場合です前には文字列定数のグループを NS_STRING_ENUMを使用して型に変換しました SpaceKitは実際にはこのような定数のセットを２つ持っていますので他のセットにも同じ処理を渡すことにしようと思いますしかしこれらはマクロで定義されておりしかも問題が存在しますそのうちの１つは未解決ですどのような問題でしょうか Swiftは書かれる可能性のあるマクロを必ずしもすべてインポートすることはできません基本的にマクロは Objective-Cソースコード内の任意の場所で使用可能なテキストのスニペットにすぎません同じマクロであっても異なる場所で使用されると異なったものになる可能性がありますそしてSwiftがマクロの使用方法を理解する方法はありませんしかしSwiftはマクロを認識しておりこのマクロは定数を宣言するためによく使用される特定のパターンと一致しますこれらのうちの１つを見ると Swift定数としてインポートされています SKCapsuleマクロの最初の３つは単一の文字列リテラルという Swiftが認識するパターンの１つと一致しますそのためSwiftは定数としてインポートしますしかし４番目のマクロは別のマクロで置換されその後文字列リテラルを連結します Swiftはマクロ置換の他のObjective-C機能との相互作用についてすべて理解している訳ではありませんこれにより別のマクロに名前を付けたりマクロに他のものを含ませることができますが “両方とも”ではありません Swiftではコードパターンが認識されないためこのマクロをスキップして次に進みますこのインポート不可能なマクロを修正する方法は数多く存在します最も簡単な方法は文字列リテラルを他の文字列と同じ方法で生じさせることでしょうしかしこれらをstring-enumのケースに変換する場合は実際の定数に変換することをお望めしますその後これらをSKRocket定数と同じように文字列列挙してそれぞれの方法で進められます
この時点であなたは自分の型を強化し正しくないコードを修正しました可視化される必要があるものをすべて確認しました
ここからが楽しいパートですフレームワークを改善し Swiftクライアントを可能な限り素敵なものにします名前付けから始めます Swiftのmethod naming規則は Objective-Cとは若干異なりますどちらの言語もすべての引数がラベル付けされている場合比較的長い名前を使用しますしかしSwiftの名前はそれまでよりも短くなる傾向がありまた型を見て明らかな情報は省略される傾向があります２つの言語には技術的な相違点もあります Swiftの場合は各メソッドにベース名が付けられていますがデフォルトではすべての引数にラベルが付けられています Objective-Cセレクタは基本的に別のベース名がない引数ラベルが付けられています従ってベース名に含まれる情報は最初の引数ラベルに含まれています
このような相違点を支援するために SwiftではObjective-Cメソッドをインポートする時に自動的に名前が変更されますこれにより型名と一致する接頭辞と接尾辞が取り除かれそしてベース名および引数ラベルにセレクタの最初の部分を分割する方法を理解するため英語の文法と語彙の表が使用されています通常かなりよい結果になりますが基本的に審美的な判断を下しているコンピュータプログラムとなっていますそのため時折あなたとは反対の判断を下すでしょう例えば多くの開発者はこのメソッドセレクタが正しく分割されていないと言うかもしれません “flown”という単語はベース名ではなく引数ラベルの一部である必要がありますこれはメソッドが以前のミッションのリストをフェッチしそのミッションが特定の宇宙飛行士によって飛ばされたミッションであるためですすべての開発者が同意するとは限りません個人的意見ですこの問題を解決するにはメソッドの後にマクロNS_SWIFT_NAMEを付けてこれにベース名と引数ラベルを渡しますメソッドを呼び出さずに参照しようとした場合は Swiftで記述する方法が表示されます Swiftはそれ自体を生成する名前ではなく指定された名前でメソッドをインポートしますしかしNS_SWIFT_NAMEは方法であるだけではありませんそれはほとんど何にでも適用することができるのです
例えばこの列挙型を取ります Swiftはすでにこれを使用してかなりよい仕事をしていますオーサーがNS_ENUMを使用したため Swift列挙型としてインポートしますしかし名前を少し調整したい場合は NS_SWIFT_NAMEを使用して調整することができますさて名前からSKプレフィックスを削除するために NS_SWIFT_NAMEを使用できましたしかし実際にはお勧めしません Objective-C型の名前の多くはフレームワークのプレフィックスを “クエリ”や“レコード”のような単語と組み合わせたものですプレフィックスを削除し失われた精度を補足するため名前に他の何かを追加します
型の場合に最もよく使われるのはそれらを入れ子にすることです例えばこのSKFuelKind列挙型が連携した SKFuelKindクラスが存在した場合は SKFuel.Kindに変更することができますこれはSwiftで呼び出す型である可能性が高くなります
もう１つのいい用途は型名の外観が Swift型とは全く異なるライブラリでの使用です小文字の型名に似ており Cライブラリで時々見るものです NS_SWIFT_NAMEはグローバル定数変数関数でも使用できます例えばNS_SWIFT_NAMEを SKFuelKindToString機能へ適用できますその名前から余分な情報を削除する以外に引数ラベルやObjective-Cが関数をサポートしているものも追加する目的があります
しかし実際に興味深い領域に入りましたグローバル定数や変数特にグローバル関数に適用されると NS_SWIFT_NAMEは驚くべき強大な力を受け取りクライアントがあなたのフレームワークの使用方法を劇的に再構築できますはじめに型のObjective-C名を指定しその後にドットを付け次にObjective-Cの名前を入力してグローバル関数を静的メソッドに変換します
その後引数ラベルの１つを “self”に変更する代わりにインスタンスメソッドに変えますするとSwiftで呼び出されたインスタンスを渡す場所が理解されます
そしてそのメソッドの前に “getter”を置くことでそのメソッドをプロパティに変換できます変更可能なプロパティを作成するためにセッターでも同様のことを行うことができます
これらのテクニックを完全な機能のフレームワーク全体に適用し APIサーフェス全体を劇的に再形成することができます Core GraphicをObjective-Cと Swiftの両方で使用する時私の言ったことが分かると思いますこの名前変更機能を無数のグローバル関数に適用してそれらをはるかに使い勝手のよいメソッドプロパティそしてイニシャライザに変換しました
さてここでNS_SWIFT_NAMEでできないことがあるのか疑問に思うでしょう確かにありますこのグローバル関数を“description”というインスタンスプロパティに名前を変えた場合でも型をCustomStringConvertibleプロトコルに一致させる目的でNS_SWIFT_NAMEは使えません Swiftではプロパティを使用して SKFuel.Kindsを文字列に変換しますしかしカスタムSwiftコードの１行を使用しその適合性を強化できますではやってみましょう
追加する必要があるコードというのはこれです Fuel.Kindに拡張子を書きますそしてこれをCustomStringConvertibleに対して一致させますそして私のObjective-CヘッダーからすでにNS_SWIFT_NAMEを使用して説明プロパティを提供していたので…
これで完了ですステップ３はありません私はカスタムSwiftコードの非常に簡単な使用方法を実証しましたがこのようなSwiftファイルで必要となる Swift限定のAPIを書くことができます例えばSwiftUIをインポートしフレームワークのAppKitビューまたは UIKitビューによる SwiftUIビューが記述できますもしくはコンプリートハンドラのようなものを使用するAPIを取り代わりにCombine Futureを返すラッパーを書くことができます Swiftのクラスと型でこれらのテクノロジーの使用についてのセッションはすべて提供しましたただし混合言語のフレームワークで使用した場合実際には何も変わりませんなのでクラッシュコースを提供するのではなく SwiftUIとコンバインの関連セッションを示して残りはあなた次第となります最後にエラーコード列挙型について説明しましょう
多くのフレームワークと同様に SpaceKitではNSエラーで使用できるカスタムエラーコードを必要とします他のフレームワークのエラーと衝突しないように SpaceKitではエラードメインと特定のエラーコードNS_ENUMを含む文字列定数が宣言されますさてこの生成されたインターフェイスをご覧になったら何が問題なのかと思われるかもしれませんあなたは文字列定数を宣言し文字列定数はそれ自体として入ってきましたあなたはNS_ENUMを宣言しすべてのケースとコードがそのままの状態で Swift列挙型として入りその名前も正しく短縮されました本当にインターフェイス自体には問題はありません
しかし実際に使う方法を考えると問題はより明確になります例えば打ち上げられたミッションが中止された場合はレスキュー部隊が宇宙飛行士を救出するのを確認したいはずですこれはざっと見るとこのように見えますあなたはmission.launchを呼び出しそれがlaunchAbortedのエラーであればエラーをキャッチしたいと思いますしかしそのcatch句は実際にはどのように見えるのでしょうかさてエラーからドメインとコードを抽出する必要がありまずNSErrorとしてキャッチする必要があります
次にエラーがSKErrorDomainにあり別のエラーコードに同じエラーコードを使用する可能性があるドメインではないことを確認する必要があります
次にエラーコードをintから SKErrorCodeに変換しますそして最後にそれが目的とするケースかどうかを確認しますすべてのチェック事項を見てみましょうこれは… 私がユーザーに書いてほしいことではないですね
エラーに対して一致させるためにこのような努力は必要ありません
SwiftでSpaceKitを書いており Swiftエラー列挙型である場合これよりも少ない行で同じことができますエラーの種類とケースに名前を付ければ Swiftでは投げられたエラーに対してこれらが一致させられますこれはより優れた方法ですただしもちろんあなたは Swiftエラー列挙型を保持していません Objective-C列挙型とエラードメイン定数を持っていますこれをSwiftエラー列挙型と同じようなものに変えることができるのでしょうか？可能です本当に簡単といえますしなければならないことは NS_ENUMをNS_ERROR_ENUMと置き換えることだけですその後エラードメイン定数を使用して raw typeを置き換えます
このことはエラーコード列挙型に対して大きな効果があります SKErrorCodeはSKError内にネストされており Swiftで作られた全く新しい型になります
Xcode生成インターフェイスでは列挙型にそのケースとしてすべてのエラーコードが含まれていることが分かりますまたこれらは構造体上の静的定数として繰り返されておりドメインの場合もこのような静的定数があります
しかしSKErrorもエラーに準拠しているのでネイティブのSwiftエラーと同じように投げてキャッチすることができます
イニシャライザエラーコードのプロパティユーザー情報辞書がこれに含まれますエラーコード列挙型には ~=オペレータが存在しますこれはcase句とcatch句で使用される一致するオペレータですここでもしエラーを切り替えたりキャッチしたりしている場合 SKError.Codeと照合するように言われていますマッチングはエラードメインとエラーコードの両方が正しい場合にのみ成功します SKErrorには静的なコード定数が含まれているため catch SKError.launchAbortedコードを記述できますそしてSwiftは該当するエラーコードに対しエラーを一致させるためにこのオペレータを使用します SKErrorのこれらの部分は Swiftコンパイラが合成するため生成済みのインターフェイスでは可視化されませんただし使用してもらうのが目的なので実際にSwiftでかなり上手く動作する Objective-Cエラーコードを作りますすべてを取得するために唯一必要なのは２つの識別子を変更することです１行の差分としては悪くありません
しかしエラーコードから始めたのでもう一度より大きな教訓について考えてみたいと思います生成済みのインターフェイスには問題発生を示す明白な兆候は見られません改善の余地があったのは SKErrorCodeの活用方法を検討した時のみなのですこのセッションを通じて皆様に生成されたインターフェイスをご覧いただいています Swiftでヘッダーがインポートされる仕組みを確認するいい方法だからですしかし生成済みのインターフェイスはフレームワークの内容を理解するためのツールにすぎません本当に重要なのはそれを使用する時にクライアントが書き込む呼び出しですそのためフレームワークに取り組んでいる時に生成済みのインターフェイスを確認し使用サイトのことを念頭に置く必要があります心の中で想像してみてくださいホワイトボードに走り書きしますプレイコートでいじくり回しテストで体系化しますフレームワークに対するクライアントの好みはコマンドをクリックして表示されるインターフェイスではなくクライアントが書くコードに基づくものです
まとめに入ります
Objective-Cフレームワークをお持ちであればヘッダー注釈のみまたは Swiftコードを使用することで Swiftクライアントに対して上手く機能します
これを実行している時はより強調した具体的な型を― Swiftクライアントに掲示する機会を探してみてください Swiftでフレームワークが正しく使用されるように Objective-Cの規則を遵守してください
そしてXcodeは生成済みのインターフェイスを表示してはいますが APIの用途を振り返ってみてくださいそうすれば設計が推進されます
詳細は Swiftの仕様書の“Language Interoperability”セクションをご覧ください今回の機能のすべてをより詳細に説明していますもっと具体的な感触を得て Swift APIを“こなれた”ものにするには Swift コアチームおよびコミュニティが推薦する原則や規則の一部を紹介している― “API Design Guidelines”をご参照くださいそしてセッション“Behind the Scenes of the Xcode Build Process”では― SwiftがObjective-Cヘッダーをインポートする方法とまたXcodeが混合フレームワークを構築する方法について詳細を説明しています SwiftにObjective-Cフレームワークのヘッダーの一部が足りないように見える場合やインポートしそうにない場合は特に関連していますお時間をいただきありがとうございます皆様のローンチがすばらしいものになるお手伝いになればと思っております

4:43 - Describe nullability to control optionals (method and property annotations)

//
// SKMission.h
//
// View the generated interface to see how Swift imports this header.
//

#import <Foundation/Foundation.h>

@interface SKMission : NSObject

@property (readonly, nullable) NSString *name;

- (nonnull instancetype)initWithName:(nullable NSString *)name;

@end

6:53 - Describe nullability to control optionals (ASSUME_NONNULL blocks)

//
// SKMission.h
//
// View the generated interface to see how Swift imports this header.
//

#import <Foundation/Foundation.h>

NS_ASSUME_NONNULL_BEGIN

@interface SKMission : NSObject

@property (readonly, nullable) NSString *name;

- (instancetype)initWithName:(nullable NSString *)name;

@end

NS_ASSUME_NONNULL_END

7:14 - Describe nullability to control optionals (qualifiers)

//
// Misc.h
//
// View the generated interface to see how Swift imports this header.
//

#import <Foundation/Foundation.h>

NSString * _Nonnull const SKRocketSaturnV;

@interface ResourceValueContainer : NSObject

- (BOOL)getResourceValue:(id _Nullable * _Nonnull)outValue error:(NSError**)error;

@end

8:09 - Finding nullability mistakes with Objective-C tools

//
// SKMission.h
//

#import <Foundation/Foundation.h>

@interface SKMission : NSObject

@property (strong, nonnull) NSString *rocket;
@property (strong, nonnull) NSString *capsule;

@end

//
// SKRocket.h
//

#import <Foundation/Foundation.h>

extern NSString *_Nonnull const SKRocketSaturnV;

// 
// SKMission.m
//
// Try building this file and then try analyzing it.
//

#import "SKRocket.h"
#import "SKMission.h"

@implementation SKMission @end

@interface SKMissionConfigurator : NSObject

@property (strong, nullable) SKMission *mission;

@end

@implementation SKMissionConfigurator

- (void)testBadUseWithWarning {
    [self.mission setCapsule:nil];
}

- (void)testBadUseWithStaticAnalyzer:(BOOL)missionIsSkylab1 {
    NSString *capsule = nil;

    if (!missionIsSkylab1) {
        capsule = SKCapsuleApolloCSM;
    }
    
    self.mission.capsule = capsule;
}

@end

11:07 - Use Objective-C generics for Foundation types

//
// SKAstronaut.h
//

#import <Foundation/Foundation.h>

NS_ASSUME_NONNULL_BEGIN

@interface SKAstronaut : NSObject
// Stub declaration
@end

NS_ASSUME_NONNULL_END

//
// SKMission.h
//
// View the generated interface to see how Swift imports this header.
//

#import <Foundation/Foundation.h>
#import <SpaceKit/SKAstronaut.h>

NS_ASSUME_NONNULL_BEGIN

@interface SKMission : NSObject

@property (readonly) NSArray<SKAstronaut *> *crew;

@end

NS_ASSUME_NONNULL_END

11:33 - Use Int for numbers—unsigned types are for bitwise operations

//
// SKRocket.h
//
// View the generated interface to see how Swift imports this header.
//

#import <Foundation/Foundation.h>

NS_ASSUME_NONNULL_BEGIN

NSInteger SKRocketStageCount(NSString *);

NS_ASSUME_NONNULL_END

//
// NSData+xor.h
//
// View the generated interface to see how Swift imports this header.
//

#import <Foundation/Foundation.h>

@interface NSData (xor)

- (void)xorWithByte:(uint8_t)value;

@end

13:23 - Strengthen stringly-typed constants

//
// SKRocket.h
//
// View the generated interface to see how Swift imports this header.
//

#import <Foundation/Foundation.h>

NS_ASSUME_NONNULL_BEGIN

typedef NSString *SKRocket NS_STRING_ENUM;

extern SKRocket const SKRocketAtlas;
extern SKRocket const SKRocketTitanII;
extern SKRocket const SKRocketSaturnIB;
extern SKRocket const SKRocketSaturnV;

NSInteger SKRocketStageCount(SKRocket);

NS_ASSUME_NONNULL_END

15:24 - Specify initializer behavior

//
// SKAstronaut.h
//
// View the generated interface to see how Swift imports this header.
//

#import <Foundation/Foundation.h>

NS_ASSUME_NONNULL_BEGIN

@interface SKAstronaut : NSObject

- (instancetype)initWithNameComponents:(NSPersonNameComponents *)name NS_DESIGNATED_INITIALIZER;
- (instancetype)initWithName:(NSString *)name;
- (instancetype)init NS_UNAVAILABLE;

@property (strong, readwrite) NSPersonNameComponents *nameComponents;
@property (readonly) NSString *name;

@end

NS_ASSUME_NONNULL_END

// 
// SKAstronaut.m
// 

#import "SKAstronaut.h"

@interface SKAstronaut ()
@property (class, readonly, strong) NSPersonNameComponentsFormatter *nameFormatter;
@end

@implementation SKAstronaut

- (id)initWithNameComponents:(NSPersonNameComponents *)name {
    self = [super init];
    if (self) {
        _name = name;
    }
    return self;
}

- (id)initWithName:(NSString *)name {
    return [self initWithNameComponents:[SKAstronaut _componentsFromName:name]];
}

- (id)init {
  [self doesNotRecognizeSelector:_cmd];
  return nil;
}

- (NSString *)name {
    return [SKAstronaut.nameFormatter stringFromPersonNameComponents:self.nameComponents];
}

+ (NSPersonNameComponents*)_componentsFromName:(NSString*)name {
    return [self.nameFormatter personNameComponentsFromString:name];
}

+ (NSPersonNameComponentsFormatter *)nameFormatter {
    static NSPersonNameComponentsFormatter *singleton;
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        singleton = [NSPersonNameComponentsFormatter new];
    });
    return singleton;
}

@end

20:00 - Follow the error handling convention

//
// SKMission.h
//
// View the generated interface to see how Swift imports this header.
//

#import <Foundation/Foundation.h>

NS_ASSUME_NONNULL_BEGIN

@interface SKMission : NSObject

/// \returns \c YES if saved; \c NO with non-nil \c *error if failed to save;
///          \c NO with nil \c *error` if nothing needed to be saved.
- (BOOL)saveToURL:(NSURL *)url error:(NSError **)error NS_SWIFT_NOTHROW DEPRECATED_ATTRIBUTE;

/// @param[out] wasDirty If provided, set to \c YES if the file needed to be
///   saved or \c NO if there weren’t any changes to save.
- (BOOL)saveToURL:(NSURL *)url wasDirty:(nullable BOOL *)wasDirty error:(NSError **)error;

@end

NS_ASSUME_NONNULL_END

22:40 - Refine an Objective-C API for Swift users

//
// SKMission.h
//
// View the generated interface to see how Swift imports this header.
//

#import <Foundation/Foundation.h>

NS_ASSUME_NONNULL_BEGIN

@interface SKMission : NSObject

/// \returns \c YES if saved; \c NO with non-nil \c *error if failed to save;
///          \c NO with nil \c *error` if nothing needed to be saved.
- (BOOL)saveToURL:(NSURL *)url error:(NSError **)error NS_SWIFT_NOTHROW DEPRECATED_ATTRIBUTE;

/// @param[out] wasDirty If provided, set to \c YES if the file needed to be
///   saved or \c NO if there weren’t any changes to save.
- (BOOL)saveToURL:(NSURL *)url wasDirty:(nullable BOOL *)wasDirty error:(NSError **)error NS_REFINED_FOR_SWIFT;

@end

NS_ASSUME_NONNULL_END

// 
// SwiftExtensions.swift
//

import Foundation

extension SKMission {
    public func save(to url: URL) throws -> Bool {
        var wasDirty: ObjCBool = false
        try self.__save(to: url, wasDirty: &wasDirty)
        return wasDirty.boolValue
    }
}

31:35 - Fix method names with NS_SWIFT_NAME

//
// SKMission.h
//
// View the generated interface to see how Swift imports this header.
//

#import <Foundation/Foundation.h>
#import <SKAstronaut/SKAstronaut.h>

NS_ASSUME_NONNULL_BEGIN

@interface SKMission : NSObject

- (NSSet<SKMission *> *)previousMissionsFlownByAstronaut:(SKAstronaut *)astronaut NS_SWIFT_NAME(previousMissions(flownBy:));

@end

33:12 - Rename and rework value types with NS_SWIFT_NAME

//
// SKFuelKind.h
//
// View the generated interface to see how Swift imports this header.
//

#import <Foundation/Foundation.h>

NS_ASSUME_NONNULL_BEGIN

@interface SKFuel : NSObject
// Stub class
@end

typedef NS_ENUM(NSInteger, SKFuelKind) {
    SKFuelKindH2 = 0,
    SKFuelKindCH4 = 1,
    SKFuelKindC12H26 = 2
} NS_SWIFT_NAME(SKFuel.Kind);

NSString *SKFuelKindToNSString(SKFuelKind kind)
    NS_SWIFT_NAME(getter:SKFuelKind.description(self:));

35:59 - Add conformances to Objective-C types using custom Swift code
```
extension SKFuel.Kind: CustomStringConvertible {}
```

37:02 - Improve error code enums

//
//  SKError.h
//  SpaceKit
//

#import <Foundation/Foundation.h>

extern NSString *const SKErrorDomain;

typedef NS_ERROR_ENUM(SKErrorDomain, SKErrorCode) {
    SKErrorLaunchAborted = 1,
    SKErrorLaunchOutOfRange,
    SKErrorRapidUnscheduledDisassembly,
    SKErrorNotGoingToSpaceToday
};

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

リソース