トーク

みなさんiPhoneのセンサで取得できる位置情報と聞いて何を思い浮かべますか？
おそらくCore Location Frameworkを使った緯度経度情報を思い浮かべる方が多いのではないでしょうか。
ロボット開発の観点では自己位置推定と呼ばれるLiDAR,カメラ,加速度センサなどを組み合わせることによってロボットの位置を推定する技術が日々研究されています。
本トークでは位置情報を得るという目的のためにiPhoneのセンサを使って検証した結果を

• どのようなセンサを使う方法があるか
• 取得できる位置情報の精度

について紹介します。

タクシー配車アプリ「GO」では、UIKit ベースで実装しており、ViewController の数は300近くあります。
2019年の WWDC で発表された SwiftUI の機能を徐々に活用していき、2021年に iOS 12 のサポートを終了したタイミングでプロダクションに SwiftUI で作った画面を展開していきました。
本トークでは、大規模なプロジェクトにおいて、どのように SwiftUI を導入し活用しているかをご紹介します。

・SwiftUI の導入
・UIKit ベースのプロジェクトでの SwiftUI 利用
・Xcode Previews の活用
・SwiftUI 利用したことで得られたメリット
・ここが辛いよ SwiftUI
・SwiftUI 利用のこれから

本トークでは、既存サブスクリプション商品にアップグレード・ダウングレードを追加する方法についてご説明します。

具体的には、

アップグレード・ダウングレード・クロスグレードについて

• サブスクリプショングループとは
• レベルの設定
• レシートはどうなるのか

上記を公式ドキュメントを織り交ぜながらご説明します

運用しているサブスクリプションにアップグレード・ダウングレードを追加するには

• 新規商品を申請するために注意すべき箇所は何か
• SandBoxで検証する際のtips
• SandBoxで確認できない範囲の検証結果

導入しづらい運用ケースとは

• 複数のサブスクリプショングループを運用している場合
• クレジットや他プラットフォームでの決済手段がある場合

を予定しております。

本トークでは、iOS・Android両OSで展開しているアプリ向けに、KMMを用いたテキストリリース共通化を提案します

まずはじめに、長年運用しているアプリだからこその課題を交えながらモチベーションについてご説明します。その後、比較検討した手法と想定している移行手順についてご説明します。そして最後に、+aの要素や今後の展望についてご説明します。

課題の抜粋

• OS間で新規追加する粒度が異なる
• OS間で参照する既存リソースにズレがある
• 片方だけ修正されるテキスト

+aの例

• ボイスアンドトーンの統一
• テキストリソースのルール設定
• textlintによる校閲
• a11y

を予定しております。

フチ文字とは、文字の輪郭を線で縁取る文字装飾の手法です。
新聞の見出し、スーパーのチラシ、そして動画のテロップなどでよく用いられています。
みなさんも一度は目にしたことがあるかと思います。

そんなフチ文字、さらにグラフィックソフトで作成したようなフチ文字をアプリ内で使いたい。
そうデザイナーから相談されたとき、どんな方法が思いつきますか。
AttributedStringを用いて文字の輪郭に線をつければ解決、そう思いませんか。
しかし、この方法にはある問題があり…。

本トークでは、私が試行錯誤しながら、より質が高く美しいフチ文字を模索した内容を事例を交えながらお話します。

以下の内容を予定しています。
・フチ文字とはなにか
・発表者の思う美しいフチ文字、美しくないフチ文字の定義
・UIKitを用いたフチ文字の実現方法
・SwiftUIを用いたフチ文字の実現方法

現在swift-evolutionでは大量のproposalと共に長年Swift上で不便だった正規表現関連の実装を刷新する流れが続いています。実際にWWDC 22でもSwift 5.7のリリースとともにRegexBuilderと正規表現リテラルが導入されることが発表されています。

このトークではNSRegularExpressionやNSStringにおける課題がどのように解決されているかをswift-evolutionの各proposalをもとに振り返り、iOSやサーバーサイドでのアプリケーションや文字列処理が生きてくる書き捨てのスクリプト（例えばログ解析など）でどれぐらい実用的に利用できるのかをベンチマーク結果を添えて検証していきます。

特に普段Rubyなどで書くことが多い書き捨てスクリプトを置き換えるポテンシャルがあるのかどうかに個人的に興味があります！！いかに！？

WWDC21 が開催されていた昨年の6月、AVKit に追加されたひとつの機能に社内がざわつきました。
PiP（ピクチャ・イン・ピクチャ）の機能を応用して、Android の画面オーバーレイのようにアプリ外に自由なコンテンツを描画できる期待感を経験のあるエンジニアは感じていましたが、既存のアプリに機能を組み込むまでには R&D 的な開発やパフォーマンスとの戦いがありました。

