トーク

なんとiOSDC2025は最初の開催から今回で10回目！！
そんな記念すべき節目を祝うにふさわしい舞台...

そう、それはDJしかねえ！！アゲアゲ⤴︎⤴︎

でも、ただのDJじゃ物足りない...
エンジニアなら、機材だってコードで動かしたい！

そこでStream Deckを使っていくぜ！
なんとSwiftからコントロールすれば立派なエンジニア向けDJ機材に早変わり！

このステージでは、Stream Deck を使った華麗な DJ さばきで会場を沸かせます。
このセッションでは、Swift を使って Stream Deck を操作し、音を楽しみつつ実装を解説していきます。
　
俺のステージでみんなを沸かせるぜ！！
みんなでiOSDCをお祝いしましょう！！

Swiftには様々な文法があり、それらは明示的・直感的で読みやすいことに定評があります。

一方でSwiftの特定の文法を応用すると一見"奇妙"なプログラムも記述できます。
以下はコンパイルの通る正しいプログラムです。どの文法を用いているのか、どんな結果になるか、みなさんはわかりますか？

• [1, 2][{ _ in }]
• {String.init}()("a",10)

このような"奇妙"なプログラムにはSwiftの様々なテクニックが含まれており、解き明かすことで様々な発見を得ることができます。

このトークでは、一見"奇妙"なSwiftプログラムを複数個例示し、背景にあるSwiftの文法ルールや応用方法について解説していきます。
このトークを聞くことで、「そんな書き方ができたのか！」と、みなさんの普段の開発にも役立つ発見があることでしょう。

世の中にはBuy Me a Coffeeのように、クリエイターが寄付・投げ銭を受け取るためのサービスがあります。
しかし、そうしたサービスはユーザーを決済可能なWebページに誘導することになるため、iOSアプリにそれらのリンクを掲載することはAppleの規約により禁止されています。

それを踏まえると、「広告を載せるのはアプリの世界観に影響を与えるから避けたい。でも収益源が無いからせめて寄付や投げ銭を受け取りたい」と考える開発者は、アプリ内課金で似た仕組みを作る必要があります。

本トークでは、個人開発アプリに実際にユーザーから寄付・投げ銭を受け取るためのアプリ内課金を実装し、今年約50のユーザーに課金していただいた私が、その実装と実績を振り返ります。
具体的には特に工夫した三点（金額設定UI、ライティング、課金に対するフィードバック）について、その意図と実装、および実際に運用して感じた良かった点と改善点を共有します。

それぞれの詳細は以下の通りです。
・課金額の設定UIについて：ユーザーがどのように課金額を決定できればスムーズかを考える
・ライティングについて：ターゲットとするユーザー層によっては「コーヒーをn杯贈る」というよくある表現が、その分の投げ銭を意味するということが伝わらないのでは？という疑問から考える
・課金直後にユーザーに返すフィードバックの必要性について：消耗型課金だが、何かアイテム数のようなものが変化するわけでもない課金のフィードバックはどうあるべきか、Buy Me a CoffeeやYouTubeのSuper Chatの体験から考える

サブスクリプションの価格変更は一大イベントですが、頻繁に実施するものでもないためその手順についての情報は多くありません。
本LTでは実際に価格変更を実施した経験に基づき、見落としがちな罠や、Tipsについてご紹介します。

・ 申請手順と必要な確認事項
・ 新規 / 継続ユーザーへの価格変更の反映タイムライン
・ サマータイムの罠
・ 価格の変更時刻を厳密にコントロールするTips

価格変更の際にはこれを思い出せば大丈夫！という内容をお届けします。

これまでアプリを開発したり、利用してきた方には自動更新サブスクリプション(Auto-renewable Subscription)は馴染みが深いと思います。
その名の通り、特定の期間中で自動で更新・課金されるもので、ユーザーがキャンセルしない限り、自動的に更新されるものです。

では、「非更新サブスクリプション」(Non-renewing Subscription)は聞いたことはありますでしょうか？
これもその名の通り、更新されない課金のことかなと想像ができると思います。

でもAppleの課金種別にはそのほかにも「消耗型」、「非消耗型」というものも存在します。
これらの課金も更新されない課金のように読み取れますが、違いは何になるのでしょうか？
また、自動更新サブスクリプションとの違いは「更新されないこと」だけなのでしょうか？

このトークでは、非更新サブスクリプションに焦点を当てて、他の課金種別とは何が違うのか、どういう時に使えば良いのか実際に運用した実績をもとにを探っていきます。
これからの課金サービス提供を検討する際の一助になれば幸いです。

ゴール:
・「非更新サブスクリプション」についての理解が深まる
・課金サービス提供時にどの種別の課金にすれば良いか判断材料を得ることができる
・「非更新サブスクリプション」での運用方法のノウハウが手に入る

アジェンダ:
・Appleの提供する課金種別について
・「非更新サブスクリプション」でできること・できないこと
・「非更新サブスクリプション」の運用について
・「非更新サブスクリプション」で提供するに適した課金サービスについて

