サブスクリプションの価格変更は一大イベントですが、頻繁に実施するものでもないためその手順についての情報は多くありません。
本LTでは実際に価格変更を実施した経験に基づき、見落としがちな罠や、Tipsについてご紹介します。
・ 申請手順と必要な確認事項
・ 新規 / 継続ユーザーへの価格変更の反映タイムライン
・ サマータイムの罠
・ 価格の変更時刻を厳密にコントロールするTips
価格変更の際にはこれを思い出せば大丈夫!という内容をお届けします。
リリース前のE2Eテストを、実サービスに適用可能なレベルで運用するには、ツールを導入するだけでは不十分です。
SwiftUI・UIKit・WebView が混在するiOSアプリにAppiumを用いたE2Eテストを導入・維持する中で直面したさまざまな課題と、それをどう解決してきたかを本セッションでご紹介します。
まず、accessibilityIdentifierの管理が煩雑になった問題です。
画面ごとにidentifierの付け方がバラバラで、統一された基準がないためにテスト実装時に混乱が生じていました。
この問題をプロジェクト内でどのように整理し、テストしやすい構造に落とし込んでいったのかをお話しします。
最後に、複雑なUIフローに起因するflakyテストの問題です。
日付選択 → オプション選択 → 決済画面への遷移 → WebViewでのメッセージ受信など、状態変化が多いフローにおいて、テストの安定性を確保するために取った構造的アプローチを紹介します。
3つ目は、E2Eテストをリリースフローに安定して組み込むための課題です
テスト実装 → 実行 → 結果確認 → QA → リリース、という一連のプロセスをどのように定着させたのか、実際のチーム運用をもとに共有します。
テスト自動化ツールを導入したものの、信頼性のあるテスト体制を作れずに悩んでいる方や、複雑なUI構成の中でテスト運用に課題を感じている方にとって、少しでもヒントとなれば幸いです。
AI Agentの進化によって、「Design to Code」への期待値が大きく高まっています。
その動きを受けて、Figmaで作成されたデザインを元に、GitHub Copilot Agentを活用してSwiftUIコードを自動生成する取り組みを行いました。
精度向上のためにコンテキスト整備(ディレクトリ構造、コード規約、TCAの実装パターンなど)やプロンプト最適化(実装計画や注意事項の指示追加など)を試みましたが、リスト表示の消失やアイコンがそのまま残るなど、UIの再現度が著しく下がってしまい、期待通りにAgentが動いてくれないこともしばしばでした。
これらの課題をどのように解決し、どのような結果が得られたのか、AI Agentを使いこなすために得られたヒントをお話しします。
世の中にはBuy Me a Coffeeのように、クリエイターが寄付・投げ銭を受け取るためのサービスがあります。
しかし、そうしたサービスはユーザーを決済可能なWebページに誘導することになるため、iOSアプリにそれらのリンクを掲載することはAppleの規約により禁止されています。
それを踏まえると、「広告を載せるのはアプリの世界観に影響を与えるから避けたい。でも収益源が無いからせめて寄付や投げ銭を受け取りたい」と考える開発者は、アプリ内課金で似た仕組みを作る必要があります。
本トークでは、個人開発アプリに実際にユーザーから寄付・投げ銭を受け取るためのアプリ内課金を実装し、今年約50のユーザーに課金していただいた私が、その実装と実績を振り返ります。
具体的には特に工夫した三点(金額設定UI、ライティング、課金に対するフィードバック)について、その意図と実装、および実際に運用して感じた良かった点と改善点を共有します。
それぞれの詳細は以下の通りです。
・課金額の設定UIについて:ユーザーがどのように課金額を決定できればスムーズかを考える
・ライティングについて:ターゲットとするユーザー層によっては「コーヒーをn杯贈る」というよくある表現が、その分の投げ銭を意味するということが伝わらないのでは?という疑問から考える
・課金直後にユーザーに返すフィードバックの必要性について:消耗型課金だが、何かアイテム数のようなものが変化するわけでもない課金のフィードバックはどうあるべきか、Buy Me a CoffeeやYouTubeのSuper Chatの体験から考える
visionOSやAndroid XRの登場により、私たちアプリ開発者にも「空間をデザインする力」が求められる時代になりました。
そこで注目したいのが、オープンソースの3D編集ツール「Blender」です。
このLTでは、開発者が知っておきたいBlender活用術を紹介します。
「ちょっと触ってみようかな」と思えるきっかけを5分でお届けします!
Swiftでは、Arrayに対してfilterやmapをつなげた宣言的な記述をよく使いますが、「この書き方で実行速度は大丈夫?」と感じたことはないでしょうか?
このLTでは、users.filter { $0.isActive }.map { $0.name } のような典型的な記述を対象に、filterやmapをつなげた場合の処理速度を、書き方の違いによって比較検証した結果を交えて紹介します。
ちょっとした記述の違いやlazyの有無によって意外な差が生まれ、期待通りに高速化されないケースもありました。
実際のコード例や計測結果を交えながら、宣言的コードとパフォーマンスのバランスをどう考えるかについてお話しします。
「lazyは速いと思ってたのに…」そんな小さな驚きと発見をお届けします。
再帰って便利ですよね。関数の最後に再帰呼び出しを置く「末尾再帰」なら、スタックも節約されて、ループと同じくらい効率的に動く。
そんなふうに信じていた時期が、私にもありました。
「末尾再帰なら安心!」と信じて書いたSwiftのコード。動作確認もOK、見た目もスッキリ、ところがある日、ちょっと大きな値を渡しただけでStack Overflowで爆死!
何が起きたのか? 調べてみると、Swiftは末尾再帰の最適化(TCO)を保証していないらしいです!
しかも、見た目的には末尾再帰に見えるのに、ちょっとした演算の影響で最適化されないことも。
このLTでは、そんな「Swiftの末尾再帰、信じすぎ注意!」という話を、実際に書いて動かして試してみた結果とあわせて紹介します。
なぜStack Overflowが起きたのか?
末尾再帰が最適化される場合とされない場合の差は?
今は大丈夫なコードでも、未来永劫ずっと安全?
楽しく聞いて、明日から「ちょっと再帰が心配になる」。
そんな5分をお届けします。
とある開発期間1年・iOSメンバー5人の長期アプリ開発プロジェクトにおいて、QAでの不具合発生率を普段の半分以下の2%に抑えることに成功しました。
この要因の1つはメンバー全員が「小さなPull Request」を作り続けてきた事です。
「小さなPR」は品質向上と開発効率に大きく貢献するのです。
「PRは小さければ小さいほどレビュワーに優しく、早くマージされ、バグ発見率も向上する」という原則を深掘りします。
多くの開発者が「差分行数」でPRの粒度を判断しがちですが、本当に重要なのは「関心事の少なさ」です。
ユニットテストやXibの差分でPRが膨らんでもレビューが苦にならないのは、関心事が少ないためです。
本セッションでは、具体的な画面実装の例を挙げ、API層、UIコンポーネント、通信処理など、関心事ごとにPRを分割する具体的な戦略を詳細に解説します。
このセッションを通じて、チーム全体の生産性とプロダクト品質を向上させるヒントを持ち帰っていただければ幸いです。
AIコーディングがiOS開発でも注目される中、visionOSの空間アプリ開発にもClaude Codeを使って挑戦してみました。
SwiftUI × RealityKitでの開発は一筋縄ではいかず、空間体験の構築には想像以上の試行錯誤が必要でした。
コーディングだけでなく、3Dモデルは生成AIやBlender MCP、Skyboxは画像生成AI、効果音は音声生成AIに任せ、アセット面でもAIをフル活用。
さまざまな壁にぶつかりながらも、AIと二人三脚で空間アプリを形にしていく中で得た知見をお伝えします。
このトークでは、VisionフレームワークのOCR機能とCoreMLのシンプルなテキスト分類モデルを活用し、レシートの自動仕分けに挑戦した事例を紹介します。
画像からテキストを読み取り、正規表現を用いて金額を抽出し、商品名をカテゴリに分類するプロセスについて解説します。
複雑な前処理や高度なモデルを用いず、どれだけシンプルな仕組みで実用化に近づけるかを探求した結果を共有します。
手軽に試せる手法であるため、個人で家計簿や経費精算の自動化アプリを作成したいと考えている方々にとって、有益なヒントとなることを目指しています。
@Environment(.keyPath)、それはSwiftUIが提供しているデータフローの仕組みの一つであり、SwiftUIでアプリを組んでいるエンジニアで、これを全く使ったことがない人はいないでしょう。
ところが、あなたは本当に@Environment(.keyPath)を正しく使っているのか?もしくは@Environment(.keyPath)の実力を知ってて使っているのか?@Environment(.keyPath)の思わぬ落とし穴に陥ったことありませんか?
このLTでは、そんな@Environment(.keyPath)にまつわるクイズを集め、ぜひ会場の皆さんに挑戦していただきたいです!そして全問正解の方は、「@Environment(.keyPath)王」の称号を授けましょう(嘘)!
日々の開発の中で「この処理をBuild時やCIで実行しておきたい」と思い、自作コマンドを作ってる人は少なくないと思います。
しかしながら、自作のツールをチームに共有する手法が確立していないという問題があります。
毎回メンバーにビルドしてもらうのは避けたいですし、バイナリを配布するのはhomebrewのtapを作ったりする必要があったりとなかなか面倒でした。
SwiftではartifactbundleとCommandPluginを活用することでサードパーティのツールに頼らず、ビルド済みのバイナリを配布し実行することができます。
このトークではSwiftツールチェインだけでSwift製バイナリを配布・実行する方法について紹介します。
本文の提案:
アプリ開発で、バックエンドAPIの準備が整っていないために、モックサーバ構築に多くの時間を費やした経験はありませんか。
本セッションでは、iPhoneを活用して軽量なHTTPサーバを動作させ、開発中のアプリが必要とするAPIを迅速に提供する手法を紹介します。
この手法は、複数クライアントを捌く本格的なサーバではなく、1対1で開発中のアプリとペアリングするシンプルな構成であり、手軽に導入できる点が特徴です。
従来のモックサーバ構築では、APIスキーマの定義、レスポンスデータの準備、サーバ環境の構築など、多くの工程が必要でした。
しかし、iPhoneサーバアプリを使用することで、これらの課題を効率的に解決できます。
このセッションで話すこと:
対象者:
UIテスト時にUI要素を特定するための識別子であるAccessibility Identifierですが、SwiftUIのViewにAccessibility Identifierを指定するには各Viewに accessibilityIdentifier Modifierを適用する必要があり、テストケースの増加に伴いModifierの適用が面倒になってくるという課題があります。
Swift 6.0から「SE-0415: Function Body Macros」という、既存の関数の中身を書き換えることができるSwiftマクロが導入されました。本トークでは、Function Body Macrosを使ってSwiftUIのViewにaccessibilityIdentifier Modifierを自動で付与する方法と、実装時に遭遇した落とし穴とその回避策についてご紹介します。
Accessibility Identifierを自動付与することで、accessibilityIdentifier Modifierを各Viewに適用する煩わしさから解放されましょう!
話すこと:
「暑い日にスマートフォンを使っていて、アプリの動作が遅くなった…」そんな経験、ありませんか?
特に屋外で利用されるアプリにとって、端末の温度はユーザー体験を大きく左右する重要な要素です。
スマートフォンが熱を持つと、アプリのパフォーマンスが著しく低下したり、一部の機能が制限されたりすることがあります。このような影響を把握しておくことは、快適なサービス提供のために非常に重要です。
本LTでは、Foundationフレームワークに含まれる ProcessInfo.ThermalState API に注目します。このAPIを使うことで、デバイスの熱状態を4段階で把握することが可能です。
今回は、実際に屋外で利用されるモビリティアプリにおいて、春から夏にかけてThermalStateがどのように変化するのかなど、実測データと共にご紹介します。
さらに、端末が高温になった際にアプリが取ることができる対策についても触れます。
スマートフォンを「熱中症」から守り、夏でもクールで快適なユーザー体験をお届けしましょう!
広島という地方生まれの私がパソコンを触るようになったのはExcelでお小遣い管理を始めたのがきっかけでした。そこからVBAを触ったりブログを作ったり、Webサービスを開発するようになりました。最初は書籍を通じて学べていたものの、次第に相談できる人が必要になりました。でも周りに詳しい人はいませんでした。
そんな時出会ったのが地域のITコミュニティでした。
メンバーに相談していく中でカンファレンス運営に携わる機会やインターンを紹介して頂くこともできました。
今、僕が都内でiOSエンジニアとして働くことができるようになったのはコミュニティ活動によるものが大きいと実感するようになりました。
上京や転職など私の人生に大きく影響しているITコミュニティ活動について変遷を紹介します。
iOSDCをはじめとするカンファレンスやSwift愛好会などのコミュニティなどは基本的に有志のメンバーが活動・運営しています。
このセッションを通して少しでもコミュニティに興味を持っていただけると幸いです。
日々の開発作業でシミュレータを操作する際、細かな手間が積み重なって、貴重な時間を奪われていませんか?
「ダークモードの表示を確認したいだけなのに、ホーム画面に戻って、設定アプリを開いて、デベロッパメニューをタップして…。」
「プルリクに添付する動画を撮りたいけど、QuickTime Playerを起動して、収録範囲を選ぶのが地味に手間…。」
そんな、誰もが経験する「ちりつも」な手間に、貴重な開発時間を奪われていませんか?
もし、その面倒な操作がキーボードショートカット一発で片付いたら、どうでしょう?
例えば、あれだけ手間だったダークモードとライトモードの切り替えも、たった一つのコマンドで瞬時に行えます。
本トークでは、このように日々の動作確認を劇的に効率化する、選りすぐりのショートカット術をデモを交えて紹介します。
画面の回転やスクリーンショットといった基本技はもちろん、意外と知られていない2本指操作やシェイク操作など、知っているだけで開発体験が格段に向上するテクニックを厳選しました。
このセッションを聴き終えれば、あなたはもうマウスに頼ることなく、キーボードだけでシミュレータを自在に操れるようになります。開発をもっと快適に、もっと集中できる時間にしましょう。
※ 本セッションは非常に真面目な内容となっております
iOSアプリ開発において画像リソースを格納することは多々あるかと思います。
でもその格納するファイルの形式や内部の構造について正しく把握していますでしょうか。何も考えることなくPDFやSVG形式にしていませんか?
ファイル形式や方法を間違えるとたった100KBの画像を格納したつもりでも、アプリサイズを30MB増えたりする可能性もあります。
本セッションでは、普段何気なく利用している画像リソースの拡張子や格納方法について現時点のベストプラクティスを探求し、効率的な格納方法を見つけ出していきます。
我が家はかわいい猫と暮らしています。ネットワークカメラとして設置したGoogle Nest Camは、Google HomeのアプリとWebでカメラ映像をストリーミング視聴可能です。せっかくなのでペットの行動をリアルタイムで把握でき、安心して外出できるように、macOSやvisionOSでも実行可能なアプリが欲しくなりました。Smart Device Management APIとWebRTCを使って、ストリーミングアプリを手に入れましょう。Appleプラットフォームでアプリを実装することで、映像再生に留まらず、自分自身で機能拡張が可能になります。Google Nest Camからの映像をAppleデバイスで解析し、VNDetectAnimalBodyPoseRequest
を使って猫の骨格を検出、かわいいポーズを可視化するアプリを開発しました。
本LTでは「Smart Device Management APIの準備」「WebRTCでの映像接続」「Vision.frameworkでの映像解析」を経て、制御可能なストリーミングアプリを作成する過程をギュッと5分で紹介します。この発表を通じて、ハードウェアとAppleプラットフォーム技術を組み合わせる楽しさをお届けします。
猫は気まぐれ、開発では振り回されましたが、それもまたかわいいものです。
対象聴衆
現代のiOSアプリ開発ではSwiftUIの LinearGradient
や MeshGradient
、CIFilterの linearGradientFilter
などを使えば簡単にグラデーションを実現することができます。
多くの場合はこれらの強力なAPIを使うことで事足りるのですが、イラスト制作におけるグラデーション効果などにおいては、表現の幅を広げるためにより高機能なグラデーション描画を行いたいことがあります。
例えば、虹のような表現を行うためにグラデーションの制御点を複数用意したり、透明色からブラシ色に徐々にグラデーションするような表現が用いられたり、色の変化に緩急をつけるために補間関数を設定するようなケースがあります。
そのようなケースにおいて、既存コンポーネントでは実現することが難しいため、自分でシェーダーを記述して実現することになります。
このLTでは上記のような高度なグラデーションをAppleプラットフォーム向けのグラフィックスAPIであるMetalを利用して行った話と、その際にハマった透明色の扱いについて紹介します。