Free Press

Cocoa プラットフォームは現在、macOS、iOS/iPadOS、watchOS および tvOS SDK という 4 つの別々のフレーバー、またはサブプラットフォームで表現されています。 各 SDK は、通常「フレームワーク」と呼ばれる個別のライブラリで構成されています。

Objective-C 側では、各フレームワークは、バイナリ (Windows の .dll に相当する .dylib) と Objective-C ヘッダー ファイルの両方を含む .framework 拡張子のバンドルとなっています。 Elements では、SDK 内の各フレームワークは、ヘッダーからすべてのメタデータを集約した .fx ファイルで表され、Elements コンパイラーが消費しやすく、高速になります。

Elements には、4 つの SDK の最新バージョンに付属する標準 Apple SDK のすべてのフレームワーク用の .fx ファイル（および一部の古いバージョン用）があらかじめ作成された状態で付属します。 フレームワークの多くは、いくつかの、あるいはすべての SDK で共有され、すべてのサブプラットフォーム間でコンパイルおよび共有できるコードを書くための膨大なクラス ライブラリを提供する一方で、各 SDK はプラットフォーム固有のフレームワークも多数提供していることがわかります。

• All macOS SDK Frameworks
• All iOS SDK Frameworks
• All tvOS SDK Frameworks
• All watchOS SDK Frameworks
• All Mac Catalyst Frameworks

これらのフレームワークをより詳しく見ていきましょう。

Foundation

Cocoa アプリケーションにとって最も重要なフレームワークは、おそらく Foundation フレームワークでしょう。 これには、NSString や NSArray などの単純で重要な型から、ディスク アクセス用の NSFileManager、通知を扱うための NSNotificationCenter、ネットワーク リクエストを扱うための NSURL* クラスなどのコア OS サービスへのアクセスを提供するクラスなど、NS* プレフィックスを持つ標準クラスのほとんど (GUI クラスを除けば、それについては後で説明) が含まれ、

詳細は Foundation.fx でお読みいただけます。 これは、すべての Cocoa サブプラットフォームで利用可能です。

ユーザー インターフェイス。 AppKit vs. UIKit vs. WatchKit.

ユーザー インターフェイス開発の領域に入ると、iOS、watchOS、tvOS、および macOS SDK の間の類似性はなくなりますが、これには理由があり、これらのプラットフォーム上のアプリケーションの UI は大きく異なるからです。 このため、SDK は 3 つの非常に異なるフレームワークを提供します。

AppKit は macOS SDK にのみ含まれ、Mac アプリケーションの作成に必要なすべてのクラスとコントロールを提供します。 レガシーな理由により、これらのクラスのほとんどは Foundation と共通のネーミング プレフィックスを持ち、NS* で始まり、使用するクラスには NSWindow、NSButton、NSTableView などのものがあります。 多くの概念は AppKit と UIKit で共有されますが、クラスは異なる &mdash があります。 たとえば、両方のフレームワークには色を表すクラスがあり（それぞれ NSColor と UIColor ）、非常によく似た動作をしますが、UINavigationController や UITabBarController などの定義済みコントローラの使用など、UIKit にかなり固有の概念もあります。

WatchKit は最後に、Apps、Glances、および Notification の観点から Apple Watch 用の UI を構築するために watchOS で使用されています。 (ウォッチ フェイスの Complication を構築するための ClockKit もあります。) WatchKit は UIKit とは異なる、よりシンプルな UI デザイン用のアプローチを使用します。

異なるフレームワークは、開発者にアプリケーション UI を一から考え直し設計するよう迫りますが、これは良いことです。

しかし、フレームワークの背後にある多くの概念は類似しており、1 つのフレームワークでアプリケーションを作成することを学べば、多くの場合、他のフレームワークに容易に移行できることに気づくでしょう。 たとえば、3 つのフレームワークすべてが、実際の UI をそれを駆動する「コントローラー」クラスから分離するために、モデル-ビュー-コントローラーのパラダイムを受け入れています。 これは最初の UI を作り始めた瞬間に明らかになります。.NET のように独自の Window や View クラス（iOS はシングルウィンドウのため、UIKit アプリケーションは主にウィンドウではなくビューで考えます）をコードで実装するのではありません。

Working with XIB Files の記事など、このドキュメント サイトの他のトピックでは、これらの概念についてより詳細に説明しています。 このフレームワークは、Foundation と AppKit をバンドルしたものに過ぎません。 プラットフォーム全体を指す「Cocoa」という用語の一般的な使用と混同しないでください。

More Specific UI Frameworks

両方の SDK には、AppKit と UIKit の上に構築して、より高度または特定の UI 要素へのアクセスを提供する追加のフレームワークが含まれています。

iOS と macOS の両方は、Twitter、Facebook、Sina Weibo およびその他のソーシャル ネットワークでコンテンツを共有する UI をアプリケーションで表示できる新しい Social フレームワークを含んでいます。

iOS は、電子メールと対話し、ユーザーがアプリケーションから直接電子メールを送信できるようにする MessageUI フレームワークを提供します。

SpriteKit (iOS 7.0 および OS X 10.9 で新規追加) および SceneKit (OS X 10.9 およびバージョン 8.0 の iOS で新規追加) によって優れたゲーム UI を容易に作成することができます。

System Services

また、アプリケーションがシステム サービスと対話できるようにするフレームワークも多数あります。

GPS（および Wifi ベースの位置情報サービス）を扱う CoreLocation。

オーディオおよびビデオ メディアを扱い再生する CoreAudio および CoreVideo。

Addressbook および EventKit。ユーザーの連絡先およびカレンダー（iOS の EventKitUI と共に）を扱う。

ゲームを Game Center と統合する GameKit。

（すべてのプラットフォーム間で共有）など、その他にも多数。

Lower-level Frameworks

AppKit/UIKit 以外のユーザー インターフェイスを開発する場合、両方の SDK は、より低レベルの UI で作業できるフレームワークも提供します。

• CoreGraphics は、コア UI フレームワークのすべてのグラフィックス レンダリングの基盤であり、独自のカスタム コントロールを作成する際に使用できます。

rtl.fx, libToffee.fx, libSwift.fx

Elements では、コア SDK フレームワークに加えて、その動作に不可欠な .fx ファイルが 3 つ追加されています。

• rtl.fx は Foundation フレームワークよりもさらに基本的で、macOS、iOS、watchOS および tvOS のコア UNIX システムを構成するすべての低レベル C スタイル API が含まれており、Grand Central Dispatch および CommonCrypto などのライブラリも含まれています。 基本的に、rtl.fx は /usr/include.
• libToffee.fx のヘッダーの大部分を表し、Elements コンパイラー自体にとって重要なヘルパー タイプが含まれています。 たとえば、Future Types、汎用 NSArray<T> および NSDictionary<T> 型、LINQ サポートなどの内部サポートを含みます。
• libSwift.fx は Swift 言語に固有の追加の型と関数を提供します。

Cocoa アプリケーションは、それが参照に明示的にリストされているかどうかにかかわらず、自動的に rtl.fx を参照することになります。 libToffee.fx と libSwift.fx への参照はオプションです。libToffee.fx または libSwift.fx への参照を必要とする機能が使用され、それらが参照されていない場合、コンパイラは警告/エラーを表示します。