プロポーザル

このセッションを通じて、Core ML Stable Diffusionの利用方法を簡単に深く学び、iOS上でAIを活用することができるようになります！
わくわくするAIの世界を楽しく体験しましょう！

1. Core ML Stable Diffusionとは何か？
   　どのように機能するのかを、専門的な言葉をなるべく使わず基本概念やメリットを理解できるように解説します。
2. 手順と実践例
   　具体的な手順と実際のコード例を通じて、iOSアプリに組み込む方法を学びます。
3. デモとエクササイズ
   　参加者が自身のデバイスで手軽に試せるデモやエクササイズを用意します。
4. ユーザーエクスペリエンスのアイデア
   　Core ML Stable Diffusionを使って実現可能なユーザーエクスペリエンスのアイデアを共有します。

iOSではリストの子要素をスワイプするUIをよく見かけます。
SwiftUIでは、Listに子Viewを列挙することでリストを実現でき、その子Viewに対してswipeActionsを利用しスワイプを可能にします。
しかし親ViewがList以外の場合、子ViewにswipeActionsを利用しても、スワイプは適用されません。
よって、親ViewにListを使わずに構築しているリストなどの子Viewにスワイプを適用する場合、swipeActionsを適用できないため独自実装が必要となります。

本トークでは、Listではない親Viewの子Viewにスワイプを適用するために独自実装したSwipeableStackを紹介します。
SwipeableStackの実装内容と使い方を具体的に解説します。

Alamofireを使って通信処理を実装しているアプリ世の中には結構あると思います。
Alamofireはv5.5.0でSwift Concurrencyに対応されており、いくつかのmethodが存在しています。
このトークではAlamofireでのSwift Concurrencyに対応された実装の紹介と、具体的な実装方法などを踏まえて紹介したいと思います。
説明内容
・AlamofireのSwift Concurrencyのメソッド紹介
・実装前と実装後の具体的な比較をもとにした実装方法の紹介

みなさんHuman Interface Guidelines読んでますか？
HIGにはAppleのプラットフォームで優れた体験を生み出すための豊富な知識が詰め込まれたガイドラインです。
2022年6月以降内容をアップデートしさらにパワーアップしております。WWDC2023ではついに日本語にも対応しました。
そんなHIGですが、なかなか量が多く、読むのに時間がかかります。忙しい開発者の方々は呼んでる時間なんてないよ😭という人も多いでしょう。
そんな方に向けて本稿では特に私が大事だと感じた部分を抜粋し標準アプリの実例を備えて解説させていただきます。
・ 標準アプリの実例を踏まえて大事だと思ったところを説明します。
・ すぐにでも明日の開発に役立つよう業務に役立つ内容に焦点を当てます。
・ 実際にアプリケーションを開発する上で役に立った点などを説明いたします。

私達はTVerという動画配信サービスを開発・運営しており、昨年4月に一部システムを内製化しました。
しかしモバイルアプリケーションについてはほぼ全ての開発をパートナーのお世話になっている状況であり、現時点では自社のiOSエンジニアはまだ1人もいません。

内製であれ外部への委託であれ、サービスを提供する以上は私達がサービスへの責任を全て負う必要があります。
本トークではiOSアプリケーション開発への専門知識が無いSREの私がNew Relicを導入し、サービス品質の可視化と改善を行っている話をします。

聴講対象

・ オブザーバビリティの導入を検討しているiOSエンジニアおよびSRE

お話すること

・ TVerにおけるiOSアプリ開発の課題
・ オブザーバビリティの実装と効果
・ 動画プレイヤーの観測

お話しないこと

・ TVerにおける具体的なiOSアプリの実装

RunCatはMacのメニューバーにCPU使用率に応じて走るネコを表示できる個人開発のユーティリティアプリです。
開発/運用が5年目となるRunCatの歴史を振り返りつつ、技術的な課題や工夫、知見を詳解します。

・OSごとに変わるメニューバーの仕様
・ランナーの作り方とリソース節約の工夫
・アプリ内課金のProduct IDにまつわる失敗
・システム情報の取得に関する苦労
・アプリ自体のCPU使用率を下げる工夫
・バージョンアップによるマイグレーションの難しさ
・ユーザーからの不具合報告対応のコストを減らす工夫
・開発者向け機能から生まれた自作ランナー登録機能
・無学によるスパゲッティコードとリアーキテクト

などなど、可愛いだけじゃないRunCatの裏側を覗いてみませんか？

タクシーアプリ『GO』では、現在大規模な英語への対応作業を進めています。
日々追加される案件開発や差し込みでの対応と並行しながら、既に存在する大量の画面をPdM・デザイナーと適切に連携を取りながら複数言語に対応させていく作業はかなり難易度の高い作業です。
現在タクシーアプリ『GO』では外部文言ツールとGitHub Actionを組み合わせた文言管理を行っていますが、現在の運用に方法を採用するまでには様々な課題が有りました。
そこで本セッションでは、多言語対応に本格着手した際に発生した課題や問題点に対してどのように対応してきたか、及び現在の運用にしてどのような問題が解決されたのかなど、多言語対応にどのように開発チームが対応してきたのかをお話いたします。

