macOS向けCocoaの新機能

(音楽)

(拍手)

どうも 私はアリです 同僚のクリスとジェスと macOS Mojaveの Cocoaの新機能を説明します

AppKitの新機能の話を 昨日しましたが 今日も様々な機能や― APIの改良点も紹介します ダークモードや Layer Backing クイックアクションの カスタムです では まずは 我らが誇るAPIの話です 我々は機能的で力強い APIを目指してきました その思いの下で Objective-CやSwiftの 改善に努めてきました AppKitや Foundationに限らず UIKitにも対応しています

APIを Objective-Cに 完全にソース互換させ 将来的にはSwiftでの利用も 目指しています APIの改良点を 見ていきましょう

まずは文字列型の アップデートです 前回は列挙型を紹介しました 関連する定数を まとめる方法で APIの文字列型の扱いが 明確になります

例えば１行目 NS STRING ENUMと 宣言します これは 拡張性のない フレームワークの 値を指定するための 列挙型です 次にNS EXTENSIBLE STRING ENUMです これで列挙型を宣言し ボックスの値が指定できます 他のフレームワークでも 使えます

改良点は２つで １つ目はシンプルです 今紹介した２つの文字列を 類似のものに置き換えました これは ノーオペレーション命令で コードなどに 変化はありません 次はNSImageNameです 列挙型に代わる 最も重要な変化となります NS SWIFT BRIDGED TYPEDEFと Typedefを宣言します Swiftなら こんな具合です Swift 4では構造体になり このように列挙型を 宣言します Swift 4.2では昔ながらの Typealiasを使います シンプルですね なぜこれをするのか？ コールサイトの例です

Swift 4では文字列に NSImageを使って 名前を表示できます 文字列を選び NSImage.Nameを用い さらにNSImage namedと します NSImage.Nameを 繰り返すのは面倒ですね 次に Swift 4.2です NSImage.Nameは重複せず より合理的で ムダが少ないですね こちらのTypedefの方が 普遍的な値です (拍手) 皆さんの意見を聞き―

こちらが適していると 確信を得ました 値とは フレームワークに関わらず 普遍的であるものです 画像や色 自動保存の 名前も同様ですから 普遍的な方が適しています この新機能があっても API独自の宣言が使えます NSImageの宣言方法です NSImage.Nameの話が 先ほど出ましたが ここでもまた出てきます ３種類のリストです これは実に多くの型で 用いられているのです

まだまだあります 多くの型が変更になります

次はプレフィックスです 今まで サフィックスから 移行してきました 数年来 Objective-Cは プレフィックスを用いています グループに名前をつけたり 見つけやすくなったり Swiftが容易になります 例を見てみましょう

macOS 10.13のSDKには NSLineJoinStyleと 出てきます macOS 10.14では こうなります MiterLineJoinStyleが LineJoinStyleMiterとなり Swiftのプレフィックスが 変化しました MiterLineJoinStyleが Miterにです この型を 繰り返す必要がなくなり コールサイトも 簡潔になりました 思わずニッコリですね (拍手) どうも そして 他の型でも 同様のことを行いました 型のリストです

次はプロトコルの話です かつては NSObjectといった 非形式のプロトコルを 使っていました 以来 オプショナルな 機能を加え 形式プロトコルに 移行してきました その例を１つ お見せしましょう

validateMenuItemで macOS 10.13の 非形式プロトコルの機能です 形式プロトコルでは NSMenuItemValidation Swiftの表示はNSObjectから 形式プロトコルに変わります Swift 4.2では NSMenuItemValidationです このプロトコルに従った オブジェクトと宣言されます 他の多くのAPIで 同様のことを行いました AppKitに追加した 形式プロトコルのリストです 色やフォントの 切り替えといった NSEditorや NSEditorRegistration 形式プロトコルの一覧です

次はインスタンス変数への アクセスです 現在 我々のAPIでは インスタンス変数は ほぼプライベートです しかし 古いAppKitでは 宣言のされ方次第で インスタンス変数に 直接アクセスできるのです お気付きでなかった方は 試さないでください 自分で書いたのではない 古いコードが インスタンス変数を 直接 使うのです 今後は こういった現象に もう少し注意して 非推奨していきます 直接インスタンス変数に アクセスした際の警告です 次回の更新で削除されます このような警告が出たら 修正してください 直接アクセスするより 修正はよっぽど簡単です ゲッターを呼ぶか プロパティに行ってください 理由があってのアクセスなら 我々に知らせてください 非推奨の話が出たので お話しします

