トーク

Swiftが公開され今年で10年目となったように、iOSアプリ開発も長い年月をかけて運営し開発を続けていく現代では、プロダクトにおけるテストコードの量も自然と大量になっているはずです。そのうえ大人数がプロジェクトに関わっているのなら、機能追加や不具合の修正に加えてテストコードも日々大量に増え続けていることでしょう。

そして現代のプロジェクトでは、新たに開発した機能や不具合の修正は既存の全てのテストコードが正常に成功しないとマージできないという開発のフローを採用しているはずです。そのような開発フローにおいて、意図せず稀に失敗するようなテストコードが紛れ込んでいると、自分が関与していない不安定なテストが自分の開発リズムに割り込んでくる厄介な状況が発生します。

さらには大量のテストコードが実行時間をかけた末に失敗してしまうと、各メンバーがスムーズに作業を進められず、開発時間が不要に伸び開発体験が低下してしまうのも問題です。

このトークでは、結果が不安定となるテストコードの原因を分類し、具体的な例を交えながら改善点について解説します。

また、Xcode 16で正式統合されそうなswift-testingを活用することで、ある種の不安定なテストを解決できるのではないかという事についても話しができればと思います。

iOSアプリ開発は、サーバーサイドエンジニアやAndroidエンジニア、デザイナーやプロダクトマネージャーといった様々な役割のメンバーと一緒に進めることが多いですね。
しかし、iOSアプリ開発に軸足を置いている人からすると当たり前のことが伝わっていないことが多々あり、それが原因で協業しにくくなることがあります。

たとえば、アプリリリース時の審査プロセスです。審査プロセスがあること自体知らない人もいますし、存在は知っていても審査期間や審査結果のばらつきについては知らない人も多いです。

他にも、デザイナーに対してはSwiftUI事情や限界の話、プロダクトマネージャーに対してはOSサポート事情や段階的更新などリリース関連の話、サーバーサイドエンジニアに対してはAPIインターフェースや強制アップデート機構の話など、最初に認識を揃えておくとよさそうな話が意外と多いです。

このトークでは、そういった「iOSエンジニア以外にも知っておいてもらえるとよいiOSアプリの開発事情」についてまとめてお話します。社内にそのまま共有すれば、より認識が揃って仕事がしやすくなるような内容を目指します。

昨年度に入院することになり、入院中にトイレの時間と回数を記録をするように言われましたが、いい感じに記録できるアプリがありませんでした
ないときは自分で作ればいい！
ということで、手術までの時間に突貫でトイレ記録アプリを実装する入院アプリハッカソンを行いました！
せっかくなら自分だけでなく、自分以外の人にとっても使いやすいアプリを作りたいものです
そのため手術前の短時間で作ったものから、残りの入院期間や退院後の時間や別の入院期間でのドッグフーディングや他の人からのフィードバックを踏まえて、少しずつUX改善と機能追加を重ねていきました
この発表では今回のアプリ実装や経験をもとに、今後の展望や希望も含めた以下のUX改善のポイントについてお話しします

1. ドッグフーディングとユーザーフィードバックの重要性
2. WidgetやWatchOS対応などの複数の登録導線の実装
3. Accessibility Inspectorを使ったアクセシビリティ機能の改善
4. iBeaconを使った記録リマインドの通知

UX改善に決まった正解はないので、試行錯誤しながら少しずつ改善していくしかありません
今回の発表を通して皆さんの開発しているアプリやサービスのUX改善のヒントを掴んでいただければと思います！

2024年2月に Apple は Pkl （ピックル）をオープンソースで公開しました。
Pkl は豊富な検証機能とツールを備えた、コードとしての構成言語です。
Pkl をどのように使うのか、使うことで何ができるのかを解説します。

1. Pkl の導入方法
2. Pkl の使用方法
3. Pkl のユースケース
   a. 静的構成の生成
   b. アプリケーションのランタイム生成
4. Swift からの Pkl 構成言語呼び出し
5. その他の活用方法

JSON、YAML、 Plist などの既存の構成言語とは異なるアプローチを探している方にとって、 Pkl が新たな選択肢にとなる可能性があります。ご興味のある方はぜひ聞いていただけると幸いです。

