トーク

巷ではApple Carが自動車業界の大変革を起こすのではと噂されていますが、そんな未来をちょっとだけ先取りして体験できるのが「テスラ」です。私はiPhoneが登場した時のような衝撃を受け、気づいた時にはテスラモデル3の購入ボタンを押していました。テスラ車にはテクノロジーに興味のある方なら誰もが興味を持つであろう機能が盛り沢山です。また、非公式ながら車体の情報を取得・操作するためのAPIや、ハードウェアの情報にアクセスするためのインターフェースが備わっていたりと、ソフトウェア開発者がテスラ車自体を拡張する余地がいくつかあります。「このAPIを使えば楽しそうなことができそうだな」とワクワクしながら考えることは、我々モバイルアプリエンジニアの最も得意とするところかと思います。このトークでは、実際にテスラを購入していじくり倒して得た知見をご紹介します。このトークを通じてテスラの面白さを知ってもらいつつ、まだ見ぬApple Car OS(?)アプリ開発の世界について色々と想像してみましょう。

アウトライン（検討中）

• テスラモデル3自体とその先進的な機能群についての紹介
• 非公式のTesla APIを使ったiOS/Apple Watchを開発し実際にリリースした話
• Tesla API の詳細
• 全ての走行データが蓄積されるのでログ好きにはたまらない話
• Webブラウザも備えているのでなんでもありな話
• 車載カメラに記録された動画でいろいろ遊べる話
• Apple Carを想像する

PickGo for Partnerは配送ドライバーのためのアプリとして2015年からiOS/Androidアプリを提供しています
そして2021年5月にFlutter化とFlutter版への完全移行を実施しました。
WebViewを利用しており、計画的には問題なく移行できる想定ではあったものの、既存で今もなおユーザーが利用しているアプリを移行するということはとても大変なもので技術力と精神力を大きく使ったと振り返ると思います。今回この移行で培った知見をまとめて皆様に共有することで、同じようなことをする方がより省力で移行が実現できるようにまとめたものです。

• 既存のネイティブアプリをなぜFlutterにフルリプレイスしたのか？
• 移行計画の策定と進め方
• 移行前に立ちはだかった問題
• 移行後の積み残しと今後の展望
• まとめ
  アプリ - https://apps.apple.com/jp/app/%E8%BB%BDtown-%E8%BB%BD%E3%82%BF%E3%82%A6%E3%83%B3-%E8%BB%BD%E8%B2%A8%E7%89%A9%E3%83%89%E3%83%A9%E3%82%A4%E3%83%90%E3%83%BC%E9%85%8D%E8%BB%8A%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9/id1053791248

■概要
楽天グループが運営するラクマでは、旧フリルから含めて今年の7月末で9周年を迎え、10年目に突入します。

長年開発されてきたアプリのため、レガシーな部分が残っており、リファクタリングを継続して行っています。
その一方で、早期から iOS13 以上のサポートへ切り替えているため、新しい API の導入を積極的に行ってきました。
例えば Combine、SwiftUI、Compositional Layouts といったものです。

今回は、実際にプロダクションレベルで運用している実装について、特に Compositional Layouts について触れていきます。
また、その他にラクマの iOS 開発における挑戦を紹介したいと思います。

■登壇者
鶴田: @hcrane14 (Twitter)
黒田: @darquro (Twitter)

あなたの組織では幾つのサービスが開発されていますか？ 1つ、2つ、それとももっと多くでしょうか？ 具体的な数はさておき、同じ組織にいても違うサービスを作っていたり、違う機能を作っていたり、組織の規模拡大に伴い開発チームが分かれていくと、だんだんチーム毎に品質に差が出てくるかと思います。 そもそも品質というのは決まった物指で測れるものでもなく、サービスやチームによってそもそも何を品質の評価軸とするかも変わってくるものです。 でも本来同じ組織で開発しているサービスなら、エンドユーザに届けたい価値に対する根本的な思想や、最低限担保したい品質の基準があるはずです。 その価値に対する根本的な思想を伝えたり最低限担保したい品質を満たすためのサポートを、サービスやチームを横断して執り行っていく組織横断チームが必要になります。

しかし自分が常日頃開発に関わってない他のサービスやチームが今どういう問題を抱えているか、どういう状態にあるのかを把握していると自信を持って言える人はいないでしょう。 場合によっては自分のサービスやチームの状態や抱えている問題に関してすら、改めて他人に話そうにも整理しきれてないこともあると思います。 そこで組織横断チームを始めるためにはまず他のサービスやチームの状態や抱えている問題を知るための術、ひいては自分が他の人に話すために一度整理するための仕組みが必要になると私達は考えました。

