この記事は2021年7月29日（木）に開催された、Radiotalk TechTalk vol.5「【耳だけ参加OK！覗き見OK！】iOSエンジニア 4社合同LT会」の後日レポートです。
登壇者
1．パラレル株式会社 Software Engineer 石川 直樹 氏
2．株式会社ミラティブ クライアントチーム マネージャー 千吉良 成紀 氏
3．株式会社ヤプリ iOSエンジニア 岸川 克己 氏
4．Radiotalk株式会社 iOSエンジニア 山岸 央青
（本文敬称略）
モデレーター
Radiotalk株式会社 Androidエンジニア 牧山 瞭
パネルディスカッションテーマ
1．Xcode 13 / iOS 15 / Swift 5で気になること
2．SwiftUIとの向き合い方
3．新しい技術をサービスにどういう判断で導入するか、また導入時の流れ
※進行順
LT
前半では登壇者が各自準備したLTを発表しました。記事ではスライドのみ展開します。
1．パラレル株式会社 Software Engineer 石川 直樹 氏
2．株式会社ミラティブ クライアントチーム マネージャー 千吉良 成紀 氏
3．株式会社ヤプリ iOSエンジニア 岸川 克己 氏
4．Radiotalk株式会社 iOSエンジニア 山岸 央青
パネルディスカッション
当日はそれぞれのLTについて視聴者からいただいたコメントや気になる点、興味深い点などを率直に語りあったのち、パネルディスカッションに移りました。あらかじめ登壇者から挙げてもらったテーマから、ピックアップされたものを中心にディスカッションしていきます。ここではトークの一部を抜粋してご紹介します。
１．Xcode 13 / iOS 15 / Swift 5で気になること
山岸：iOS15で気になるのはSharePlayですね。どこまでサービスとして提供するのか。動画だったら「友達と一緒に見る」といった使い方が想像できるんですが。
石川：Appleもついにこういうところを目指しているんだな、というのは共感できました。考えられるユースケースとしては、Apple（TV）のムービーだったりとか、Appleのアプリ上で提供されているコンテンツをFaceTime経由で共有してもらうといったところがメインなのかなと思っています。ただ、コンテンツを一緒に、いきなり見るのって、誘うのも含めてなかなかハードルが高いですよね。
山岸：FaceTime自体が（相手の）電話番号を必要としますよね。結構身近な人でないとやらないんじゃないかな、とは思うんですが。 Appleが毎回プレゼンしているほど、FaceTime、そんなふうに使われていないぞって（笑）いや、使われてるのかな？ 身近な人では！
岸川：アメリカだと違うかもしれないですね。iMessageとかすごい使われているし。
山岸：あとは、通知まわりですかね。iOS15といえば。
岸川：通知については、基本的にメンション以外の通知はするなというか、してもOSに勝手に止められる、みたいな流れになっていますね。まぁ、使ってる分には、妥当だなっていうところはありますね。仕事の話でいうと、通知がこういう仕様になるんで、何か個別のユーザーにかかわるお知らせとかだったらまだしも、会社からの一斉お知らせを送るのは無駄だし、そもそも誰も見ていないよっていう感じですよね。
千吉良：いい流れだとは思います。ミラティブの場合はプッシュ通知を介して配信中にコミュニケーションを取っている部分があるので、ユーザーが知らないうちに通知をまとめる設定とかにしていたりすると通知がユーザーの目に触れないことになるので、ユーザーに対するコミュニケーションは必要なのかなと思いますね。
山岸：サービス側としても「こうしてね」と、ユーザーに案内する文言や工夫が必要ですね。どうしたらうまく（通知が）届くんだとか、実装においては考えることが多くなりますね。
岸川：＠（アットマークメンション）的な、「この人に向けて（の通知）」っていうのが自動的に、機械的にわかるような補足を上手いこと付けるとか、いいんじゃないですかね。
石川：そこらへんのプロダクティビティみたいなこと、すごい重視してますね。フォーカスモードみたいなのが出たり。（こうした流れは、ユーザーファーストの観点から見ると）いいとは思います。
あとは、Xcode Cloudが気になりますね。
岸川：Xcode Cloud便利ですよ。全体的にクセは強いんだけど、少なくとも最初のセットアップさえ乗り切ることができれば、すごい楽だと思います。「TestFlight」の（β版アプリ）配信も自動的に対応してくれるし。
石川：ベータ版への対応も早いじゃないですか。マシンスペックとかは公開されてないですかね？
岸川：されていないですね。もしかしたら、カスタムスクリプトとかでuname（カーネル情報コマンド）とか実行すれば出てくるかもしれないけど。まぁ、どうせVM（仮想マシン）だろうしね、っていうところがあるのと、そんなに超絶技巧みたいなことはたぶんなさそう。
ちょっと（ドキュメント）読んでると、「クリーンする」チェックマークがあって、（スマホアプリの）GUIではあまりクリーンってそんなにしないよね、って思って。「必要ないよ」と思って眺めていると、なんかXcode CloudはDerived Data（デライブド・データ：自動補完データやログ、デバッグビルド、中間ファイルなど）を積極的にキャッシュしている、というようなことが書いてあって。
もしかしてこれ、状態継続するの？ みたいなのをちょっと思って…… そこは気になりますね。
石川：キャッシュとかも全然ないんですかね？
岸川：ないけど、Derived Dataをずっと結構持っているから、クリーンするときはちゃんと（明示的に）クリーン（しなければいけない）みたいな感じで書いてあったから、謎だなと思って。環境は使い捨てで、（状態に関するデータは）キャッシュでやりくりするのがセオリーだと思うんですけど、どうなのかなって感じですね。
石川：（そのあたりの仕組みは）あまり公開されなさそうですよね。
岸川：他のCIサービスは、カスタム（ビルド）ステップとかも全部オープンソースだから。Bitrise（ビットライズ：CIツール）が「全然余裕ですよ」みたいなこと言ってますけど、あのへんはたぶんそういう感覚があるんだと思いますね。やっぱり一日の長はあるし、最後発にしては微妙にわからない（ノウハウがありそうな？）感じになってる部分があるから……。
主なオートメーションみたいなところはやはり、BitriseなりGitHub Actions（GitHubのCIツール）なりを使いつづけるかなっていうところはあるかなと。とくにGitHub Actionsに関してはすごい簡単ですしね。そのへんのアドバンテージは変わらなそうな気がします。
山岸：Swift5.5だと、async/awaitとかActorとかですかね。
岸川：そこだと思いますね。ただ、バックポート（新バージョンの機能が旧バージョンにもさかのぼって適用）されるのかどうかっていうところですね。
石川：（開発者コミュニティでは）議論中なんですかね？
岸川：そうですね、（開発者コミュニティの議論）スレッドがちょっと加熱しすぎて、いったんロック（凍結）にはなってしまいましたけど。作ってる人は、さすがにバックポートしたいとは思ってると思うんですよね。そうしないとそもそも使う機会が全然ないんですよね、普通に考えて。他のAPIといっしょに考えると、早くて1年後みたいな話になっちゃうんで。
async/awaitは他の言語ではポピュラーとはいえ、SwiftもOSSとしては先進的なところがあるから、どんどん使って慣れていかないというところがすごいあるんで。「（実装が）アナウンスされたけど、（実際に使えるのは）1年後だよね」みたいなスタンスだと厳しいと思うんですよね。これに関しては。
2．SwiftUIとの向き合い方
山岸：それでいうとSwiftUIとかも使いたいけど使えない企業とかも、結構あるじゃないですか。
岸川：SwiftUIは少しずつバックポートされてる部分があるっぽいんですよ。SwiftUI関連のニュースとか見ていると、「最新（バージョン）じゃなくても、ここから（ある程度前のバージョンから）使えるよ」というのが多くて。
だから、async/awaitも、そのあたりは期待できるんじゃないかという気がしています。
山岸：ミラティブは、（iOSの対応バージョンが）13.6以降じゃないですか。SwiftUI、使ってるんですか？
千吉良：いまはウィジェットだけですね。（プロダクト）本体にはまだちょっと先かなと思っていて。
設計はいま、ReactorKitっていうのを使っているんですけど、本来はServiceというレイヤーがあって、ユースケース的なものをキレイにまとめられるんです。ホントにキレイに分離されている状態だったら、SwiftUIでUIのガワだけ導入してみて、みたいなことがもしかしたら出来るかなという気もしているんですけど…。
いまはそこまで整理されていないし、アプリに関わる人数が意外に多いのもあって、中途半端に導入するとソースコードをいじる人たちが混乱しちゃったりするんで、下準備の期間は必要かなというステータスですね。
山岸：パラレルはどうですか？
石川：工数がないっていうのもありますが、まず着手するなら、Modelだったり、いまのPresentorから、Combine化みたいなのはできるかなと思っています。
いまXIBとかStoryboardで画面遷移の管理をやっているのを、全部SwiftUIに置き換えられるということは多分しないかな、と思います。やるなら、1から作りたいですね。そのほうがたぶん早いと思います。
岸川：SwiftUIは未来のUIフレームワークであることは間違いないと思います。正しい道、正しい未来を継ぐものだとは思っていて。
最近の完成度を見ていると、iOS15から新しく作るアプリで、iOS15以降のみ（対応）で行くのであれば、そろそろ行けるんじゃないのという気がしています。これまでは「SwiftUIへの対応は無理だから」と言っていたんですけど……。
どっちかというと、UIツールキットとしての補足部分といったところですよね。インタラクションのある部分とか、画面遷移のジェスチャーで右から左からスワイプするとか、画面の外から次の画面を引っ張ってくるみたいなやつを作るのは結構苦手というか。逆にすごいややこしくなるので。
あとは、トランジションとか、そういう操作に対応する機能がないので。プッシュ通知、モーダル表示、あとシート表示をSwiftUIで実装しようと思ったら行き詰まるっていうのがありますね。
山岸：遷移まわりがちょっとむずかしいですね。
岸川：凝った演出的なトランジション入れようと思ったら、本当に難しい。 まぁ、SPA（Single Page Application：単一ページのアプリケーション）向けですよね。画面にいったんすべてのパーツを置いておいて、すでにあるものが消えたり点いたりするっていう。
そもそもSPA向けの手法だと思って、最初に全部パーツを置いておいて表示／非表示を切り替えるっていう感じでやっていくのが正解なのかもしれないですね。
山岸：画面の一部分でも使われているものはありますよね。ヤフーとかクックパッドとか、結構エンジニアがテック記事を出していますが。
岸川：SwiftUIにアドバンテージを感じている部分があると思うんですよね。おそらく、Xcode Previewsですよね。Previewsとの連携がすごく強力っていうのはあるので。
PreviewsはUIKitでもだいたい問題なく動くから、Previewsのほうを上手く使っていければ、SwiftUIでは細かいボタンとかシェイプとかの記述は本当にラクだから。そのほうがトータルで書きやすそう、というところはSwiftUIを使っていく、というのは、いままでのバージョンのiOSでのやり方の延長線上ですよね。
iOS15からは、もしかしたらSwiftUIファーストでも行けるんじゃないかという気は若干しています。
石川：いずれはWidgetみたいにSwiftUIオンリーにならないといけないような感じになるかもしれないし……。
岸川：iOS15以降もUIKitによる実装を残すかは微妙なところですね。ただ、ツールキットとして考えると、UIKitはすごいので。もっとわかりやすく考えて、Macアプリを作る場合にはSwiftUIはオススメでいいかなと思いますね。AppKitはちょっと難しいのと、調べても情報が結構出てこないので。
Macアプリはややこしくって。Mac Catalystがあるんですよね。Mac CatalystはiOSアプリを作っている人にはいいけど、だいぶややこしいので。それならSwiftUIでいいんじゃない？ とは思いますね。
山岸：あとは、iPadOS15からiPad上でもXcodeが動作するようになり、iPadだけでアプリを作れるようになるじゃないですか。誰か、iPadからアプリを出したりしないですかね。そういう勇者はいないですかね。（※Appleの発表では2021年秋対応予定）
岸川：素晴らしいですよね。何がいいかっていうと、やっぱりiPadから直接アプリをディストリビューションできるっていうことですね。Playgroundで作成するプログラムはもはやオモチャではないので。普通にAppStoreで動作するホンモノを、iPadだけで作れるっていう。
3．新しい技術をサービスにどういう判断で導入するか、また導入時の流れ
牧山：せっかくなんで、SwiftUIとか新しい技術が出ているなかで、サービスによっても取り入れようという判断基準とか意識って違うと思うんですけど、それぞれの会社でどう判断しているのか、導入の流れみたいなのをちょっと聞いてみたいです。
石川：会社によって結構違うかな、というのはおっしゃる通りで。前職では開発者にフレームワークを提供するかもしれないという局面になったことがあるので、なるべく依存するOSSが無いように開発したりはしていました。自作できるくらい人数も多かったもあります。
パラレルでは僕しかいないので、なるべく工数をかけないように、UIとかでもOSSを使ったりというのはありますね。環境によりけりって感じです。
千吉良：ミラティブの場合は、たとえばウィジェットみたいなケースだと、とりあえず適当なサンプルを作って「作ってみました」みたいな感じでPMやデザイナーに見てもらって、「あ、いいね」って仕様やデザイン決めて出しちゃう、という流れでリリースまでいきました。
SwiftUIとかを導入するか否かの判断は、普段のアプリの設計思想に結構関わってきて、実装する上で迷いが出ちゃったりする場面も出てくると思うので。こういう新技術に関しては、将来のことを考えて「いつにしようかな」みたいな感じの考えになることが多いですね。
岸川：基本的には「その人が使いたいのであれば、やればいい」と思います。だいたい、導入する技術を選べるっていう状況はそんなになくって、時間の制約とかがあるじゃないですか。
未知の技術を使ってなにかを作ると、当然予測しないことが起きますよね。でも既存の技術を使っても予測しないことというのは起こるので。そういうことがあると考えて、もろもろ困難をクリアして期日に間に合うのであれば全然大丈夫だと思いますし。
ただ、優先順位の大きなことが他にあるとか、まずは早く出してフィードバックを得ないとそもそもいけないという場合もあると思うので。そのへんを考えると、基本的なセオリーとしては「枯れている（使いこなされている）ものを使う」というのが普通の判断だと思います。
そのうえで、その人が本当にその技術が好きとか、興味関心があるとか、「予測不可能なことがあっても自分で調べて乗り越えられるし、それがモチベーションになります」とか。「もうUIKitとか正直ダルいとずっと思っていたんです」とか、そういうモチベーションは全然ありだと思います。
そういうエネルギーって、障害を乗り越える原動力になるので。そうやって、どんどん道を切り開いていく人は絶対必要なので。そうであるならば、どんどんやりましょうという感じでいいと思いますね。
牧山：探究心をもって、新しい技術にパッと飛び込んでくれる人も大事だったりしますもんね。
岸川：そうですね。逆にそういうのが無いなかで、よくわからないまま「とりあえず使ってたほうが人が集まるから、SwiftUIを使おう」みたいな考え方はどうかと思いますね。
山岸：千吉良さんが言ったように、「これいいね」みたいな感じで進めていく場合もありますし、岸川さんが言われたみたいに「これやりたいんだ」といって、先導してやっていくようなやり方とかがRadiotalkでは結構多いですけども。
やっぱりエンジニアでしか判断できなくて、「新しい技術だけど、これ入れたいな」という部分は、簡単なタスクを作って、若干工数を多めに申告して取り組んでいますね。
岸川：「ダメだったら、ダメだとあきらめる」というのはありますね。そのへんを柔軟にできるといいですね。
（了）
最後に視聴者の質問への回答もまじえながら、各社のプロダクトの印象や感想を伝えあい、会は和やかに終了しました。 登壇者の皆様、ご参加の皆様、学びの多い時間をありがとうございました！ Radiotalk TechTalkでは、今後もエンジニア同士の勉強会、知見共有を通じて技術力の向上をめざしていきます。