対象者:
・課金サービスの提供を予定するエンジニア・非エンジニア
・課金種別が多すぎて違いがよくわからない方
・課金についてあまり詳しくないが興味がある方

世の中には、いつの時代も「有償機能を無料で使う方法」に溢れています。
そしてそれはiOSも例外ではありません。

筆者が個人開発をしていたとき、有償で提供していたソフトウェアをクラックされ、世界中に配布された経験があります。
iOSにおいては、レシート検証をすれば、または、レシート検証をしてくれるライブラリを使えば安心、という印象がありますが、果たして本当にそうでしょうか。

このトークでは、実際に課金バイパスを行うダイナミックライブラリの解析内容を交えながら、よくある課金バイパスとその対策を詳しく解説します。

予定している内容

• 課金処理のよくある検証手法
• 現実世界での様々なバイパス手法

StoreKit 2の登場により、アプリ内課金の実装は以前のStoreKitと比べるとかなり簡単に行えるようになりました。StoreKit ConfigurationやStoreKit Testingといったデバッグ・テスト環境も整備され、開発効率は大きく向上しています。

それだけに留まらず、WWDC 23ではアプリ内課金実装に利用できるSwiftUI向けのコンポーネントやModifierも発表され、UIの実装も提供されているものを使うだけ可能になりました。

その中でも SubscriptionStoreView というSwiftUIコンポーネントを使うことで、サブスクリプションプランの一覧表示からプランの契約まで、複雑な課金処理のビジネスロジックを開発者が書かずともサブスクリプション機能を提供できるようになりました。

このLTではStoreKit Configurationファイルを用いてテスト用の課金アイテムを用意し、SubscriptionStoreViewを用いたサブスク機能の実装を5分の制限時間の中でライブコーディングを行います。

StoreKitの進化を一緒に体感してみましょう。

「ブラウザを誰かに見られるのってイヤだな」
と思ったことありませんか？

履歴やブックマークには、
「絶対に他人には見せたくないけど、自分には必要」
そんな黒歴史が潜んでいます。

深夜の勢いで検索した履歴…
ちょっと恥ずかしい趣味のブックマーク…

でもいちいちシークレットモードを切り替えるのは面倒だし、履歴自体は後で見返したい…
ブックマークにも登録したい…
かといってパスワードでロックするのは逆にあからさまに隠してる感があってイヤ…

そこで注目したのが iOS16から利用できるFocus Filterです。
集中モードに合わせて

• 履歴を非表示に切り替える
• ブックマークの表示をモードごとに出し分ける

といった「自然に見せない仕組み」を自作ブラウザで仕込んでみるアイデアです。

このLTでは
「履歴もブックマークも人には見せたくない。でも自分はいつでもアクセスしたい」
というわがままを Focus Filter でどう叶えるかを技術的に語ります。

Focus Filter自体、まだ活用例がほとんど知られていない機能です。
まだ誰も挑戦していない
Focus Filter × 自作ブラウザの世界を
一緒にのぞいてみませんか？

先日 担当しているアプリの譲渡をしたのですよ。

で、よくあるアプリ譲渡の手順で、事前準備もしっかりとして、つつがなく 譲渡が完了！
….と、思っていたのですが、「あれ、このAPIを使うには、Appleに許可がいるの？」という思わぬ事態に遭遇！

具体的には、PassKit の requestAutomaticPassPresentationSuppression(responseHandler:) を使っているのですが、これは特別なEntitlementをAppleに申請しないと利用できないAPIだったので、譲渡後に改めて申請をしました。

この経験をきっかけに、Appleに申請・許可が必要なAPI について調べてみたところ、他にも「申請必須API」があることが分かりました。

このライトニングなトークでは、Appleにメールを送信してから、APIが利用できるようになるまでのプロセスと、その他の許可が必要なAPIについてお話しします。

いざ許可が必要なAPIを利用する際に焦りたくない方におすすめです。

皆さん、The Swift Programming Language（通称TSPL）をご存じでしょうか。TSPLは、Swiftの主な特徴や主要な機能を詳しく解説した公式ドキュメントです。

一見すると、Swiftをこれから学び始める方のための入門書のように思われるかもしれません。しかし、実際にはSwiftの深い考え方や、意外と知られていない機能についても学ぶことができます。

Swift6.2のリリースに合わせて、TSPLにはSwiftユーザーがSwiftをより深く理解するための更新が行われています。これにより、現在TSPLに注目しておくことは非常に有益です。

私は2021年にTSPLの日本語版を作成し、それ以降も原文に合わせて継続的に更新してきました。ありがたいことに、私の翻訳はSwift.orgにもリンクされています。
このトークでは、TSPLの構成について詳しく説明するとともに、私がこの経験を通じて感じた、ビギナー、ミドル、シニアエンジニアそれぞれに適したTSPLの読み方について紹介します。

このトークを通じて、「Swiftともう少し仲良くなれそう」と皆さんに感じていただけることを目指しています。ぜひご参加ください。

