前回の WWDC で特別な瞬間または注目すべきリリースを選択する必要がある場合、それは間違いなくSwiftUIです。 これについては、最近すでにお話ししましたが、開発者やデザイナーがアプリを作成する方法がどのように変化するかについてもお話しました。しかし今日は、このプロジェクト自体、その由来、iOS 13 以降でのみ機能する理由、そしてその開発の簡単な紹介についてお話したいと思います。さらに、Apple が作成したこの新しいテクノロジーを使用してインターフェイスを作成することがいかに簡単でシンプルであるかを理解していただくために、小規模で簡単な紹介を独占的に提供します。
SwiftUI、3年間存続するプロジェクト
macOS、tvOS、watchOS、iPadOS、iOS などのすべての Apple システムで動作する SwiftUI のようなプロジェクトは、Apple Park の同僚 3 人がしばらくの間、 「ああ、見てください」と言うようなものではないと真剣に言えると思います。 , Google が Jetpack Compose をリリースしたので、コピーしてみよう!」 。 SwiftUI のようなライブラリを作成することは、言語自体に統合されており、機能するために進化して新しい要素を組み込む必要さえあるため、数日でできるものではありません。これは、前述の Jetpack Compose (5 月の Google I/O で発表)、SwiftUI 以前の Flutter、または React Native と同様、数年にわたるプロジェクトです。
Apple でのプロジェクト後の一部のエンジニアとの会話の中で、彼らは約 4 年間 SwiftUI に取り組んでいることを確認しました。ここ数日で読んだことによると、すべての源は Facebook の React Native テクノロジーであるようです。 2015 年 3 月に登場した、宣言的にインターフェイスを作成するこの方法は、すぐに Apple の注目を集めました。主に、 Facebook がより快適で直感的な方法で UI の構築を技術的に解決したという事実です。開発者コミュニティでの成功を見て、このコンセプトを Swift 言語内に適用して、Apple の環境にも非常に破壊的なものをもたらすことができると考えられました。
そこで、クパチーノのチームはこのコンセプトを Swift とその仕組みに適用して検討し始めました。プロトコル指向や値の型などの概念は、Swift を最もよく定義する 2 つの特性です。そして彼らは、すべての Apple デバイスの中で最も要求の少ないデバイス、つまり SwiftUI の種が出現したデバイス、つまり watchOS でそれをテストしました。分析すると、Appleスマートウォッチは制約や要素の使用という点で最も要求が少なく、この新しい作業方法のプロトタイピングを始めるのに理想的なシステムでした。
最初の 1 年ほど、おそらくもう少しの間、このチームは非常に興味深い結果を達成し、それが他の Mac チームまたは iOS チームの注目を集めました。基本的に、このフレームワークの能力とそれがどれほどよく計画されているかを見て、彼らはそれをさらに拡大したいと考えました。そして、当初は Apple Watch の宣言型になる予定だったものが、残りの機器の助けを借りて、すべての Apple システムのライブラリになりました。 Dave Abrahams (Apple に入社する前は C++ アーキテクト)、Luca Bernardi、John Harper、Nate Cook など、クパチーノで最も有名なエンジニアの何人かが、多かれ少なかれ SwiftUI の開発に関わっています。
SwiftUI (Swift 5.1 より前ではない)
Apple が Swift 5 を発表したとき、 私たちはここで、言語のさらなる進化を可能にした基本的な概念、つまりバイナリの安定性についてお話しました。
通常、プログラミング言語の初期には、バイナリ コードの安定性という基本的な問題があります。 Swift のような言語には、それ自体に重要な部分があり、それが標準ライブラリです。これには、ほとんどの種類のシステム、API、および言語自体やその基本構造ではなく、言語の重要な部分であるライブラリやデータ型である重要な部分など、作業に使用するコンポーネントが含まれています。
問題は、Swift 5 までは、特定のバージョンでコンパイルされた標準ライブラリのみが、同じバージョンのバイナリ コードを実行できることです。バージョンを変更すると、コンパイルされたバイナリコードとして接続する方法が機能しなくなりました。そのため、Swift 5 までは、Swift のプログラムはリソースに言語ライブラリを含める必要がありました。 Swift に 30 個のアプリがある場合、各アプリの異なるバージョンのライブラリは 30 倍になります。
Swift 5 ではこの問題は修正され、Swift 5.1 (WWDC でリリースされた Xcode 11 に付属するバージョン。すべての Apple システムの新しいメジャー バージョンの最終バージョンになります) では、モジュールの安定性という決定的なステップを踏みました。ライブラリ (またはフレームワーク) をバイナリ形式でコンパイルしてオペレーティング システムにロードし、Swift 5.1 以降の任意のバージョンが、それを使用する任意のアプリにバイナリ レベルで接続してそれ自体を理解できるようにする方法。 。
これにより何が許可されるのでしょうか? Apple は、Swift で作成されたネイティブ ライブラリをオペレーティング システムにロードして、どのアプリでも使用できるようにすることができますが、ライブラリをその中に含める必要はありません。これが、iOS 13 以降のアプリが占有するスペースがはるかに少なくなる主な理由です。これは、アプリの基本ライブラリの大量の負荷が、それらを使用する各アプリにそのままコピーされるためです。そのため、スペースを取りすぎてしまいました。
なぜ私がこんなことを話しているのでしょうか？ iOS 13 でアプリが占めるスペースが大幅に減った理由を説明するためだけではありません (グラフィック リソースの圧縮などの他の要因は別として)。なぜなら、私たちがあなたに伝えているのは、SwiftUI で設計されたアプリが iOS 13、iPadOS 13、macOS 10.15、watchOS 6 および tvOS 13 でのみ実行できるということです。モジュールの安定性のおかげでライブラリがオペレーティング システムに読み込まれるためです。 。
実際、今年 Apple は、前述の SwiftUI、拡張現実用の RealityKit、非同期イベント用の Combine など、初めてオペレーティング システムに組み込むことができる、Swift で特別に作成された多数のライブラリをリリースする機会を利用しました。 SwiftUI と連携して管理します。
では、SwiftUI を使用してアプリを作成するにはどうすればよいでしょうか?
基本的に、すべては 1 つの重要な要素、つまり視覚に帰着します。このビューは、コンテンツが存在するBody返す必要があります。テキストなどの孤立した要素から、相互に複数の要素が入れ子になった構造まで、上位レベルのコンテナ (1 つだけ) が必要なコンテンツ。ただし、それは最高レベルのビューにすぎません。
たとえば、ナビゲーション バー (本文を返す最上位の要素) を垂直積み上げビュー内、ボタン内、ボタン上にテキストと画像を配置できます。ビュー内では、より多くの要素を含む他の構造で作成した他のビューを返すこともできるため、より複雑だが組織化されたこれらの階層を作成できます。
システムの上位レベルの要素として、ナビゲーション ビュー、リスト、積み上げビュー、フォーム、スクロールビューなどを返すことができ、これらの構成要素と残りの要素がインターフェイスを構成する方法になります。どのビューも最上位レベルに置くことも、ネストされたビューの一部にすることもできます。基本的には Web ページとよく似た構造です。
そしてデータは？使用するさまざまなビュー間でデータを渡したり、構造自体内でデータ列挙を使用したり、オブジェクトを動的データとして提供する同期データ ソースを作成したりできます。非同期データであっても、取得されるとインターフェイスにイベントが表示されます。いくつかのプロパティに状態を与えることもでき、プロパティが変更されるたびに、画面上のビューが再描画されます。
SwiftUI でフォームを作成する方法に関する簡単なチュートリアルを見たい場合は、Apple コーディングの「スニペット」セクション内に私が YouTube に投稿したビデオがあります。このビデオでは、簡単かつ迅速にフォームを作成する方法が説明されています。シンプルなビューと、リアルタイムで結果を確認する方法。
なぜ SwiftUI なのか?
Apple でのアプリの作成とデザインの現在のテクノロジーでは、描画できるインターフェイスがコードとどのように接続されているかをデザイナーが理解するのが難しいのが現実です。そして、私たちプログラマーにとって、Apple でのインターフェイスの構築方法に従わないことで、私たちの仕事を過度に複雑にするデザイナーのアイデアを複製しなければならないのは、言いようのない怠惰に思えます。すべてが問題だ。
SwiftUI は、Web とそのアダプティブ デザイン (前身である React Native がそうであったように) により似た概念にアプローチし、純粋にデザインに専念する人々による理解とデザインを容易にします。これにより、インターフェイスがどのように見えるかが一目でわかり、各要素がどこから来てどこに接続されているかを理解することができます。メンテナンスが容易で、構造が単純であるため、Sketch や Adobe XD などのデザイン ツールで、デザインを開発者に渡すコードに直接変換するコード「ジェネレーター」を作成するのが非常に簡単です。
間違いなく、Apple システム用のアプリ開発において新しい時代が始まり、非常にエキサイティングです。そして、私たちはまだその道を歩み始めたばかりです…Apple が最終的にユーザーエクスペリエンスを豊かにするコンポーネント (さらにはサードパーティの開発者) をさらに多く作成するだろうと私は確信しています。私たち全員が勝ちます。テストを開始したい場合は、Mac と Xcode 11 をダウンロードするだけで済みます。事前に確認したい場合は、macOS Catalina のベータ版と、お持ちのデバイスをインストールする必要があります。
この小さなコーナーから、この開発の背後にあるチーム全体に敬意を表します。ブラボー。