00:01
はい、みなさんこんにちは。今回、AirSap第33回ですね。
今回はですね、先日行われたWWDC2019についてですね、私水口と若林さんと、そして今回ゲストでnotoさんが来てくださってますので、
あーでもない、こうでもないと話していけたらなと思います。
notoさんは前回20回目に出演してくれてますので、そちらも併せてお聞きください。
では、簡単にnotoさんにまた自己紹介をお願いできますかね。
notoでございます。iPhoneアプリを作っております。
iPhoneアプリ、もう10年ぐらいやってますけども、まだまだAppleが出しているものに対して、うまく扱ったり扱えなかったりしております。よろしくお願いします。
よろしくお願いします。
じゃあ今回のWWDC2019なんですけど、結構iOSあたりもTBOSとかもガラッとね、なんかこうベースが変わりそうですね。
いやーなんか盛りだくさんでしたね。
そうですよね。
去年があったからこそ、今年がかなり多く見えるっていうのもありますけども、前回のWWDC2018で発表されたものとはちょっと違うものが出てきたりとか、結構面白いところが多かったです。
具体的にはUIキットっていうのが、アプリのベースのなるキット、SDKの1個が、そんなに去年ほどフューチャーされてないというか、もっとでっかいものが出てきて消し飛んでしまってるって感じになってます。
SwiftUIですね。
SwiftUI、なんとSwiftにUIがついてしまう。
このスペース入れないっていうのがポイントですね。
Swiftとはまたちょっと別っていう感じなんでしょうかね。
なんて言うんでしょうね。
SwiftでUIを書きやすくしたものっていう感じで、UIキットとかMacのAppKitだとか、そういったものとはちょっとレイヤーが違うというか、SwiftUIで抽象化されたって言えばいいのかな。
そのUIを組む方法が提供されていて、それで例えばViewを作ったっていうことをすると、
iOSアプリ上ではUIビューが表示される。
Mac上のAppKitではNSViewが表示されるっていう形で、
結構共通化できるっていうのが一つのミソなのかなと思いますけど、こんな感じの理解であってます?野田さん。
03:05
SwiftUIを使う側にとっては、MacだろうがiPadだろうがiPhoneだろうが、気にしないで扱えちゃうっていうのがすごいとは思いますね。
ウォッチOSも同じ仕組みでいけるって言ってましたもんね。
ウォッチOSもビューっていうか窓というか、画面上に出てくる視覚の領域の組み合わせなので、
本当にSwiftUIを使うと何ちゃらUIビューとかNSビューじゃなくて、ビューみたいな本当にそのまんまみたいな名前で呼び出せちゃうというか、記述できちゃうって話ですね。
なので、あんまり作り手としては、ウォッチOS作ってんのか、iPhoneのアプリ作ってんのか、Macのアプリ作ってんのかよく分かんないというか、気にしないで済むように一生懸命Appleが採掘したって形です。
より今までTVOSとかウォッチキットとかなんとかキットとか、そういうのを使って、それぞれのデバイスに特化したコードを書いてたのが、
一つそのSwiftUIというものを使うことで、Appleが自動的にそれに合わせてくれるので、開発のUIとか作る時間を最低限にして、それ以外のコンテンツを作る方に時間を当てられるよみたいな、そういう狙いがあるんじゃないですかね。
そうですね。記述方法自体もすごくシンプルになっていて、iOSのアプリでよくみんなが使うUIテーブルビューってあるじゃないですか。
あれがリストっていうものになってるんですけど、SwiftUIでリストを書くと、裏でUIテーブルビューに変換されるのか、独自の何かかは分かんないですけど、UIテーブルビューっぽいものができるんですよね。
それが本当に、iOSアプリを書いたことがある人だと分かると思うんですけど、UIテーブルビューコントローラーっていうのと、それに付随するデータソースとデリゲートっていうのがあって、それぞれいろんな場所にいろんなコードを書いて、リストっぽいものが出来上がるっていう仕組みになってるんですけど、
リストって作ってあげて、この辺りのものを、このデータセット使ってここに表示させてね、ぐらいな感じでテーブルビューができてしまうっていう、4行とか5行とかで終わっちゃうんですよね。それは本当に省力化っていう意味ではすごいなっていう感じですね。
06:01
これまでSDKにかけてた知識とノウハウというか、深く追求することが減ってしまうというか、今まで学習してたものって何なの?って思うぐらいのものができちゃうっていう形です。ステフと言えば、使いこなせばって話ですけども。
逆にあれですよね。今までのやり方で、多分ちょっと小技っぽいものを聞かせてたような場合はそういうのができなくなって、多分またSwiftUI用のそういったちょっとした小技みたいなものが出てくるんだろうなって感じですよね。
そうですね。SwiftUIから呼び出せる小技機能の部品がもっと増えてくるんじゃないかなって気はします。テーブルビューでも特殊な表示をするための部品はそれこそMacKitとかiOSとかiOS SDKとかを知ってる人が作って、それを使うだけの人っていうのが増えてくるのかもしれないです。
確かにライブラリいっぱい出そうですね。そのSwiftUIの中で、今までのUIビューとかUIキットの部品を使う方法っていうのがあるので、その中間部分を書いたライブラリめっちゃ出そうですね。確かに。
その辺りでオープンソースというか、自分で作ったものを公開してみんなで使っていいよっていう人たちがiPhoneのアプリの開発者とか結構いらっしゃるので、そういう人たちとの情報網とか連絡網でこういう便利な部品できましたよって言ったらみんなワッと取り組むみたいな。
そしてさらにもっといい機能になるかみたいな感じでさらに機能が改善していくっていう、部品部品の機能の改善っていうのは期待できるかもしれません。
あとなんかSwiftUIってすごい書き方が、ある意味自由になったというか、なんかそのウェブサイト組み立てるみたいな雰囲気で、縦並びでこれを表示してねとか、間にスペース入れてねとか、間にディバイダー、
線入れてねとか、そういうのをコードで書いていって、プレビューも出てて、どっちからも操作できるんですけど、一見すごく自由に書けるような感じがありつつも、
09:00
ディバイダー入れてねって言ったらディバイダーの形決まってるとか、ナビゲーションの次の画面に行くためのボタンにするよって言ったら右側にシェブロン、ひらがなの句みたいなやつが自動で出るとかっていうところがあって、
あとパディングって入れたらいい感じに余白を開けてくれるとか、自由に組み立てられるっぽいけど、逆にSwiftUI側でいいようにやっとくよみたいな部分の不自由さがあったりとかして、その辺のバランスがすごい面白いなと思って今見てますね。
思ったものをそれっぽくいい感じに作ろうとするのはすごい早くて、ただすごい凝ったものを作ろうとすると、凝ったというか、デザイナーが1ピクセルレベルでこだわりを持ってやろうとかっていうようなものをやろうとするとまた大変なのかなみたいな。
印象を持ってますね。その辺どう思います?野党さん的には。
SwiftUIに関してはその難易度を下げるって部分がかなり大きくて、例えば注力しない画面ってSwiftUIだけで描けるよねっていうことを言えると思うんですよ。
デザイナーがそもそも苦労して作りましたって画面は置いといて、まずは設定画面とか、あの辺の画面ってほとんどリプレイスできそうな雰囲気じゃないですか。
で、もともとそういうシンプルに書こうっていうようなものはオープンソース、要はネットに公開している便利機能の中に設定一覧、特殊な記述を書いた設定一覧で書けばそれがそのまま画面になりますよみたいな便利機能もあったんですけども、それはほとんどリプレイスできちゃうんじゃないかなっていう期待はあります。
なるほどなるほど。
あとはこれを見る限りだと、やっぱりもっとアプリシンプルに作ろうよっていうイメージとメッセージが伝わってくるかなって気はします。
ですよね、自分もそれすごい思って、余白とかを勝手にデベロッパー側のデザイナーが決めんなよみたいな、うちでもいい感じの最適なものを用意してるんだからっていうような感じとか、あと文字の大きさとかもタイトル属性だとかサブタイトル属性だとかっていう入れ方をできて、
フォントサイズに関してもダイナミックタイプっていうユーザーごとに見やすいように設定できる仕組みもあるし、いい感じに用意されてるんだから、変にフォントサイズいじらずに決まったものを使えばいい感じの見た目になるし、使いやすいんだぞみたいなアップルのメッセージがすごい見えるかなって思いますね。
12:26
そういう視点でいうと、使い手っていうものがアプリ開発者っていうよりかは、それこそHTML5とかCSSとか、そういったものを使うのはウェブデザイナーが触ってほしいみたいなところもあるのかもしれないです。
ウェブデザイナー気質がある人をより優先、優遇してる感じでストレスかけますよみたいなアピールしてる感じがします。
確かにウェブもHHタグとかそんな感じですもんね。
そうですね。ドットシンタックスでドットを叩けば何か属性出てきますよっていうのも同じですし、そういう点でいうと本当にウェブの書き方ですよと。
ボディーなんてキーワードって特にウェブでよく使うキーワードじゃないですか。
確かに。
今はスイフトのコンテンツのサンプルコードとかちょっと見ながら話したりするんですけども、例えばそのスイフトUIを記入するコードの中にボディーっていう変数があって、これって要はCSSとかで言うときのボディーだよね、ウェブの言うときのボディーだよねみたいなざっくりした切り方で見てます。
今のところはやっぱりアプリをチクチクチクチク作って労働集約的にUI作りましたっていうのはちょっと考え直した方がいいんじゃないのっていうメッセージが見て取れますね、Appleからの。
そういう面で言うとスイフトUIだけじゃなくて、今回iOSでもダークモードが出てきたじゃないですか。
ダークモードにきちっと対応、きちっと対応というか楽に対応しようとするときはやっぱりフォントの設定、文字の設定をタイトルとかそういう指定にしておけば後はOS側でいい感じに色をダークモードの場合は文字色白だったりグレーの濃さを変えたりとか。
確かグレーもアルファ入ってて10日のグレーだったりして結構複雑なんですけど、そのあたりもいい感じにしてくれるよっていうのがあって。
やっぱりそこでも決まったものをそのまま使ってくれた方がユーザーにとってもいいし、下手にお前らがいじるよりもいい感じになってるからこれを使ってねみたいな。
15:01
そういったメッセージというかそういう方向にしたいんだろうなっていう感じがちょっと見えるかなって思いますね。ダークモードに関しても。
もちろんこれまでの過微なUIって全否定してるわけじゃないと思うんですけども、アプリにあるとしたら1個ぐらいとかそういった感じかもしれないです。でっかいワンボタンのUIってちょっと前まで流行ってたじゃないですか。
ワンボタン、画面上のでっかいボタンみたいなものをタップすると機能が走って大体何かやってくれるとか、そういうようなUIを別に否定するわけではないと思うんですけども、その周辺の画面パーツ、リストを表示しなきゃいけないとかは、
こっちにSwiftUIの示してるところに乗っかった方が楽できるんじゃないかなって思います。人間的な労働力的な問題も時間とかも含めてね。
そうですね。だからSwiftUIのセッションでも今野戸さんが言ってたみたいなことを言ってたような気がしますね。
ここぞというところでは頑張って、そうじゃないところは頑張らなくていいみたいなことを言ってたような気がします。
Appleは今後、ドラスティックな変更を今後も加えていくということかもしれませんし、本当に今回出てきたSwiftUIのパーツって本当にシンプルなものなので、ここから新しいキーワードとか新しい仕組みが入ってきたら、もうかなり機能的にはモリモリになってくるので、今のところはこういうシンプルな作りだけど、
とはいえ今後機能がある程度欲しい機能とか開発者とか作り手から出てきたら追加するよっていう余地はかなりあるかなって気がします。
ところでSwiftUIのチュートリアルってやりました?
チュートリアルは半分やってます。序盤は見てます。
チュートリアルが結構順を追ってSwiftUIで何ができるかっていうのを教えてくれる教材になってて、
なんか今までになかったですよね、Appleがそういうチュートリアルっていうものを出すのは。
詳しいドキュメントとかはあったりとか、わかりやすく簡略化されたドキュメントみたいなのはあったと思うんですけど、
あとサンプルコードとか、これを使って順にやっていくと理解できるよみたいなチュートリアルってなかったかなと思って。
18:00
自分も全部で何個あるんでしたっけ?
6個か7個あるうちの、最後の2つだけ読むだけにして、あとは大体やってみましたけど、
理解が進むような感じで、なかなか良かったですね。
ただやっぱ疲れますよね、チュートリアルって。やってると。
結構細かく書いてますね、これね。チュートリアル。
そうですね。
まずエッセンシャルからアニメーションも作ってデザインしてっていう感じ。
アニメーションを入れていくあたりがAppleらしいっていうか、ここは外せないなっていうところがありますよね。
アニメーションのチュートリアルがかなり充実してる感じですね。
これでもXコードを開いてプレビュー出したまんまでやるじゃないですか、SwiftUIって。
それでさらにチュートリアルの画面をiPadか何かで見ながらやるっていうのが結構作業スペース的にしんどいものがありましたね。
それはデカいAppleが出したディスプレイを買っていただいて、8Kディスプレイでスタンドだけで10万円のやつを買っていただいて。
あれ6Kです、6K。
6K。8Kじゃなかったか。
プロディスプレイXDRだっけ。
それを買えっていうメッセージですかね、それを。
デカいディスプレイは正義っていうメッセージは受け取りました。
確かに。
高いかどうかは知らないけど、とりあえずデカいディスプレイはいいぞっていう。
しかもあのディスプレイローテートもできて縦長にもなるんで、すごいいいなって思いました。
コードを書く上で。
高すぎですけどね。
本当に業務用ですよね。
あれ45とか45万とか45万ぐらいですよね。
高っ。
足別で45万ですよね、たぶん。
足入れると50万オーバー。
55万とか56万とか素敵なやつです。
どういうことか。
製作のところに置いておくようなマシンですね。
CGとかムービー制作とかの感じですよね、あれだと。
ディスプレイ3台ぐらいバンバンバンって置いて、ムービーをほぼリアルタイムに編集するみたいな。
マックプロ買うと、新しいマックプロだったらこれ6枚ぐらいいけるんですよね、確か。
6枚いけたはずですね。
でもあのディスプレイの値段見てから、どのディスプレイ見ても安いなって思いますね。
XDR、今回出したディスプレイの値段で、値段以下で4Kディスプレイ3枚ぐらい買えちゃうってレベルか。
21:04
いや、もっと買いますよ。
買えるか、素晴らしい。
4Kディスプレイだって今3万ぐらいかありますもん。
すごく安くなりましたよね、一時期に比べて。
Apple Storeで売っている5Kディスプレイでも14万とかなんで、
6KのプロディスプレイXDRと比べると、なんて安いんだって思いますね。
話がちょっと戻したいんですけども、
SwiftUIのSDKがチュートリアル出て新鮮、Appleとしては新鮮だったっていうのがあると思うんですけども、
それって多分SDKベースで教えてるのと、SwiftUI経由で教えてるのってのステップが違うというか、教え方が違ってるのは確かに認識してて、
iOS SDKとかだと、動いてるものを見てもらわないと何が動いてるかわからないっていうところがあると思うんですよ。
つまりサンプルコードとして動かさないと全体像をつかめないというか、そもそも物が動かないってことが多くて、
部品部品を説明しづらいってところがあったんでしょうけど、SwiftUIだとそもそも部品の塊なので、
部品部品1個作っていってそれを改善していくプロセスで説明しやすいってところがあると思うんですよね。
しかもプレビュー動かせますもんね。
ほぼリアルタイムに動くので、それをいじっていくというか、チクチク確認しながらやっていくっていうところが、
これまでのXcode、開発ツールに入ってたUIの操作系とは違う話で、全く異なってくるという。
リアクトネイティブとか、ああいうホットリロード効くのと開発の仕方が似てくるかもしれないですね。
リアクト系、近づいてはいると思います。
ただAppleらしいエッセンスというか、それはなぜかというと、言語レベルから改善しているとか変更しているというところがかなりAppleらしいと思います。
なんか初めて見るSwiftの書き方みたいな、結構ありましたもんね。SwiftUIのチュートリアルとか見てると。
SwiftUIの見てない方に説明しますと、SwiftUIって別に特殊な記述方法とか言語みたいな定義ではなくて、記述文ではなくて、Swiftそのものなんですよ。
Swiftの言語を書くのように見えないんだけども、それでUIが書けちゃうみたいな、あんまり見ないような記述方法なんだけども、これSwiftの正しい記述方法になってて、
24:15
見えるし、試しに画面を作るときにもSwiftUIのソースコードを見るっていうすごい特殊な動きになってますね。
なかなか説明してないというか、書いてるものが見えたものにそのまま直結するっていうかなりすごい作りにはなってます。
今までのiOSの開発だと、コードとストーリーボードっていう画面をビジュアルで作っていくものと2個があって、
それらを接続してお互い行ったり来たりして作ってたっていうところがあるんですけど、
それは接続されてて参照してるっていう状態だったのが、
今回のSwiftUIはプレビュー自体とコード自体は1対1で完全に同じものをコードで見せてるのかプレビューで見せてるのかみたいな感じになっているから、
そういう意味では作り方が根本的に違うっていう感じがありますよね。
プレビューにとってはこのSwiftUIに書かれたコードって別にSwiftとして解釈しなくていいんですよ。
UIの記述ルールに基づいてるからこれをそのまま表示するみたいな感じで見せて解釈もできるじゃないですか。
ここまでSwiftっていう言語とはちょっと違う記法になってて、
普通のマークアップ言語っぽい、実際にはDSLっていうドメイン固有言語っていうUIとか何かを実現したいときに定義する言語ではあるんですけども、
それがSwiftっていう言語と同じみたいな、
本来は目的があって記述するための言語ってプログラミング言語とは別々に用意するっていうのがこれまでの考え方なんですけども、
SwiftとSwiftUIはそれを取っ払ってSwiftUIの記述イコールSwift言語としても見えますよっていう、
非常にストレートに言って分かりやすいような分かりにくいような、従来の会社はすごく混乱させるようなバッツリと変更を加えてるっていう印象があります。
でもメリットすごく大きいですよね。
こちらのメリットは測り知れないと言えますね。何しろ書くものが少ない。見るものが少ない。
27:10
あとバージョン管理でコンフリクトしないストーリーボードの。
独自の記述って結構、人間の目とかあんまり気にしないで作るもんだから、バージョン管理って人間が作ったものを視覚的にここが変わったよとか見せてくれるんだけども、それが効かないんですよね。
今までは。SwiftUIっていうのはほぼソースコードというか、本来ソースコード管理っていうアプリを動かすための元のデータを利益をちゃんと持って管理するってところにマッチしてるというか、管理する仕組みとすごくマッチしてます。
普通にソースコードで自分がこのUI変更したっていうのがバッツリ分かっちゃうっていうか、すごく分かりやすくなったって形です。
今まではできるだけストーリーボードを分割して、お互いに複数人で返すときは触らないとかそういう話で、わけのわからない状況になるのを避けるっていうのをやってたけど、そういうのが必要なくなりますよね。
無駄なローカルルールがなくなるっていう話です。
そうですよね。
具体的には、例えばソース管理できないUI、アップルが提供しているUIの設計機能っていうのを全く使わないっていうふうな縛りをしている会社とかアプリ会社とか会社とかもあるので、
そこまでけぎらいされてたものをアップルが2019年WWDCで全部取っ払えるよというすごいことを言ったっていう形ですね。
本当に会社人とか個人によってまちまちでしたね、これまでのUI設計の良いか悪いかっていう話で言うと。
そうですね、全部コードで書くよみたいな人とかも結構いましたもんね。
オートレイアウトを使いたくないとかいましたもんね。
オートレイアウトをソースコードで記述するって人もいましたね。
いましたね。
変な幅図がいて、全部ソースコードベースで記述すればバグが出たときにあたふたしなくて済むっていうようなことの信念を貫きすぎて、
もうすごい開発効率落ちてるっていうところはあったりなかったりしますね。
それは会社によって温度差があると思います。
個人開発者だとサッと作るんだからUIのツール使わないでどうするのみたいなところもあるし、
30:06
大きな会社だといやいやそんなんダメでしょみたいな。
そういう開発者同士の断絶感がありましたね、UIに関しては。
そんなこれから色々と便利になりそうなSwiftUIですけど、
とはいえiOS13以降じゃないと使えないんですよね。
話だと13って話ですね。
ですよね。
なので結局多くの企業とか開発者はまだまだSwiftUIを使うっていうのは2年後ぐらいまではお預けになるのかなって気がしますね。
お預けですけど早く来た時にこれ分かってないと終わりますね。
今からやっとくのは大事って感じですよね。
これを全否定してるのはちょっと違うかなって気がしますね。
今まで自分たちがこれと似たようなことを手で返した労力があってそれを手放せないっていうことで
SwiftUIを取り組まないっていうことをやると大変なことになると思います。
だいたいSwiftUI解決してることが多いので。
あとはiOSはOSのアップデート早いので、ユーザーがアップデートする機会が多いので、
やはり1年2年なのか1年なのかってちょっと期間はわからないですけども早々に受け入れられる可能性はあります。
とりあえずフットワーク軽い個人開発者とかはもう今年の後半にはSwiftUI使って
iOS13専用でアプリ出すとかをやっといても良さそうだし、
その方が今後4,5年のメンテとかを考えると楽かなって感じがしますね。
いいですね。今回はほぼ言語の一部じゃないですか、言語っぽく見えるじゃないですか。
なのでコンバーターみたいなものもすごく分かりやすく動くのかなって期待はしてます。
毎回Appleって新しい言語がアップデートするたびにその言語をアップグレードする仕組みを用意してくれてるんですよ。
それがSwiftUIだとスムーズに動くんじゃないかなっていうちょっと期待はしてます。
今後の話ですよね、13から14とか、今Swift 5.1が出たところですけど、
33:05
5.1から6になる時とかにSwiftマイグレーターでしたっけ?
マイグレーション機能みたいな。
そうですよね。自動で変更されるところをいい感じにやってくれたりやってくれなかったりする機能が、
確かにSwiftUIで書いておくといい感じになりそうですね、確かに。
なので過去の言語の使用が書いたものが無駄になるっていうことが減るのではないかという期待はあります。
SwiftUIで書いておけば。
とはいえ、最近はそんなに大きな問題になるようなことも減ってはいましたけどね。
おそらくはそのボキャブラリー、ビューとかが何かもっと多様化してくると、
今までのビューっていうのはSwiftUIでも一番シンプルな画面の単位なんですけども、
この画面の単位の種類が増えたらマイグレーターでいい名前にしてくれるとか、
そういったことは期待できそうな気がしますよね。
確かにありそうですね。
何か基本的なボキャブラリーの語彙の部分が変更になったときにちゃんとマイグレーションしてくれるとかだとありがたいなって気がします。
そういう可能性があるというだけでやってくれとは保証されてるわけではないんですけど、
このサンプルとかをチュートリアル見る限りだとすごくカリタシーの良さを感じます。
SwiftUIに関して言うと、個人会社だと今度はApple WatchとiPhoneとMacで同時にアプリ出しましたみたいな
ドヤーができるんではないかなという期待はあります。
とはいえ共通の書き方ができるというだけでそれぞれに最適化しなきゃいけないのは確かなので、
なやかねで共通のコードでは書けなさそうな感じはしますけど、
特にWatch。
でもある程度共通化しやすいというか、再利用しやすいという感じはありそうですね。
UIで何か便利な機能を提供する開発者よりかはネットとか、
ネットの奥裏にあるサービスを叩く時のアプリを作る時にはすごく重宝な気がします。
SwiftUIを使う開発のターゲットとしては、ユーザーと開発者としては、
36:05
すでにウェブでサービスが立ち上がっていて、
それのアプリ版を作りましたというのはすごく簡単に言えるのかなという気がします。
なやかねでそういうアプリが一番多いですもんね。
今はそういったアプリがかなりの割合を占めている気がします。
メインの画面がウェブページベースで、横のメニューとかが
Android、iPhoneとかでネイティブの機能を使ってますよみたいなものは多いので、
そういったアプリのSwiftUIの切り替えっていうのは起きるかもしれません。
さっきから水口さんが非常に静かなんですけど、
しっかり聞いてて入る余地がなかったというところがありますね。
結構戻るんですけど、そのSwiftUIの技術のウェブみたいだって言ってたときに、
確かにスタイルシートを書いてるような感じで、
レイアウトを変えていけるっていうようなところも感じてて、
その辺ざっくり本当にプロパティ書いてるような感じで編集されてたんで、
編集というかアプリ作ってたんで、その辺はすごい今までよりも楽になってるなっていうのは感じました。
チュートリアルまだやってなかったんで、今Xcodeダウンロードしてやってみようかなって考えてるところですね。
チュートリアルとかサンプル動かしたら面白いのは、プレビュー側からプロパティを追加できる。
SwiftUI側にポコポコいろいろ追加できるんですよ。
ただのプレビューと思いきや、何か機能とかを追加できたりとかするんですよね。
パーツをコードにドラッグ&ドロップするみたいな機能ですか?それとは違う?
それもありますし、それはスタックかな、Vスタックとか、エッジスタックっていう積み上げ系のUI。
横に並べますよとか縦に並べますよみたいなUIもそうですし、
一個一個の部品に関してもプレビューから追加できるはずです。
今までのストーリーボードに部品を追加するみたいな操作をプレビューに対してやると、
プレビューに当然足されるし、それと同時にコードの方にも同じものが反映されて追加されるっていう動きがちょっと面白いですね。
39:00
すごいですね、それね。
前はストーリーボードに追加して、それをコードで動かして、実機とかシミュレーターでテストしてっていうところだったのがかなり簡略化されるっていうところですね。
変更箇所が一箇所にまとめられてるっていうところですよね。
何やってもSwiftUIの定義に反映されるってすごい良い話ですよね。
今までの開発だとそうではなくて、部品の初期に入っている値なのかどうかもすら怪しいので、
どこの色変更しましたっていうのもよくわからないってことが多かったので。
それこそSwiftUIって名前の通りのUIとSwiftのコードがより密接になってすぐわかるようになったっていうようなところが非常に扱いやすそうだなって思っています。
そうですね。UIの定義イコールSwiftのコードっていう言語仕様的にはそうなってしまったので、Appleが。
だからSwiftUIで特徴的なのはリターンってないじゃないですか。
そうですね。
でもそれは実は1個しか与えなければそれはリターンだみたいな。
デフォルトリターンみたいな感じ。
1行しかコードが入っていなければ、その定義の中で1行しかコードが入っていなければそれはリターンが入っているとみなすっていう省略系があるんですよ。
Swift 5.1で入った新しい仕様ですよね、確か。
そうですね。5.1以前にもそれっぽい記述ができるところはあったんですけども、書ける場所は違ってたんですよ。
書ける場所を今回増やしましたよっていう、ある条件下でリターン書かなくてもいいよっていうルールをもっと広く適応、もうちょっと広く適応しましたっていうのがSwift 5.1の話ですね。
なので一見これはただの定義じゃないかって思ったらそうではなくて、実は何かのリターンが入っているとか、そういったふうに捉えることもできる。
Swiftの言語仕様とか知っていれば。
なのでアプリ開発者としてはUI書いているような雰囲気を押しつつでも、これはSwift言語なんだっていうふうな頭で手を動かしていると理解度が早まるかもしれません。
あとはサムとか謎の定義があって、これSwift言語じゃないじゃんって言うかもしれませんけども、これはサムっていう定義があるんですけども、
それってSwift 5.1以前はなかったんだけど、5.1からわざわざ追加された、Swift UIのために追加されたような仕様で。
そういう感じでAppleはSwift言語にまで手を入れてSwift UIを作りましたっていうことを分からせてくれると教えてくれますね。
42:09
だいぶ本気ですよね、本当に。
本当に言語仕様を自分のプロダクトに合わせて書いちゃうってすごいよねみたいな。
もともとSwiftがAppleが作ってたものっていうのはあるんですけど、根っこから変えるってところはApple大好きですから、
本本的な開発者が持っているトラブルとか困難とか直面していることをAppleらしい本本からひっくり返すっていうことで直してくれるっていうのはありがたいですよね。
時間的にもうそろそろかなと思うので、最後に。
野田さんはもうSwift UIで何か作ってみるって予定はあるんですか?
現状のバッテリーモニターのアプリを出してるんですけども、それってSwift UI向けかなって思ってます。
それに変更してバージョン2になる可能性はあります。
何てアプリでしたっけ?
グロリアスバッテリーっていうのがありまして、複数のiPhoneのバッテリーとかのモニタリングするというバッテリーの状態を一つの画面にまとめて表示するみたいなアプリがありますね。
これって本当にシンプルなUIで構成されているので、本当にSwift UIとか出てくるとありがたいっていう思いしかないです。
9月のiOS13が出るあたりにきっと野田さんのグロリアスバッテリー2がSwift UI制で出てくるというのを皆さん楽しみにしてくださいって感じですね。
あともう一個予定はしてて、iPadのアプリが出るかもしれないです。Swift UIベースで。
ちょうどSwift UIでアップルからの良い技術的な縛りが出てきたので、それを含めてiPadのアプリを作れればいいかなとは思ってます。
iPad OSですね。
iPadオンリーのアプリの方が切り口としては面白いかなと思ってて。
iPhoneだとどうしてもマスとかいっぱい使うユーザーとか一般のユーザーを気にしなきゃいけないところがあるってあんまり好きじゃなくて。
だったらもうちょっと業務に特化したとか目的に特化したアプリを出すんだったらiPadの方がいいかなって気はします。
っていうのをSwiftで作りたいなって気はします。
この夏は忙しいですね、そしたら。
45:02
夏が消し飛びますね。
でもその夏が消し飛ぶぐらいやりたいことができるようなそんなSwift UIの発表だったという感じですね。
開発者全員リセットですからね。
この神の雷がドーンみたいな感じで来たっていうのはアプリ開発者嬉しいところです。
そうですね、みんな多分そういうふうに思っているかもしれないから
結構iOS 13出た時に個人開発系のアプリ多く出るかもしれないですね、新規アプリが。
しかも結構早いはずですねSwift UIは。
ネイティブでの描画処理とかガンガン使っているので
ハードの13で切ってしまったハードを気にしなくなったので
その分処理が早くなる可能性があって
iOS 13っていう切り口だけでも結構早いサクサクアプリがいっぱい増えてくる可能性はあります。
13で結構古い機種は切られているので
あとはSwift UIってその辺の最適化を勝手にやってくれるので
従来のOSよりかはすごく軽いものがリリースされる可能性はあります。
UI的に軽いという意味で。
一般ユーザーにも恩恵がありそうだと。
恩恵があるのではないかなと。
一般ユーザーごとインストールするので何かヒーローが出てくるかもしれないです。
ARとか他のWWDCの技術とかも含めて
うまくマッチしたものが何点か受け入れられるという可能性はあります。
夏遊んでる場合じゃないですね。開発しないとですね。
これはまた用意ドンという感じで発表までにしっかり間に合わせるという感じですね。
iOS 13のラウンジまで。
ローンチか。
ローンチはローンチでとんでもないものが出てくる可能性もあるので。
ハードを含めて。
ハードで実はARでしたとか今回話題にしなかったところが
のハードが出てくる可能性とかもあるので。
そうですね。ARグラスが出て
そういう人言われてすぐかけるよとか言ってね。出るかもしれないですね。
ハードによってそうですね。
春にハード無しで発表して
ローンチタイミングでハードと新しいSDKに何か追加しましたよっていうのをポロッと出すので
ありがちですね。
UIはちょっとあんまり影響はないと思うんですけども
ARとかそういうハードに直接絡む部分に関してはちょっと要注意というか
48:03
Apple目離せないというところはあります。
今日はそんなところですかね。
そうですね。
SWIFT UIの話ができて今回は満足です。
では今回はこんなところでご静聴ありがとうございました。
ありがとうございました。
ありがとうございました。