このトークでは、ゲーム配信アプリミラティブに実装され多くのユーザーに利用されている、視聴者からのコメントや各種配信情報をアプリ外で表示する「配信コメントバー」機能の開発の裏側と技術の詳細についてご紹介します。

・「配信コメントバー」機能の概要
・実装の解説
・R&D 開発とパフォーマンスの解決
・PiP と AVAudioSession との関係
・PiP のカスタマイズ性

Swift ConcurrencyはWWDC2021で発表されてSwift5.5で追加された新しい技術であり、まだ名前しか聞いたことないよという人もいるかもしれません。Swift Concurrencyは非同期処理や並列処理をシンプルに書くことができる機能です。

本トークではではSwift Concurrencyとは一体何か、どんな利点があるかをSwiftUIを使った実装例を通して紹介します。
この話を聞くと、もうクロージャを使った非同期処理なんて書きたくない！って思えるかも笑

株式会社ゆめみでは新卒iOSエンジニア向けに研修課題をGitHubで公開しています。
弊社の新卒課題は一見すると簡単ですぐに終わってしまうように見えますが、ところどころにハマりやすい罠があります。
　・ライフサイクル
　・Delegate
　・コールバック
　・スレッドブロック
　・テスト
などなど、ハマりやすい要素がたくさんあります。

ゆめみの新卒として研修を経験した私だからこそ感じた初学者がハマりやすい罠をご紹介します。

参考：https://github.com/yumemi-inc/ios-training

UIデザインツールというとFigmaとSketch二択になってきましたが、アイコンデザインなどビジュアルデザインに近い部分を除いたら、意外とSwiftUIでデザインできちゃいます。SwiftUIだと静的デザインをそのまま実装に組み込めるメリットがあり、開発効率向上にもつながります。

本トークでは、Figmaと比較してSwiftUIがどれぐらい便利かつ直感にレイアウト組めるかをご紹介します。
SwiftUIでデザインしてみませんか？

デザインをいただいて、実装しようとすると以下のように戸惑うことはありませんか。

• 部品のまとめ方
  • 新規部品
  • 既存部品のバリアント
• サイズの決め方
  • 固定サイズ
  • 余白を決める上で決める
• 1行に表示しきれない文言
  • 改行
  • 3点リーダー
  • 1行に表示しきれるように文字サイズを動的に調整
• 複数部品の揃え方
• スクロール領域
• アニメーション

デザインツールの機能不足により妥協したデザイン表現になり、直接デザイナさんにどういうデザインにしたいかを聞いて実装する場合もあると思います。しかし、デザインツールの進化により表現できるデザインが年々増えてきており、困るケースも少なくなってきました。

本トークでは、FigmaにおいてiOSエンジニア目線で、表現できるケースと表現できないケースをご紹介します。

さまざまな場面でローディングインジケータなどを使い、ユーザを待たせていると思います。
しかし、それが果たして必須な要件かというとそうではなく、実装時のコストの兼ね合いで妥協している場合が多いと思います。

本トークでは、ユーザを待たせずに済むよりよい手法とそれを実現する実装方法の具体例をご紹介します。

売上を最大化させるためのレジの台数といった合理的な意思決定の方法を考える学問である「オペレーションズ・リサーチ」において、数式で求めた結果が合っているのかを確かめるのは難しいものです。しかし、SceneKitで現実世界を再現することで結果の”検証”を行うことができます。SceneKitによる新しい数学の学習方法を複数の具体例とともに紹介します。

ある日、あなたはプロダクトマネージャーから「API から統計情報を提供するから、アプリでグラフを描いてくれない？」と言われたら、どうしますか？

新規アプリであれば、 WWDC 2022 で紹介される Swift Charts を Swift UI を用いて、実装すれば、 Apple から提供されるフレームワークですし、サポートされているすべての OS で適切に描画できそうです。でも、 Swift UI を導入できていない既存アプリだったら、どうしますか？

本トークでは WWDC 2022 で紹介される Swift Charts でグラフを描いた場合と Swift Charts が無かった場合のベストプラクティスを探求し、比較をします。
※ Swift Charts が開発者に提供されなかった場合は WWDC 2022 での発表内容を元に比較を行います。

