2024年6月12日、「スマホ特定ソフトウエア競争促進法」が可決され成立しました。
これによりApp Store以外のストアからアプリをインストールする「サイドローディング」が義務化されることになります。
もしサイドローディングが認められると、どのような変化が起こるでしょうか。
アプリ配信者として、どのような選択を取るべきなのでしょうか。
新法成立の影響が身近なところにまで及ぶかもしれません。
改めてこのタイミングで、アプリ配信を取り巻く社会的な動きを知っておくことは、将来の備えとして大事なことだと考えます。
本セッションは、サイドローディングの賛否について、提言するものではありません。
新法に対する様々な意見を整理しながら、法律の内容や目的について理解を深めた上で、
先行するEUを事例として、これから起こりうる変化を想像します。
Appleが発表したスマートホーム規格の「HomeKit」に対応しているアクセサリは、iOSやmacOSの『ホーム』アプリやコントロールセンターなどから操作できるという、他のスマートホーム製品にない強みを持っています。
しかし、日本国内でよく知られているスマートホームのメーカーの中で、HomeKitに対応している製品を出している企業は非常に少ないという課題があります。
このポスターセッションでは、HomeKit非対応のアクセサリを『ホーム』アプリに追加する方法であるHomebridgeとMatterに焦点を当て、私自身が実際に構築した『ホーム』アプリで一元管理できるスマートホーム環境を紹介します。
さらに、現状できることや得意・苦手な点を説明し、これからスマートホームを始める際のおすすめの方法を解説します。
このセッションを通じて、私自身がスマートホーム環境の構築で感じた課題感をもとに、2024年夏現在の国内のスマートホーム事情をキャッチアップできる内容をお届けします。
Swift 5.9からSwift Macroが使えるようになり、iOSアプリ開発の現場でもその活用が進んでいます。Swift Macroは手作業で書く必要があったコードを自動生成できボイラープレートを減らす上で非常に有効です。
このポスターセッションでは、
Swift Macroの簡単な概要と従来のコード生成系ライブラリにはない長所を説明し、私が公開した超絶便利なswift-property-nameというSwift Macroの実装について詳しく紹介します。
このセッションで取り上げない内容として、Swift MacroのFreestanding MacroとAttached Macroのさらに細かい分類については触れません。さらに、コンパイル時間はどうなるのか、手作業でボイラープレートを書くほうが温かみがあるではないか、などの話題にも触れません。それらの話は、他のセッションに期待したり、各種ドキュメントを参照していただくのが良いと思います。
私が今回話すのは、複数あるSwift Macroの実装方法のなかで、私が何を考えてそのような実装にしたのかだけです。このトークを通じてみなさんのiOSアプリ開発の効率化にも何かしら役立てていただければ幸いです。
The Composable Architecture(TCA)はiOSアプリ開発において関数型スタイルの原則を取り入れているOSSのフレームワークでありライブラリです。このポスターセッションでは、2020年5月にv0.1がリリースされ現在まで4年を経過しアップデートされ続けているTCAの良さを整理します。
そもそもiOSアプリ開発においてフレームワークが何の役に立つのでしょうか?現代はSwift Concurrencyがあり非同期処理は簡単に捌けます。SwiftUI.ViewもあるんだからModelという奴をつくりObservationで使えるようにしたり、もしくはObservableObjectにViewModelなんて名前をつけてそれっぽくやったらアプリなんて簡単にできるじゃないですか。さらにXcode 16ではオンデバイスでAIが候補を出してくれたり、Swift Assistがあなたの代わりにコードを用意してくれます。またSwift Macroによって、より無駄なコードを書く必要もなくなってもいます。
そのような現状で、TCAもSwiftの進化にあわせて進化し、互換性を保ちながら弱点を解決しさらに使いやすくなっています。このセッションでは、iOSアプリの作り方を知っているだけでは解決に至らない課題について説明し、TCAがどのようにそれらを解決するかを具体的に解説します。
業務や個人開発を問わず、機能実装の準備段階や進行中に、GitHubに公開されているコードや動画プラットフォームで提供されるサンプル実装を参考にする機会は多いと思います。しかし、そのようなコードをただ動かして実装を見るだけでは、断片的な理解で終わってしまったり、応用可能なポイントを見逃してしまうことがあります。
私自身もそのような経験をたくさんしてきました。特にiOSアプリ開発において、UI実装や表現に関連する複雑な実装コードを読み解く際には、手書きノートを活用して理解を深めています。具体的には、重要な部分を「簡単な図解と説明を交え、自分の言葉で整理」する取り組みを行っています。
このトークでは、公開されているサンプル実装や私が自主的に取り組んだUI実装を題材に、書き起こした図解や説明を活用した事例を紹介します。これにより、業務や個人開発だけでなく、円滑なコミュニケーションの機会にも応用できる方法をお伝えします。
会場では、これまでにまとめたノートのアーカイブを持参する予定ですので、皆様とインプット術や複雑な実装に向き合う方法について意見交換ができれば嬉しく思います。具体的な事例を元にコードを紐解くアイデアも共有し、積極的なディスカッションを期待しています。
依存関係が複雑なプロジェクトほど、Xcode Previewsビルドに時間がかかってしまいます。ビルド時間を短縮する方法として、Preview用のTargetを作成する方法があります。依存ファイルを減らすことでビルド時間の短縮を狙いますが、Targetを設定するだけでは期待通りに機能しないことが多いです。
例えば、Viewが依存関係が複雑なクラスを参照している場合、そのクラスが依存している全てのクラスをコンパイルする必要があり、更にそのクラスが…のように依存関係が続くと、結局膨大な量をコンパイルするため、ビルドに時間がかかってしまう問題があります。
本ポスターセッションでは、この問題に対する解決策を提案します。
ポスターに掲載する内容
私が担当しているプロジェクトでは、この方法を用いることで、約120秒かかっていた初回のPreviewビルドが約23秒になりました。本セッションを通じてTargetを活用したPreviewビルドの高速化について学ぶと共に、提案した解決策は適しているものなのか、もしくは別の解決策もあるんじゃないかなどを議論できればと考えています。
Visionフレームワークは、Appleが提供する画像処理ライブラリであり、このフレームワークを使うことで、顔認識・テキスト認識・物体検出・画像分類などの画像認識機能を実現できます。例えば、顔認識ではユーザーの顔を検出して認証に使うことができ、テキスト認識ではレシートや書類の文字を抽出することができます。
特にテキスト認識は、画像や動画内の文字を抽出することができ、正規表現という特定のパターンに一致する文字列を探索したり加工するための方法と組み合わせることで、より高度なデータの抽出に利用することが多いです。
みなさんは、賞味期限に様々なフォーマットがあることをご存知でしょうか。例えば、YYYY/MM/DD、MM-DD-YYYY、MM/DD-YYなど様々なフォーマットで商品の賞味期限が表現されています。
本セッションでは、正規表現とテキスト認識を組み合わせた応用例として、賞味期限を画像から抽出してアプリ内で表示・管理する方法を紹介し、実装コードの例も交えて説明いたします。
このセッションを通して、賞味期限をアプリ内で管理するための具体的なTipsや実装方法を共有します。興味のある方は、ぜひ一緒にお話ししましょう。
皆さんのプロジェクトのディレクトリ構造は綺麗な状態ですか?
ディレクトリ構造は、プロジェクト初期には綺麗に整理された状態でも、ルール化や継続的なメンテナンスがされなければ徐々に複雑化していきます。
私が開発しているiOSアプリのプロジェクトはリリースしてから10年以上経ちますが、機能追加やアーキテクチャの変更に伴い、ディレクトリ構造がカオスな状態になっていました。
本ポスターセッションでは、そんな10年以上続くプロジェクトのディレクトリ構造をどのように整理したか、その過程と得られた知見を詳しく説明します。
ポスターに掲載する内容
本セッションを通じて、あなたのプロジェクトのディレクトリ構造も整理するきっかけにしませんか?
皆さんのプロジェクトのディレクトリ構造は綺麗な状態ですか?
おそらくすぐに「YES」と答えるのは難しいかもしれません。ディレクトリ構造は明確なルールが無いと、時間とともに複雑化しがちです。私が担当しているプロジェクトもその一例で、基本的なアーキテクチャの方針に基づいた大まかなルールはありますが、具体的な配置は各開発メンバーの裁量に任されています。その結果、時間とともに複雑化してしまいました。
今回、そんな複雑化したディレクトリ構造を整理し、どのように配置すれば最適かを考えてみました。
現状の構造を俯瞰することで見えてきた課題や、実際に適用してみてわかったアンチパターン、未だに悩んでいる配置についても共有します。
ディレクトリ構造の配置については正解がないと思います。各プロジェクトに応じた最適解があり、個々の考え方も異なるでしょう。本セッションでは、私が担当しているプロジェクトを一例として取り上げ、「こんなルールもいいんじゃないか」、「そのルールだとこういう問題も出てくるんじゃないか」などを議論し、ディレクトリ構造の整理とルールについて深く考える機会にしたいと考えています。
みなさん個人開発を楽しんでいますか?
このセッションでは SwiftUI が発表されてから5年間で私が作成した25個の個人開発アプリから 成功と失敗、そしてそれらがもたらした利益や学びを振り返ります!
ぜひこのポスターセッションに参加して、一緒に「ああでもない」「こうでもない」とざっくばらんに議論しましょう!
何気ない会話から新しいアプリのアイディアが生まれるかもしれません。
Appleの新しいデバイスVision Proの登場により、従来のiOSの平面的な表現とは異なる3次元的なUI戦略も進み、3Dモデルの需要が急増しています。その際、Apple独自の3Dファイルフォーマットである.usdzを利用する機会も増えていくと予想されます。
本セッションでは、usdzファイルの特性やメリットの説明から、作成方法、表示方法など、usdzを利用するために必要な知識を網羅的にまとめます。このセッションを通じて、参加者がusdzファイルを開発者として効果的に利用できるようになることを目指します。
さらに、Unityを用いてusdzファイルを利用する方法や、サーバー上にある3Dモデルをアプリケーションで描画する際のTipsなど、私がusdzファイルを使用して得た実践的な知見を共有します。
SwiftUIでのアプリ開発では、フォントの指定はText("Hello").font(.title)
のように簡単に行えます。
しかしこの方法では、SwiftUIフレームワークのフォントスタイルをそのまま使うため、特にAndroidアプリも開発するようなチームでは、デザインの一貫性を維持しつつ効率的に開発を進めることが難しくなります。
本セッションでは、カスタムのフォントスタイルとモディファイアを定義し、一貫性のあるUI実装をより効率的に進める方法を紹介します。
具体的には、以下の内容について、コードを交えて解説します。
これらの工夫により、iOSエンジニア以外のメンバーとのコミュニケーションが円滑になり、デザインの一貫性を保ちながら効率的にアプリ開発を進められるようになります。
本セッションを通して、チーム開発をより円滑に進めるヒントが得ることができます。
モバイルアプリにおいては、ユーザーの操作に応じた適切なフィードバックを提供することが重要です。しかし、UIAlertControllerを使ったアラートの表示は、時としてユーザーの操作を阻害することがあります。
本セッションでは、Material Designで定義されているSnackbarコンポーネントに着目します。
Snackbarは、ユーザーの操作に応じた短いメッセージを素早く表示するのに適しており、取り入れることで操作完了時やエラー時のメッセージ表示をスムーズに行える効果が期待できます。
本セッションではまず、Snackbarの基礎概念や利点、アラートとの違いを整理して解説します。
続いて、VIPERアーキテクチャのiOSアプリを例に、軽量なSnackbarを設計・実装するためのポイントを、具体的なコードを交えて紹介します。
Snackbarを活用することで、ユーザーとのコミュニケーションをより円滑にし、ユーザー体験を向上させることができます。
本セッションが、iOSアプリ開発におけるユーザーインタラクションの設計の選択肢を広げるきっかけになれば幸いです。
SF Symbolsが発表されてからしばらく経ちますが、私の所属組織ではいまだPDFでのアイコン作成/iOSアプリへの取り込みが主流でした。また開発観点から見ても、5,000以上の多様なアイコンをあらかじめ揃えたSF Symbolsの活用は、スピードの求められるグロース開発とも相性がいいことがわかっているのに、適用の下準備が整っていませんでした。
そこで今年、開発側のSF Symbols利用の土台作りとともに、デザイン側のカスタムシンボル作成のワークフロー整備をおこないました。
このポスターセッションでは、カスタムシンボルを使ったオリジナルアイコンの作成方法や、SF Symbols.appへのSVGデータの取り込み/加工のデザインワークフローの作成、更にデザイナーとエンジニア間のデータのやり取り方法を整備した事例を紹介予定です。
実際にデザイナーがSF Symbols.appを利用してみると思わぬ落とし穴にハマったり、想定外の動きをしたりしました。また、アイコン作成者(デザイナーごと)に依存する形状のブレが生じないよう、Adobe Illustratorのガイド機能を利用したプロセス調整なども行っています。これらの整備をする上で、SF Symbolsに込められたVariablesの思想なども見えてきたため、Tipsもまとめます。
技術カンファレンスは様々な方がそれぞれの形で貢献し作り上げるイベントです。
公式サイトや公式アプリはイベントの内容や方針がよく表れるものであり、その開発はITエンジニアならではの貢献のひとつです。
オープンソース化されているものならば使用されている技術も必見です。iOSアプリエンジニア、もしくはAndroidアプリエンジニアとしてソースコードを読んだり実際に開発に参加したりした方も多いでしょう。
毎年ゼロから開発している公式アプリであればその年の最新の設計や流行のライブラリを窺い知る貴重な資料になります。
本ポスターセッションでは、カンファレンスの公式iOSアプリを通してカンファレンスについて考えます。
ポスターに掲載する内容
対象カンファレンス
このポスターセッションが技術領域の垣根を超えた交流やカンファレンスへの貢献の促進につながれば幸いです。
macOS上で動作するIMEを開発するために、Appleが公式で提供するInputMethodKitを利用して開発しました。
InputMethodKitでは主に、IMKInputController、IMKCandidates、IMKServerの3つのクラスを使い開発します。実際の開発中に、特にロジックが集中するIMKInputControllerのコードが肥大化し、コードの見通しが悪くなるという問題に直面しました。他にもIME開発特有のデバッグの煩わしさもありました。
そこで、コードの見通しをよくするためにThe Composable Architecture(TCA)を導入し、IMEのデバッグの煩わしさを軽減するために、fastlaneを使った自動化や、Repository層とUseCase層を採用したマルチモジュール構成で開発する方針を採用しました。
これらについて実際に書いたコードと一緒に以下の内容について解説します。