始めまして！！クラシルリワードでiOSエンジニアをしているkaikaiと申します！
今回は、業務の時間を使って、8/23、8/24に開催された iOSDC 2024に 弊社のiOSエンジニア複数人でオフラインで参加してきました！(delyでは必要に応じて平日開催されるイベントへの参加もできます！)
今年の開催でも多くのセッションがあり、クラシルリワードのこれからの開発に役立ちそうなもの、もっとより良いものを作っていくために大事な学びがあったので、参加レポートという形でシェアできればと思います！
- セッション
- Day0
- Day1
- Day2
- さいごに
セッション
ここからは、参加した各セッションについての内容は、参加メンバーの感想を書いていきます！
※ 以下、使用している画像は登壇者様の登壇資料より引用させて頂いています。
Day0
StoreKit 2によるモダンなアプリ内課金
登壇者 ：蔀さん
資料 ：StoreKit 2によるモダンなアプリ内課金 - Speaker Deck
概要
このセッションではAppStoreの課金から StoreKit V1, V2 の違いまでiOSアプリで課金を行うためにはどういったルール・方法があるのか知ることができました。特に外部決済でも手数料がかかることや、StoreKit2を導入する際の失敗談について言及されている点がとても良く、弊社でも移行時には参考にさせていただきたいと思いました！
ポイント
Appleは最近EUでの流れもあり外部決済が許可されつつあります。
しかし外部決済を利用する場合でも27%の手数料がかかることはキャッチアップが遅れていたこともあり非常に驚きでした（実際は売上の27％に加えてクレカ決済手数料の3−7％が上乗せされる）
しかしAppStore自体の決済方法を利用するメリットも存在しており（OSレベルでの課金リクエスト対応、容易な返金リクエスト処理）まだまだ争いは収まりそうになりです。
そんな問題あるなかAppleはiOS15以上向けにStoreKit2と関連するサーバ向け機能を提供開始し、WWDC24ではStoreKit1の廃止が宣言されました。
StoreKit2はKit1に比べて以下の点が改善されました。
- 設計が分かりやすくなった
- Swift Concurrency ベースで実装可能
- レシート検証が簡略化
- ニアリアルタイムにユーザの課金状態を監視可能
また、StoreKit2では初回のみ課金アイテムの登録時に審査が必要かつ、アプリのアップデート（と審査）が必要というトリッキーな仕様が入っているようです。
失敗談として、課金アイテムは削除したら対象のIDはアカウント単位で利用することができなくなる点、課金アイテムの追加時に審査がありリジェクトになった話が紹介されていました。
以前に比べてテストも書きやすくなっており、検証などもやりやすくなったため新たに実装する際はStoreKit2を利用したいと思いました！（StoreKit1からv2へ移行するモチベーションは今のところ deprecated になったことだけで、提供されるサービスに変更はないとのこと）
by uetyo
新OSの機能を古いOSにバックポートする
登壇者 ：Mike Apurinさん
資料 ：https://speakerdeck.com/auramagi/iosdc-2024
概要
このセッションではビルド方法の違い（StaticLink, DynamicLink）とライブラリの提供方法、具体的にバックポートをする方法について紹介されました。中でもバックポートできるものとできないものの違いが分かりやすく、クラシルのアプリでも知らず知らずのうちにバックポートされたAPIを利用していたんだと気がつくことができました！
ポイント
著名なところだと TCA の PointFree が Observation をバックポートして話題になっていましたが、本来新しいOSでしか利用できない機能を古いOSでも利用できるにする技術がバックポートです。
いくつか方法があり、純正機能のバックポートやマクロを用いたもの、OSS（PointFreeのObservationとか）があります。
純正バックポートとしては iOS18でリリースした gestrue@backDeploied キーワードをつけることで実現できたりするようです。
@backDeployed to extend function availability to older OS releases
https://www.avanderlee.com/swift/backdeployed-function-back-deployment/
バックポートできる基準は古いOSでもAPIが隠されているか、古いOSの機能を用いて実現できる場合のみで、OSに密接なWidgetKit等はできないとのことでした。
クラシルリワードは長くOSサポートを行わない（直近2年以内、新しいOSがリリースされて半年ほどで以前のバージョンをサポート解除）ためバックポートを行うメリット自体は少ないかもしれませんが、Swift/iOSエンジニアとして非常に興味深いセッションでした
by uetyo
Day1
StoreKit 2によるモダンなアプリ内課金
登壇者 ：Ookaさん
資料 ：Dropbox - 20240823_iosdc_binary_analysis.pdf - Simplify your life
概要
このセッションでは、SDKにarm64（シミュレーター）向けのバイナリがなく、Apple SiliconのMacでシミュレーターをビルドできない場合の対処法を紹介されていました。
ポイント
SDK導入時に発生する「found architecture 'x86_64', required architecture 'arm64'」というエラーは、x86_64向けのバイナリしかなく、arm64向けのバイナリが必要な場合に表示されます。
SDKがどのアーキテクチャ向けのバイナリを持っているかは、.aファイルで確認可能です。
解決方法の手順：
バイナリ解析で違いを発見 otoolを使用して、端末用とシミュレーター用のバイナリの違いを調査。
MashOを使用してバイナリを修正 見つけた差分を基に、MashOというSwiftのツールを使って、実機用のarm64バイナリをシミュレーター用に修正。
動作確認 修正後、シミュレーターで正常に動作することを確認！
感想
このセッションを通じて、普段あまり意識しない.oファイルと.aファイルの関連性や、バイナリ解析の有用性について学ぶことができました！
今後、同様のエラーが発生した際には、こんな方法もあるんだということを念頭に置いて対処できればと思います！
by kaikai
複雑さに立ち向かうためのソフトウェア開発入門
登壇者 ：shizさん
資料 ：https://speakerdeck.com/auramagi/iosdc-2024
概要
このセッションでは、エンジニアが向き合っている複雑さの正体を「認知負荷」や「認知リソース」を焦点にしながら掘り下げ、複雑さに直面しているときの問題点を整理した上で、どのように対策するかについて紹介されていました。
ポイント
すごく勉強になるお話しが多く、具体例もあり状況を想像しやすかったです。
その中でも個人的に大事だと思ったポイントは以下です。
複雑さの正体は、「認知負荷」が「認知リソース」または「ワーキングメモリの容量」を上回っている状態であるということです。
「認知リソース」は集中力や注意力のような、脳が情報を処理するためのエネルギーであり、ワーキングメモリは脳が一時的に情報を保持し操作する能力と紹介されていました。 これを1つのタスクを遂行するために必要な認知リソース、つまり「認知負荷」が上回ると人は複雑さを感じるようになるというものでした。
人が複雑さに直面している状況においては、つまらないミスを繰り返したり、忘れっぽくなったり、学んだことが身につかない、といった問題点があるため、如何にそのような状況を避けるかについても紹介されていました。
それが、「わける」、「だす」、「たよる」です。
ワーキングメモリの容量の限界を超えないように、向き合うタスクのボリュームを「わける」ことによって小さくしたり、メモなどに情報を「だす」ことによってワーキングメモリの容量を空けることができます。 また、チームに「たよる」ことで負荷を分散することができるというものでした。
まとめ
弊社iOSチームでは、PRを小さな粒度（目安100行前後）で作る開発文化がありますが、これはまさにレビュアー・レビュイー双方にとって認知負荷を下げることで、レビューサイクルを高速化するための効果的な運用であることに改めて気づきました。
そして、認知負荷が高い状態ではワーキングメモリから長期記憶に定着させる工程がうまく働かず、学んだことが身につかないという状況に陥ることは真剣に向き合わなければいけない問題だと思いました。
弊社には開発スピードを重要視したカルチャーもあるため、やることが多いという状況は簡単に生まれます。 このセッションで紹介されていた「わける」、「だす」、「たよる」という対策を、うまく仕組みとして落とし込み、エンジニアが学び成長できる組織にしていきたいと思いました。
座談会 「Strict ConcurrencyとSwift 6が開く新時代: 私たちはどう生きるか？」
登壇者 ：
shizさん
kntkさん
koherさん
omochimetaruさん
まつじさん
概要
このセッションは、iOSエンジニア5人でSwift 6で導入されるStrict Concurrencyとどのように向き合うかについて、土台となるSwift Concurrencyの理解から、Complete Strict Concurrencyへの移行戦略など様々な切り口で話し合うというものでした。
ポイント
どのトピックも非常に示唆に富むものが多かったですが、中でも個人的に勉強になった部分を整理してみます。
これは必ず抑えておくべきことの一つで、Swift Concurrencyはデータ競合（data race）を防止してくれるもので、競合状態（race condition）を防止してくれるものではないということです。
データ競合（data race）は、複数のスレッド間で共有しているデータに対して、同時に読み書きが発生した際に、その結果が全く予想がつかなくなる事象を指します（読み込みだけの場合はデータ競合にはならない）。
対して競合状態（race condition）とは、各スレッド上で行われる操作の実行順序に依存して、その結果が変わってしまう事象を指します。
Swift ConcurrencyのActorを使うとデータを特定の領域に隔離することができ、その領域内で複数スレッドからデータに同時アクセスできないようにすることでデータ競合を防止しています。
データがそのような領域（隔離ドメイン）を超えられる条件が上記であり、基本的にはSendableに準拠して対応すれば良いという紹介がされていました。
また、今後データ競合を防止する際は、基本的にはスレッドをブロックしないActorを使い、どうしても同期アクセスしたいケースにおいてMutexやAtomicなどを使いましょうと紹介されていました。
iOSアプリにおけるSwift Concurrencyとの向き合い方についても話されており、iOSのようなGUIアプリの場合は基本的に隔離ドメインを超えるシーンは一部のModel内のロジックに限定されるだろうと紹介されていました。
弊社クラシルリワードのiOSアプリでも実際上図のようにMainActorを使用しているため、余計に難しく考えるのではなくViewModelとModel間のデータ送信において、隔離ドメインを超えるものなのか、MainActorに隔離できないものなのかを着目できていれば基本的には良さそうです。
また、Swift6ではそもそもデータ競合リスクがあるコードの場合はコンパイルエラーになり、データ競合が作り込まれることは無いため、とりあえずActorにしておくというような考え方も不要になります。
余談ですが、fps60だとすると1/60秒で処理を全て終えることができればUIを固めないのだから、そのなかで終わる処理はMainActorで良いという話もされており、これは確かになと思いました。
まとめ
実は弊社クラシルリワードのiOSチームでは、すでにSwift6への移行を計画的に推進しています。
当然その中にはComplete Strict Concurrencyへの移行も含まれているのですが、我々の工夫として独自のSwift Concurrency Guideというものを作りながらこれを進めています。
このセッションでも最初に認識合わせや理解の確認から入ったように、Swift Concurrencyへの理解度はチームメンバーによってバラつきがある状態なので、基本的な理解や考え方から実際にプロジェクトで使用する際のプラクティスまでをまとめた一つのガイドとして構築しています。
このガイドはまだまだ作成途中で、上記でポイントとして挙げた点は聞いていて絶対ガイドに盛り込もうと思いました。 そして、このガイドも使いながらチームで勉強会を行い、チームとして向き合える体制を作ってComplete Strict Concurrencyへの移行を完遂させていこうと思います。
複雑さに立ち向かうためのソフトウェア開発入門
登壇者 ：小森英明さん
資料 ：https://speakerdeck.com/techtver/20240826-iosdc-japan-2024
概要
このセッションでは、アプリダウンロード総数7,500万あるサービスのiOSアプリについて、現状のアーキテクチャが抱えている問題を整理した上で、如何に安全にリアーキテクチャを進めていくかについて紹介されていました。
ポイント
安全にリアーキテクチャを進めていくためのナレッジが詰まった発表で、非常に参考になるトピックを多く含んでいました。 個人的に特に大事だと思う部分を紹介してみます。
それが「マルチモジュール構成＋モジュールごとのアップデート」です。
リアーキ後の一括リリースはどれだけテストしていても怖いですよね。 なので、マルチモジュール構成にしてモジュール単位でリアーキを推進していき、リアーキできたモジュールからリリースしていこうという戦略です。 このように進めることで、影響範囲を抑えながら段階的にリアーキを進めることができます。
さらに工夫として、リアーキモジュールのFeature Flagを用いた段階的な開放が紹介されていました。 リアーキしたモジュールをいきなり100%のユーザに公開するのではなく、クラッシュ発生率や問い合わせ件数などをモニタリングしながら、段階的に開放率を上げていくというものです。 このような工夫は、特にクリティカルな機能などを含むモジュールの公開においては、より安全に進めていくことができ非常に効果的だと思いました。
まとめ
数年前にかなり大規模なモバイルアプリのフルリプレイスを経験したことがありますが、そのときは1年くらいかけてリプレイスを実装しきり、一括リリースするという進め方を採用していました。
テストはその時考えられていた十分なレベルで行っていましたが、結果的には障害が群発しその対応に追われたのは苦い経験でした。
このセッションで紹介されている内容は、上記のような事態を効果的に防止することができると思います。 また、モジュールごとの段階的なリアーキは、プロダクトの施策と同時並行で開発を進めていくこともでき、施策を止めないという意味でもメリットが大きいです。
そもそもマルチモジュール構成になっていないプロジェクトの場合、進め方にはもうひと工夫必要だと思いますが、今後リアーキする機会があればぜひ取り入れていきたいと思います。
実は弊社が提供するクラシルも数年前にリアーキテクチャを行っているので、気になる方はチェックしてみてください。
Guide to "kurashiru android" app architecture vol.1 概要編 - dely Tech Blog
なぜ MVVM + FRP は Elm Architecture に勝てないのか - dely Tech Blog
Mergeable Libraryで高速なアプリ起動を実現しよう！
登壇者 ：giginetさん
資料 ：https://speakerdeck.com/giginet/2024-08-23-mergeable-library
概要
このセッションでは、iOSアプリのStatic FrameworkとDynamic Frameworkについて、それらのリンクの実行タイミングの違いをおさらいしつつ、それぞれのメリデメを整理した上でその良いとこ取りを実現できるMergeable Libraryについて実際のパフォーマンス改善効果と合わせて紹介されていました。
ポイント
Mergeable Libraryの利点を理解するために、大事だと思ったポイントを挙げてみます。
まずはおさらいになりますが、Dynamic FrameworkとStatic Frameworkのライブラリをリンクするタイミングの違いについて紹介されていました。
リンクとは、モジュール化（ライブラリ化）されたプログラムを一つに統合することを指しますが、Dynamic Frameworkはアプリ起動時にそれが行われ、Static Frameworkはビルド時に行われます。 これにより、Dynamic Frameworkはビルド時間が早くなる一方でアプリの起動時間が増加する性質があり、Static Frameworkは逆の性質を持つというものでした。
上記を踏まえて、Mergeable LibraryはDebugビルド時はDynamic Frameworkとして振る舞い、Releaseビルド時はStatic Frameworkとして振る舞うものだと紹介されていました。
まさに良いとこ取りという感じで、これまですべてのモジュールをStatic Frameworkにしていたプロジェクトでは、これを導入することでビルド時間を改善し開発者体験を向上させることができそうですし、逆の場合はアプリの起動時間を改善することができそうです。
スライドでは実際にベンチマークした結果も紹介されていましたので、ぜひご確認ください。
まとめ
弊社のiOSアプリはマルチモジュール構成を採用しており、多数のモジュールで一つのアプリが構成されています。
基本的にそれらはStaticリンクされているので、アプリの起動時間には影響しない一方でビルド時間は長くなってしまいます。
今回紹介されたMergeable Libraryを導入すると、アプリの起動時間はそのままにビルド時間を改善して開発者体験を向上させることができる可能性があり、その導入もそこまで工数がかかるものでは無いため、早速iOSチーム内で検証してみようと思います。
Appleの新しいプライバシー要件対応：ノーコード アプリプラットフォームの実践事例
登壇者 ：Nao-RandDさん
資料 ：https://speakerdeck.com/nao_randd/applenoxin-siipuraibasiyao-jian-dui-ying-nokodoapuri-puratutohuomunoshi-jian-shi-li
概要 去年から今年の春にかけて大変話題となったプライバシーマニフェスト対応の要点、そしてどのような対応を行なったかの解説をされていました。
ポイント
IDFAを利用する通信を行うドメインは、Privacy Tracking Domains に追加する必要があります。 そして、トラッキングを許可していないユーザーがそのドメインを利用した通信を行うと、エラーが発生します。
つまり、、、、 ⚠️同ドメインで、IDFAを必要としていない通信を行なっても、エラーが生じてしまう….
これに対し、yappliさんはトラッキングの許可状態に合わせて、domainを変更することで、トラッキングを許可していないユーザーでも、エラーが発生することがないように回避をしていました。
以前、自分がプライバシーマニフェスト対応したアプリでは、トラッキング機能を利用していなかったため、こんな落とし穴があったのか、、、ととても勉強になりました！
まとめ
プライバシーマニフェスト対応に関する自分の知らなかった対応内容、
そしてノーコードアプリプラットフォーマーとしてのyapliさんならではの対応をされており、
手法を知ることができて大変勉強になりました。
by kaikai
楽しく簡単に！QRコードの読み取り機能を実装しよう
登壇者：ぺんぎんさんさん
資料 ：https://speakerdeck.com/penguinsan_pg/le-sikujian-dan-ni-qrkodonodu-miqu-riji-neng-woshi-zhuang-siyou
概要
以前までのAVFoundationを使用していたQRコード読み取り機能を、
新たに誕生したAPI、VisionKitを利用して快適に開発した内容を解説していただきました。
ポイント
VisionKitが登場するまでは、AVCaptureDevice、AVCaptureDeviceInput、AVCaptureConnection。。。。。。など、多くのクラスを巻き込んで実装する必要がありました。
VisionKitのDataScannerViewControllerの登場によって、AVFoundationを使うよりとても少ないコードかつ、高品質なQR読み取りを実行することができるようになったとのことです！
実際に、ソースコードも映していただきましたが、目に見えてコード量が削減されていました。 （半分以下に….!!）
また、QRコード読み取り以外にも、バーコード読み取りなどにも利用できるそうです。
⚠️注意点として、2018年以降のNeuralEngineを搭載したiOS16以上の端末しか動作しないので、サポートOSは注意する必要がありそうでした！
まとめ
発表内容の学びも深く、ユーモアがある発表方法でとても面白かったです！
クラシルリワードアプリ内でも、バーコード読み取りの機能は存在するので、
いち早く導入し、コードのリファクタ、および機能の高品質化を図りたいと思いました！
by kaikai
メインスレッドをブロックさせないためのSwift Concurrencyクイズ
登壇者 ：tokizoさん
資料 ：https://speakerdeck.com/tokizuoh/swift-cocurrency-quiz
概要
Swift Concurrencyを使った非同期処理におけるメインスレッドのブロックリスクを見極めるため、登壇者が用意したコードを用いてクイズ形式で知識を深めることが目的でした。
ポイント
完全な理解が難しいSwift Concurrencyの実装について5つのケースを用いて、理解度を測ることができ、本セッションでは、主に以下のポイントについて再度おさらいしました。
- Detached Taskについて
- Actor隔離されていない非同期関数
- プロパティラッパーからの推論
- Global Atorの規則
また、「メインスレッドを適切に管理する」とは以下のことを指しており、適切に管理できるようになることが狙いでした。
「メインスレッドを適切に管理する」とは「UI更新などではメインスレッドで処理を実行する」・「メインスレッドでは行わなくてもいい処理はバックグラウンドスレッドに逃す」ということを定義されています。
具体的なクイズの例としては、以下のようなコードを例題を含め6つ用意されており、それぞれなぜMainActor.assertIsolated()が通るor通らないのかを確認しました。
感想
現在弊社のiOSチームでは、Swift6以降に伴い、Swift Concurrencyの利用のガイドラインが設けられているところでもあるので、今回こちらのセッションで学んだことも念頭においてガイドラインの精度に寄与できればと感じました。
個人的には、クイズ形式で確認することで、ケースごとの対処法を学ぶことがあったので、大変有意義なセッションとなりました！ また、自分で実装していて自信の無い箇所は丁寧にMainActor.assertIsolated()などを活用しながら、プログラムの実行が停止されないかを確認しながら、実装したいと思いました！
by takky
開発を加速する共有Swift Package実践
登壇者 ：el_metalさん
資料 ：https://speakerdeck.com/elmetal/our-case-studies-of-shared-swift-packages-to-accelerate-development
概要
サイボウズの3つのプロダクトで共有利用する社内OSSを作成したことや、その経緯と内容についてを発表がメインで、質疑応答でも運用についてを話しされていました。
ポイント
アプリ内の認証機能等の共通部分は同じロジックで実装したいニーズがあったが、それぞれのアプリで利用されている技術スタックが異なりロジック部分の実装で他アプリの参考をして散逸してしまうことがあったので、負債が拡散する問題があったそうです。
上記も含め共有Swift Packageを実装する際に「SwiftUIに馴染むAPI」「高いtestability」「ドキュメントの徹底」を大事にしてより利用しやすいシステムにされました。
また、Owner・Contributor・Userの3つのロールに分かれてパッケージを成長させていく仕組みに関しても、より効率良くプロダクト開発において参考になるポイントかと思いました！
弊社のプロダクトである、クラシルとクラシルリワード内のユーザー認証機能等が統一されているので、発表されていたことを参考にして共有Packageを作ることで当社にもメリットはかなりあり、新たにプロダクトを立ち上げる際の立ち上げコストがかなり圧縮されると感じたので、機会があれば、社内共有するOSSの作成は大変魅力的だと感じました！
感想
上記にもある通りで、各企業で同じような悩みを持っていると思うので、参考にさせていただきやすい内容で、運用方法や辛かった部分等についても機会があれば詳しく伺いたいと感じました！
また、導入した効果として、「コード整理」「ロジックのSSoT」「置き換えの加速」「アプリコードの品質向上」など大きなメリットも挙げられていたので、複数アプリを運用する企業や組織は社内で共有利用するPackageの導入は検討してみてはいかがでしょうか！
by takky
iOSアプリらしさを紐解く
登壇者 ：Natsuho Ideさん
資料 ：https://www.figma.com/deck/SdnNYyqxF80BpyvQLt5Pof/iOSDC-Japan-2024-%E7%99%BB%E5%A3%87%E8%B3%87%E6%96%99?embed_host=twitter&kind=deck&node-id=30-413&page-id=0:1&scaling=min-zoom
概要 「iOSアプリらしいデザイン」とは、直感的で使いやすいデザインであることを再認識し、登壇者が調査した結果を共有するセッションでした。
ポイント
上記のように、「直感的で使いやすいデザイン」を「iOSアプリらしいデザイン」と定義されたのは、HIG（Human Interface Guidelines）やApple純正のアプリに触れることで、ヒントを得たそうです！
その「直感的で使いやすいデザイン」を実現するためのデザインを実現するためには、特に以下の4つのデザイン原則が重要とのことでした！
- 直感的な操作性：ユーザーが直接的に操作できるインターフェースを提供すること。
- フィードバック：ユーザーが操作の結果を視覚的・聴覚的・触覚的に理解できるようにすること。
- 現実世界の比喩：現実世界のオブジェクトや動作を模倣することで、ユーザーが操作を直感的に理解できるようにすること。
- ユーザー主導：ユーザーが自由に操作を行い、その結果を制御できるようにすること。
具体例として、カードコンポーネントとお気に入りのUIの例にとって説明されており、従来のpush遷移をズーム遷移に変更することで、より直感的な操作性を実現されていました。
また、お気に入りUIでは、アイテムが実際にお気に入り一覧に吸い込まれるようなアニメーションを追加し、ユーザーにとっての操作と結果の一貫性を強調し捜査の一貫性が大事であることを学べました！
このような改善は、WWDC24でも紹介された手法を参考にしており、今後のプロジェクトでも積極的に取り入れていくために、デザイナーやPMにも積極的に提案したいですね！
感想
直感的なデザインを実現するためには、HIGを確認したりAppleのデザイン原則を理解するだけでなく、デザインの背景にある考え方や実際にアプリを触ってみることで理解できると改めて、学ぶことができました。
特に、ユーザーが操作を通じて自然に結果を得られるようなデザインを心がけることで、アプリの使いやすさが大幅に向上することを実感しました。
by takky
詳解UIWindow
登壇者 ：atsuyanさん
資料 ：https://speakerdeck.com/elmetal/our-case-studies-of-shared-swift-packages-to-accelerate-development
概要
UIWindowについて再度のおさらいと、SwiftUI時代ではどのようにUIWindowと付き合っていくべきなのかを共有するセッションでした。
また、UI構成の際によくやりがちな画面サイズ取得の例などを挙げながら、UIViewやUIWindowView、UISreenの特徴を解説されていました。
ポイント
画面サイズを取得する際に検討される、UIWindow等の上記のクラスがあるが、どのように取得すればいいかをUIの表示レイヤーについて解説されていました。
また、UIWindowの活用方法としてアプリ内で、最前面にUIを表示したい際に操作するのが良さそうであり、具体的には、画面のローディングやトースト、デバックツールの表示などを挙げられていました。 当社では、リワードアプリのDebug版ではイベントの取得をリアルタイムで確認するためのツールは最前面に表示するように設計されているため、登壇内容を聞きながら思わず頷いてしまいました。(笑)
SwiftUIを利用して、画面サイズを取得する際の方法として、「App内のViewからから取得する場合」と「App外で作成したUIWindowに紐付くSwiftUIのViewから取得する場合」の2つに分けられるとしておられました。
リワードアプリの開発組織的にもGeometoryReaderで毎回画面サイズを取得することよりも、どこかで画面のサイズを取得して、その値を利用することで、わざわざ画面横幅を取得するために大量の差分を発生させずにするとの話になっていました！
すごくタイムリーな話だったので、持ち帰って議論もして検証後よければそのような仕組みでUIを組めるようにしたいと考えています！
感想
上記でも述べていますが、画面の横幅を取得してUIを組みたいニーズがある時に、毎回GeometoryReaderを書いてしまっていたので、変更差分の圧縮やボイラーコードになりつつ箇所を削ることができそうなので、すぐにでもプロジェクトに適応できそうです！
by takky
Day2
クロスプラットフォーム普及増加。SwiftでiOS開発はもうやらないのか....?
登壇者 ：清水翔貴さん
資料 ：https://speakerdeck.com/teamlab/iosdc-2024-kurosupuratutohuomupu-ji-zeng-jia-swiftdeioskai-fa-hamouyaranainoka-dot-dot-dot
概要
昨今、多く話題に上がるクラスプラットフォームによる開発と、それに対するネイティブ開発、
それぞれのメリットデメリットをわかりやすくまとめ、言語化されていました。
ポイント
普段、なんとなくクロスプラットフォーム流行りだよなぁ、と思いつつ、自分はクラスプラットフォームのメリットデメリットをちゃんと理解していませんでした。
そんなクラスプラットフォーム開発のメリットデメリットを言語化してわかりやすく解説していました。
挙げられているメリットの中で、特に印象深かったのは、以下です。
- iOSとAndroidの実装差分が軽減される
AndroidでできてるのにiOSではできていないんだけど！ ということは今までたくさん言われてきた経験があり、いい思い出はありません、、、、、
また、差分を出さないために両OSのエンジニアの認識を合わせるのも、少ない工数ではありません。 認識合わせの工数を削減できるのは、とても強いメリットだと思いました。
また、デメリットで気になったのは以下です。
- サードパーティのSDKが対応していない場合がある
超コアな機能の開発に使用するSDKが対応していない場合とか、どうするんだ、、、ととても 気になりました。 (そもそもそんなことが起きないように技術選定しっかりしようね！という話なのかも)
感想
改めて、クラスプラットフォーム開発に対する考え方を知るいい機会になりました！
それと同時に、クラスプラットフォーム、少し触ってみたいな！と思いました。
今後、クラスプラットフォーム開発が選択肢に上がった際は、こちらのセッションを思い返して、 技術選定の参考にさせていただきたいと思います。
by kaikai
医療アプリ開発の最前線 - 安全性と生産性の両立への挑戦
登壇者 ：Shogo Yoshidaさん
資料 ：https://speakerdeck.com/medley/yi-liao-apurikai-fa-nozui-qian-xian-an-quan-xing-tosheng-chan-xing-noliang-li-henotiao-zhan
概要
リリースから8年を超える医療系のアプリを継続的にリファクタリングし、生産性を高めつつ、自動化できる部分は積極的に自動化している点が非常に参考になりました。特に、ADR（ArchitectureDecisionRecord）については、このセクションを聞いた翌週にすぐにクラシルリワードにも取り入れ運用を開始しています。
Magicpodについてもクラシルリワードは導入済みですが、なかなか安定しないため100％の運用率を保っていることは非常にモチベーションにも繋がりました！
ポイント
オンライン診療アプリはリリースから8年を経過しているが、継続的なリファクタリングによりSPMベースのマルチモジュールに対応しMVP開発を支えている。
また、クラシルリワードでも先日導入したADR（ArchitectureDecisionRecord）を残すことでアーキテクチャ設計の思想背景などを後世に残すドキュメンテーションの取り組みを積極的に行っている点が我々のチーム、組織でも学べる点だった。
例えばクラシルリワードではリリース速度を優先するあまり、中途半端な設計のまま積み上がってしまうケースがあり、改修するタイミングもずれるため作成した本人もどういった思想でその設計にしたのかうろ覚えなケースがあり、改善する必要があると認識している。
Magicpodに関しても運用スコア100％を保持しており、QAチームと並んで改善を行っている。特にQAチームは企画説明時から一緒に参加することでスムーズに対応できる話などが印象的でした。
by uetyo
さいごに
iOSDCの参加を通じて、普段業務で取り扱っている以外の技術や、業務に応用できそうな技術など、たくさんの知識を吸収することができました！
また、他企業のエンジニアさんとも多く話す機会があり、とても刺激をいただけことも今回オフラインで参加した大きなメリットに思います。 iOSDCで得た知識、経験を活かして、さらに弊社で展開しているiOSアプリをもっと良いものにしていければと思います！
delyでは、iOSエンジニアを大募集しています！
開発ではスピードを大切にしており、最新技術を積極的に取り入れ、より良いアプリを作るために、チーム一丸で切磋琢磨しております。
気になる方は、ぜひカジュアル面談でお話ししましょう！