本セッションではそれに対し私達が試している取り組みとして、サービス及び開発体制の定期健康診断と称した質問票ベースでの現状把握フロー、そしてその結果を踏まえた組織横断チームの運用と品質改善の取組みについて共有します。 またそれでも解決しきれていない問題についても共有します。

ミダスキャピタルが出資する株式会社GENDAは、連結従業員4000人以上からなるエンタテインメント領域のホールディングス会社です。2018年5月に創業し、現在は日米中3カ国に事業を展開、M&Aによる事業拡大に力を入れています。昨年度末には、セガグループからセガ
エンタテインメントを連結子会社化し「SEGA」ブランドのゲームセンター事業の運営も開始しました。
このセッションでは、老舗エンタメ企業をテクノロジーで進化させていく挑戦と、モバイルアプリの活用事例を紹介したいと思います。

寄付体験を身近にすることを目指して開発されたアプリ「dim.」

・SwiftUI 95%以上
・エンジニア1人
・開発期間2ヶ月
・リリース前に大きな仕様変更を2回行う
実はこんな条件下で生まれたアプリです。

皆さんご存知の通り、SwiftUI はまだ実用レベルに達していないと言っても過言ではありません。が、実体験を元に「実用レベルに達していない」と口にしているエンジニアはどれほどいるでしょうか。
SwiftUI が未熟だという周りの声を鵜呑みにして逃げているだけではないですか？ SwiftUI を採用しない理由を明確に説明できることは非常に重要です。なぜなら、 SwiftUI が適している要件にも敏感に反応できるようになるからです。
このトークでは主に以下に関して実例と共に SwiftUI の現状をご紹介いたします。

・SwiftUI 採用の理由
→キーワード：チーム開発, デザイナー
・2回もの大型仕様変更への高速対応を可能にした SwiftUI レイアウトテクニック
→キーワード：Modifier, XcodePreviews
・粘ったけど、UIKit に浮気せざるを得なかった TextField
→キーワード：最小限に抑えた UIKit 利用術
・油断禁物！ SwiftUI 未対応ライブラリ達
→キーワード：Firebase, 計測ツール

このトークにより、SwiftUI をチームで採用するための説得材料を手にすることができます。また、 SwiftUI による開発方針を「チーム」という広い視野で考える“きっかけ”になるでしょう。

ある日フロントエンドエンジニアが、Unityを組み込んだiOSアプリの開発を行う業務が決まりました。そこからSwiftなどを習得し、先輩エンジニアの経験も伺いながら、Unity as a Libary (UaaL)を採用しました。

Unity as a Libraryは、フレームワークとしてUnityをネイティブアプリに組み込むことができる仕組みです。多彩な3D表現を得意とするUnityと、ユーザーフレンドリーで洗練されたUIを実現できるネイティブ実装のいいとこどりができます。

プロダクトとして、デザイン性と実用性が必要とされる中で開発した経験や、iOSアプリ初心者の視点からつまずいたポイントなどを意識して、以下のテーマをお届けします。

• Unity as a Libraryを採用するべき条件
• 巷にある先人方のUnity as a Libraryの実装方法を比較検討した結果
• 実用面とUXを考えて採用した、Unityの組み込み方法
• Unityとネイティブ(Swift)の間のやり取りについての検討と実装
• UnityのBuildで必要な操作を自動化したTip

このトークでは、モバイルアプリにデザインシステムを導入した話をします。

デザインシステムとは、デザインに関する原則やコンポーネントの実装をまとめたもので、有名なものではGoogleのMaterial Designなどがあります。デザインシステムは以下のような目的で作られています。

• ボタンの見た目など画面・サービスごとに違ってユーザーを混乱させない
• 同じような実装をまとめることで、コード量・メンテナンスコストを減らし、生産性を上げる
• 誰が実装しても同じものを作れる
• 統一したUIを提供することで、ブランディングを向上させる

弊社では、4つ以上のアプリを同時に開発しており、iOS・Android・Webのそれぞれのプラットフォームでサービスを展開しています。これまでは、各アプリでそれぞれUIの実装を進めていましたが、共通化できる部分も多くあります。すでにWeb版ではデザインシステムが開発・運用されていますが、どのようにしてアプリでも使えるように整備していったかをお話しします。

内容

• Figmaからのリソース自動書き出し
• Kotlin Multiplatform Mobileを使った共通実装の作成
• SwiftUI / UIKitでの実装
• (Jetpack Composeでの実装)