Swift Playgrounds Appを使用することで普段のアプリ開発するWorkspace上で、簡単にDemoApp, PreviewAppを作れるよっていう話をします。
マルチモジュール構成やSwiftPackageを使ったマルチモジュール構成での開発も増えてきたかと思いますが、
デモアプリの開発でXcodeProject(.xcodeproj)を使うと、WorkspaceとProjectを行ったり来たりしないといけなかったり(複数Window)、WorkspaceやProjectを複数開いた場合に共通するpackageの依存が解決されないや、デモアプリのProjectで検索がうまく動かないなど(特に移行期など)が発生します。

1Workspaceで、Package内のモジュールの開発build、Appのbuild、デモアプリのbuildまでできる環境便利です。

アプリケーション等のプログラムを実行する際最初に呼び出される処理や関数のことをエントリーポイントと呼びます。
Objective-C時代はmain.mというファイルが必要でしたが、Swiftになって @UIApplicationMain が登場しエントリポイントが隠蔽されるようになりました。
更に、SwiftUIや @main の登場により @UIApplicationMain を deprecated にしようという動きもあります。

本トークではそんなエントリーポイントの変遷を紐解いていくことで、エントリーポイントについての理解を深めていければと思います。

「エントリーポイントについて理解するとAppDelegateをモック化できる」
「AppDelegateをモック化できるとどうなる？」
「知らんのか」

「副作用の少ないテストが書ける」

「お前も Swift Playgrounds を使った開発者にならないか？」（１年ぶり２回目）

昨年の「iPadOSDC Japan 2022」では、Swift Playgrounds を知ってもらうために、 Xcode との機能差分やメリット・デメリットを紹介しました。
本セッションでは、その中でも触れた内容の１つをさらに掘り下げます。

Swift Playgrounds では、プロジェクトファイルを持たずに、Package.swift を起点に開発することになります。
これをうまく活用することで、Xcode と併用して Feature 単位でのマルチモジュール開発が可能になります。

ただし、これは完全に機能するわけではなく、まだ問題点もあるので、実際のプロジェクトを通して経験したことも含めて、お話ししていきます。

我々が日常的に利用するモバイルアプリが増えていく一方で、ユーザ体験の重要性が高まっています。最高のユーザ体験は、単に素晴らしいデザインや機能性だけでなく、異なるデバイス間でも一貫性と流動性を持つことが求められます。
しかし、この挑戦は容易なものではありません。特にiPhoneアプリをiPadやMac Catalystに単純に移植するだけでは、ユーザーに違和感を与えることがしばしばあります。

本セッションでは、異なるAppleデバイス間での一貫した体験を提供するためのデザイン戦略と技術的なアプローチを解説します。具体的には、UIの適応、OS独自の機能の活用、そしてこれらすべてがユーザ体験にどのように影響するかを議論します。

このセッションを通じて、オーディエンスの皆さんのアプリをクロスプラットフォーム対応にするための具体的な戦略とベストプラクティスを考える一歩になれば幸いです。

私たちのチームでは品質維持のためにテスト戦略を見直し、その結果、自動テストを導入しました。
半年が経過した現在、自動テストのシナリオ数は35を超えていますが、その過程で多くの課題がありました。
例

• どのようなフロー・タイミングで自動テストを実行するのか
• 成熟したプロジェクトでどの機能から自動テストを導入するのか
• 自動テストを実施するか否かの判断をどうするか
• 不安定なテストシナリオへの対処法

上記で挙げた課題に対して行ったことの紹介はもちろん、以下のことについても話します。

• テスト戦略の見直しを行った背景
• テスト戦略の見直しから自動テストの選定までの流れ
• 受けられた利益やデメリット

技術選定にFlutter、integration_testを使用したプロジェクトのトークになりますが、トーク内容はモバイルアプリ全般に適用できる内容です。

私は以下の構成で個人アプリを開発しています。

• UIの実装: SwiftUI
• アーキテクチャ: MVVM
• ソース管理: Swift Package

サードパーティ製のフルスタックフレームワークは使わず、SwiftUIを純粋に使ってきれいなコードになるよう心掛けています。
アーキテクチャはAndroidの公式ドキュメントを参考に設計し、可読性やコードを書くときの迷わなさを高めています。
Viewの分割も読みやすい粒度で適切に行っているつもりです。

ただ自分のコードが本当に読みやすいかは、実際に他の人に読んでもらわないとわかりません。
そこで 個人アプリのREADMEとソースコードをできる限り印刷して公開します 。

持てる限りの知見を共有するので、みなさんはぜひゴリゴリにコードレビューしてマサカリをぶん投げてください。
よりよいコードを作り上げ、一緒に成長しましょう。

SwiftUIは強力なUI構築手段ですが、アプリ開発にだけ利用するなんて勿体無いと思いませんか？