私は、iOSおよびAndroidのアプリエンジニアとして長年の経験を積んできました。
このトークでは、クロスプラットフォームからiOSネイティブ開発に戻る際に直面する課題について、コードベースで具体的にお話しします。以下の内容について詳しくお話しする予定です。

SwiftとDartの言語仕様の違いについて（null安全性や型システム）
Swift Concurrencyの導入による非同期処理のモダン化について（async/awaitやActor）
SwiftUIを用いた宣言的UI実装のFlutterとの差分の実例
FlutterのHot Reload機能に依存した開発体験から、ネイティブ開発に戻った際のギャップと対策

これらのトピックを通じて、フレームワーク間の移行がもたらす技術的および開発体験上の影響について共有したいと思います。

我が家はかわいい猫と暮らしています。ネットワークカメラとして設置した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プラットフォーム技術を組み合わせる楽しさをお届けします。
猫は気まぐれ、開発では振り回されましたが、それもまたかわいいものです。

対象聴衆

• ペットと暮らし、Google Nest Camや類似のネットワークカメラをお持ち方
• Swift/SwiftUIでWebRTCやVision.frameworkを使ったリアルタイム映像解析に挑戦したい方
• とにかくかわいい猫に癒されたい方

普段は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を実行する過程で得た気づきや発見を共有いたします。

再帰って便利ですよね。関数の最後に再帰呼び出しを置く「末尾再帰」なら、スタックも節約されて、ループと同じくらい効率的に動く。

そんなふうに信じていた時期が、私にもありました。

「末尾再帰なら安心！」と信じて書いたSwiftのコード。動作確認もOK、見た目もスッキリ、ところがある日、ちょっと大きな値を渡しただけでStack Overflowで爆死！
何が起きたのか? 調べてみると、Swiftは末尾再帰の最適化（TCO）を保証していないらしいです！
しかも、見た目的には末尾再帰に見えるのに、ちょっとした演算の影響で最適化されないことも。

このLTでは、そんな「Swiftの末尾再帰、信じすぎ注意！」という話を、実際に書いて動かして試してみた結果とあわせて紹介します。

なぜStack Overflowが起きたのか?
末尾再帰が最適化される場合とされない場合の差は?
今は大丈夫なコードでも、未来永劫ずっと安全?

楽しく聞いて、明日から「ちょっと再帰が心配になる」。
そんな5分をお届けします。

今を去ること 6 年前、iOSDC Japan 2019 にて、トレーニング企業で受講者に利用してもらうための多数の Mac の環境構築に関する試行錯誤についてお話ししました。

弊社では Mac を多数用意してトレーニング環境をあらかじめ構築し、受講者にご利用いただいています。その際、機材ごとにアプリケーションのバージョンが異なっていたり、macOS の設定が異なっていると受講者が混乱してしまいます。そのため、できる限り環境を統一した状態で用意したいのですが、それを手作業で行うのは人の温かみはあるものの、非常に大変です。
以前は NetRestore を利用して環境の完全なクローニングとリストアが高速にできていました。しかし、macOS のバージョンアップやファイルシステムの APFS への変更、ハードウェア自体も T2 Security Chip の導入や Apple Silicon へのアーキテクチャ変更などもあり、その度に制限事項が増えています。

これらの制限との戦いを経て、一度は回帰してしまった「温かみのある手作業」による環境構築から抜け出すことができたのか？
現在の状況と環境構築の工夫とは？そしてまだ手作業の温かみは残っているのか？

我々の試行錯誤の数々と、現在の状況をぜひお聞きください！

2025年6月5日、ビル・アトキンソン氏が亡くなりました。彼は初代MacintoshのグラフィックAPI QuickDrawを開発した人物で、MacPaintの開発者としても知られています。本LTでは、彼が1987年に生み出したHyperCardというソフトウェアを紹介します。

HyperCardは、Macintosh用のオーサリングツールです。「カード」と呼ばれる画面を組み合わせて、インタラクティブなコンテンツを作成できました。プログラミング知識がなくても、ボタンやテキストフィールドを配置し、絵を描き、カード間をリンクでつなぐだけで何かを作れます。さらにHyperTalkというスクリプト言語で、より複雑な動作も実現できました。

当時のMacintoshに無料バンドルされていたこともあり、教育現場からアート作品、ゲームまで多様なコンテンツが生み出されました。インターネット普及前にハイパーリンクでカードを繋ぐ概念は、ローカルで動くWWWのようでした。Cyan社の名作ゲーム「Myst」もHyperCardで開発されたことは、その可能性を物語っています。

実際の画面をざっと見せながら、HyperCardがどんなソフトウェアだったか紹介します。カード、ボタン、フィールド、ペイントツール、HyperTalkスクリプト。これらがどう組み合わさって動作していたのか解説します。また、もしスティーブ・ジョブズのApple復帰後も開発が続いていて、幻のHyperCard 3.0がリリースされた世界線はどんなだったか、少しだけ思いを馳せてみます。