00:03
みなさん、こんにちは。今回は、AirSap第36回です。
今日は、ゲストにnotoさんをお招きして、SwiftUIについて話していただこうと思います。
notoさんは、この間ツイッター上で、SwiftUIの地雷を全て踏むというツイートをされていましたので、
今回、どんな地雷があったのかとか、その回避策があれば、話していきたいなと思います。
SwiftUIって、ほとんどの開発者さんは知っていると思うんですけれども、今までストーリーボードで書いてきたUIを、
Swiftのコード上で書けて、しかも、非常に簡単にシンプルに書ける。結構、管理が楽になるようなイメージがあります。
で、あっているのかな?
大体、ざっくり言うと…
ざっくり言うと…
ざっくり言うと…
そんな感じなんですが、ただ新しい機能であるので、いろいろと問題点とかもまだまだ山積みなのかなというようなことなんですけれども。
ちなみに、SwiftUI自体を、今話している3人のメンバーで使ったことあるのは、僕とnotoさんだけかな?
そうですね。僕はデモみたいなところで、こんな風になるんだな、ぐらいのものしか認識できてないですけど。
チュートリアルとかもまだ触ってない感じ?
チュートリアルを読んだって感じですね。
なるほど。多分、多くのリスナー、まだ触ってないリスナーの人も多いと思うんで、そういう視点で…
そうですね。同じような感じです。
突っ込んでいってもらえるとありがたいですね。
お願いします。
じゃあ、notoさんも何回目の登場でしたっけ?
3回目ですよね。
3回目。
notoさんの紹介はもういらないですね。
そうですね。概要欄の方に書いておきますので、過去のオーディオを聞きたい方はそちらを見ていただけたらと思います。
そんなSwiftUIを使ったアプリをnotoさん、先日出されまして、どんなアプリでしたっけ?
アプリが、ユーティリティなんですけども、バッテリーの状態を報告してくれるアプリで、充電報告さんという名前です。
充電報告さん。
充電報告さん。
日本語では充電報告さんですね。
ちなみに英語版は何て言うんですか?
英語版はバッテレシーバーっていうらしいです。
なるほど。
らしい。
バッテリーとレシーバーをただくっつけただけという。
どこかで聞いたようなネーミング手法な気がしますけど。
伝統ある名前の付け方を投資をさせていただきました。
そのアプリはほぼフルスイフトUIなんですかね?
スイフトで書かれたのがほぼほとんどですね。
iOSにしかない機能の部分は使ってますけども、それも2カ所ぐらい。
03:02
多分あれですよね。QRコードを読む画面でカメラを呼び出すとか、
あの辺は多分元々のココアタッチじゃなくて、
AVファウンデーションだ、コアなんとかって言おうと思ったからわからなくなった。
AVファウンデーションのレイヤーか何かを普通のココアタッチのUIビューに乗っけて
それをラップしてスイフトUIから呼び出してるみたいなことをやってる。
そういう形になってます。
スイフトUIまだあまり触ってない方に簡単に説明すると、
スイフトUIっていろんなUI部品をかけるんですけど、
まだまだ足りないものが多くて、
足りないものだらけですよね。
できるのは今までの1割、2割下手をするぐらいだと思うんですけど、
足りないものは元々あるiOSのSDKのココアタッチっていうもので作って
それをラップして呼び出すみたいな。
混在させることができるということですよね。
混在させることを前提とした準備はしてあるという。
混在するのをMacだとMacの基本のSDKのものから持ってこれるし、
iOSだとiOSの基本のものからも持ってこれるみたいな。
ある程度その辺の既存のSDKの資産は持ってこれますよということは歌ってます。
今回ののとさんの充電報告においては、
極力その機能に頼らずに2カ所ぐらいそういうのを使ったけど、
あとはほぼスイフトUIだけでUIを組んだっていうイメージですよね。
あらゆる画面上のオブジェクトはだいたいスイフトUIのパーツになっていて、
充電報告サンテナのグラフが画面にあるんですけども、
その線の一本まで実はスイフトUIで書いてるという。
これそうなんですか?
絵で描画したわけじゃない。
こんなことを今すごい口で説明しづらいんですけど、
すごい細い、今iPhone11で画面見てるんですけど、
0.5ミリぐらいの幅の棒がいっぱい立ってる棒グラフがあるんですよね。
時間の系列を出すための、ちょっとした飾りっぽく見えるんだけど実はグラフですよみたいな。
そうですね。時間ごとのバッテリー残量を表しているグラフなんですけど、
この一個一個がスイフトUIのレフタングル四角かなんかで作ってるってことですよね。
はい。
スイフトUIってそういうことをやっても全然重たくなんないんですか?
その辺はかなり賢く動いてくれてますね。
さすがにここはなんか普通にスイフトUI以外で描画してると思ってました。
これはスイフトUIにしてしまったがために時間がかかったっていう、完全再現を目指したので、
06:03
もともとObjective-Cとかあとは普通のiOSのSDKベースで作ってたものをそのまま持ってきたので、
もともとのオリジナルのアプリがあって、それのスイフトUIで使った版っていうのが今回作った充電報告さんっていうアプリなんですよ。
そうですよね。もともとグロリアスバッテリーでしたっけ?
グロリアスバッテリーっていう名前が違って機能は同じみたいなアプリを出してまして、
それが5年前みたいな話だったんですけども、
それを完全にiOS13が出るタイミングで機能はそのまま記述してる言語をスイフトUIとかの組み合わせにしてるという形なので、
本当にモノマネというか、オリジナルがあってそれを完全に真似しましたみたいな形になってます。
でも逆にそうでもしないと、スイフトUIの制約の中でシンプルに作ろうとしてしまって、
地雷はなかなか不明なかったかもしれないですね。
ある程度、ゴールがまず完成品があるので、そこのゴールに行き着けばいいっていう、
まず目標が楽、ゴールがはっきりしてるのが楽だったので、
あとはそれをどう同じような形、同じような表示をスイフトUIで実現するかということだけに取り組んでる。
気分としては半分楽な感じですね。ゴールが見えないという感じではなかった。
まずスイフトUIを習得したいとか、先に結構扱ってみたいみたいな気持ちがあって、
今回そういうアプリを作られたって感じですかね。
ノトさん的にスイフトUIにこの夏から秋にかけて、すごい時間というか意識を投入してるように見えてたんですけど、
スイフトUIはノトさん的にはすごく魅力があるっていうところだと思うんですけど、
どういうところにこれから未来を感じるってことだと思うんですけど、スイフトUIへの思いみたいなのがあったら教えてほしいです。
スイフトUIについては、基本的には今Appleが何かしようとしている時の毎段階のものをスイフトUIという形で出してる気がするんですよ。
例えば新機能がついたらまずは真っ先にスイフトUIにつくんじゃないかなと思ってて、
iPhoneとかMacとかに関わらない新しいプロダクトベースの時にスイフトUIをまず使ってねみたいな言い口をしてくるのかなっていう気がしてる。
その時に開発者って、じゃあそういうのを取り組んでくれる会社って誰だろうって言った時に既存のアプリ開発者はもうがんじがらめで動けないとなったら、
もう他の開発者を、他の分野から取り組んでこなきゃいけないと。
その時にウェブ開発者がいっぱいこの世の中にいらっしゃるので、その人に親和性がある言語を持ってきたのかなって気がしてるんですよ。
なるほど、そういうことですね。
なので新しい世界に飛び込むタイミングというか、アップルが先にちょろちょろっと出してるかなっていうのに首突っ込んでる感じです。
09:01
それこそ噂の2022年に出ると言われるAR眼鏡とかそういう話ですよね。
画面空間上にふよふよとUIが浮いててもおかしくない世の中になりつつあるので、そうなった時にiPhoneとかMacのフレームワークとかってどうよみたいなことになってくると思うんですよ。
なるほどなるほど。
その時に考えるとやっぱりウェブベースでシンプルなシンプルとかウェブベースの方向でかけた方が開発者をいっぱい呼び込めるよねっていうのは三段がアップるんじゃないかなのに私も乗りたいって形ですね。
なるほど。僕もARかどうかは別にして新プラットフォーム狙いで出したっていうような気はしてるんですけど、僕ちょっとのとさんと見方がちょっと違って。
今までAppleってiOS以降に新しいプラットフォーム2つ出してるじゃないですか。
WatchOSとTBOSでどちらもiOS SDKとは違うものを使っていて、Appleって成功体験があったんですよね。
マックからiOSに行った時にマックのAppKitと違うUIキットiOS SDKっていうのを作って似てるけど違うものを作ってそこにみんな乗ってきてくれたっていう成功体験があったからまたWatchOSとTBOSで似てるけどちょっと違うっていうSDKを出した。
けどiOSの場合は最初に一気に爆発的に普及したのと、多分みんなモバイルっていうのをやりたかったっていうタイミングがあってだから新しいものをみんな学習してくれたけど、
意外とWatchとTBOSは儲かる匂いがしないとか、デバイスがそんなに普及しないとか、いろんな事情があってみんな意外と乗ってこなかったっていうところがあって、新しいものを習得、学んでまでは乗ってこなかったっていうところがあって、
その失敗の経験からSwiftUIである程度一緒に書けるフレームワークっていうのを作っておいて、iOSでSwiftUIに慣れてる人はそこまで考えなくてもその次のプラットフォーム行けるよみたいな、
新たに学習する部分は少ないですよみたいなことをやりたいのかなって僕は思ってます。
結構SwiftUIって、野戸さんは書き方の話されましたけど、僕はどちらかというと、例えば同じ書き方、同じ部品を書いた時に各プラットフォームで勝手に変換されるっていうところに注目してて、
そっちなのかなっていう、多分両方だと思うんですけど、そういう狙いかなっていう気はしてますね。いずれにしろAppleが次の一手を打つための前準備っていうのは、確かに野戸さんの言う通りな気がします。
UI周りに言いますと、Appleってその前身のNextっていう会社があって、そのNextOSの頃からリソース、UIのリソース、ネクストステップか、ネクストステップの時にインターフェースビルダーっていうかインターフェースを作って、それをソースコードと連結してみたいな動きがあるじゃないですか。
12:19
今はストーリーボードになってるやつですね。
ストーリーボードになってしまってますけども、それ実際にはもう20年くらい前のやつだったりするので、20年は効かないんじゃないかな。
そうですね、多分20年効かないですね。80何年ですよね、最初のNextって。
マイクロソフトもVisual Basicとかいうものでほぼ同じものを作ってたりするので、フォームとか、あとはボーランドとか、他の90年代とか2000年代頑張ってたゲーミングのコードの会社さんですけども、それもやっぱりフォームベースになってるんで。
そこからのやっとかっていうところもありますよね。やっとソースコードベースというか新しい考え方の方にシフトしたっていうところがあるので、一番最古参のそういうUI作ってるところがSwift UIでぶち上げたっていうのは結構大きいかもしれないです。
本当にUI周りの考え方が変わってきてるというか、リソース、U&画面の部品配置してそれをソースコードと連結させるみたいな仕組み、アウトレットとかを使って踏み込むみたいな考え方はそろそろ変わっていくんじゃないかなって気はします。
今まではグラフィックソフトみたいなノリで物を配置していったのをテキストで書いてる記述してるところに紐付けてみたいなところが両方ガッチャンコされたっていう感じですよね。
そうですね。定義ベースというかウェブでページを作るときにタグって書くんですけども、そのノリで書けるところもあるし、今までのプログラムとUIを作る方法も残して、両方を組み合わせて使えますよということをアピールしてるんだと思います。
というところで、そろそろ地雷の話を聞いていこうかなと思うんですけど。
今夢の話をしてたんですね。
そう、今は夢の話、いい話。
いい話を。
でもこんな夢のようなもののわけがないじゃないですか、現状は。
現実、1年目ですしね。1年目で6月に出して、今何ヶ月経ちましたっけ?6月に発表して半年とかになるのか、そろそろ半年みたいな感じなんだけど、まあひどいという感じですね。
そうですよね。僕も実は今出してるファストエヴァ3の設定画面はSwift UIでできてるんですけど、なんて言うんでしょう、ようよそネイティブの開発環境で作ったとは思えない感じの挙動が少し残ってるというか、
マルチプラットフォーム系の開発環境なんじゃないかみたいな、ちょっと気持ち悪さは若干ありますよね。
15:00
たぶんのとさんはそれ以上にもアプリ全体をSwift UIでやってるから、かなりの地雷があったんじゃないかというとこなんですけど。
アプリとしては、10年報告3という今回新しく出したアプリは、メイン画面と設定画面みたいなほぼシンプルなアプリとしては規模が小さくてこじんまりとしててっていうアプリなんですけど、それですらあらゆるものを踏み抜くっていうのがちょっと経験させていただきました。
具体的な例を挙げていってよろしいでしょうかね。
はい、お願いします。どうぞどうぞ。
まず、コードを書くときに、Swift UI自体はUIを書いてるんだけど実はソースコードみたいなちょっと不思議なルールになってて、
UIを記述するための言語に見えて実はSwift言語ですよみたいなちょっと不思議な仕組みになってたりするんですよ。
そうですね。
なので、何が起きるかっていうと、普通に書いてるだけでコンパイルエラーっていうSwiftの構文のエラーとか、これおかしいよって指摘が入るんですけども、その指摘が普通にSwiftでプログラミングすると構わないようなエラーが出ると思いきや、かなり的が外れてる。
ちょっと文法を間違えると、何か数行前の本当に問題が起きてるところよりも、かなり前のところでさらに不思議なエラーメッセージが出るっていう。
ありますね。
ちょっと構文間違えただけだよねってなのに、いきなりその前の前の一番最初の部分にエラーが出てるよみたいな、本当に人を困惑させるのが好きなのかなみたいな、そういうエラーの出し方をしてくれるってとこがありますね。
なんかSwift UIってそのSwiftだけど、Swift 5.1から入った新しい構文をフル活用して、なんかSwiftっぽくない言語みたいな感じで書くじゃないですか。
で、あれのそのコンパイラーの解釈っていうのがまだうまく完璧には実装されてなくて、おかしくなってるのかなっていう気はしますね。
実質、そのUIを書いてるように見えて、実はSwiftを書いてる、プログラミングコードを書いてるって意識で書かないと、何ていうか、常にエラーが出てなんだなんだみたいな、エラーばっかり出て何も終わらないよみたいな、そういうイライラ感が募ってしまうってところがありますね。
そうですよね。
あとは、ある程度Swiftの構文のルール等を理解していけばいいんですけど、それを今回だと6月に始まって、9月、3ヶ月ぐらい、ひいひい言いながら慣れるっていうか、構文に慣れるっていう作業を繰り返してました。
18:05
なぜ構文を慣れないといけないかっていうと、ミスをするとエラー探しがすごく時間かかるから、なるべくミスがないようにコーディングしなきゃいけないっていう神経を使わなきゃいけない。
しかも結構最初の方に構文が結構変更あったりとかして、ググって調べたやつが古くて全くコピペしても動かないとかっていうのはありがちですよね。
コピペは不可能になってますね。
不可能ですよね。だから、ちゃんと読んでちゃんと書くって当たり前のことを当たり前にやらなければいけないと。横着はできないみたいな。
楽しい緊張感でやらせていただきましたみたいな感じになって。ですけども、やってる当時はイライラしかしないという。
いかにコピペ文化、コピペで作業してるのかってのはバレちゃうんですけども。
SWIFT UI 書くまではみたいな感じなんですけど。
でもプレビューもあるし、割とすぐにおかしいっていうのはわかるっていうのはある意味利点かもしれないですね。
そのプレビューすら走らないので。
そうですね。プレビューが走らないっていうのでわかるじゃないですか。ビルドしなくても。
どっちにしろか。どっちにしろ選べますもんね。
プレビューっていう機能がSWIFT UI 作る時に出てて、これすげーって言ってるんですけども、こいつも結構問題があって。
もちろんUIを書いてる時に変な構文書いて、エラーになったらもう二度と通常の状態、エラーがない状態に戻るまでプレビューが止まっちゃうんですよ。
そのプレビューっていうのはコードでUIを書いたら、それを実際のアプリ上ではこういう見た目になりますよっていうのがグラフィカルに右側に出てくるやつですよね。
そうですね。パーツパーツを作れるっていうのがSWIFT。
パーツ単位でじっくり考えてUIを作ってそれを組み合わせることができるよっていうのがSWIFT UIの利点の一つなんですけども、
その頼りにすべきプレビューっていうのが結構エラーが不親切なんでよくわからないので、結構止まりやすい。
あとはベータのタイミングだと結構バグがあって、プレビューからソースコードを追加するみたいな便利機能もあったんですけども、それがほぼ使えてなかったっていう。
今使えるんですか?
今は生きてる。レイアウトというかパディングとかああいう属性を貼り付けるっていう機能をすら呼び出せなかったみたいな。
プレビューしてるものからコマンドクリックとかで、コマンドキープラスクリックなんかでプロパティ出せてそこでパディングとかを指定できたんですけど、
できるって言ってるんだけど、私が開発してるタイミングだとほぼ動いてなかったですね。ベータ版のタイミングだと。
そうだったんですね。
21:00
あとプレビューって初回ビルドが意外とかかりますよね。
初回ビルドかかりますし、かつ30秒以内に終わらないとエラーを出します。
そうだったんですね。
でもその30秒以内にコンパイルできませんでしたっていうメッセージがあって、しつこくレジュームすると動いてくれます。
そうなんだ。
あくまでも30秒以内にできなかったよっていうメッセージなんだけど、赤いエラーが出るので、これ失敗したんだとか、そういう混乱を生みやすい感じですね。
そうですね。プレビューでエラーが出たら完全にコードが間違ってるって思いますもんね、普通は。
違うのもある。
違うのもある。なるほど。
エラーの違うのの別バリエーションで、これはかなり困ったやつなんですけど、アプリ側で何かのエラーを握り潰してましたと。
そのエラーが起きてる状態でプレビューしてもプレビューが止まります。
どういうことですか?
アプリを普通に実行したら、プレビューばっかりやってて、アプリを実行しない?シミュレーターとか使って全体を動かさないっていう時間がちょっとあったりすると、そのタイミングでアプリが動かないような、なんかの設定ファイル読み込み失敗してクラッシュしてますよとか致命的エラーが出てる場合。
アプリ本体で致命的なエラーが出てるにも関わらず、それを無視してSwiftUIのプレビューで何かしようとしても動かないです。エラーが出ます。
そうなんですね。
そのエラーはSwiftUIでのエラーなのか、アプリのまた別のコードのエラーなのかというのは判別するんですか?
それはエラーが出た時の詳細をちゃんと読まないとわからない。結構不親切。
不親切というか、普通にSwiftでプログラミングしてる時のエラーがドバッと出ます。
なるほど。
でも、なんかよく、普通の人が見たらよくわからんわなみたいな感じになってます。
じゃあパッと見どっちでエラーが出てるのかわからんと。
何もしてないのに壊れたって言うと思います、普通の人は。
そういうレベルなので、しかももともとGoogleとかにも危険がないので、そこは調べなきゃダメというか、自分で解決しなきゃいけないという、我荒野を行く状態になってまして、
本当にGoogleで調べても、検索で調べても、Google検索で調べてもわからんっていう、そんなエラーないよみたいな。
人柱的な。
新しいものはやっぱり、エラーわかんなくてググっても、スタックオーバーフローとかで、このエラー起こるけどようわからんみたいな、書いてあって、
まだ問題が。
回答がないみたいな。
まだ問題がフローしてないっていう。
フローしてない。
スタックオーバーフローなのにフローしてないわみたいな、そういうことに出会いましたね。
その辺の事例もあるんですけども。
24:02
さらに他の事例は。
さらに、今まで話したことってUIパーツとか、まだ慣れ切ってないから悪戦苦闘してますとか、細かいノウハウというかがないっていうだけの話じゃないですか。
ところがですね、そこからUIパーツが全部揃ってそれを組み合わせるぞってなってくる時にこそ地獄が始まるというのがSwiftUIなんです。
どういうと。
具体的に言いますと、部品を組み合わせていくとコンパイル時間がどんどん長くなってきます。
普通に単純に何も考えないで組み合わせていくと。
それはクラスを分けないでみたいな。
部品が大きすぎて一個一個にかかるコンパイルが長くなってくる。
特にSwiftUIって階層構造になって、ルートというか根っこの部分に部品が集まりがちじゃないですか。
そうなってくると、ルートの根っこの画面をビルドするのがどんどん遅くなってくるっていう。
要は根っこの部分にかかってる部品をもうちょっとバラバラにしていけばいいんですけど、
でもそれって例えばどっかの日にリリース日に合わせなきゃいけないとか、そういうプレッシャーがあった時に非常に何もできないと動きが取れなくなっちゃうっていう感じですね。
なるほど。
そういうちゃんと部品をどんどん分けていくっていうことを繰り返さないと、どんどんビルドが遅くなっていくっていう問題に遭遇してます。
だから解決策としては最初から重くなりそうだなと思った段階でちょっとずつ部品を分けていくみたいな。
部品を分けていく。最低でも関数に分けてあげるとちょっと軽減するんですよ。
ボディの中に定義をそのまま入れてしまうと本当に遅くなってくるので、遅くなる原因は多分型を全部見ちゃってるのが問題。
スイフト独自の問題があって、ちゃんと型を、値とかをちゃんと検証してくれるんだけども、それをいつもやりすぎてるっていう問題がある。
型推論に時間がかかりすぎてる。
そうですね。なので厳密な型を、何かの画面パーツを配置したらその型をちゃんと見ちゃうので、それをさせないような工夫が必要。
あるいは型推論をさせないテクニックっていうのを知らないと、要はスイフトの知識がないと立ち向きできないみたいな。
型を手動で指定してあげるとかですよね。
型を忘れさせる感じで、型消去っていって、型をここは記憶しなくていいよっていうことをコンパイラーに示さなきゃいけないっていうテクニックが必要になってきます。
そのためにスイフト5.1でサムなんちゃらっていうのが出てきたんです。サムかな?
27:01
サムですね。
サムですか。サムビューっていうのが指定してあげると、スイフトはこれ型考えなくていいんだっていうふうに気が楽になるらしいです。
だからスイフトのコンパイラーをあやしてる状態なんですよ。
なんでコンパイラーの様子を見なきゃいかんのじゃみたいな不満が出てくるのかもしれないですけど、そういう知識が必要です。
型消去が型推論するから重くなるんだっていうふうな考え方がちゃんと入ってないと、スイフトUIで全部の画面構築をずっと詰まりますね。
なるほど。大きくなるとそうなってくるわけですね。
どうしても雪だるま式に増えていくので、画面のパーツを作って安心してる場合ではなかった。
数ヶ月前の私はそうだったんだけど。
画面パーツ作れてこれで組み合わせればできればみたいな、今までのiOSの画面パーツの考え方でやってたら途端にひひ言うことになったっていう。
パーツを分ける具体的な方法なんですけど、このコードの中でバー、ボディー、コロン、サム、ビュー、中括弧かな。そういうのをどんどん増やしていくって感じなんですかね。
基本的にはコード、スイフトUIのコードをどんどん細分化していくのがまずは最初の手順ですね。
基準としてはビューの中に入ってる、ボディの中にいっぱい型が入ってくるようになったらちょっと危険シーンがある。
例えばグループとかスタックとかってビューをさらにグルーピングするような機能がいくつかあるんですけども、
その中にいろんなビューが入り込み始めたら別のビューで一回切り分けた方がいいよっていうことだと思います。
ロツさんの経験上何個ぐらいとかってそういうの具体的な数字ってあったりします?
具体的な数字はちょっと…
これからアプリ作ろうって思ってる人にこれ分けておいた方がいいなとかあれば。
先ほど言った30秒オーバーコンパイルが始まったら危険信号ですね。
そうですね、マシンパワーによりますよね。
マシンパワー…そうですね。
CPUとかそうですよね。
結構ハイエンドマシンで30秒って感じですね。
そっか、のどさん今って何使ってるんですか?
私は2018年度のMacBook Proのi9とかだったかな。
i9のモデル。
当時の最強クラスみたいなやつですね。
当時のMacBook Proの…
CPU増し増しモデルですね。
まあでもそんなもん全然遅くないですよね、今もね。
全然早いですね。
うちのMacよりは早い。
2.7GHz。
この型推論とかコンパイラーの方でまだまだ最適化っていうのがされるんでしょうかね、
Appleの中の人たちが。
ここは最適化してねっていうな、
なんかワーニングは出すような気もしますが、
出す可能性はあるかもしれない。
30:00
ここが複雑になってるからどうにかしてねっていう。
解釈できないよっていう。
ここ複雑化してないみたいな提案型になると思います。
もしかしたら言われるとしても。
型推論自体は残ってくるので。
型推論自体は、
多分まだやっぱりちゃんと動いてない感があるので、
よくはなるんじゃないですかね、きっとコンパイラーは。
まだまだその改善の良しというか、
1年目なんで、ここからAppleはスイフトの方も改良するし、
スイフトUIの方も改良していくと思います。
それこそ来年のWWDCで、
方向性が今年で出した問題を多分改善してくれるのではないかなと。
今ここで言ってたような話が、
直って拍手喝采っていうのが見えますね。
コンパイラー時間が何パーセントファースター。
グラフがシュッとありそう。
1年目から触れること自体は悪くないので。
しっかり動いてアプリもリリースできてますしね。
アプリの規模がUTATレベルなので他と比較はできないんですけど、
基本的にはオリジナルよりもうまく動いてるはず。
開発工数っていうのはやっぱ減ります?
デバッグとか含めちゃうと今ちょっと時間かかってるみたいな感じなんですけど、
例えばテーブルビューとかでしたら何個テーブルがあって、
ここのセクションとかに番号を振っていって、
そこの台名は何個とか結構ソースコードの中でバラバラに分かれちゃうと思うんですけど、
スイフトUIだったら直感的に書けて楽なのかななんて思ったんですけど、
どうでしょう?
スイフトUIによって効率化されたというよりかは、
スイフトUIによってオブジェクトとかの管理をする概念そのものを変えざるを得ないんですよ。
それによってスイフトUIを変えるとその裏方で動いてる仕組み、
データの管理とかの持ち方もそれに特化した形になるので、
スイフトUIを使うごとに相乗効果というか、
現状の商業アプリとかアプリ開発する会社とかは、
もうやってるこういうデータの持ち方の新しい考え方、
Fluxとかその辺のあれにスイフトUIがマッチしてるので、
なんと言えばいいかな、
アプリの裏側で動いてるデータの持ち方とかの変更をそのまんまスイフトUIは反映しやすいという形ですね。
なるほど。今までがちょっと煩雑だったというようだ。
今までの裏側で動いてるアプリのデータの動きとかは、
結構オシャレになってるんだけども、
それが現状のiOSのUIパーツを作るときはすごく無理やりなんとかしてるって感じだったものが、
スイフトUIだとある程度素直にできる感じです。
僕が使った感じだと、
33:02
ちょっとしたテーブルビューとかだったらスイフトUIで作りたいなって思う感じですね。
逆に結構凝ったレイアウトのコレクションビューとかだと、
裏側の話は置いておいて、
多分スイフトUIで作りたいって人もいるだろうけど、
自分だったらUIキット使いたいなっていう感じ。
決まりきったものだと、
変な挙動をしても許せるわけではないけど、
変な許容の幅が小さいというか、いいかなって思ってます。
あとやっぱりラックですよね。
さっき水井さん言ってたみたいに、
セルのこの行に何書くっていうのと、
実際にタップされた後の場所が、
データソースとデリゲートで普通にUIテーブルビューでやると、
分かれちゃうのが一箇所になるから、
ミスが減るとは思いますね。
たまにあるじゃないですか、一行ずれてるアプリ。
確かに。
ここタップできちゃうの?みたいな。
ありますからね。
そういう意味では使いたいなって感じはしますね。
そうですね。
スイフトUIの場合はデータモデルとか言うんですけども、
流し込むデータをそのまま反映することができるので、
そういう作りであるとすごく使いやすいというか、
例えばリストとかだと、
すごいシンプルなリストだと、
とっても単純に書けるっていうのはあります。
なので、扱っているデータそのものを
反映しやすいっていうところはあります。
見たまんま、リストをそのまんま出しますよとか、
そういうことに関しては、
スイフトUIはすごくありがたいというか、
という形はなってるかなって気はします。
例えば、何かの値を変更したらすぐ反映するみたいなことも、
ほぼUI側の技術というか、
イフ分で一生懸命条件分岐みたいなことはしなくて済むみたいな形ですね。
そうです。
あとは、例えば何か3種類ぐらいを選択するような画面で、
テーブルビューの1段目でタップしたら、
次の画面に行って、何か3個から選ぶみたいな、
そういうのってすごく簡単に書けて、
今までだったら、2つビューコントローラー作って書かなきゃいけなかったのが、
1個のスイフトUIのビューの中で、
ピッカーの種類をちょっと変えてあげるだけでできるのがあったりとかして、
そういう意味では、やっぱり半雑さがない感じはありますね。
覚えることは、裏のデータの作り方でアイデンティファイアブルみたいな、
新しいプロトコルがあって、
そういうのを覚えたりとかはしなきゃいけないですけど、
楽っていうのとも違うな、なんかスッキリしますよね。
確かにコードを読みながらのプレビューが頭の中でできそうっていうようなことはありますね。
2つのビューコントローラーに分かれていたりすると、
そのコードも行き来してみなきゃいけなかったりするし、
そういう意味ではすごい分かりやすいのかなって思いました。
UIに関しては集中できますね。
リソースと分かれてるとかいう話もないし。
36:02
最近、僕モハベでスイフトUIやってて、
諸事情があって、カタリーナにはしたくないので、
プレビュー全く使ってないんですけど、
毎回ビルドするでも全然いいし、
プレビュー固まるっていう、さっきの野戸さん言ってた問題みたいなのも遭遇しないから、
意外とプレビューなしっていうのもありかなっていう感じがしてます。
最終的にはプレビューは使い物にならないというか、
シミュレーターが実機で動かなきゃいけないので。
そうなんですよね。最終的にはどうせそうだから。
プレビューばっかり使ってると、
最後の部品の組み合わせのタイミングでヒイヒイってしまうっていうか、
もっと最初に潰せたはずな問題が残ってるっていうことがあります。
あとはそのUIキットと、自分の場合結構混ぜ混ぜしてやってるから、
書き方によってはプレビューが動かないとかあるんですよね。
絶対にプレビューが動かないみたいなのもあったりとかするから、
意外とプレビューなしという選択肢もあるかもしれない。
本当に素直に動いてくれるというか、動いてくれるのでいいかなと思います。
さて、そろそろ時間の方が迫ってきてるんですけど、
野田さん何か言い残したことはありますか?
まだまだ時代のネタはありますね。
最終的に組み込むときの追い込みの時に起きるのが一番きついっていうトラブルなんですけど、
それの一番大きいやつがありますんで。
とりあえずまだまだあるぞというところですね。
まだまだAppleに居たいことがあるんだっていうところがありつつ、
でも触ってて久しぶりに楽しい仕組みではありますね、SwiftUIは。
来年のWWDCでSwiftUIの改善点発表されたときに、
また野田さんの喜びの声を聞かせてもらえるといいかもしれないですね。
怒りがまた増しましたとかそういう可能性もちょっと否定できない感じですけど。
喜びを期待しておきましょう。
じゃあこんなところですかね。
そうですね。では皆さんご清聴ありがとうございました。
ありがとうございました。
ありがとうございます。