アプリの効果測定にはインプレッションの集計は有効な手段の一つです。しかし、より正確な測定結果を得るために単純に「1ptでも表示したらインプレッション発生」という訳でもなく、ユーザーに視認されることが可能と言えるインプレッションといった厳密な視認可能インプレッションの定義が必要かもしれません。
本トークではZOZOTOWNのホーム画面で対応できた独自の視認可能インプレッションの話を紹介します。
「面積のx%以上がy秒間表示し続けるとインプレッションの成立とする」、「インプレッション再記録の条件は◯にする」などインプレッションの設計から、CompositionalLayoutで対応されたホーム画面でそれを実現した際の裏話を大公開します！
・視認可能インプレッションの設計
・CompositionalLayoutでのreusableViewとcellの面積計算の問題
・パフォーマンス面の考慮

ARKitが持つ多くの機能の中でも、みなさんはフロントカメラとバックカメラを同時に使用することによるフェイストラッキングとワールドトラッキングの並走機能をご存知でしょうか？実はこの機能、Human Computer Interaction（HCI）の研究者たちの注目を集めたアツい機能なんです。この機能により、視線を向けるだけで目の前のコーヒーメーカーがコーヒーを淹れてくれるような、これまでにスマートフォン1台ではできなかった体験を実現することが可能となりました。
本トークでは、この並走機能に新たな可能性を感じた私が実際に作ったいくつかのサンプルアプリの紹介やそこで得られた知見の共有をします。

・視線を向けるだけで電気を点けたり、コーヒーを淹れられるアプリ
・目からビームを発してヴィランをやっつけるアプリ
・ユーザが暗い表情をしていると、辺りに花が咲きほこるアプリ

巷では正しい設計、正しい実装、正しいアーキテクチャなど……強迫観念に近い「正しさ」を求めるがあまり、プロジェクトの後半になってなぜ私たちは1つの機能を作るのにこんなにもコードを書かなければいけないんだ…… このコンポーネントは本当に必要なのかと疑問に思いながらも、みんな現実から目を背け、迫りくるスケジュールに怯えながら無心にコードを書き続けていることも多いでしょう……

そこで私が数々のプロジェクトで遭遇した、ほんとにあったオーバーエンジニアリングをご紹介しましょう……

1. そのDIって必要！？
2. 無駄なprotocol定義
3. バケツリレーするだけのコンポーネントたち
4. なんでもリアクティブ
5. MVCで十分じゃね

• なぜ人はオーバーエンジニアリングをしてしまうのか、その傾向と対策

UITest書いてますか？
書いた方がいいとは分かってはいますが、

• SwiftコードでUIテストの実装は大変だよね…
• メンテコストもかかるよね…
• 開発スピードが落ちるよね…

などなど…様々な理由でなかなか導入に踏み込めないプロジェクトが多いと思います。

そこで、GUI操作のみでUITestを構築できるMagicPodとAutifyの実例を交えながら、ノンコードで実装するE2Eテストをご紹介します！

• E2Eテストは何をテストするべきなのか
• メンテナンス性が高いUIテストとは
• テストは誰が書くべきか
• MagicPodとAutifyの違い
• CIの記述方法

iOS開発では便利な周辺ツールが充実してきて、以前はCococaPods、Carthageくらいでしたが最近はSwiftLint、XcodeGen、SwiftGenなどを採用するケースが増えてきました。
これらはHomebrewやRubyのBundlerでインストールすることが多いと思いますが、チーム開発になるとツールのバージョンを合わせたり、Apple SiliconとIntelの両環境に対応する必要があり、環境構築自体が複雑化してきました。

そこで、これらの環境構築にまつわる様々な問題点を解決するために、環境依存に振り回されることなく確実に環境構築を行う手法をご紹介します！

• 脱！環境構築の手順書
• 脱！Homebrew
• 脱！Ruby

参考: https://zenn.dev/yusuga/articles/dc0597ea7c0b97e397af をさらに発展させる形

タイミーでは、全ての職能を1チームにまとめた職能横断型チームとしてプロダクト開発に取り組んでいます。
職能横断型チームに属する開発者は1つの専門領域に特化しながらも、他の領域も広く理解していくことが重要だとされています。
しかし、過去に職能別にチームを分けていた名残が強くあり、依然としてiOSのタスクはiOSエンジニアしか担当できない状況が続いていました。
それを打開するために、iOSのプロジェクト構成を見直しました。SwiftPMをプロジェクトの中心に据えることで環境構築のコストを限りなくゼロにしたり、他の領域でも使われつつある宣言型UIであるSwiftUIを導入することで、iOS開発へのハードルを下げてきました。結果、iOS専門外の開発者もPRを投げてくれる状況になりました。

タイミーでの事例を踏まえ、職能横断型組織へのシフトと、それに追従したiOSプロジェクトの変遷をお話しします。