動画や音声については私自身これまではほとんど触れたことはありませんでしたが、これらを取り扱うサービス開発の中に身を置いた経験を通じて、アプリならでは機能ロジックとUI体験との調和を生み出すための奥深さや工夫の深淵を垣間見ることができた様にも感じました。その一方で、普段私達はiOSアプリを通じて多くの動画や音声に触れていてとても身近な存在ではあるのに、いざ実装しようとすると「あの機能と似たイメージのものを作りたいんだけど、どうすればいいんだろう...?」とその当時に知らなかった故にやきもきしていた経験もしました。

本発表では、

• Apple公式ドキュメントや掲載サンプルから紐解く押さえておきたい基本部分のご紹介
• 動画の再生や停止といった基本的なプレイヤーとしての操作実装や画面レイアウトに関する解説
• アプリがバックグラウンドに移行した際にも連続して音のみの再生へ移行する機能
• 他のアプリを利用しながら動画再生をするPicture in Pictureの機能と実装に関する部分
• 普段使い慣れている動画再生アプリ等でよくお目にかかる機能や振る舞いを実現する際のヒント
• 動画再生プレイヤーアプリに付随するUI実装や表現に関する説明

について、簡単ではありますがご紹介と解説ができればと考えております。

本発表につきましては「機能を実現するための実装に関するはじめの一歩を踏み出す」ための難易度を想定しておりますが、実際に動作するサンプルコードを用いた検証や試行錯誤を通して感じた実装で押さえておくと役に立った部分や、実務を通して実装した知見等が少しでもお役に立つことができればとても嬉しく思います。

iOSアプリの開発している私たちは日頃CocoaPods, Carthage, SwiftPMなどのいわゆる「Package Manager」にお世話になっています。

Package Managerはソフトウェア開発をする上で欠かせない重要なものです。
しかし、「使い方は知っているが仕組みがどうなっているかはよくわからない・・・」という方も多いのではないでしょうか？

ここでは

• Package Managerとは何か？
• なぜPackage Managerを使うのか？
• iOSにおいてPackage Managerはどう進化してきたのか？
• CocoaPods, Carthage, SwiftPMはそれぞれどのような特徴があるのか？

といった点を整理し、基本的な概念や仕組みを理解していきたいと思います。

一緒にPackage Managerについて学び、より適切に選択・利用できるようになりましょう。

アプリの立ち上げの話はよくあると思いますが、クロージングの話を聞く機会はあまりないかと思います。

昨今サブスクリプション型のアプリも増えてきているなかで、実体験から語られるサービス終了の側面をともに見てみませんか？
実際にアプリのクローズに立ち会い、そこで考慮したこと、終了のフロー、App Store Connect上での操作したこと、その時の思いをまとめていきます。
自分が開発に携わったアプリが終わっていく姿を見たいエンジニアなどいないとは思いますが、いざその時が来たとき、正しい方法でスムーズに対応できるよう、知見を共有したいと思います。

従来、金融や通信サービスの契約における本人確認では、実店舗に行ったり、身分証の写しを送付するなどの煩雑な手続きが必要でした。それらの対面や郵送での本人確認に代わり、オンラインで完結する本人確認が身近な存在になってきています。すでに何らかのサービスで実際に体験された方も多いのではないでしょうか。

「eKYC」と呼ばれるオンライン形式での本人確認では、複数のベンダーさんが高い品質のSDKを提供しています。しかし、僕らはアプリ内でのより統一されたユーザー体験を実現するために自前での構築を選びました。

このセッションではiOSアプリでのeKYCの実装において得られた知見をお話しします。身分証や顔写真の撮影におけるVision.framework / ML Kitの活用など、体験を向上させるための技術面での工夫やTipsも紹介していく予定です。

【内容（予定）】

・eKYCの簡単な概要（社会的背景や従来の本人確認の課題）
・B/43での本人確認フローについての前提
・シームレスなユーザー体験を実現するためのプロダクト設計
・iOSアプリでのeKYCの実装における技術面での工夫
・自前で構築したeKYCを運用して得られた効果と今後の課題

Swiftではコードの自動生成ツールでボイラープレートを避けるということがよく行われます。
そして方法には様々ありますがXcode上で実行する場合は多くがファイル作成もしくはビルド時にコード生成をします。

しかし、ユースケースによっては実装中のコードからそれに対応するコード生成を行いたいこともあるでしょう。
例えばリファクタリングのためにProtocolで依存を切り出したり、Mockクラスを作る場合などがそれにあたります。