非推奨公式ソフトです 多くのAPIが非推奨になり 代替が提案されています 緊急でない場合は 手順を踏んで非推奨にします リリースノートを出すなど 非推奨の勧告をし その後 非推奨にします 混乱を防ぐためです 一方 公式に非推奨にする 方法があります 例を見せましょう 非推奨の記号があります NSBoxOldStyleは 非推奨され 非推奨と明記されていますね バージョンナンバーは API TO BE DEPRECATED コンパイラに非推奨の警告を 出さないようにしています もし この記号をXcodeや 新しいコードで用いたら 警告を受け 代替の記号が提示されます Swiftでも同様です バージョンナンバー100000に 注目してください これは遠い将来発売される SDKではなく プレースホルダ番号で この機能を示します

公式の非推奨の他の例です これを見てください MiterLineJoinStyleは LineJoinStyleMiterになり Objective-Cのソースコードは 互換性があります では 自分がリネームした 古い記号は？ API TO BE DEPRECATEDが 古い記号には使われ 新たに使おうとすると 警告が出るようになります しかしObjective-Cの ソースコードを乱さないため 既存のものは残されます

こういった対象になる記号が 多かったため 多くのAPIが非推奨と 記されています 多くはプレフィックスへの 移行のためで 新機能への転換のため 非推奨にしたものもあります あとで話す ダークモードが いい例です

最後は セキュアコーディングです OS X 10.8とiOS 6で セキュアコーディングを 復活させました これによりアーカイブの際 クラスを特定するのに 役立ちます エラーがあった場合は アーカイブに入れられません 我々の セキュアコーディングは オプショナルな機能でした しかし新しいAPIでは デフォルトにできます エラーリターンも得られます エラーリターンは あった方がいいですね 新APIはエラーリターンが デフォルトです

