00:00
さあ今日もやってきました、AirSap。 あれ、そんな入りでしたっけ?いっつも。
どうでしたっけね? なんか最近やってないか忘れちゃった。
今日はね、ゲスト会。久々かな?ゲスト会なんですけど、 何度か出てもらってるnotoさんがですね、ちょっと話したいことがあるということで、話題を提案してくれたので来ていただきました。
そして、notoさんだけじゃなく、もう一人ゲスト来ていただいています。 ということで、まずnotoさんから軽く自己紹介お願いします。
札幌でアプリ、iPhoneのアプリ開発してます、notoです。 主に最近はSwiftUIにハマっております。
ハマってるっていうのはどっちの意味でハマってるんですか? ドツボンにハマってるのをハマってるです。
なるほど。そしてもう一方、菅原さん。 よろしくお願いします。報道会社ピコスの菅原と申します。
今日はnotoさんの政治役というか、ツッコミ役というか、そういう役目でお呼ばれしました。
よろしくお願いします。
今日いただいた話題というのがですね、今年のWWDCがもうそろそろ近づいてきてて、6月7日から6月11日っていうアナウンスがあったんですけど、
そこで、当然ね、SwiftUIっていうものの進化がね、することは当然予想されるので、
その進化を予想するっていうような内容で、 notoさんが結構そのSwiftUI、今ドツボンにハマっているということで、
結構SwiftUIの進化っていう話をね、デブサップの勉強会とかでもよくされているので、そういう話をね、してもらうという形になってます。
ということで、まずSwiftUIって何ですか?
SwiftUIとはですね、まさしくあのSwiftっていうプログラミング言語でUIも書けるよっていう、
Appleが触れ込んでいる、まあ、UIを作るための方法ですね。
2019年なんで、2年前にAppleが発表して、その時はみんなわっと驚かされたというか、突然出てきたので驚かされたという
仕様でございます。特徴としては、見た目はHTML5みたいな、そのUIをコードで記述して、それが見た目に反映されるような仕組みになっています。
あとはですね、マルチプラットフォームで動きますよと、 複数の、Appleが言うマルチプラットフォームっていうのは、iOSだったりiPadOSだったりMacだったり、
TBOSだったりっていう、Apple製品で同じような書き方で書けますよというのが、触れ込んで登場しております。
03:00
そのコードでUIを書けるっていうのが、今までのiOSのやり方とは大きく転換したっていうところがあるんですよね。
はい、転換といってもですね、結構歴史は古くて、
Nextstepっていう仕組みを作った、Jobsも絡んだ時に作られたUIの作り方の基本がありまして、何かと言いますと、
UIを操作してボタンをポチポチと画面上に配置して、それとソースコードをつなげるみたいな作り方があるんですけど、
NextstepっていうOSですよね、昔あった。ちょっと補足すると、グラフィカルにボタンとかを置いておけるっていう意味ですよね、ポチポチとっていうのは。
そうですね、本当に見た目が見えている状態で、ここにボタンを置こうとか、ここに入力欄を入れましょうかというのを試しながら、まずUIを作りますと。
そこにUIに対応するソースコードというかプログラミングの機能をいろいろとつなげ合わせると、実行するとすぐ動き出すという仕組みですね。
もともとあれですもんね、今は開発環境のXコードの中で、そういうグラフィカルにUIを作ってコードを書いてっていうのは両方できるけど、
昔はインターフェースビルダーっていう別なソフトでそのUIをグラフィカルに作って、別なソフト同士でつなぎ合わせるってことをやってましたもんね。
そうですね、本的には別のツールって形で独立していたものが、ある段階でXコードの中に全部取り込まれてしまってるって状態ですね。
それに対してSwiftUIは?
SwiftUIはXコード上のテキストエディター、プログラミングとか書く場所なんですけど、テキストを入力する場所なんですけど、そこでUIを書いていくと、
UIが反映されるし、プレビューみたいなものがありまして、そこにすぐに即時反映されると。
かつ、プレビューしている側に見た目ができているのに、その中にボタンを配置するとさらにボタンが追加されるみたいな、相互に見た目と記述した内容がほぼ同期して作業、あとUIを構築できるみたいな仕組みですね。
だからあれですよね、今まではUIをグラフィカルに一つのファイル作ってて、コードを別なファイルで作ってて、それを紐づけるっていう作業をしてたのが、
1個のファイルをコードで見せたり、グラフィカルに見せたりっていう見せ方を2つ作って、それが同じものを参照しているから同期しているっていう感じですよね。
操作している間は、そうですね、プログラミングをしている間はそういう感覚で、UIを作っていながらコードも書けるみたいな感覚で作れると思います。
06:06
今までストーリーボードとかジブとかがXMLファイルに書いてた、そのXMLファイルからプログラムのコードを生成していた部分が、代わりにSwiftを書き込むことになったから、
普通のプログラムのコードがUIに反映されるし、UIのグラフィカルの部分がSwiftコードに反映される。
そこが一番大きくて、あとはコンフリクトの問題があったので、XMLだと複数に開発した時のコンフリクトの解消がすごい難しいっていう部分が、
SwiftUIがSwiftコードを直接書いてくれるおかげで、Swift上のコードの差分が出るので、コンフリクトが発生したとしても解消が簡単。
ここら辺がすごいインパクトはあるんですが、いろいろあるという話を、たぶんのとさんはするんですよね。これから。
理想的なコードの書き方ではあるんですけど、結構それをするためにAppleが、SwiftUIを使うための言語であるSwiftにもちょっかい、いろいろ介入してますし、
その言語で拡張しきれてない部分は、もう無理やり使用をねじ込んでみたりとかしてまして、結構危ない端が渡り続けてるんですよ。
何が起きるかっていうと、途端に何も意味不明なエラーを吐いて、見た目の部分も消えちゃうし、エラーを吐き続けるみたいな状況になるとか、
そういうトラブルがまだまだ転がってるっていうか、少し外れると途端に脱線してしまうような危うさがありますね。
なぜそうなってるかっていうと、そのUIを記述するための記述そのものがプログラミング言語の一部だったりします。
なのでプログラミング言語って、ちょっと書き方間違えるとエラー出るじゃないですか。
それがそのままUIにも反映されちゃうので、コードで書いてて間違ったコードを書くと、途端に何も動かなくなりますよってことが発生します。
あとはSWIFTは結構型を厳密に考えてまして、型が違うと途端にエラーチェックが走ったりとか、エラーですよとか警告が出たりするんですけど、
SWIFT UIも、データの形はどうですか、これは正しいデータをもらってるんですかってことを厳密にやりすぎるがあまり、
UIが複雑になればなるほどビルド速度が遅くなってしまうことが発生すると。
それを解決するためには、都度書いたコードが複雑じゃないかを自分で考えて直さなきゃいけないみたいな手順が入ってきたりします。
09:09
結構複雑すぎるって怒られたりしますよね。
そうなんですね。プログラミング言語でお前は複雑だって言われるの、それこそ微妙な気分じゃないですか。
お前の書いてるのはわからんっていうことですから、コンピューターがわからないとは何事だ感がちょっと。
現実的な時間で処理できないよっていうような感じではあるんですけど、わかんないじゃなくて複雑だっていうエラーは確か。
あれですよね、型推論が所定の時間にできないからっていうのが発生しやすいってことですかね。
なんか普通のSwiftUI以外でも多分Swiftって型推論重くて、
途中で何点もなくて普通にコンパイルエラー起きたりしますけど、結構発生するんですか。
ちなみに僕はSwiftUIは遊びでしか使ってなくて、そんなガチなのを書いてないんですけど。
起きやすいですね。基本的には型を大量に持っているので、
例えばUIをリストって言って置くじゃないですか。
一覧みたいな感じで置けるのも実は10個とか。
10個ごとに型があるんですよ。
あれ無理やりですよね。引数10個にしてて。あれはしょうがないのかなとは思いつつも。
その10個もし無理やり詰め込んだとしてもコンパイルがそれ10個ずつを精査するので、
その詰め込んだUIがさらに複雑だったらさらに精査が始まるということがあり、
コンパイルがどんどん遅くなる。最後にはある一定時間まで完了しないと怒られてしまうという現象が発生する。
コンパイラーとか型とかをちゃんと怪しつつコードを書かなきゃいけなくなるというのが厳しいところです。
それって型明示したりするんですか?
型消去をするって形ですね。
型を考え、コンパイラーが考えなくていいよってことを明示的に示さなきゃいけないってことです。
いわゆる型消去のことですか?
はい。
それめんどくさくないですか?
なので書いた都度見直しが必要になってくる時もあります。
特にアプリ開発を追い込んだときにそれが始まるともう作業中断しちゃうので、段階段階でちゃんと見直しが必要になってきます。
なるほど。なんかちょっといい話聞きたいんですけど、今いい話が出てないから。
確かにメリット的な話がね。
メリット的な話は、例えばシンプルな図形とかはもうすごい充実してるし、
かつそれを表現する方法の考え方が基本的にはHTML5のCSS、スタイルシートの考え方なんで、
12:08
ウェブの基本的な知識があれば、そういうシンプルなUIとかを自力で作ることができちゃったりします。
なるほど。じゃあそっち側意識して設計してるんですね。
そうです。もう完全にウェブ開発者の知識があれば書けますよみたいなことを推してるというか、
その分UIキットに慣れ親しんでる人にとってはあんまりピンとこないかもしれないけど、
ウェブ開発者多いので、そっちの方に寄せてるのかなっていう気はします。
じゃあ現状今のところスイフトUIで全部書くっていうのはなかなか難しい。
アプリによるとは思うんですけど、ストーリーボードとスイフトUIを共存させるっていうのがいい感じなんですかね。
そうですね。スイフトUIはネイティブの開発キット、iOSだとUIキットですし、
macOSだとAppKitがあるので、それと組み合わせても動くように設計はされてるので、
その辺はネイティブの機能が欲しいときは我慢せずに使えるっていうのはすごい利点ですね。
結局ザッパーなんですかね。いじるやつもありますよね。
どうしようもないときにUIキット側を探索してみたいなツールありますけど、
ほとんどの部品はもうUIキットのラッパーなんですか?
一部高速化されているものがあって、テキストフィールドとかボタンとかはもう完全に別物になってます。
これがですね、確か2019年の最初のスイフトUIが出たとき、iOS13とセットに出たやつですね。
あのときは確かリストはUIキットのUIテーブルビューのラッパーだったんですけど、
これが2020年バージョンになるとそうじゃなくなって、独自描画になったのかな。
2019年の頃はスイフトUIが生成するテーブルビューをいじることによって、
例えばセパレーター消したりとか、そういうハックがあったんですけど、
2020年版からはそういうことができなくなって、アビ共感みたいな話は聞いたことがありますね。
アビ共感って、みんなそれ使ってたって。
そうそう、それを使っちゃってたみたいな話がね。
使いたいですよね、確かに。
結構その2019年と2020年で変わったんですよね。
なるほど、じゃあ次の年を聞きたくなりますね。
とりあえず一旦2019年と2020年で何が起こったかのとさんに軽くおさらいしてもらって。
15:00
2019年、最初のリリースは本当に最低限の機能を追加しましたよとか形で、
しかもWWDCの2019が発表された後から、
仕様変更の嵐が始まるという細かい調整が始まったので、
1ヶ月、数週間で動かないコードが出来上がるという。
書き方がんがん変わりましたよね、あの頃はね。
細かい大枠は変わってないんですけど、イベントとかの名称とかが変わってたりとか、
変わる考え方もUIキットに寄せてみたりとか、
あとはUIキットにある型の定義をそのまま取り込んでみたりとか、
要はより会社の親しみやすいような取り組みはしてたって形です。
で、たぶん出来上がるのがiOS13のリリースの2週間ぐらいまで変更があった気がしますね。
うん、なんかそんな感じだった気がしますね。
てか出てからも変更があった気が。
出てから2、3個変更というか仕様が変わったことがあった気がします。
挙動変わりましたとかそういうのがあった気がしますね。
それはバグなのか仕様変更なのかがちょっと曖昧なまま、
特にみんな使ってなかったので影響がなかったんじゃなかったんですかね。
そこまでディープに使っている人が多分いなかったっていう形なので、
メジャーなアプリで不具合が起きない限りは、
あまり影響がなかったのではないかなと思います。
それが2020年には?
2020年はセカンドメジャーリリースとApple自身が名誉ってですね、
かなりUIの充実しました。
かつSwiftUIだけでアプリ作れるよっていう触れこびで、
iOS、iPadOS、macOSでSwiftUIだけでアプリが作れるという宣伝がされました。
あとマルチプラットフォームアプリも作れるようになったんですよね。
そうですね。本当に言うがごとく、iOS、iPadOS、macOSで動くよというか、
個別にビルドするって形ですね。
1個のコードでっていう。
1個のコードで2つのアプリを出力できますよって形ですね。
コード的には流用しているところもあるし、
macOSとiOSで切り分けるってこともコード上で可能になったって形です。
なので多分これは今のmacOS Big Surに合わせて無理やりやった感がちょっとあるんですけど、
一応名目上はマルチプラットフォームで動くってことになってます。
実際やってみると、あんまり現時点ではいいものじゃなかったなとは自分は思ってるんですけど。
どういう点でですかね。
触ってみて別に特に何かアプリを作る可能性まで言ってないんですけど、
18:01
結構分岐しなきゃいけないんですよ。
macOSの場合はこうとか、結構分岐が必要なのと、
あと結構こっちでうまく表示、例えばiOSの方でうまく表示できるようにいじったら
macOSの方で崩れるとか、逆とか。
マルチプラットフォームとは。
こちらを立てればあちらが立たずみたいなことが結構あって、
別々にやった方がいいんじゃないかなみたいな感じですね。
私もmacOSのアプリを出そうかなと思ってたんですけど、
そもそもmacOSに関する知識がないっていうことに気づきまして、
そこから始めなきゃいけなくなったので、結局マルチプラットフォームとはいえ、
各ネイティブの事情っていうもの、OSごとの事情をちゃんと把握してないと前に進めないってことでトンザしてるという状態です。
結局僕一回、自分専用のリリースするようじゃなくて、
ちょっとしたMacアプリを一個作ったんですけど、
それはSwiftUIのmacOSアプリとして作ったんじゃなくて、
SwiftUIでiPadアプリ作って、それをカタリストっていう仕組みがあって、
iPadアプリをMacアプリに変換するっていう、これは2018年に出た仕組みなんですけど、
それを使いましたね。
要はiPadアプリをSwiftUIで作って、それをカタリストで変換するってやった方が楽だった。
iOSアプリ開発者としては。
アップキットの仕様とかを知らなくても、そのままiPadの感じでMacで起動できるからみたいな。
そうですね。
まだ現実が追いついてないですね。全然難しいですね。
2020年のトピックとしては、WidgetKitっていうのができてまして、これは何かっていうと、
SwiftUIでiOSにかつて、今でもありますけど、
Today ExtensionっていうWidgetをSwiftUIで作れるよみたいな機能が追加されてて、
Today Extensionを新しいWidgetで置き換えたんですよね?
置き換えた。Replaceですね。
もうそれはSwiftUI必須っていう形で出してきてます。
Today ExtensionがUIキットも使えるし、SwiftUIも使いました。
ですが、iOS14から採用される新しいホーム画面とかに出すのがWidgetなんですけど、
それはSwiftUIで作ってね、みたいな。もう強制です、みたいな振り込みになってます。
UIとかいろんな補助機能が充実しているのは2020年なんですけど、
そこまで大規模な回収が行われてないっていうか、
私としては結構2020年は不満でした。
そこまで抜本的な回収とかではなくて、本当に2019年の延長上に2020年があるだけみたいな印象です。
21:07
じゃあ2021年、どう予想しますか?
2021年なんですけど、最近ちょっと懸念がありまして、
AppleってSwiftUIを単に既存の機能のリプレイスにしか使う気ないんじゃないか問題がちょっと浮上しております。
何が言いたいかって言うと、
多分今年WWC2021はARとかVRとか出すんじゃないかなっていうふうな、
ちまたんに言われてるんですけど、
そこにSwiftUIはあんまり絡んでこないんじゃないかな説があります。
あんまりそういう最新のところはいつも通りのSDKを作って、なんちゃらキットを作ってやりますよっていうだけで、
SwiftUIは別の使い方するんじゃないかなってちょっと予測しております。
それはなぜですか?
なぜかというと、リプレイスしたい仕様があるからって感じですね。環境があるからって話でして、
何かって言うと、結局WebのフロントエンドをAppleはリプレイスしたいんじゃないかなと思ってたりします。
SwiftUIを使ってWebフロントエンドを作り変えたいんじゃないかなというような予想をしております。
Web?
Web、もうHTML5ですよね。
WebサービスをSwiftで書けるようにするんじゃないかっていう予想をのとさんはしてるってことですか?
結構大胆な予想だと思うんですけど、結構そう思える部分が今の2020年の段階のSwiftUIでもあって、
結局提供してるUIってWebページで使う部品ばっかりな気がしてます。
Webにあってもおかしくない部品ばっかり作ってるし、
iOSのための特殊な処理とかもなるべく入れないようにしてるという印象がありまして。
例えば?
例えばテキストによるスルーランの機能としてテキストフィールドっていうのがあるんですけど、
それってiOSだとすぐにフォーカスが当たってキーボード出したいみたいな要求あるじゃないですか。
めっちゃありますね。
それが欲しいって会社多分みんな思ってるんだけど、
Appleは何かカタクナに拒否してるという、このおかしさっていう感じですね。
フォーカスを当てる機能って実はiOS以外はあって、
TBOSとかウォッチOSとかでSwiftUIを使うとフォーカスを当てることができるんですよね。
次のフォーカスはどこですかってことは指定できるんで、
ただ最初のフォーカスはここだみたいなiOSで欲しい機能は入れてくれないみたいな不思議な感じになってます。
コードでも書けないんですか。ファーストレスポンダーにするってことですよね。
できないですね。
はあ、そう。
確かになんでできないんだろうっていうのは、もう2年もかかってて、
24:03
やらないっていう選択をしているようにしか確かに見えないとは思いますね。
かつ今のウェブって基本的にはフォーカスが当たらないというか、
ウェブページは基本的には最初のフォーカスを当てるみたいな命令はないので、
ウェブページのテキスト入力に順次てるのかなって気はしますね。
なるほど。
でもそれって、例えばウェブ用のSafe UI for Webみたいなのが出たとして、
その時にウェブだけではフォーカスを当てる機能は使えませんよみたいな感じにすればいいだけな気もするんですけど。
そこもちょっと疑問ではあるんですけど、
それだともう少し今年出してもおかしくないなって気もしてたりするので、
そこはApple判断してないというか、何も考えてないわけではないとは思うんですけど、
その切り分けはするのかなって感じですね。
そもそもそういうUIは最初から提供する気がないとしか私は今のところは見えてない感じですね。
なるほど。
ちなみにSwift UIでウェブを作れるようになるという野戸さんの予想ですけど、
Apple的に何が嬉しいんですかね?
Apple的にはモバイルのアプリ全体に今後影響する話だと思ってて、
AppleってiPhoneでアプリを出せて10年以上経過しつつあるじゃないですか。
10年経過しちゃったのかな。
そこで結局AppleとかGoogleが独占するの良くなくないみたいな、
各国の政府とか経済圏が文句を言い始めてて、
そもそもモバイルアプリの立場が危ういんじゃないかなと思ってます。
そこで中立の場所としてマルチプラットフォームでアプリ作れる環境ありますよってことで、
SafariとかChromeが引っ張り出されてるんじゃないかなっていうか、
引っ張り出したいっていう気があるんじゃないかなと思ってます。
なので今後のアプリは普通にネイティブなアプリみたく、
ウェブアプリも同じUIの書き方で書けますよって感じで、
ウェブアプリを再度引っ張り出したいんじゃないかなっていうような
Appleの思惑があるんじゃないかなって気がします。
それはありそうな気がしますね。
なんかで、アプリの検索便利になったじゃないですか、
ホットライトじゃなくて、
検索、他のアプリのメタ情報をアクセスできる、
あれの仕組みの話の時に、
要はGoogle検索とかあって、
今はGoogle任せというかにやってるけど、
ああいうのを除いて、
今ってユーザーってほとんどウェブページもアプリもあんま分かってない人は、
27:05
多分一般の人ってそこってあんま意識してないから、
要はウェブアプリを書きやすくして、
ウェブページみたいな感じで簡単にリリース可能なものでして、
かつAppleかの検索は、
ホーム画面で下に引っ張ってあそこに打てば、
要は目的のものにたどり着けるっていう、
あそこのコンテンツが充実すれば、
多分Apple的にはすごく良くて、
だからHTMLのリプレイスとかそっち系じゃなくて、
普通に検索コンテンツとしてウェブフロントエンドの人とかが、
参入しやすくなる言語環境を整えている、
だとなんかありそうな気もしなくもないですね。
もう一個の、Appleはいろいろ考えていると思うので、
そういうウェブページを共通のアプリ化する環境にするっていうのもありますし、
あとはSwiftっていう言語をアプラ推奨しているんですけど、
とはいえランキング的に言うと、
人気プログラミングランキングで言うと、
10位にも入らないみたいな状況なんですよ。
10位に入ったのは、実はSwiftの前身のObjective-Cが最後で、
Swiftはそんなに何か出てきていなかったりする。
Appleとして困るのは、Swiftの使える開発者が増えないと、
アプリを作る人も増えないので、
そういう開発者の人口が減ると、
アプリを作るっていう、そもそも人がいなくなっちゃうっていう可能性があります。
なので、そもそもだったら、
一番人気健康ランキングで1位、2位を取ってるっていうのは、
実はPythonとJavaScriptがランキング上位なんですけど、
そのうちJavaScriptは、
開発者の層をSwiftに取り込めればいいじゃないか、
っていうふうに思ってるんじゃないかなって気はします。
Swiftをかけるとウェブページもかけるし、
アプリもかけるよみたいな振り込みで、
開発者の層を増やしたいのかなっていう、
意図がある気がしてます。
今ちょっとその話聞いてて、
別な意図も思いついたんですけど、
ウェブアプリはどうしても存在するわけじゃないですか。
Appleが何をしようが、
ウェブサービスっていうのは存在してて、
ウェブサービスの世界で、
今Flutter for Webもあるし、
なんやかんやで、
Googleのマテリアルデザインが、
意外と幅を利かせてるんじゃないかなと思っていて、
適当に作るときは。
IOSっぽいモバイルデザインのサイトとかもあるけど、
なんちゃって偽デザインみたいな感じだったりするので、
ウェブアプリのユーザー体験的なものを、
30:05
AppleのUIの文法で、
いい感じのものを作りやすくする環境を提供することによって、
iPhoneユーザーがアプリでもウェブでも、
シームレスに近い体験で使えるっていうのを狙ってるとか、
そういうのはあるかもしれないなって、今思いましたね。
利用者がウェブとかアプリとか関係なく、
Appleの文法で操作できた方がいいよってことを
推し進めたいという。
これってそもそもなんですけど、
Swiftブラウザーエンジンで動かないですけど、そこは?
そこは、今のウェブブラウザーって
WebAssembleって言って、
C言語とか、C Rustかな?とかって言語の
ビルドして動かせるっていう、バイナリーを
ロードできるような仕組みは実はもう用意されてるんですよ。
なるほど。
そこにSwiftの言語をビルド、
LLVMとかCLangとかそういった、
Appleって言語のツール群をかなりカバーしてるので、
こっそりやってるんじゃないかなって、
ウェブ用に作ってるんじゃないかなっていう気がしてます。
それをそのまんま、まずはSafariで動かすし、
もしかしたらKrobeとか他のブラウザでも
HTML5の共通のプラットフォーム上で動きますよってすれば、
JavaScript使わなくて、JavaScript補助的にして、
メインはSwiftでビルドしたバイナリーで上で動かしますよみたいな、
アプローチもできるんじゃないかなという気はします。
確かに。それは、なるほど。
どっちまで気合い入れて頑張るって可能性ですね。
大胆予測ですね。
確かに。
それのカプライヤーとしては、
KeynoteとかNumbersとかAppleのアプリって
今ウェブ化してるじゃないですか。
iCloudで使いますよね。
iCloudで動かすのって、
JavaScriptとかBaseとか、
HTML5のテクノロジーを使ってるんですけど、
それって多分リプレイスもできると思うので、
SwiftUIでウェブで動かしますよってこの
加工のデモとなるんで、
その辺も含めてこっそりやってるんじゃないか
みたいなちょっと予想してます。
そもそもAppleって、
Safariっていうウェブブラウザを持ってますし、
Safariの中で動く描画のエンジンって
WebKitって言うんですけど、
WebKitってエンジン自体も、
Googleが出してるChromeとかが
最初使ってたりして、
今は分岐して、
別エンジン見たくなってますけど、
基本的には、
Appleの基本的な技術の上で、
HTML5とかそのウェブのエンジンが、
ルールが使用が決まってるので、
別にAppleはその辺は、
できないわけがないみたいな。
33:00
できる技術はだいたい揃ってるよね、
っていう状態だと思うんですよ。
なので、GoogleとAppleが示し合わせて、
そういう環境に押し進めるみたいなことを
やり始めると、
政府とかそういう、
アプリが独占してんじゃないかってところを
回避していけるんじゃないかなっていうような、
思惑働くんじゃないかなと思います。
で、最後に帰結するんですけど、
今年の2021年の予測なんですけど、
ウェブに全部振って、
AR、VRは最新のところにはUI投入しないし、
基本的な機能もあんま変わんないんじゃないかな、
みたいなのが私の予測です。
ウェブか。
既存そんなにイケてる感じじゃないのに。
なるほど、愛を広げるために
舵を切ると。
あとは開発者を増やしたいし、
アプリはアプリでARとかVRのハードを
使うために必要なので、
そっちはそっちで開発を進めるんじゃないかな。
で、こなれたらSwiftUIにも
数年後取り込みますよみたいな。
なのであくまでもSwiftUIは基本の、
既存のよくある機能のリプレイスみたいな扱いで
使うのかなみたいなのが今年の予想ですね。
2ヶ月後が楽しみですね、答え合わせが。
始まる前なんで何でも言いたい放題なんですけどね、今のところ。
けど基本あれですよね、SwiftUIって
UIキットのリプレイスですよね。
なのでなんとなく他のやつってSwiftで書けるから、
AR、VRの新しいUI出たとしても
普通にフロントアクセスで書く?
SwiftUIキットの、なんとかキットが出てきて
普通にオブジェクティブシーンで書けたり
Swiftで書けたりとか、普通のクラスライブラリというか、
我々はよく慣れ親しんだ
普通のアプリの作り方に準じて
AR、VRでできますよって言ってくる可能性はあるんだけど
そこにSwiftUIが絡む要素が今のところないかもみたいな。
若林さんはSwiftUIは今年はどう予想しておりますか?
いや僕はもう今年は普通にテキストにフォーカスが合うようになるとか
順当に使える部品が増えるとか
普通に進化するんじゃないかなっていう風に予想してますけどね。
本命予想だ。
ガチガチの本命。
1.2倍ぐらいの、本当に1.2倍ぐらいのあれですけど。
確かにリッチテキストが複数行とかないですよね。
そうなんですか?
あとは何がないかな。そこまでなんか。
もうUIキット系はカバーできてるんですか?コレクションビューとか。
36:04
その辺はできてますね。
逆にできてないところってあります?
UIキットの細かい属性があんまり結構削られてるとか。
UIキットほど細かくその画面を操作できないというか。
デザインこだわる場合結構辛いんですかね。
例えばナビゲーションバー透明にしたりとか無理ですよね。
ナビゲーションバーの透明とかあとステータスバーを色を細かく変えてみたりとか。
結構まだ痒いところ手届かない感じなんですね。
あとはスクロールビューの指定の位置までスクロールっていうのが2020年に一応できるようになったんですけど、
そのこのパーツまでみたいな感じなんでそのポイントで指定できないですね。
十分といえば十分なんですけど。
それが対応になるのか、そういうのするなというアップルの。
これに関してはそういうのするなような気はしますね。
ナビゲーションバーも色を変えるな、スクロールもコンポーネントごとにちゃんとそこまでいければいいだろうみたいな。
あるかもしれない。
そういうレベルでもうちょっとってだけなんですね。
なんかいろいろ困ったことはあるような気はするんだけど思い出せないですね。
じゃあ普通にアプリ作れるレベルです?今。
作んないです。自分は作んないです。
理由としては?
理由としては確かに核のラックなんですけど、さっき言ったようなその細かいことができないっていうことがあるのと、
そういう時に本当にできないかどうかっていうのがわかんない。
要はUIキットだったら誰かがやってることはできることなんですよ。
だけどスリフトUIは他のアプリでできてるからといってできるかできないかわかんなくて、そこを調査するのに時間がかかるし、
なんかハマった時とかも、最近はスタックオーバーフローとか情報増えてきたけど、
情報もちょっと少ないっていうのもあって、簡単な画面とかでは使ってるんですけど、
凝ったことをしようとすると最初なんかサクサクかけて気持ちいいんですけど、
壁に当たった瞬間にいきなり難易度が上がっちゃうんですよね。
なのでUIキットで地道にやっていく方が結果的に時間短縮になるっていう感じです。
なるほど。本筋じゃないですもんね、そこは。
細かいことで調べたりはやりたいことに集中できないですね、それだと。
39:05
そうなんですよ。
これはみんな使う未来はあるのかっていう、何かよっぽど大きなメリットがないと結構大変そうですね。
スイフトUIよりもUIキットの歴史が10年も経ってるんで、さすがに10年の歴史が重みがあって、
そこのノウハウがかなり溜まりに溜まってるし、新しい機能もキャッチアップしやすいのがありますね。
スイフトUIはそこに、まずそれは何でそうなるのかっていうリズムがなかなかUIキットに比べてしにくいというか、
こうやればこうやるはずだっていうスタンダードな解決方が全然わからないというか、
っていうのが2019年から2020年の段階で、ノウハウ的には増えてきてますけど、
それでもスイフトUIの仕様を全部網羅してる記事というか、調べても出てこないのとかありますからね。
実はそれを使えば動くんだみたいなところも、あんまりAppleは言ってくれないというか、
そこまでこと細かに何も教えてくれない感じがありますよ。
一番ひどいのはAppleのドキュメントがかなり素っ気ないっていうか、
これは何々を装飾する、終わりみたいな。
UIキットだともう少し英語でもちゃんと書いてくれてるんですけど、英語ですら書いてない。
読んで字のごとくだろうみたいなところが多くて、そういう突き放し方するんだみたいな。
ドキュメント不足の深刻さはちょっとありますね。
それは確かにありますね。
ただ独自のUIを作るとか、私も自分のブログで投稿してるんですけど、
代わりでタブバーとか作って遊んでたりします。
そういうカスタマイズされたUIを作る時にはすごく楽しいんですけど、
普通のUIの振る舞いを作るとなると途端に手詰まり感が出てくるというのはありますね。
ボタンとかテーブルビューが動いてほしいような、
普通みんなこう動いてほしいようなってところが実は動かないとかが分かっちゃう。
結構そういう微妙なやつありますよね。
例えばリストの、今までのテーブルビューみたいなやつの中にボタンを入れたら、
ボタンの文字が書いてあるところしか押せないとか、
なんか謎の挙動が発生したりとかして、
なんかそういうこともあるから、
やっぱり安心感がちょっとまだ足りないかなっていうのはありますね。
でもそれも時間の問題で解決することだと思うんで、
順当に使えるようになっていくんじゃないですかね、何年かかけて。
SwiftだってSwift 3まではちょっとアレな感じだったじゃないですか。
42:00
そうですね、3年。個人的には5まで。
ABIが安定するまではすごい使いづらかったので、
5年ですかね。安定まで5年かかったので。
5年なんて近いもんですよ。
そうですね、確かにSwift言語のときとちょっと似てるのは、
Swift UI 2020年版の機能を使うためには、
対応OSもiOS14以降にしなきゃいけなかったっていうのがあって、
広報互換的なものがない。
なので、今年何かが出ても最新OSでしか
良くなったものを使えないとかになるから、
そういう意味では初期Swift的な書き方作り直しみたいなのとかも
発生したりとかいろいろあるかなっていう気がしますね。
それを考えるとWebフロントエンドでSwift UIは手っ取ればいいんじゃないですかね。
戻った。
むしろその話を聞いて、確かにWebだとすぐ最新技術使えるなみたいな風に
むしろ思ってしまいましたね。
確かに数年かかるのは事実で、
UIキットでも新UIとか作っても結構抵抗があるじゃないですか。
新しいUIをAppleが作っても、いつ投入できるんだろうかみたいな悩むことないですか。
ありますあります。
ステップUIとかあったんですけど、
あれもいつ使えばいいか、使いどころ分からずにそのまま使ってないみたいな。
あれはそもそも使いどころがないものなので。
なんで今更感があるし、これそんな使いたいと思うかなみたいな。
そういうのを考えるとやっぱWebアプリで修正即反映ってやっぱその
それをAppleの開発環境でできるっていうのは結構魅力的な気がします。
なんかWebだと地獄だなと思うのは、
なんかIE対応とか昔のバージョン対応みたいので、
こんなApple手動でガンガン広報互換を削っていく開発とは合わない気もしてて、
なんか要は新しいSafariじゃないと、
このビルドしたバイナリー動かないみたいなことがあったら、
その最新環境のブラウザを使ってる人じゃないと表示できないとかってなると、
余計辛いので、なんかAppleとも合わないなって思うんですが。
まあそういう考え方もあるし、もしかしたらAppleは
Flashみたいな環境を提供したいのかなって気もしますし。
Flashを殺して、自らがFlashになるみたいな。
このために。
このためのFlash殺しみたいな、そういう
Flashを叩きつめましたみたいなところがある。
45:01
とはいえ、Flashのアイディアは確かに出た時はみんな面白がって使ってたのが事実なので、
そこからセキュリティとかいろいろ他の問題が出てきて、
もちろんAppleがFlashを潰したっていうのもあるんでしょうけど。
Swift UIでWebアプリっていう話、さっきの話ですけど、
確かにAppleがFlashを殺したように、
Googleとかマイクロソフトが殺せますよね。
逆に。
Swift UIで書かれたものは、
例えばWeb標準とちょっと違うから実行できなくしてやるぜみたいなことを言い出すと、
もうアウトじゃないですか。
そうですね。
ただ、現状AppleとGoogleしか生き残ってない。
あとはVocelaとぐらいしか生き残ってないので。
マイクロソフトエッジというものがあります。
それは存在してないらしいので。
ちょうどフロックっていうGoogleが提唱している広告トラッキングの新しい仕組みがあるんですよ。
最近Appleとかがうるさくて広告トラッキング難しくなってきてるじゃないですか。
フロックっていう新しいGoogleの仕組みを提唱していて、
それがどういったものかっていうと、
ユーザーの行動をユーザーと紐づけないで、
同じような行動をしているユーザーを全部グルーピングして、
その人たちに合う広告を出すみたいな。
したら匿名でしょっていう割と乱暴な仕組みなんですけど、
それをChromiumには標準搭載してるんですね。
オープンソース版のChromeですね。
そのChromiumをベースにしているマイクロソフトエッジがフロックを殺してるんですよ。
マイクロソフトとしては賛同できないから。
デフォルトだとフロックオンになっているはずなのに、
あえて殺してて、フラグいじってフロックをオンにしたとしても、
エッジではフロックが使えなくなるっていうことなんですよね。
なので、その賛同できないっていう何らかの大義名分があれば、
ウェブブラウザ上で動くものは、
ブラウザの開発メーカーが殺せるっていうのは、
今現在進行形であるので、そういうリスクもありますよね。
そのあたりはAppleが一番よくやってるところでもあって、
プライバシーっていう理由で、
あらゆるChromeが提唱している機能とかを全部ダメって言ってるんですよね。
例えば、何だったかな。
ハードウェアのBluetoothとか、フィンガープリント取れるような。
あとUSBもウェブから使えるMIDIも個人特定できるか却下して、
48:00
みたいなところはあるんですけど、
共通でマルチプラットフォームで動かしますよっていうことの言い訳にために、
そこだけは戦わない中立地帯を作ることもできるんじゃないかなっていうふうにも思いますね。
ある程度妥協点があって、
その妥協点をする相手があんまりそんなにいない。
それこそAppleとGoogleとちょっとModularみたいなところがちゃんと
マイクロソフト、マイクロソフト。
マイクロソフトは存在しないので、
マイクロソフトにChromeを入れることはあっても、
Edgeを使ってる人ってそんなにあんまり、
ブラウザーの視野的にもいないので、
モバイルとPCのほうでブラウザーを占拠している人たちが、
そこで中立でアプリが動きますよってことに。
言い訳にして既存のアプリ市場を守るみたいな動きに使われるんじゃないかなっていう。
技術的に確かにブロックできるし、
この動きダメですってもちろんあるんですけど、
そのあたりはあんまり障壁にならないんじゃないかな。
むしろ自分たちが持ってるアプリのストアをクローズされるよう、
介入されるようなマシンだみたいな。
介入って政府とかそういう大きな企業に対しての、
批判をかわすために使うんじゃないかなって気がします。
なるほどなるほど。
なのでウェブブラウザーを中立して、
大企業が戦わない場所にして、
アプリの市場自身もあんまり政府とかとガタガタしないようにして、
新しい市場に行きたいんじゃないかなとアップルは。
そういうことまでスイフトを調べているうちに考え込んだっていうので、
今回の企画ですね。
スイフトUIからアップルの戦略が透けてくるかもっていうところもあります。
なるほどなるほど。
じゃあまあとりあえず6月7日のね。
6月7日にジャッジメントが。
ジャッジメントが入りますんで、どうなるか。
じゃあ6月になったらまた答え合わせシリーズを。
大反省会。
ウェブなんて一言も出なかった。
一言も出なかったみたいな。
むしろ当たったら自分が驚きますわみたいなことかもしれないし。
のっとさんがすごい勝利宣言する可能性もね。
ガッツーポーズかもしれない。
ありますんで。
じゃあそういう感じで。
今回そんな感じですかね。
最後に聞いてみたいんですけど。
のっとさんに毎回聞いてるんですけど。
2021年はスイフトUIの実業務?
普通の案件とかそういうので投入できるかどうかは今年も聞いてみたいです。
51:00
現時点では使えるようになりそうですか?
現時点だとあんまり補助的な部分、部品には使えるかなっていうレベルですね。
じゃあ今年もまだみんなが遊んでる段階と。
遊んでるかその本業に影響がない程度でみんななんか作って腕を磨く段階か
いきなりウェブフロントで作れるぞってみんながわき上がる状況ですけど。
木爆材がないと多分みんな使い始めないと思うんで。
かといってAR、VRにスイフト投入して
スイフトUIって何回かつAR、VRの新規に使ったら何が起きるかって誰も実装できないようになっちゃうんで。
いずれにしろ何か木爆材がないとユーザー数が増えないし
そもそもスイフトっていう言語自身を使う層も少ないしみたいなので
自利品になっていくんだと思いますね。
どっかでAppleは増やさないといけないっていうのは
実用になる前にみんな使わなくなる可能性
それこそFlutterとかあっちのほうにみんななびき始めてるって状況があるので
他の言語のほう
スイフトUIがなんとかなる前に会社がいませんっていうのはちょっとあるシナリオだと思いますね。
分かりました。じゃあ僕は今年もやらないです。
なんか面白そう。あれスイフトUIよりもスイフトUIに付属する新しい言語仕様は結構使ってます。
そっちのほうが使えますね。プロパティラッパーとか
ああいうのは全然使えない。
あのあたりもかなりフレームワークレベルでスイフトを拡張
スイフトって言語拡張するってちょっとびっくりしましたけど。
あれはちょっと黒魔術すぎて好きじゃないですけど
コード量が格段に減ったり
一番使うのはSwiftieUserDefaultっていうオープンソースのライブラリーがあって
あれとかがすごくうまく使ってて
プロパティラッパーでSwiftieUserDefaultの
AddSwiftieUserDefaultでキーパスやると
そのプロパティの更新イコール
UserDefaultに書き出してくれる
ゲットしてくれるみたいな形になるので
ああいう方向性はちょっと言語仕様重くなるんですけど
まだありかなと思ってて
音形も感じてるので
僕はちょっとSwiftUIはやる気はないですが
売りに付随する言語仕様はちょっと期待してますね
そうですね
プロパティラッパーっていうのは
Swiftアトリビュートとかいわれる
Swiftにさらにいろんな機能を付加するために
例えばUIキットとかの外部仕様とかを詰め込むために
54:03
UIキットとか
基本的にSwiftとは外の関係ないじゃないですか
OSとは関係ある話だったりする仕様を
無理やり埋め込むところとかに使われてるんで
その辺を拡張して
でもSwift言語自体は
なるべくOSに依存しないように
作ってるっていうところはありますよね
そうですね
あれはどっちかというと
Xcodeのコンパイラーの機能なんですかね
コンパイラー側で勝手に作り替えちゃうってところですよね
その方向性はいいですよね
でもそれって例えばLinuxとかWindowsだと
また違う動きになるってことですよね
一応SwiftってLinuxとかSwiftだと
X Windows 10で動くってことで
ビルドで使えるようになってるんで
そういうOSごとの逃げ口をちゃんと作ってるってことですね
言語仕様に組み込まないってことですよね
言語仕様に組み込まないっていうスタンスは
堅持しつつ自分のやり方をやるってのがAppleですね
Swift UIみたいなめちゃくちゃなものを作っちゃうっていう
Webに行こうとしてもできると
一応オプションとしては持ってるんじゃないかなと思う
今年やるかどうかはちょっと
みなさんの味気で自信なくなってくるなと思って
そんな自信あった?
条件としてはいろいろと揃ってるのは確かで
ここ数ヶ月下調べしてる段階では
結構技術的なところは揃えてるなっていう印象はあります
じゃあ最後他に何か言っときたいこととかあったら
あと1ヶ月と数日ですか
WWTC2021を待ちたいと思います
ちょっと楽しみになりましたね
ちょっとね楽しみになりましたね
ほうばくちを打ったんでちょっと
みなさん期待してもらってですね
はい じゃあ答え合わせ会やりましょう
やりましょう
ということで今回もお聞きいただきありがとうございました
番組へのご感想や話題のご提案などは
このポッドキャストの概要欄にあるお便りフォームでお寄せください
ハッシュタグエアサップでの感想ツイートも大歓迎です
はい それではありがとうございました
ありがとうございました