決済は、物理的な商品の購入を行うE-commerceアプリでは、必須かつ重要な機能です。
出前館アプリでも、決済機能はユーザにとって重要な機能として位置付けられています。

アプリ開発者として決済機能を運用する際は、アプリだけでなく、トランザクション処理全体の把握など、サービス全体を通じた知識が求められます。

また、近年の決済機能は、3D SecureやSMS認証などの多要素認証によって、よりセキュアに価値を提供することが求められています。
複雑な決済フローをユーザに認識齟齬なく継続的に提供するためには、バックエンドの処理に加えて、アプリで各種例外処理の考慮をするなど、様々な工夫を行う必要があります。

本発表では、決済機能の運用について、出前館アプリの決済機能の運用を例に、以下の話をします。

• 決済の基礎(決済とは何か/AuthorizationやCaptureの話)
• 決済の近年の傾向
• 出前館の決済機能での改善例
• 複雑なドメインをチームに共有する際のノウハウ

発表者は、出前館アプリの決済機能のアプリ開発・リードを経験する中で、決済機能の運用例には、複雑なシステムを運用するためのノウハウとして共通の学びがあると考え、本プロポーザルを提出しました。
決済に関わっている方に限らず、複雑なシステムをどう運用するか興味のある方など、本発表を聞いていただけますと幸いです。

FlutterはDartで実装するクロスプラットフォームのフレームワークです。
通常、Flutterプロジェクトは主にDartで開発されますが、既存のSwiftで書かれたiOSプロジェクトに対してadd-to-appアプローチを用いることで、Flutterを一部の画面に統合することも可能です。
また、ネイティブ機能を利用するためにSwiftの実装が求められることもあります。

iOSエンジニアとして、Flutterプロジェクトに参画した際にSwiftの最新技術を使いたくなることは多いでしょう。
そうした場合、最新のSwift機能を利用できるのかを知りたくなるのではないでしょうか？
本セッションでは、特にSwift Package Manager (SwiftPM)とSwift 6の新機能に焦点を当て、Flutterプロジェクトにおける現状と今後の展望について詳しく解説します。

【話す内容】

1. Flutterにおけるパッケージ管理の現状とSwiftPM対応の展望
2. 全ての-enable-upcoming-featureを有効にした状態でFlutterプロジェクトがビルド可能かどうか
3. FlutterプロジェクトでSwiftコードと連携を取る際にSendableやActorをどう適用すればいいのか

Dive into the world of visionOS and discover how it can revolutionize AR development with a step-by-step guide to creating a dice app, which can roll dices with the users' gesture. In this session, you'll learn how to use SwiftUI, RealityKit, ImmersiveView and more to build an interactive and visually stunning application. I will cover everything from initial setup and design principles to advanced features like gesture recognition and real-time entity updates. By the end of the talk, you'll be equipped to push the boundaries of AR and create immersive experiences that captivate users.

エンジニアとして、私たちは日々多岐にわたる知識やスキルを学び、さまざまな問題を解決しています。たとえば、開発する機能の仕様やドメインの知識、プログラミング言語やライブラリの使い方など、多方面にわたる学習が必要です。これらの学習を積み重ねることで、より複雑な問題にも対処できるようになり、スキルアップも図れます。

しかし、学習には時間と労力がかかります。集中力や注意力も不可欠で、「覚えることが多くて大変だ…」「なかなか身に付かない…」と悩んだり挫折したりすることもあるでしょう。もしかしたら、それは学習方法が原因かもしれません。

効率よく学習を進めるためには、脳の仕組みを理解し、それに合わせた方法を取ることが重要です。本セッションでは、以下の点に焦点を当てます。

• 学習の正体
• 脳に負荷をかけ過ぎない学習戦略
• 努力を効率化する学習方法

これらのトピックを中心に、技術的なスキルの習得に焦点を当て、今後の学習に活かせる考え方や方法を皆さまと共に探ります。

「業務で必要だから」「キャリアアップのため」「おもしろそう」など、学習理由は人それぞれ異なりますが、一つスキルが身に付くとさらに新しいスキルが身に付きやすくなり、世界がどんどん広がります。

このセッションを通じて、皆さまが日々の学習において具体的な改善策を見つけ、より効率的にスキルを身につける手助けができれば幸いです。