一番興味深い APIをお見せしましょう NSKeyedUnarchiverです keyedUnarchiverを作り エラーを返します 他にも２つのメソッドが 適用されます unarchivedObject (ofClasses fromと unarchivedObject (ofClassfromです これらはオブジェクトを 安全に アンアーカイブし 問題時にエラーを返します ２つめのメソッドです かなりゴテゴテですね これでSwiftがリターンの タイプを識別できます Swiftの得意分野ですね 注意してほしいのは これらのすべてが macOS 10.13やiOS 11に 対応することです 古いバージョンのSDKでも 利用可能です

一覧のメソッドが 入れ替わります macOS 10.14やiOS 12では これらは非推奨になります セキュアコーディングでは ないため 通常の手順を踏まず 非推奨にします セキュアコーディングを 推奨するためです

次にValue Transformerに ついて NSValueTransformerは 自動的に値を変換する クラスです unarchiveFromDataと keyedUnarchivedFromDataで アーカイブをロックしたり 解除したりします 思ったように 機能しなかったので 非推奨し 新しいものに置き換えます 安全にアンアーカイブする FromDataTransformerName こちらを使ってください

さらに セキュアコーディングを 多くのAppKitにも 適用していきます NSAppearanceは 新しいですが かなり利用されています ダークモードや 他のAppKitの機能にもです セキュアコーディングを 導入したAPIの リストになります 最後にもう１つ 木曜のセッション “Data You Can Trust”で 堅固で安全なコーディングや アーカイブの話をします 木曜の朝９時に お待ちしています

ここからはAppKitの 新機能の話に移ります クリスを呼びましょう (拍手) どうも ダークモードは 注目の新機能です もうご存知の人も いると思いますが 見てみましょう すばらしいアートワークの システムですね インターフェイスの 見た目がよくなり コンテンツが引き立ちます さて これを導入する方法です

第一段階は簡単です macOS 10.14のSDKに リンクします 美しいアプリケーションを 作るのに 多くの場合は これだけでは不十分です 次に色を設定した値の箇所を アプリケーション内で探し アピアランス対応の 色に置き換えます AppKitは ほとんどのUIに対応し 現状のアピアランスに準じた カラーシステムを提供します macOS 10.14のものも 加えましょう

システムの設定をしなくても ドキュメントモデルの 見た目も映えます Asset Catalogから 色を選べます Xcodeの色編集機能に行き 右のサイドバーを使って 見た目や色の設定ができます ここでモードの明暗によって 色を選択します フォールバックカラーも あります

色と同様 テンプレート画像も 見ていきましょう テンプレート画像は モードに関わらず 明るい色になっています グレーや黒のアートワークの アプリケーションは ダークモードでは 映えませんでした そこで テンプレートを作り カタログに追加できます ダークモードでも 制限することなく ダークモードで映える画像を 特定できます このアプリケーションで 北米はダークモードで夜です 他のモードでは北米は昼です

ダークモードの特徴の１つは デスクトップの 写真の処理です 例を見せましょう システム環境設定は ダークグレーに見えますが 実際はもっと複雑です 背景の砂丘には 青や 光やダークグレーがあります この写真に 平均色の長方形を重ね ダークブルーで 塗りつぶします インターフェイスの背景は ダークグレーにしました ダークブルーも残ります ウインドウの内容を戻しても 変わりません デスクトップで映えるのです 違う写真ではどうなるか お見せしましょう もっと明るい紫や緑の デスクトップの色が ウインドウに影響します 赤い花の写真にしたら もっと分かります デスクトップの暖かい色が ウインドウに反映され インターフェイス全体が 変わります みなさんは 疑問に思うでしょう ウインドウ位置や 平均色を特定し 変更するのは 大変じゃないかとね 心配しなくても大丈夫 AppKitがしてくれます すでにご存知の これらのクラスを使います ウインドウや スクロールビューなどは 何も変えずに ダークモードで使えます カスタマイズしたければ それも可能です 背景のカラープロパティです そして 私が 特に紹介したいのが ここに挙げた４種類の NSColorです これらは デスクトップの 写真と調和し インターフェイスの 役割によって変化します もう１つ紹介したいのが NSBoxです ボックスのカスタマイズに 塗りつぶし機能が使えます NSColorや 他のカラーも使えます NSBoxでボックスを きれいな色で塗れるのです 他のクラスでは難しいですね

もっとこだわる人には 別のクラスを紹介します “NSVisualEffectView”です マテリアルの プロパティがあり 背景に合わせた視覚効果を 決定できます 色のブレンドをするのです 使用された例を いくつか見せましょう macOS 10.14には もっとあります どんなインターフェイスにも 合ったマテリアルがあります 過去のOSではダークか ライトか明記されていました 新しいモードでは 見え方が違ってきます

そこで アクセントカラーの話です これらのUIは 目を引くものですが それは色や 様々な要素のおかげです macOS 10.14には アクセントカラーを 多数追加しました すばらしいでしょう？ 自分で作るなら… 拍手を待ってます (拍手) どうも これらのUIを作る時は モチーフも自分で作って 色を加えます 以前はNSColor. currentControlTintを使って システムがアクアか グラファイトか選択しました 今はこれより もっと多くの色があります macOS 10.14ではNSColorの controlAccentColorを 推奨します NSColorは アクセントカラーだけでなく 他の機能も満載です UIの作成時 一番気にかけるのが ユーザインタラクションで 色が反映されるかです そこでwithSystemEffectを 導入しました 起動時と非起動時の 効果を設定します 将来的にはベースカラーから 新しい色を作り アピアランスに 加えられるようにしたいです そうすれば色を変える際 自分で式を作る必要は ありません インタラクションごとの 複雑なコードも 必要ありません 便利なAPIになります

さらに色の話です コンテンツの明清色と 呼んでいるものです このモックアップにあるのは 一見 テキストだけですが いくつかの要素があります

これは ユーザが クリックする箇所です 一般的なボーダーは 使いたくありませんでした macOS 10.14ならボーダーのない ボタンにできます 画像表示で クリックできると認識します 簡単な操作です NSButtonと NSImageViewの総称が Content Tint Colorです 好きな色や 色調の変更も設定できます これをInterface Builderに 組み込めます 画像表示の設定です 色調の選択は 右のサイドバーです

macOS 10.14の アピアランスに関する さらなるセッションが WWDCの アプリケーションにあります ぜひご覧ください

次のトピックです CocoaはLayer Backingなしに 語れません

まずは確認です macOS 10.14で新しいSDKに リンクすると AppKitは従来の バッキングストアを使いません Core Animationのレイヤを 使います iOSユーザなら 親しみのある機能ですが 詳しく見ていきましょう UIKitでの ビューの関連図です とてもシンプルですね 各ビューにレイヤが１つ ビュー間の親子関係も 表されています AppKitでのレイヤ関連図は ビュー階層のプロセスで 決められます 複数のビューに対し １つのレイヤを選択できます するとシステムやGPUの メモリ消費を減らし ウインドウサーバの 負荷も軽減できます 強調しておきたいのは ビュー階層の設定に 基づくということです だから変化できるのです iOSのような親子関係に 縛られることもありません

ここでのプログラムとしての 大きな変化は wantsLayerを 使わなくてもいいことです macOS 10.14を使えば AppKitがしてくれます

macOS 10.14を… (拍手) このプロパティを使う 推奨すらしません “true”にすれば ビューのレイヤが決まります 最適化しなくとも 複数のビューが １つのレイヤに表示されます 古いOSでは 必要な手順ですが 無視して 飛ばすこともできます

次に CALayerを使う際の 他のパターンを紹介します 簡単なのは CALayerを 上書きするか デリゲートメソッドを 実行します NSViewには 様々な機能があるので そちらを 使った方がいいでしょう

NSViewを使う場合は ダイナミックカラーの反映も 管理してくれます バッキングストアの 解像度も管理します レイヤメソッドと同様に 簡単なので ビューレベルでの 描画の上書きをお勧めします

CALayerを使って レイヤプロパティを 更新することもあります その方が効果的で 作業も早いからです NSViewを使って レイヤに上書きすれば drawRectでも 同じ効果が得られます レイヤとNSView 両方の手法が使えるのです レイヤにビューが１つの場合 レイヤのメソッドを使い 他のビューもある場合は drawRectを用います 両方使用した方が いいわけです CGやAppKitのAPIでも 表現しきれないなら wantsUpdateLayerを 上書きします それで“true”と返ってきたら レイヤを明示にします

AppKitとCore Animationの 別の便利な利用法です NSViewsの基本的な用語で インターフェイスを設定します NSImageViewとNSBox NSTextFieldです 複雑なインターフェイスの 設定には最適で 表示にどんな技術を使っても 正確に起動します

Layer Backingの変更点です これはmacOS 10.14では もう使えません NSViewのlockFocusと unlockFocusを使う場合 直接ウインドウに アクセスする場合は NSViewをサブクラスにし drawRectを実行します どちらのメソッドも 細心の注意を払い トラブルを避けましょう これはObjective-C用で Swift関連で話すのは変です Swiftではこのコードを 見たことがありませんから 試して私を驚かせようなんて しないでください

Layer Backingの もう１つの変化です NSOpenGLのクラスで OpenGLで表示し macOS 10.14にリンクします MacでのOpenGLの技法は 少し違います 何点かあります しかし重要なのはmacOS 10.14の プラットフォームで OpenGLは 非推奨だということです NSOpenGLより MTKViewをお勧めします Metalのセッションが 今日予定されています

最後の改良点はフォントの アンチエイリアスです 比較してみましょう 左がmacOS 10.13で 右がmacOS 10.14です ウインドウのテキストは 基本的に同じです しかしスケール因子48倍まで 拡大すると macOS 10.13はカラーフリンジが 用いられています 一方 macOS 10.14では 使用されていません どんな大きさのパネルで 拡大しても テキストがぼやけません 他にもいろいろありますが その説明はジェスに 代わりましょう

(拍手) みなさん どうも まず ユーザ通知の フレームワークです iOSにあったものを macOS Mojaveにも導入しました

ユーザ通知の 管理を容易にします iOSと同様にアプリケーションが 作動するのです 使うのは NSApplicationの registerFor RemoteNotificationsか userNotificationCenterの requestAuthorizationです

同時に関連するAPIを 非推奨にしました NSApplicationの remoteNotificationTypeや OptionSetです registerForRemote Notificationsや enabledRemote NotificationTypesもです NSUserNotificationも 非推奨にしました SDKを再設定する際は フレームワークを 更新してください

次にNSToolbarの話です ツールバーの中央に アイテムを入れる際 両サイドに スペースが必要でした これには欠点があり さらにアイテムを入れると 押し出されてしまいます しかし NSToolbarの 新しいプロパティでは 中央にしたいアイテムを 特定できます そして そのアイテムは 他のアイテムが入っても 押し出されません

他の改良点も お伝えしましょう

Auto Layoutが アイテムのサイズを測ります 最小値 最大値が 未設定なのが条件です

この機能はmacOS 10.14のみ 対応しています ボタンのサイズを変える際 サイズが自動で測られます

Interface Builderで centeredItemIdentifierも できます これが インスペクタペインです 一番下に 新しいボタンがあります ここをクリックする だけでよく APIに戻る必要がないのです インターフェイスの ほぼすべての設定ができます Interface Builderの すばらしい新サポートは 編集のための NSGridViewです グリッドビューは 数年前に開発されました ビューをグリッドで 表示します 例をお見せしましょう このレイアウトを設定する 制約はとても少ないです しかしNSGridViewで もっと簡単に作れます Interface Builderの 新サポートです これはStoryboardファイルの インターフェイスです コントロールを選択し グリッドビューを適用します そして 余白や セルのそろえを調整し レイアウトしていきます 表計算のように セルにビューを入れられます 列と行からセルを選び プロパティを調整します 下の２行のように セルの結合もできます 試しに列を選びましょう インスペクタペインは このようになります この行のセルの位置と 上と下の余白を調整します サイズインスペクタで 行の幅を明示しなければ 行のサイズは内容によって 自動的に決まります

この機能のいい点は 過去のOSでも使える点です Interface Builderの グリッドビューは macOS 10.13.4に戻しても 使えます セルの結合以外は macOS 10.12でも使えます 古いバージョンで アプリケーションを設計する時も このすばらしい新機能が 使えるのです

次はNSTextViewの改良点です 新ファクトリメソッドは 数点です fieldEditorが NSTextFieldと同様に テキストビューの 編集をします これによりテキストビューの 設定を簡単にします 下の３つは スクロールビューで 一般的な使用ケースです さらに編集を加えたければ ドキュメントビューを 見てください Interface Builderでも これらは可能で APIに戻る必要がありません ４つすべてを示した サンプルウインドウです テキストビューの ミスコンフィグレーションは FieldEditorの ファクトリメソッドで防げます scrollableTextViewは テキストビューに使われます ポップオーバーなどの 補足テキストのためです 下の２つはメイン文書の テキストです 左はリッチテキスト 右はプレーンテキストです 何が違うのかと 疑問に思うでしょうね 一番は システム設定の 心配が要りません ダークモードの方が もっと分かりやすいですね リッチテキストの背景は 白のままですが プレーンテキストは黒になり システムにマッチします このファクトリメソッドで システムの他の仕様と 一貫性が出ます

他の改良点としては テキストの変更メソッドの PerformValidated Replacementです テキストビューでの テキストの扱いが簡単になり ユーザ自身で変更した際の 対応もします デリゲートメソッドも 実行してくれます 何よりも 入力文字列が 特定されていない属性は typingAttributesで 自動的に属性を持たせます 例をお見せしましょう リッチテキストの ウインドウです スニペット“performValidated Replacement”に “Developers”と入れます そうすると文字になって 現れます 周囲のスタイルと合っていて 属性の指定は不要です ここで少し注意が必要です 属性の指定は typingAttributesが行います それなので リッチテキストから始め 最後を薄い字にして 真ん中に挿入すると スタイルの属性は最後の 薄い字になります

そのためperformValidated Replacementを呼ぶ前に 範囲を選択するか 見極めないといけません

選択すると こうなります

次にContinuity Cameraの 説明を簡単に macOS Mojaveの 特徴の１つです NSTextViewを使っているなら フレームワークが 自動で起動してくれます しかし もっと特化した 利用がしたければ 直接使うこともできます これは既存のAPIサービスの 実装になります 応用クラスが画像を 処理できるようにするのです validRequestorで 可能です validRequestorや 関連のメソッドの説明に 目を通しておきましょう

次はクイックアクションの カスタムです クイックアクションについては 昨日も紹介されました アプリケーションを 開くといった簡単な動作から 複雑な動作では ファイルに フィルタをかけたりできます クイックアクションの カスタムは App Extensionや Automatorを使ってできます 様々な場所で使え 起動の仕方も様々ですが 一押しはTouch Barです Touch Barに クイックアクションを加えれば いつでも簡単に使えます システム環境設定の “キーボード”に行き Touch Barの表示のさせ方を 設定します カスタムしたいなら 一番下にボタンがあります

また ショートカットの サービスを見ると 何を表示させるかを 選択することができます Touch Barに 表示されないのは 例えばFinderウインドウです コンテキストメニューに クイックアクションがあります

プレビューにも クイックアクションがあり “More”を押すと リストが出てきます Automatorのアクションは サービスで見られます TrimLogsはデバッグログを 検索するものです

次にアクションのまとめ方を 説明します これはAutomatorの 新機能です 新規ドキュメントを作ると オプションが出てきます 一般的なワークフローですが １番上のボタンで インプットやアウトプット アイコンの色も設定できます 簡単な例をお見せします テキストエディットで ファイルを開きたくても 拡張子のため 開けないことがあります Automatorなら 簡単に解決です ライブラリに行き Finderアイテムを開くを選び テキストエディットで開くと 設定すればいいのです これはFinder内の 全ファイルに適用されます 名前を付けて保存すれば Touch Barや他のメニューにも 表示されます

さて 様々な新機能や 改良点を説明してきました 皆さんのエクスペリエンスや アプリケーションを 向上させるものです 新SDKのリストをチェックし アプリケーションに使ってください よりよいアプリケーションになり ユーザも喜ぶでしょう さらなる詳細はこのURLで WWDCのアプリケーションも 見てみてください 関連する セッションもあります ありがとうございました (拍手)