去年のiOSDCのパンフレットでは、私は@Environment(.keyPath)について、入門から実践の応用まで、さまざまな活用法を紹介しました。8ページにも及ぶボリュームでしたが、おかげさまで非常に好評をいただきました。
ところがそれが@Environment(.keyPath)の全てだと思いました?いえいえ、@Environment(.keyPath)の底力はまだまだそんなものではありません!
今年は、その更なる高みを目指して、いかに@Environment(.keyPath)を使ってスッキリしたアーキテクチャを作れるか、ご紹介していきたいと思います!刮目せよ、@Environment(.keyPath)の真の実力を!
Swift 6がリリースされてからまもなく1年が経過しようとしていますが、数々のUpcoming Feature FlagsやStrict Concurrency Checkingによる影響度合いの大きさからSwift 6モードに完全移行が叶ったプロダクトはまだまだ多くないのではないでしょうか。
そしてそれはOSSとして公開されているライブラリも同様です。
一方、Upcoming Feature FlagsやStrict Concurrency Checkingは段階的に適用させることが可能です。
そしてそれらはPackage.swiftの差分として可視化できます。
本稿では、Swift Packageで公開しているライブラリをSwift 6に対応させるためにPackage.swiftを魔改造した過程を紹介します。
WWDC24で発表されたSwiftとJavaの相互運用に興味を持ち、Xcode 26とSwift 6.2の環境で試行を重ねています。本トークでは、筆者が入門時に直面した課題や解決策を紹介し、これからSwiftとJavaの相互運用を始めたいと考えている方々がスムーズに学習を進められるよう、具体的なステップとポイントを分かりやすく説明します。特に、開発環境の構築から基本的な相互運用の実装方法、よくある問題とその対処法について詳しく解説します。興味を持っている皆様が第一歩を踏み出す手助けとなれば幸いです。
皆さんのアプリは、アクセシビリティに配慮したアプリになっていますか?
アクセシビリティ対応は、多くのユーザに使いやすいアプリを届けるための重要な要素です。
2025年AppleはApp Storeの製品ページにAccessibility Nutrition Labelsを導入することを発表しました。
これにより、アプリをインストールする前にアプリが対応するアクセシビリティ機能を確認できるようになり、アクセシビリティ対応への注目はますます高まっています。
https://www.apple.com/jp/newsroom/2025/05/apple-unveils-powerful-accessibility-features-coming-later-this-year/
しかし、実際にアクセシビリティ対応に取り組もうと思っても
「対応が難しそう」
「どこから始めればいいかわからない」
「時間がかかりそう」
と感じる方もいるかもしれません。
実は、数行のコードでアクセシビリティ対応を始められます。
本パンフレットでは、そんな開発者に向けてSwiftUIで使用できるアクセシビリティ対応のためのModifierとユースケースについて紹介します。
アクセシビリティ対応を始めて、皆さんのアプリをより多くのユーザに届けられるようにしませんか?
iOSDC Japan 2020 よりパンフレット記事の公募が始まり、私は 2020 からこれまでほぼ毎年のようにプロポーザルを応募してきました。
過去、 1 度だけ同人誌を作った程度で印刷物の制作経験が少ない状態からのスタートでしたが、原稿制作ガイドに記載されている内容を理解した上で納得いくレイアウトへ落とし込めるようになるまでには様々な試行錯誤がありました。
また、社内メンバーと一緒に応募した際にはそれまで個人で利用していたツールとは別なツールに変更して入稿したこともありました。
本記事では、私のこれまでのパンレット記事に関する経験を元に、パンフレット原稿を入稿するまでの流れやパンフレット原稿執筆の魅力についてご紹介します。
想定読者:
目次:
少しでも多くの方がパンフレット原稿の執筆にチャレンジするきっかけとなれば幸いです。
アプリ開発において、エラー管理は重要な課題です。多くの場面で Error や NSError を利用した経験がある方も多いのではないでしょうか。
Error は Swift のエラーオブジェクトで、プロトコルとして定義されています。また NSError は Objective-C のエラーオブジェクトで、クラスとして定義されています。NSError を初期化する際には、domain、code、userInfo の 3 つを指定でき、エラーの種別を識別したり、エラーに関する付加情報を追加したりすることが可能です。Error を NSError にキャストしたい場合には、as NSError を用いることで、安全にキャストすることができます。それでは、キャストした際に、Error の情報が NSError の domain、code、userInfo にどのように引き継がれるのでしょうか。例えば、Error が Struct で実装されている場合、NSError に変換した際の code は 1 で固定されます。一方で、Enum で実装されている場合、変換した際の code は case の定義順や associated value の有無によって動的に変わります。
本記事では、Error を NSError に変換する際の振る舞いを LocalizedError や CustomNSError なども交えながら解説します。さらに、この知見を活かし、Firebase の Crashlytics に情報量豊かな非重大ログを送信する方法も紹介します。
Xcode は多機能な統合開発環境ですが、日常的に使えるショートカットを把握しているかどうかで、開発スピードとストレスの量が大きく変わってきます。
この記事では、実際に現場で「よく使う」「使うと効率が上がる」Xcodeショートカットを厳選し、一覧形式で紹介します。
以下のような項目を収録予定です:
初心者から中級者まで、「Xcodeを使っているけれど意外と知らない」という方々に向けて、すぐに試せるTipsとして活用いただける内容を目指しています。
ショッピングサイトの商品リンクをタップしたら、ブラウザではなく専用アプリがスッと開いて商品ページが表示された体験はありませんか?
この快適なユーザー体験は「Universal Links」という技術で実現されています。
ユーザーにとっては非常に便利な一方、開発ではWebサーバーに apple-app-site-association (AASA) という、アプリとサイトを紐付けるためのJSONファイルを設置する必要があるなど、導入には特有の知識が求められます。
この設定が正しくないと「リンクをタップしてもアプリが起動しない」という問題が発生します。特に、一度設定した後に「変更内容がなぜか反映されない」といったトラブルは、CDNのキャッシュが原因であることも多く、多くの開発者が頭を悩ませるポイントです。
この記事では、Universal Linksの仕組みといった基本から、AASAファイルの書き方、そして「落とし穴」であるCDNキャッシュについても詳しく解説します。
RealityKit は Apple の 3D フレームワークです。iOS、iPadOS、macOS、tvOS、visionOS で利用でき、特に Vision Pro での 3D 体験の実装に注目されています。
この RealityKit では、Entity Component System(ECS)設計パターンを採用しています。ECS パターンは、ゲーム開発やシミュレーションで広く使われるデータ指向の設計パターンですが、アプリ開発者にとってはあまりなじみがないでしょう。
ECS パターンとは、アプリケーションオブジェクトを Entity、Component、System の 3 要素に分割する設計パターンです。Entity はゲーム世界の中の「物」を表す識別子、Component は Entity に付与する属性や状態、System は Component に対して実行するロジックです。従来のオブジェクト指向では、データと振る舞いをクラスにまとめていましたが、ECS ではデータ(Component)と振る舞い(System)を分離します。このアプローチによって、オブジェクトが軽量になりパフォーマンスが向上します。また、拡張性が高い仕組みでもあり、RealityKit の機能追加は Component の追加という形で行われます。
本記事では、RealityKit の ECS の考え方をコードを挙げながら具体的に説明します。そして、RealityKit の Component を活用する例、特に図形を描画する例をいくつか紹介します。
この内容は、RealityKit に触れたことがない方の入門として、また少し触れたことがある方の理解を深める一助となるでしょう。
iOSDC2021以降、SPMマルチモジュール構成をプロジェクトへ採用するサービスが多く見られます。
マルチモジュール構成では、小さくモジュール分割を行い依存を疎結合に保つことでビルド時間の短縮が期待できますが 画面遷移時にFeatureモジュール同士で呼び出しを行い、依存関係が密結合になっている場合、ビルド時間の短縮が効果的ではありません。
本パンフレットでは、Protocolに各画面の生成処理を記述し、swift-dependenciesを使い遷移先画面をDIする手法を紹介します。
これによって、SPMマルチモジュールにおいて、疎結合な画面遷移が可能となり、ビルド時間の短縮が可能となります。
また、複数のDI手法や画面遷移実装を比較し各手法のメリットデメリットを紹介していきます。
以下の順番に従い、各実装の問題点と解決策を交えながら説明します
GraphQLは、API用のクエリ言語およびそのランタイムであり、単一のAPIエンドポイントに対してクライアントがデータ取得のためのクエリを準備することで、柔軟にデータを取得できます。Apollo iOSは、GraphQLクライアントの実装の一つであり、ApolloはKotlinやJavaScriptを含む多くのプラットフォームでも一般的に利用されています。本記事では、Apollo iOSを用いたクライアントの参考実装を通じて、GraphQL APIの基本概念を学べるようにします。
この記事では、以下のトピックをカバーします。
各トピックについて具体的なコード例を交えながら、わかりやすく解説します。この記事を通じて、参加者がGraphQL APIとApollo iOSの基本的な使い方を理解し、実践に役立てることができるようになります。
iOSアプリ開発のデファクトスタンダードとなったライブラリ管理ツールCocoaPodsは、Swift Package Managerの成熟によりメンテナンスモードへと移行します。その主要リポジトリは2026年にはリードオンリー化が予定されており、事実上の開発終了フェーズに入ることになります。しかし、その影響と功績はAppleプラットフォームに限定されません。
本稿では、CocoaPodsがいかにiOS開発のライブラリ管理を簡素化したかを振り返ります。そして、CocoaPodsがなぜRubyで作られたのかについても掘り下げます。さらに、CocoaPodsのために開発された依存解決アルゴリズム「Molinillo」が、そのインスピレーション源であるRubyの主要パッケージマネージャーBundlerやRubyGemsに採用され、Rubyコミュニティを長年苦しめた依存関係地獄を大きく改善したという逆転現象に焦点を当てます。
CocoaPodsがSwift Package Managerへと主役の座を譲りつつある今、iOSアプリ開発を支え、Rubyエコシステム全体を変革したその物語を紐解き、パッケージ管理の重要性を再考する機会を提供します。
徳島大学で学生の60%以上が使っているiOSアプリ「トクメモ+」。
本稿では、開発・運用・譲渡までの実践知を共有します。
大学生活の中で感じた「使いづらさ」を、誰も解決しないなら自分がやる。
そんな思いから始まったのが、学内システムを一元化するiOSアプリ「トクメモ+」の開発です。
「ログインのたびに毎回IDとパスワードを入力」「講義資料・履修情報・時間割がすべて別サイト」など、日々の小さな不便を一つずつ解消することで、口コミを通じてユーザーが増加。大学側のサポートもAPIもない中で、MAU 3500人に使われるアプリへと成長しました。
本稿では「どう作ったか」だけでなく、以下のような実装・運用・引き継ぎの工夫も紹介します:
大学からサポートが無くても、お金がなくても、個人でも、価値あるプロダクトは作れる。
そんな実例として、学生開発や個人開発に関心のある方々にヒントを届けられたら嬉しいです。
Skipは、SwiftだけでiOSとAndroid向けアプリを同時に開発できるマルチプラットフォームツールです。
皆さんが愛してやまないSwiftを使いつつAndroidアプリを開発できるなんて、魅力的すぎて日本のiOSアプリ開発者全員が試したいものだと私は確信しています。
しかし国内での導入事例はまだまだ少なく、詳しく解説された日本語での情報はあまり存在しません。また、Skipの進化が凄まじいこともあり、最新の情報を網羅した解説記事もないと思います。
本記事では、実際にSkipを使ったアプリのリリース経験がある筆者が、Skipの基礎から実践的なTips、リリースに至るまでのアレコレを解説します。
これを読むことで即座にSkipを使ったアプリ開発に取り組むことができ、他では得られないSkipの知見を得ることができます。
本記事を通してSkip入門への壁を取り除き、さらなるSkipの発展につながるよう願っています。
SwiftUIでのWebView実装に悩んだことはありませんか?
従来のWKWebView実装では、UIViewRepresentableでのラッピング、複雑なデリゲート処理、状態管理の同期問題など、多くの課題に直面した方も多いでしょう。
これらの問題を解決するために、WWDC 2025で発表された「WebKit for SwiftUI」をご紹介します。
WebKit for SwiftUIを使用することで、WebViewの実装が驚くほどシンプルになり、数行のコードで簡単にWebページを表示できます。
WebPageクラスを活用して状態を監視し、ページの読み込み状況やエラーを自動的にビューに反映させることができます。
また、Observable対応による自動状態管理、宣言的な設定、強力なJavaScript通信機能を備えており、「シンプルなURL読み込み」から「PDF生成・スクリーンショット・アーカイブ保存」まで、実務で必要な機能を簡潔に実現できます。
もはやWebView実装で悩む必要はありません。
新しいWebKit for SwiftUIを活用して、アプリ開発を次のレベルへと進化させましょう。
WKWebViewを介してWebサイトと連携するiOSアプリを開発する場面では、「アプリのWebViewだけうまく動かない」「表示が崩れる」といったトラブルに遭遇することが珍しくありません。そんなとき、多くのiOSエンジニアがまずWebサイト側に原因を求めがちですが、本当にそれは正しいアプローチでしょうか?
本記事では、iOSアプリのWKWebViewを利用した実装で何が行われているのかを段階的に確認することの重要性をお伝えします。たとえば、CSSの上書きをevaluateJavaScript
から行っていると、意図せずDOM構造を壊し、レイアウト崩れや表示フリーズの原因となる場合があります。また、特定のドメインのみUser-Agentを上書きしていたり、MessageHandler経由で何か処理をしている実装があると、同じWebサイトであっても挙動が変わってしまうことがあります。
こうした点をまずアプリ側で整理・把握したうえで、その後にWebサイト側で意図しない挙動になっていないかを切り分けていくアプローチを、簡単な具体例とともに紹介します。
「この不具合の原因はアプリ側?それともWebサイト側?」と迷ったとき、どこから調査を始めればよいかを、具体例を通じて掴んでいただければ幸いです。
iOS 13からUIFontPickerViewControllerが利用できるようになり、アプリ内でフォントピッカーを提供したい場合に簡単に実装を行うことができるようになりました。
またFonts capabilityによってカスタムのフォントも利用できるようになりました。
しかし、これらの仕組みは任意のフォントを自由にシステムにインストールできるというものではありません。
そのため、ユーザーが用意したフォントをアプリ内で利用できるようにするためには、アプリごとにフォントローダーやフォントピッカーを用意する必要があります。
この記事では以下のような内容を紹介します
Stable Diffusion を活用し、既存のキャラクターイラストから新たな創作を展開する制作手法について紹介します。
取り扱うトピック:
アウトペインティングやマスクインペイントといった主要な画像操作手法に加え、アニメ系イラストに特化した高精細なアップスケーリング手法も扱いながら、Stable Diffusion の具体的な可能性をお伝えします。
「なかなか思い通りのイラストが生成されない」
「何度も作り直しているうちに API リミットに達してしまった」
このような経験をしたことのある方も多いのではないでしょうか。
本稿は、そんなみなさんにとっての“救いの一手”となる、とっておきの 2 ページです。
WWDC25に現地参加してきました!
人生初のWWDC現地参加はとても刺激的でしたが、同時に「ただセッションを見に行くだけなら、現地に行く意味はあるのだろうか?」という疑問も抱きました。オンライン視聴が当たり前になった今、現地参加の価値とは何か?私なりに見つけた答えは、“現地ならではの人とのつながり”でした。
Appleの中の人と直接話せる1on1 LabやDeveloper Sessionの後の会話など、現地ならではの交流機会は貴重です。中でも特に印象的だったのが、「Meet the community」で紹介されているコミュニティ主催の非公式イベントたち。朝活形式の勉強会、開発者同士の雑談会、世界各国のiOSエンジニアとフラットに話せるパーティーなど、その場でしか得られない学びと出会いがありました。
本稿では、私がWWDC25期間中に参加したコミュニティイベントを紹介しつつ、イベントに参加することで得られた知見やつながり、そして次回以降にWWDC現地参加を目指す人に向けたアドバイスを共有します。「現地に行くなら、セッション以上の体験を!」そんな想いを込めた内容です。
私は今年、銀行員からiOSエンジニアへとキャリアチェンジをしました。
最近、「どうやって学習を進めたのか?」「転職までに何をしたのか?」といった質問をいただくようになったため、異業種からiOSエンジニアを目指す方、これからキャリアを築こうとする学生の方、またそうした方をサポートする立場の方に向けて、私自身の経験をまとめて共有したいと思います。
この記事では、独学でどのようにスキルを身につけ、エンジニアコミュニティと出会い、学びを加速させていったのか、そして転職を実現できたかについて、実体験をもとにお話しします。
本記事で紹介する内容:
この記事が、iOSエンジニアを目指す方にとっての道しるべとなり、また誰かにアドバイスをする際のヒントになれば幸いです。