間違いなく、開発レベルでの Apple プラットフォームの将来の可能性について、ここ数カ月間にリークされた最も興味深いニュースの 1 つは、いわゆるマジパンプロジェクトです。このプロジェクトは、 アプリを通じた iOS と macOS プラットフォームの統合を意味しており、 6 月の第 1 週に開催される可能性のある次回の WWDC 2018 で iOS 12 と macOS 10.14 が発表される予定です。しかし、それは正確には何を意味するのでしょうか？これを分析して、それがユーザーと開発者にもたらす利点を確認するだけでなく、それをより明確に理解するために、そこに至るまでの経緯を探ってみましょう。
少しの歴史
1988 年。スティーブ ジョブズは、4 年前に Apple を辞めた後、新しいコンピューター NeXT を世界に発表しました。世界で最高の研究用コンピュータを開発するという明確な目的を持った企業です。学生や学者なら誰もが憧れるワークステーションです。同社が経済的に成り立たず、機器が非常に高価だったことは誰もが知っており、最終的に Apple は 1996 年に NeXT を買収してジョブズのクパチーノへの復帰を奨励しました。
NeXT は開発をありのままに再発明し、今日に至るまで定義しました
しかし、それは NeXT の背後にある真実の表面にすぎません。実際のところ、NeXT は当時の開発を再発明し、今日に至るまでそれを定義しています。
1984 年に Macintosh が登場すると、グラフィカル インターフェイスは定着しました。しかし、アプリケーションをプログラミングすることは、開発者にとって地獄にほかなりませんでした。各ウィンドウやグラフィック要素は、コードを再利用することなく、多大な労力をかけてゼロからプログラムする必要がありました。しかし、ジョブズは 1979 年にゼロックス PARC で発見したアイデアの 1 つ (そこでマッキントッシュを作成する「インスピレーション」を与えたゼロックス アルトに出会った) を採用し、それを NeXT (グラフィカル インターフェイスにオブジェクト指向プログラミングを適用する)に適用しました。
オブジェクト指向プログラミング自体は 1960 年代後半から存在していましたが、ジョブズがゼロックスで発見したのは、オブジェクトを再利用可能な要素として使用してインターフェイスを作成するというアイデアでした。彼は、後に MVC (Model-View-Controller) パターンとなるものの基礎を発見しました。このパターンは、Apple システム向けにネイティブにアプリを作成するために今日でも使用されています。彼は、1980 年に作成された Objective-C と呼ばれる C 言語のスーパークラスを受講しました。これは、先駆的なオブジェクト指向の増分コンパイル エンジン (プログラムがコード全体ではなく、変更された部分のみをコンパイルする史上初) とその概念です。コードの再利用を可能にするフレームワークのことです。これらすべての要素を使用して、彼は史上初のグラフィカル インターフェイスを作成する商用エディタである Interface Builder を作成しました。
Interface Builder は、ウィンドウにドラッグしてプログラムを作成し、コード内でこれらの要素を使用できるコンポーネント (ボタン、ラベル、フィールドなど) のパレットを備えた最初の開発環境でした。これは、インターフェイス (ビュー) が表示内容を制御するもの (コントローラー) と通信できるようにするアウトレットまたは接続を使用し、アプリケーションが動作するためのデータはモデルに保存されました。 MVC パターンとして知られているもの。
さらに、Interface Builder により、FoundationKit と AppKit という歴史上最初のライブラリまたはフレームワークが明らかになりました。 FoundationKit は、データ型や数学関数を扱う一般的なタスクのために Objective-C をサポートし、AppKit では独自のインターフェイスを作成できるようにしました。 UIを作成するために使用されるオブジェクト、つまりボタンなどを格納するライブラリでした。このテクノロジーは非常に革新的であったため、NeXT は HTML 言語と Web ブラウザー、史上初の Web サーバー (Objective-C で動作)、Virtuoso (Freehand と最初の描画ソフトウェア ベクトルの父) を生み出したコンピューターでした。 ) または史上初の FPS が作成されたゲーム エンジン: Wolfestein 3D (Doom および Quake エンジンも NeXT で作成されました)。
現在でも、このテクノロジーはすべて依然として有効であり、macOS 用のインターフェイス構築ライブラリは依然として AppKit と呼ばれています。 30年の歴史の中で進化しているのは明らかですが、そのベースとなる本質は当時に定められ、今日まで受け継がれています。
iPhone ソフトウェア開発キットの最初のバージョンが 2008 年の夏に (App Store の開始と同時に) 開発者の手に渡ったとき、それは開発レベルで Apple にとって非常に重要な進化的変化を表しました。当時の iPhone OS 2.0 では、Apple が数年間の開発期間を経て初代 iPhone 用に作成した Objective-C に基づく新しいライブラリをサードパーティ開発者が使用できるようになりました。
当時の OS X が使用していたフレームワークの多くは、新しい iPhone 開発キットにもそのまま存在しています。実際、Apple は iPhone の最初の基調講演で、これは要するに OS X であると売り込みました。そしてそれが現状であり、これからもそうです。 iOS と macOS は異なるオペレーティング システムであるとは考えられません。これらは、同じシステム コアである Darwin と、ネットワーク使用、セキュリティ、グラフィックス、サウンド、さらにはインターフェイス自体のアニメーションなどの多くのライブラリを共有しています。 Apple が 2000 年に OS X システムの心臓部として作成したのと同じコアです。
iOS、macOS、watchOS、tvOS の違いは、Darwin コア上にあるシステム API と、それらが共有するコンポーネントにマウントされているシステム API です。たとえば、macOS では、GUI 提供 API として Aqua が使用され、インターフェイス構築 API として AppKit が使用されます。 iOS (2008 年の新機能) では、インターフェイス作成 API は UIKit と呼ばれます。新しい API はタッチ環境に適応されており、 AppKit とは互換性がありません。いくつかの点では似ていますが、互換性はありません。これは、私たちが現在どこにいるのかを理解するための鍵です。
iOS と macOS は異なるオペレーティング システムであるとは考えられません。これらは同じシステム コアである Darwin と、グラフィックス、ネットワーク、サウンドなどの一部のサービスを共有します。
したがって、今日では全員に同じコアを提供していますが、macOS 上にはアプリ構築ライブラリがあり、watchOS、iOS、tvOS 上には別のライブラリがあります。皮肉なことに、UIKit は長年にわたって進化し、他のシステムの他のビルド層からのサポートを組み込んできました。 Apple Watch とともに進化し、既存のコンポーネントと同じコンポーネントを使用して watchOS 用のインターフェイスを作成できるようになりました。そして、tvOS 上でネイティブ アプリを構築できるように再び進化しました。コンポーネントは、時計、テレビ、iOS デバイスの 3 つのケースすべてで同じです。しかし、UIKit は、同じコンポーネントの外観と操作をそれぞれの新しいプラットフォームのニーズに適応させるために、同じコンポーネントのさまざまな適応を提供します。
macOS を含めることは、次の当然のステップです。デスクトップ システムで動作するアプリを作成するために、UIKit が進化して macOS のサポートを取得するステップ。tvOS ですでに行われているように、UI がコマンド触覚とコマンドで管理されるこのシステムの動作と使用フローを継承します。は、ナビゲーション可能なタイルと、インターフェイス ゾーンによるフォーカスの概念の使用で構成されます。
統合はすでに存在します
Apple は現在、アプリを構築するための 4 つの主要な開発ライブラリを持っています。UIKit (iOS、watchOS、tvOS のみ)、AppKit (macOS のみ)、SceneKit (3D ゲーム用)、SpriteKit (2D ゲーム用) です。でも、何か知っていましたか？ SceneKit と SpriteKit が統合され、単一のコードとプロジェクトで macOS を含むすべてのシステムで動作する 2D および 3D ゲームを作成できるようになりました。
したがって、iOS アプリを Mac 上で実行する方法はもうありません。さらに検討する必要があります。 iOS アプリを Mac 上で実行するのは意味がないからです。私たちは、Google が ChromeOS で行ったことについて話しているのではありません。つまり、タッチ操作を想定しているため、アプリやゲームの一部が正しく動作しないパッチとして Android を適用したのです。つまり、iOS アプリをそのまま macOS 上で「エミュレーション モード」で実行することについて話しているのではありません。
ChromeOS が Android のサポートを追加したように、iOS アプリは macOS 上でエミュレート モードで実行されません。
Apple がMarzipanプロジェクトで行っていることは、UIKit を macOS 用のアプリの作成にも使用できるように、必要なツールを提供することです。 macOS 上で動作するということではなく、何百万もの開発者が iOS、tvOS、watchOS 向けのアプリをプログラミングする際にすでに使用しているものと同じツールとコンポーネントを使用して、macOS 上で正しく動作するアプリを作成できるということです。コンセプトとしては非常にシンプルですが、アプリが各システムに適応し、同じ互換性のあるツールを使用して、流動的で正しいユーザー エクスペリエンスを提供できるように、これらのツールを適応させるには明らかに多大な作業が必要です。
Apple システムを深く知っている私のような開発者なら、これが次のステップであることを知っています。 Steven Troughton-Smith や Guilherme Rambo (現在は 9to5mac の編集者) などの一部の有名な開発者も、これと同じ理論に同意しています。なぜなら、基本的に、これは Apple が UIKit を適応させることで実現できることをすでに示している、次の論理的なステップだからです。 tvOS のような iOS とは異なるシステムの使いやすさ。
したがって、iOS 用に作成されたアプリを macOS で動作させるには、論理的な調整が必要であることを理解することが重要です。メニューなどの独自の要素を組み込むことに加えて、アプリのすべての共通コードを再利用できる macOS 用の独自のインターフェイスを作成する必要があります。アプリにセキュリティを提供するサンドボックスを介した一時的なアクセス許可を通じてファイル アプリと連携するために iOS 11 に組み込まれた新しいインタラクションも、Finder と統合する役割を果たし、新しいアプリに対してファイル システム全体を開く必要がなくなります。
今日、すべてのシステムを含むプロジェクトを Xcode で作成すると、各システムには、各システムの実行可能ファイルとなるターゲットがあります。そして、それぞれに特定のリソースが含まれるフォルダーがあり、その一部が全員で共有されます。近年、インターフェイスはStoryboardと呼ばれる、アプリのナビゲーション マップのようなコンポーネントで構築されます。そして、tvOS 用、watchOS 用、iOS (iPhone および iPad) 用の別のものがあり、さらに macOS 用の新しいものが追加される予定です。
これは、macOS に新たな命を与え、より統一されたワークフローを可能にするユニバーサル アプリを実行できるようにする最初の非常に興味深いステップです。
開発者、ユーザー
この変化は自然なものであり、これまで見てきたように、論理的な進化の一部です。そして、この進化によって得られる主な利点は、macOS プラットフォーム自体にあります。 Mac App Store が砂漠であり、このプラットフォームが開発者にとって興味のないものであることは明らかです。ユーザー数がはるかに少ないからだけではありません。また、AppKit インフラストラクチャ自体がここ数年あまり進化していないため、macOS 用のアプリの開発はより高価で複雑になり、そのため UIKit が AppKit を使用して macOS 上で迅速かつ快適に実行するプロセスがより煩雑になり、より多くの作業が必要になるためです。
開発者に尋ねると、macOS でアプリを作成することは、開発者に過剰な敬意を与え、さらには恐れを抱かせると答えるでしょう。それはより退屈で遅いです。
UIKit の macOS への導入は、iOS エコシステムで現在動作している無数のアプリが継続使用のための統合ソリューションを提供できるようになり、macOS エコシステムが大幅に強化されるため、新風となるでしょう。私たちが iOS ユーザーだけであれば何も得られませんが、Mac を持っていれば、デスクトップ システムの新たな繁栄の時代を生きることになるでしょう。さらに、Apple 独自のアプリは 1 つの開発と連携して進化し、現在のように macOS 用ソフトウェアが放棄されたという印象を与えるのではなく、より多くの新機能が頻繁に登場するでしょう。 Apple の iOS 用ソフトウェアも放棄されたように見えることは知っていますが、 Apple が現在 macOS でも動作する新しいバージョンの開発に取り組んでおり、それが長い間アップデートを受け取っていない理由であると考えるのは論理的です。
Apple が数年前にあらゆる種類のアプリ向けに開始したソフトウェアのサブスクリプションも、非常に重要な役割を果たすでしょう。 iOS バージョンと macOS バージョンの 2 回課金されるアプリが登場し、興味のあるユーザーが iOS アプリのみ、または iOS と macOS の両方を使用できるようにするさまざまな種類のサブスクリプションが提供される可能性があり、使用の流れが作成されます。非常に興味深いもので、ついにデスクトップ システムが、別の忘れ去られたシステムとしてではなく、アプリ使用のエコシステムに完全に統合されました。
1 年以上前、 同僚の Eduardo Archanco によるインタビューで、私は、iOS チームと macOS チームが 1 つに統合されることが、ユーザーにとっていかに利点にほかならないかについて話しました。そして私たちが今目にしているのは、開発者とユーザーにとっての最初の結果であり、大きな利点です。
未来
私たち開発アナリストの多くは、 UIKit を使用して macOS 用のアプリを作成することが最初のステップになることに同意しています。
しかし、この最初のステップのもう 1 つの結果は、噂の ARM 搭載 Mac です。発表された 845 などのクアルコムの最新プロセッサは、x86 モードでソフトウェアを実行する機能を備えています。いくつかの制限はありますが、その能力はあります。 macOS アプリが少しずつ UIKit を使い始めれば、ライブラリが ARM (iOS デバイス) と x86 (Mac) の両方のバイナリを生成できるというパラダイムに直面することになります。そして、x86 の代わりに ARM バージョンの Darwin コアと、両方のアーキテクチャにすでに存在するコンポーネントが使用されれば、2006 年当時の PowerPC と Intel の間の中間段階のような、新しい Rosetta 時代が到来するかもしれません。開発を通じて両方のプラットフォームを統合する変革のステップ。
この最後の点は、明らかに、開発のレベルで技術的に妥当であり、今日の技術が可能にする基礎に基づいた理論として見なされなければなりません。そして、さらに多くの措置が講じられる可能性がありますが、それについては将来の機会に説明します。ただし、このトピックについてさらに詳しく知りたい場合は、独立した Cuonda ポッドキャスト コミュニティの一部である私のポッドキャスト Applecodingを聞いてください。 前回のエピソードの 1 つで、これらのトピックや、興味を引く可能性のあるその他のトピックについて話しました。それを掘り下げたい場合は。
ユーザーと開発者に提供される新しい可能性が明確であるとともに、私たちがどのようにしてここに至ったのかを理解していただければ幸いです。皆さんにご挨拶と感謝を申し上げます。