Swiftにおけるクロスプラットフォーム対応は、この1年で目覚ましい発展を遂げたトピックです。その中でも、Windows環境で動かすSwift、つまりSwift on Windowsは非常に大きな変化を迎えました。
iOS、iPadOS、macOS向けに開発したアプリケーションやフレームワークをWindowsでも動かせるようにすることは、非常に価値のある取り組みです。

しかし、Swift on Windowsに挑戦するためにはどのように取り組めば良いのかご存知でしょうか？

本トークでは、Swift on Windowsで開発を始めるための方法と、Swift Packagesで開発したライブラリをWindowsに持ち込む方法についてお話しします。
具体的には、GRDB.swiftやThe Composable ArchitectureをWindowsで動くようにした取り組みから学んだWindows対応の方法や、Swift on Windowsで開発したアプリを配布する際に考える必要があることなどを紹介します。

このトークを通じて、Swift on Windowsを活用して世界のデスクトップOSシェアの7割を超えるWindows向けにプロダクトを提供する新たな選択肢を紹介します。また、自信を持ってクロスプラットフォーム対応のSwiftコードを書くための考え方も提供します。

SF SymbolsはAppleプラットフォーム向けのアイコンライブラリーであり、iOSアプリ開発における強力なツールです。システムフォントにシームレスに統合されるため、コンテキストやユーザーのアクセシビリティ設定に従い、スケールやウェイトの調整もOSが自動でしてくれます。現在は5000を超えるシンボルが存在しており、アニメーション効果により表現豊かなインターフェースの実装が可能となっています。

そんなSF Symbolsですが目的に合ったものが必ず見つかるというわけでもなく、意外とSF Symbolsだけでは事足りないということが多々あります。そこで、シンボルの代わりとして画像を使うとスケールやウェイトの調整ができないため、SF Symbolsを自作するのが最善です！

しかし、SF Symbolsの自作にあたって、ベースラインやカーニングなどのグリフ要素を調整してシステムフォントや他のSF Symbolsに馴染ませたり、パスのアンカーポイントとコントロールポイントの写像を厳守するようにしないと有効なSF Symbolsにならずアプリで使えません。本トークでは私のSF Symbols作製経験を基に自作の極意を紹介します。

話すこと
・自作の手順
・コツ、押さえておくべきポイント
・既存シンボルのカスタマイズ

話さないこと
・シンボルのデザイン手法

Ignite は Swift 製の静的 Web サイトビルダーで、表現力豊かでパワフルな API を提供し、あらゆるデバイスで優れた機能を発揮する美しい Web サイトを構築します。
HTML や CSS の知識がなくても、SwiftUI のような構文を使用して素晴らしい Web サイトを構築できます。

本トークでは、試しに iOS 関連のニュースを定期的に配信する Web サイト「iOS Osushi🍣」を Ignite にリプレイスする過程で得られた知見を紹介します。具体的には、以下のポイントについて解説します。

• Ignite の基本機能と使い方
• 初公開時から追加された新機能
• 「iOS Osushi🍣」での導入プロセスと得られた成果

このトークを通じて、Swift を使った Web サイト構築にチャレンジしてみましょう！

iOSアプリケーション開発におきましては、市場の規模や開発ツールの成熟度、エコシステムの安定性といった観点から「成熟期」を迎えていると思います。そんな中、サービス開始から10年以上継続しているサービスも多くなってきており、フルリプレイスを進めているアプリも多く見受けられるのではないでしょうか。
私自身、現在iOSアプリのフルリプレイスに携わり、仕様の再設計から始まり、UI、UXの再設計、機能実装など、多くの意思決定をチームと共に行って参りました。

本トークでは、実際にリプレイスを進めていく中で、以下の観点を元にお話しさせていただきたいと思います。
・リプレイスを進めていく上での判断基準をどのように設定したのか
・どのように意思決定を進めて行ったのか、
・iOSアプリエンジニアとしての知識を活かし、どのようにチームに貢献をしたか
・成功例、失敗例、悩んだところなど

「そろそろやらなきゃな」、「リプレイス考えているよ」、「すでに始まっている」など、今現在、そして未来のプロダクトのために動かれるすべてのエンジニアの方々に、
ちょっとだけでもプラスになるようなトーク内容としたいと思います。

以上です。