トーク

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

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

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

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

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 AppをiPadやMac Catalystに単純に移植するだけでは、ユーザーに違和感を与えることがあります。

本トークでは異なるAppleデバイス間での一貫した体験を提供するためのデザイン戦略と技術的なアプローチを解説します。
ソースコードはSwiftUIを前提とし、UIKitは本トークでは扱わないものとします。

Agenda

1. iPad, Mac Catalystでビルドする
2. Stage Manger対応(デザインとコードの両方面)
3. インタフェースデザインの最適化
4. App Iconのデザイン
5. デバイスの独自機能の利用(写真、ドラッグ&ドロップ、キーボード、カーソルなど)
   and more...

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

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

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

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

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

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の仕組み上よろしくない実装をしているケースを見かけます。
この様な実装をしないために、初心に戻ってSwiftUIの基礎を学び直してみませんか？

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

• Viewが再生成・再描画されるタイミング
• 再描画を減らすポイント: View Identity
• SwiftUIの裏側にあるUIKit

これらのテーマごとに

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

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

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

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

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

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

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

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

iOS / iPadOS / macOS 等の開発に利用されるSwiftはオープンソースで開発されている言語で、開発に関わる情報は全てオープンになっています。
その一方で、どのように開発されているのか分からなかったり、どこを読んだらいいかわからないなどの理由によりオープンであることのメリットを十分に享受できていないケースもあるのではないでしょうか。
そこで、Swiftの開発体制や、機能追加のProposalの場所などをお話しし、皆様がSwiftの開発状況についてキャッチアップできるようになることを目指します！

プロジェクトの肥大化により差分ビルドの時間が伸びてしまいます。
私たちのチームはマイクロフレームワーク戦略でしたが、UI関連のフレームワークが肥大化してしまいました。

解決策として、フレームワーク分割が有効です。
差分ビルド対象のフレームワークが減り、ビルド時間が短縮します。
加えて、機能ごとにフレームワークを分けることで特定機能のミニアプリの配布が可能となります。
しかし、コンパイルが成功しても安心できません。
ランタイムクラッシュや参照の不備でリソースが見つけられない問題が生じます

本トークでは、安全なフレームワーク分割の手法を説明します。以下の項目を中心に話す予定です。

• xibファイル内モジュール参照不整合の静的検査方法
• SwiftSyntax、IBDecodableの使い方
• CIでの静的検査と、Dangerを使ったPull Requestへの警告コメントの出し方

アプリ開発に使用するちょっとしたスクリプトは、Shell Scriptでささっと書いてしまうことがあるかと思います。
Shell Scriptは少ない記述で多くのことができる反面、以下のデメリットがあると思います。

• iOSエンジニアの中でも書ける人が限られたり
• テストコードが書きづらい
• Swift のソースファイルの静的解析をしたり、Swiftのライブラリ資産を活用できない

本トークでは、実際にチームで運用がされているSwift でのスクリプト開発について詳しく説明したいと思います。
以下にスポットを当てる予定です。

• Swift Package ManagerでCLIツールを構築する
• Swiftからファイルシステムを扱う
• Makefileなどから簡単に実行する
• CI上でのキャッシュ運用tips
• 実際にどのようなスクリプトを運用しているか

近年、xcodeprojファイルを軽量に保ち、Swift Package Manager（以下SPM）の方で依存関係を定義するシンプルな構成が多く採用されています。
この方式は、Point-Freeのisowordsなどの比較的大きなプロジェクトでも運用されています。
SPMではxcframeworkのライブラリを簡単に使用することができます。

本トークでは、CarthageのライブラリをSPMから参照するやり方や、
シンプルなextensionの記述によってPackage.swiftを綺麗に保つtipsに加えて、
SPMではなくCarthageを利用することのメリットを簡潔にまとめられたらと思っています。

私は普段モバイルアプリを開発しています。その傍ら、Twitchで筋トレの生配信をしたり、この間はJBBFというボディビルの大会に出場しました。
こちらのスピーチでは、アプリ開発とボディビルのバランスについての洞察を共有します。 ストリーミング、筋トレ、コーディングの相互関係、それぞれの役割のメリット、時間管理の戦略、課題の克服、インスピレーションの見つけ方、自己ケアの優先順位について話します。 多様な情熱を受け入れ、複数の役割をうまくこなしましょう。

Swift開発者として、より高度なアプリケーションを構築するために新しいプログラミング言語を探求することがあるかもしれません。Mojoの言語は、AIアプリケーションを開発するために使用できる強力な言語であり、Swiftに似た構文を持ってところはいっぱいあります。この講演では、Mojoの基礎と、AIアプリケーションを構築するためにどのように使用できるかを探求します。また、MojoとSwiftの類似点と相違点、およびSwiftのスキルを活用してMojoをより迅速に学習する方法についても説明します。さらに、機械学習やニューラルネットワークの基礎を含むAIコーディングの簡単な紹介を提供します。この講演の終わりまでに、Mojoプログラミング言語とAIアプリケーションの構築方法についての堅固な理解と、AIコーディングの世界へのさらなる探求の基盤を持つことができます。