ここではSource Editor ExtensionとSwiftSyntaxを組み合わせたコード生成ツールの開発方法について解説します。
それらを組み合わせると、実装しながら同時にXcode上でコード生成を行うツールが比較的リーズナブルに開発可能です。

また、その方法によって実際に開発したリファクタリングツールを例として紹介します。
皆さんが開発環境改善をしたいと思ったときに検討する手法の一つになるよう話ができればと思います。

私たちのチームは今年の6月に新規レジアプリ「STORES レジ」をリリースしました。
世の中でお会計の際に使われているレジですが、レジの機能をアプリで置き換えるためには様々な周辺機器との連携が必要でした。

例えばSTORES レジではこんなハードウェアに対応しました。

• レシートプリンター
• バーコードリーダー
• キャッシュドロアー
• クレジットカード / 電子マネー決済端末

このトークでは具体的な対応内容や苦労した点、ハードウェア対応の全体像などをご紹介させていただきます。

コンテンツ

• ハードウェア対応の概要
• CoreBluetooth Framework の使い方と具体的な実装例、ハマったところ
• External Accessory Framework の使い方と具体的な実装例、ハマったところ
• MFi登録申請の概要と流れ、弊社での具体的な対応例
• ハードウェア対応で苦労したこと

ハードウェア対応？そんな仕事しないし...と思っているそこのあなた！
いつかあなたのプロジェクトにもハードウェア対応が必要になるかもしれません！
そんな時に役に立つTipsをお話しします！

Network Extensionはあまり使い方が知られていないフレームワークです。
Wi-Fiの設定変更、コンテンツフィルタ、VPNの構成あるいは実装といったiOSのネットワーク機能を拡張するAPIを提供します。

iOSデバイスでパケットキャプチャをする方法は主にCharles ProxyなどのWeb Proxyを利用したツールを使う、仮想ネットワークインターフェースを監視する、Charles for iOSなどのデバイス上でVPNクライアントとして動くツールを使うという３種類があります。

デバイス上で動作するパケットキャプチャを実装するにはNetwork Extensionを使ってVPNクライアントを実装しますが、もともと情報の少ないこのフレームワークの中でもVPNクライアントの実装方法はほとんど情報がありません。
ソフトウェアの性質上、プライバシーの観点からVPNサーバも同じアプリにローカルサーバとして実装することが望ましいですが、そのような例はまず見つからないでしょう。

そこでiOSデバイス上で動くVPNクライアントおよびサーバを実装しパケットキャプチャを行うアプリを実際に作り、パケットキャプチャの方法を説明します。
Web Proxyを使う方法では不可能なUDPパケットのキャプチャができるのでゲームなど主にUDPが使われるアプリの解析もできるのが便利です。
また自分でパケットキャプチャが書けるということは、特定のパケットに対して任意の処理を実行することができるということです。つまり他のアプリの通信内容と連携するツールを作れます。

今回は応用例として、作成したアプリを用いてあるオンライン対戦ゲームの通信を実際に解析し、普通では見えないゲームの状態や他プレイヤーの行動をリアルタイムに監視・追跡するツールを作ってお見せします。

iOSアプリ実装中、「単語の途中で改
行されてしまう…」といった経験はありませんか？
そういったとき、英語の文章であればlineBreakModeに.byWordWrappingを指定してあげれば単語中の改行は起きなくなりますが、日本語の場合は効果がありません。

このセッションでは日本語の文章でも単語中の改行をさせない方法を解説します。

• NSLineBreakModeについて
• 日本語の扱い
• 制御文字について
• どう単語を検出するか？
• MeCabによる形態素解析
• MeCab for Swift Package

開発規模の大きなアプリは、得てしてビルド時間が長くなってしまいがちです。 ビルド時間を改善する手法の1つとして、アプリを複数のモジュールで構成することで部分ビルドを可能にする「マルチモジュール化」を進めているプロジェクトも増えています。

一口にマルチモジュール化といっても様々な分離の仕方がありますが、1機能に関連するいくつかの画面を1つのモジュールとして切り出すことで、その分けられた機能毎に単体ビルドが可能になります。 このモジュールを単体でアプリケーションとして利用できるようにしたのが、開発時の動作確認用のミニアプリです。

これにより、開発途中の画面を確認するのにアプリ全体をビルドする必要がなくなり、動作確認の効率が大いに改善されました。
本セッションでは、このミニアプリの構築にまつわる以下のようなトピックについてお話します。

