先日 担当しているアプリの譲渡をしたのですよ。
で、よくあるアプリ譲渡の手順で、事前準備もしっかりとして、つつがなく 譲渡が完了!
….と、思っていたのですが、「あれ、このAPIを使うには、Appleに許可がいるの?」という思わぬ事態に遭遇!
具体的には、PassKit
の requestAutomaticPassPresentationSuppression(responseHandler:)
を使っているのですが、これは特別なEntitlementをAppleに申請しないと利用できないAPIだったので、譲渡後に改めて申請をしました。
この経験をきっかけに、Appleに申請・許可が必要なAPI について調べてみたところ、他にも「申請必須API」があることが分かりました。
このライトニングなトークでは、Appleにメールを送信してから、APIが利用できるようになるまでのプロセスと、その他の許可が必要なAPIについてお話しします。
いざ許可が必要なAPIを利用する際に焦りたくない方におすすめです。
Kotlin Multiplatform(KMP)を使うことでかんたんにクロスプラットフォーム開発をすることができます。
最近ではAndroid開発でよく使われている便利なライブラリもKMPに対応し、より一層KMPの開発体験が向上しています。
例えば、ローカルでデータを永続化するためのライブラリ「Room」もKMPに対応しました。
Roomを使って開発をする場合はすべてのコードを共通化できるのではなく、プラットフォームによって実装が違う箇所があり、その場合はactual / expect 修飾子を使って実装します。
プラットフォーム別に動くコードは簡単に書くことができたのですが、テストコードを書こうとすると詰まる箇所があり苦労しました。
本セッションでは、Roomを使って開発する際にプラットフォーム別にactual / expectをどのように実装していくかと、そのコードに対してのテストの実装方法について、具体的なコード例を交えながら紹介します。
皆さんのアプリでは、分析ログを正確かつ漏れなく収集できていますか?
私たちのサービスでも多くのログを送信していますが、かつては実装漏れやデグレによる送り漏れが頻発し、効果測定ができず仮説検証に大きな支障が出ていました。
とはいえ、少人数チームかつiOS・Androidの両対応、さらに限られた予算の中で、導入できる手段には制約がありました。
そこで私たちは、「ログ送信箇所にテストコードを追加する」方針をとることにしました。
この実践により、徐々に実装漏れがなくなり、デグレによるログ欠損も減少しました。
テストコードといえば通常はビジネスロジックに対して書くものという認識があるかもしれません。
「なぜそこにテストを?」と思われるかもしれませんが、設計を工夫すればログ送信にも十分活用でき、ビジネス上の価値も高いと感じています。
本トークでは、ログ送信に対してテストを書くことの効果や実例、そして設計上の工夫についてご紹介します。
ログ品質の担保に課題を感じている方に、実践的なヒントをお届けいたします。
StoreKit 2の登場により、アプリ内課金の実装は以前のStoreKitと比べるとかなり簡単に行えるようになりました。StoreKit ConfigurationやStoreKit Testingといったデバッグ・テスト環境も整備され、開発効率は大きく向上しています。
それだけに留まらず、WWDC 23ではアプリ内課金実装に利用できるSwiftUI向けのコンポーネントやModifierも発表され、UIの実装も提供されているものを使うだけ可能になりました。
その中でも SubscriptionStoreView
というSwiftUIコンポーネントを使うことで、サブスクリプションプランの一覧表示からプランの契約まで、複雑な課金処理のビジネスロジックを開発者が書かずともサブスクリプション機能を提供できるようになりました。
このLTではStoreKit Configurationファイルを用いてテスト用の課金アイテムを用意し、SubscriptionStoreViewを用いたサブスク機能の実装を5分の制限時間の中でライブコーディングを行います。
StoreKitの進化を一緒に体感してみましょう。
皆さん、The Swift Programming Language(通称TSPL)をご存じでしょうか。TSPLは、Swiftの主な特徴や主要な機能を詳しく解説した公式ドキュメントです。
一見すると、Swiftをこれから学び始める方のための入門書のように思われるかもしれません。しかし、実際にはSwiftの深い考え方や、意外と知られていない機能についても学ぶことができます。
Swift6.2のリリースに合わせて、TSPLにはSwiftユーザーがSwiftをより深く理解するための更新が行われています。これにより、現在TSPLに注目しておくことは非常に有益です。
私は2021年にTSPLの日本語版を作成し、それ以降も原文に合わせて継続的に更新してきました。ありがたいことに、私の翻訳はSwift.orgにもリンクされています。
このトークでは、TSPLの構成について詳しく説明するとともに、私がこの経験を通じて感じた、ビギナー、ミドル、シニアエンジニアそれぞれに適したTSPLの読み方について紹介します。
このトークを通じて、「Swiftともう少し仲良くなれそう」と皆さんに感じていただけることを目指しています。ぜひご参加ください。
【あらすじ】
社内で突然始まった、Swift 6対応プロジェクト。
しかし、iOSエンジニアはたった2人。
そのうちの1人は、「自分でやるのは面倒だから」という理由で、すべてをもう1人に丸投げしてしまう。
重すぎる作業量を前に、残されたiOSエンジニアは1人で抱えきれないと判断し、他部署や他社のiOSエンジニアなど、あらゆるリソースに声をかけて助けを求めた。
「Swift 6対応を乗り切るためなら、手段は問わない」
そうして集まった応援メンバーの協力もあり、プロジェクトは加速度的に進んでいく。
しかしその裏で、誰にも気づかれぬまま、少しずつ歯車は狂い始めていた。
ようやく作業が完了し、落ち着いたかに見えたその時、そのiOSエンジニアの前に現れたのは、思いもよらぬ「代償」だった…!?
このLTは「てんとう虫コミックス ドラえもん5巻収録『ドラえもんだらけ』」のオマージュです。
チームでの実装・レビュー遅延やレビューコメントの反映漏れに悩んでいた経験から、Cursorを導入し「実装→レビュー→修正」の開発フローを効率化しました。本発表では、以下の8ステップでCursorを活用し、開発速度と品質を両立できたプロセスを技術的に解説します。
Cursor導入前後でiOS開発が如何ほど効率化されたか、導入を検討中のチームに即活用できる提案をお届けします。
UIKitで長年運用しているアプリに、SwiftUI画面を一部導入する機会がありました。そこで採用したのが、iOSDC2023で紹介された「SVVSアーキテクチャ(Store・ViewState・View)」です。
MVVMやTCAも検討した中で、なぜSVVSだったのか? UIKitコンテキストとの親和性、学習コスト、段階導入のしやすさなど、現場目線で感じた「ちょうどよさ」を共有します。
5分という短い時間ですが、SVVSの魅力と、実際にどうやって導入し、どんな課題があってどう乗り越えたかを簡潔に紹介します。SwiftUIを使ってみたいけどまだ一歩踏み出せていない方、UIKitとの橋渡しに悩んでいる方に刺さる話です!
課題は以下のような内容になります。
・チームメンバーへの理解促進(勉強会・ペアプロ)
・エラーハンドリングが煩雑になる問題
・Storeの強みが活かせない問題
・UIKitからSwiftUIへの遷移の違和感
・UIKitのタブが正しく表示されない問題
「SwiftUIなら、きっとサクサク動くはず!」
そう信じて開発したアプリのスクロールがカクついた時、パフォーマンス改善という大きな壁にぶつかりました。「一体何から手をつければ…?」と途方に暮れたのは、きっと私だけではないはずです。
このトークは、そんな私がXcodeのInstrumentsと格闘し、Viewの描画の仕組みやLazyVStackなどの基本的な知識を武器に、"もっさりUI"を改善していくまでの奮闘記です。
本セッションでは、
を、失敗談を交えながら共有します。
パフォーマンスチューニングは、ベテランだけのものではありません。この発表が、同じ悩みを持つ皆さんの「はじめの一歩」を踏み出すきっかけとなれば幸いです。
ゲーム開発といえばUnityやUnreal Engineが代表的ですが、学習コストやライセンス費用に不安を感じていませんか?
実はApple純正フレームワークだけでも、ゲーム開発に必要な、接触判定・リアルタイム通信・ランキング・ゲームパッド対応など、実用に足る機能群がすべて揃っています。
さらに最近では、iOSのゲーム体験を高めるための公式機能が充実してきており、ユーザーがゲームにアクセスしやすくなるような変化も見られるため、ゲームデバイスとしてのiOSに注目が集まっています。
このトークは、ゲーム好きですが一般のアプリしか作れなかった私が、純正フレームワークのみでオンライン通信対戦ゲームを完成させ、インディーゲームイベントへの出展を目指した経験をもとに、以下のトピックについてお話しします。
Swiftで業務アプリを作っているあなたも、すでにゲーム開発に必要な材料を持っていたのです──
Apple純正フレームワークだけでもここまで「戦える」ということを、実例を交えてお伝えします。
ゲーム開発は特別なスキルが必要──そんな思い込みを、そっと壊す5分間です。
iOSDC Japan 連載4コマ漫画「輝け!俺のViewController」が打ち切r...最終回を迎えたのは、ネタが尽きたからです。
しかし、そんな燃え尽きた俺を差し置いて、Apple Intelligenceは進化を遂げました。
「Apple Intelligencesを使えば無限にネタが出て来ると思うし、自動『輝け!俺のViewController』生成アプリを作ればいいのでは・・・?」
プロンプトに関係なく暴走するAI、足りないAPIで試行錯誤、やばい、デバイスが燃えるほど熱い!あこれ、デバイスあったかいしホッカイロアプリとして使えるのでは...?
AIで「輝け!俺のViewController」は進化するのか?怒涛の5分間、衝撃の結末「刮目」せよ
2025年6月5日、ビル・アトキンソン氏が亡くなりました。彼は初代MacintoshのグラフィックAPI QuickDrawを開発した人物で、MacPaintの開発者としても知られています。本LTでは、彼が1987年に生み出したHyperCardというソフトウェアを紹介します。
HyperCardは、Macintosh用のオーサリングツールです。「カード」と呼ばれる画面を組み合わせて、インタラクティブなコンテンツを作成できました。プログラミング知識がなくても、ボタンやテキストフィールドを配置し、絵を描き、カード間をリンクでつなぐだけで何かを作れます。さらにHyperTalkというスクリプト言語で、より複雑な動作も実現できました。
当時のMacintoshに無料バンドルされていたこともあり、教育現場からアート作品、ゲームまで多様なコンテンツが生み出されました。インターネット普及前にハイパーリンクでカードを繋ぐ概念は、ローカルで動くWWWのようでした。Cyan社の名作ゲーム「Myst」もHyperCardで開発されたことは、その可能性を物語っています。
実際の画面をざっと見せながら、HyperCardがどんなソフトウェアだったか紹介します。カード、ボタン、フィールド、ペイントツール、HyperTalkスクリプト。これらがどう組み合わさって動作していたのか解説します。また、もしスティーブ・ジョブズのApple復帰後も開発が続いていて、幻のHyperCard 3.0がリリースされた世界線はどんなだったか、少しだけ思いを馳せてみます。
iOS 26で新たに登場した BGContinuedProcessingTask により、ユーザ起点で開始した処理をアプリのバックグラウンドでも継続できるようになりました。
今までiOSはバックグラウンド制御は大きな壁があり実行に大きな制限がありました。
本セッションでは、このAPIの導入背景や制限の変化を、実際のコードや動作デモを通じて、iOSにおけるバックグラウンド制御の制約に焦点を当てて解説します。
私は、iOSおよびAndroidのアプリエンジニアとして長年の経験を積んできました。
このトークでは、クロスプラットフォームからiOSネイティブ開発に戻る際に直面する課題について、コードベースで具体的にお話しします。以下の内容について詳しくお話しする予定です。
SwiftとDartの言語仕様の違いについて(null安全性や型システム)
Swift Concurrencyの導入による非同期処理のモダン化について(async/awaitやActor)
SwiftUIを用いた宣言的UI実装のFlutterとの差分の実例
FlutterのHot Reload機能に依存した開発体験から、ネイティブ開発に戻った際のギャップと対策
これらのトピックを通じて、フレームワーク間の移行がもたらす技術的および開発体験上の影響について共有したいと思います。
モロッコの伝統衣装の美しさと多様性を、日本語でも気軽に体験できるアプリがあったら?
このLTでは、モロッコ文化とモダンなアプリ設計を融合したSwiftUIアプリの構想「KiyanKa」をご紹介します。
MVPでは、ユーザーが写真をアップロードすると、その色や模様からインスピレーションを得たドレスが提案される仕組みをAIで実現。文化的な発見を促す形です。
SwiftUIを使って多言語対応(日本語・アラビア語・フランス語)を実装しながら、AIを活用した小さな工夫で、文化的価値のあるアプリ体験を模索しています。
This talk is an invitation to think about apps not just as tools, but as bridges between cultures.
iOSDC Japan参加者のみなさんなら、きっとiPhone、iPad、MacBookを持っていますよね!人によってはVision ProやHomePod、Apple TVもお持ちかもしれません。
私達にとっては仕事道具ですが、世間ではAppleプロダクトを使用していることは一種のステータスとも捉えらており、「おしゃれ」や「スタイリッシュ」の代名詞の一つということもできます。
そしてさらにこのスタイリッシュさは「無国籍」です。アメリカでも日本でも、喫茶店でMacBookを広げた姿は国を問わずスタイリッシュと言えるでしょう。
そのため私達はこれらAppleプロダクトを持っていれば世界中どこの国でも「スタイリッシュ」に仕事をすることができます。
でも、なぜAppleプロダクトは世界中どこで使っても「スタイリッシュ」なのでしょうか?
ソフトウェアのUI/UXの良さでしょうか?それともハードウェアのデザインが良いからでしょうか?
もちろんAppleプロダクトはソフトウェアのUI/UXは良いですし、ハードウェアのデザインも最高です。
実は、Appleプロダクトがそのイメージからは一見無関係に見える「建築」の世界からきた「素材」によってもスタイリッシュさが支えられていますとお話したら驚くでしょうか?
このLTではみなさんと一緒にモダニズムの生い立ちと、私達ソフトウェアエンジニアには意外に見えるガラスやアルミニウムといった「素材」の2観点から、Appleプロダクトがスタイリッシュに見える理由を深堀りします。
ソフトウェアエンジニアである私達が普段は見落としがちな「素材」という現実世界の要素が、なぜ「スタイリッシュ」に繋がっているのかを知ることで、皆さんの「プロダクト」作りに素材という新たな視点をもたらすことができれば幸いです。
LT会場でお会いしましょう!
εε=┌|▼▼|┘ ウッホウッホ
Xcodeは素晴らしいIDEって伝えなきゃ
ウッホウッホ └|▼▼|┐=33
本LTでは、Xcodeの素晴らしいところをウホフクロウが軽快に紹介します。
5分間でXcodeをより快適に使えるようになるはずです。
●話すこと
・Xcodeの素晴らしいところ
●話さないこと
・Xcodeの素晴らしくないところ
ウホフクロウを生暖かい目で見守ってくれると幸いです。
普段はWebのバックエンドを担当している私が、Swiftに興味を持ち、SwiftWasmを使ってオンラインプレイグラウンドを開発した実体験をお話しします。
SwiftWasmは、SwiftコードをWebAssembly(Wasm)にコンパイルして、ブラウザ上で実行可能にする技術です。Swiftに触れてみたいと思っていたものの、普段Web開発に慣れていることもあり、馴染みのあるWeb環境でSwiftを体験したいと考え、自作することにしました。
TypeScriptでの開発には慣れていましたが、SwiftWasmやWasm自体の扱いは初めてでした。特に苦労したのは、Swiftプログラムが正しく動作するために必要なWASI(WebAssembly System Interface)の一部を、TypeScriptで模倣する実装です。たとえば、fd_write
は標準出力(print()
)の処理を、proc_exit
はプログラムの終了、random_get
は乱数生成に対応しています。
「print()
一つ出すのに、こんなに仕組みが必要なのか」と思いながらも、SwiftとWebAssemblyの仕組みを理解していくのはとても楽しい経験でした。
完成したプレイグラウンドでは、ブラウザ上でSwiftコードが実行でき、配列操作やクラス定義、Optional型の処理のデモを行えます。SwiftWasmの使い方やWebAssemblyの基本を、Webエンジニア視点で解説します。
iOSエンジニアの皆さんに、WebAssemblyでSwiftを実行する過程で得た気づきや発見を共有いたします。
シニアエンジニアに必須の能力はなんだと思いますか?そうですね、WWDCでの引率能力ですね。後輩たちを博物館や交流会へ連れていきApple Parkへ辿り着かなくてはいけません。
そこで選択肢に挙がるのがレンタカーです。ライドシェアより安く済み、アジア人女性150cmの私が知らない人の車に乗る不安からも解放されます。自動運転タクシーはエリア外だしサービス一時停止してたし。
とはいえ異国での運転は楽ではありません。ご想像の通りの右側通行左ハンドル。愛車の倍の体積のアメ車。そして日本とは違う道路のつくり。ペーパードライバーを脱して1年ですが運転しないことにはスキルが身につきません。やっていきましょう💪
本LTでは、スキルアップのため私がアメ車に初挑戦した経験をもとにサンノゼの交通事情を紹介します。
CarPlay(アメリカのすがた)にも触れますよ!さっそくCarPlayからお昼のピザの注文を……えっ?電話じゃないと注文できないの??ていうか数百メートル先にHazard Aheadってなになに!?!?
話すこと
対象者
今を去ること 6 年前、iOSDC Japan 2019 にて、トレーニング企業で受講者に利用してもらうための多数の Mac の環境構築に関する試行錯誤についてお話ししました。
弊社では Mac を多数用意してトレーニング環境をあらかじめ構築し、受講者にご利用いただいています。その際、機材ごとにアプリケーションのバージョンが異なっていたり、macOS の設定が異なっていると受講者が混乱してしまいます。そのため、できる限り環境を統一した状態で用意したいのですが、それを手作業で行うのは人の温かみはあるものの、非常に大変です。
以前は NetRestore を利用して環境の完全なクローニングとリストアが高速にできていました。しかし、macOS のバージョンアップやファイルシステムの APFS への変更、ハードウェア自体も T2 Security Chip の導入や Apple Silicon へのアーキテクチャ変更などもあり、その度に制限事項が増えています。
これらの制限との戦いを経て、一度は回帰してしまった「温かみのある手作業」による環境構築から抜け出すことができたのか?
現在の状況と環境構築の工夫とは?そしてまだ手作業の温かみは残っているのか?
我々の試行錯誤の数々と、現在の状況をぜひお聞きください!