本トークではSwiftUIで名刺をデザインする方法について、実践的な手順を紹介します。

• SwiftUIで名刺をデザインするメリット
• ベクターデータをSwiftUIで取り込む方法
• SwiftUIのViewをベクターデータとして出力する方法
• 名刺を発注する際に必要なベクターデータに沿った注意点
• etc.

SwiftUI製の名刺を作ってiOSエンジニアとしてのスキルアピールや個人ブランディングに役立てましょう！！

OSSは貢献したいと思ってもそのコミュニティによって貢献できる難易度は変わってくると思います。ですが、OSS貢献は普段自分と関わりがない開発者の方々とコミュニケーションを取れるため、非日常で楽しいことだと考えています。
特にDroidKaigiでは毎年OSSとしてカンファレンスのアプリケーションを開発しており、僕も3年間貢献させていただきました。
他にも幾つかのOSSに貢献した経験をもとに、OSS活動をやってみて良かったなと思える瞬間を本LTで話したいと考えています！

深層学習モデルの識別処理は学習に比べて軽くモバイル上で実行できるオンデバイス識別の技術があり、端末上で完結するという利点を備えています。
iOSアプリでは深層学習モデルはmlpackageに変換して利用しますが、慣れていないと躓く点があると考えており、以下の内容を軸にトークを進めようと考えています。

対象者：深層学習をデバイス上で識別してみたい人・デバイス上で動作させるためのTipsに興味がある人

1. モデルのデプロイについて（CreateML or coremltools or 公式CoreML Model）
2. coremltoolsにおける推論を行うためのTips
3. モデル圧縮と識別精度に関するTips

WWDC23で発表されたcoremltools 7ではモデル圧縮のAPIに変更が入っており、そちらについてもトーク内で触れようと考えています。

「Swiftで競技プログラミングに参加できる」というのは、黎明期に比べれば多くの方が知る事実になっているかと思います。
一方で、Swiftを競技用言語として選ぶ参加者は、C++やPythonを始めとする有名な言語のそれと比べれば十分に少数派です。
実際C++やPythonから積極的に乗り換えを推奨できるものでもありません。
ただ、Swiftという「武器」には一部のコンテスタントの心を惹きつけてやまない力があるようです。

このセッションでは、私自身の取り組みから得た経験をもとに、競技用言語としてのSwiftが持つ魅力に迫ります。
具体的には

• そもそもSwiftって"速い"の？
• Swiftが持つ競技上の優位性と弱点
• 競技用言語としての現状と展望

といった話題について、初級者の視点から考察を行います。
普段のiOS開発では見逃しがちなSwiftの側面に、ぜひ触れてみてください！

アプリがネットワークなど外部サービスを通じてデータをやり取りする場合、JSONが使われることは多いと思います。
JSONのデータはJSONDecoderを使い、Combineでdecodeと組み合わせてなどの方法でCodableデータモデルに変換し処理することになると思います。
しかし世の中のWeb APIにはJSONではなくXMLでのレスポンスを返すものもあります。
また、データソースの変更で、ネットワーク経由ではなくローカルのcsvやyaml、はたまた独自のデータを変換することになったり…
そうなった場合、decodeは使えないのでしょうか？
否！JSONのデータじゃなければ、自分でDecoderを作ってCodableなデータモデルに変換すればいいのです。

このトークは、JSONではないデータに出くわしても困らない、独自のDecoderを作成するための説明を行うトークとなります。

SwiftUIが発表されてから今年で5年目に突入しました。
多くのコンポーネントが導入され、覚えることも増えてきた頃かと思います。
そんな今だからこそ、SwiftUIの基礎を学び直してみませんか？
技術を応用する際は、基礎の理解が重要になってくるものです！

このトークは次の様なテーマを取扱い

• Viewはどのタイミングで再生成・再描画されるのか？
• 再描画を減らすポイント: View Identity
• SwiftUIの裏側にあるUIKitについて

これらのテーマごとに

1. 過去のWWDCのセッション等を引用しながら、仕様を確認
2. どのようにコードを書くべきか考察

の2ステップを繰り返す内容になっています。

既にSwiftUIを使っている人でも、このトークで基礎を再確認することで
より描画パフォーマンスの良い書き方や、新しい視点での実装ができるようになると思います！

iOS 16 から Swift Charts という SwiftUIのフレームワークが使えるようになりました。

Swift Charts を使うことで、簡単にグラフを作成することが出来、特に時系列データの可視化に便利です。

一方で、コード上で設定できる項目がかなり多い上、設定項目とグラフの変化が直感的で無い事もあるため、グラフの表示範囲や見た目をカスタマイズするのが難しくなっています。

そこで今回は Swift Charts で「良い感じ」にグラフを表示する方法を紹介します。

具体的には、一般的な2変数を対象にグラフ自体を見やすく表示する方法を紹介しつつ、筋力トレーニングの記録のような3変数を持つデータの表示方法を詳細に説明します。