・単体起動可能なモジュール構成とは
・ミニアプリそのものの仕組みと導入のメリット
・チーム全体で利用してもらうための工夫
・より使いやすい仕組みを目指した諸改善

このトークを聞いて、あなたのプロジェクトでもプレビューサイクルを爆速に改善してみませんか？

みなさんがApp StoreでiOSアプリを探す際には必ずスクリーンショットを見てUIの良し悪しやアプリの機能などのイメージを掴んでからアプリをダウンロードするのではないでしょうか。App StoreのスクリーンショットはiOSアプリを運営していく上で重要な要素です。アプリの対応言語が1言語の場合は、デザイナーが1から丁寧にデザインして仕上げてくれたものを利用することも多いかと思いますが、これが言語の数や対応画面サイズが増えていくと、その必要数が爆発的に増え、対応コストが跳ね上がることになり人手での定期的な更新は難しくなります。

既知の解決策としてfastlaneというツールのsnapshotとframeitを利用することで、ある程度決まった定番のデザインでこのスクリーンショットを自動生成することが出来るのですが、とある理由から私が業務で開発しているアプリ（20カ国・言語以上のApp Storeのローカライズ対応済み）では採用出来ませんでした。それはframeitではRTL(Right-To-Left)言語であるアラビア語などが対応していなかったことや言語毎のフォントの準備やサイズの調整が難しかっためです。

この発表ではApp Store向けのスクリーンショットを多言語化して運用していく上での課題となる点を触れ、snapshotとframeit相当の処理を自前のSwift製のCLI実装する際に得た知見や、SwiftUIを画像のレンダリングエンジンとして活用する利点などについて紹介したい思います。

エンジニアに「状態管理うまくいってますか」という言葉を投げつけるのは、心に深い傷を刻む結果になると一般に知られています。

宣言的UIの流行により、GUIアプリケーションにおける支配者は状態（データ）となり、表示コンポーネントは状態の落とす影に過ぎない存在となりました。これにより「開発者は状態管理だけをうまくやればいい」という仕組みが出来上がるのですが、我々は次の現実に直面することになります。そもそも状態管理をうまくできない、と。

私がウェブ技術を17年間触れてきた中で、状態管理というのは最も難しい技術に分類されると感じています。そしてウェブ技術をベースにしているReact Nativeではその問題が直撃します。

密結合にすると変更に対して硬直化する、疎結合にすると流れが把握できなくなる、綺麗にするために状態管理ライブラリを入れたのに逆に散らかってきた、公式サイトに書いてある方法でやっても改善しない、ベストプラクティスを実践しているはずなのに結果が出ない。何も思い通りにならない。チームが技術に振り回されてる気がする。状態管理だけうまくいけば開発はスムーズにいくのに、状態管理ができない！

実際に状態管理の設計に取り組むと「管理と言いつつもほとんどの状態は管理できない場所にある」ことに気づきます。HTTP通信、デバイスのセンサ、回線の状況。つまり状態管理というのは、根本的に管理できないものを管理する技術でもあります。

このトークでは、そもそも状態とは何なのかという基本的なところから、状態をいかにコントロールして、アンコントローラブルな状態に対してどう立ち向かえばいいのかという実践的なところまで、私が今まで開発に携わってきたtoBのシステムや音声ライブサービスなどから得られた経験をもとに知見を共有したいと思います。

【注目】
せっかくスポンサーセッション枠をいただいたので、iOSエンジニアの視点から見る弊社((株)ゆめみ)についてのご紹介をさせていただきます。
聞いていただいた方には是非、ご自身の会社や働き方と比較していただき、「あっ、ウチって意外と普通だったんだなぁ」「ウチよりもやばい会社あるやん！？」と安心していただければ幸いです。合わせて、余裕があれば(株)ゆめみについても知っていただければもっと幸いです。

【概要】
主に会社紹介となります。技術的なことはあまりお話しせず、エンジニアの観点から会社の制度・仕組み・体制等についてお話しさせていただきます。エンジニアをやる上で技術的なスキルを身につけ、向上していくことはもちろんのことですが、それ以前に働く環境や考えなければいけない様々なこともあると思われます。会社に属している方なら尚更です。なので、ここiOSDCというディープなiOSについてのお話ができる場であえて技術の話をあまりせず、「成長できる会社NO.1」を目指す会社のエンジニアがどんな働き方をしているか、どんなことをしないといけないか、どんなことができるか、などを弊社の紹介という形でお話しさせていただければと思います。

【終末】
予定では合成音声を用いた動画の公開となっておりますが、もし当日人間が話し始めたら、それは動画編集が間に合わなかったということです。