トーク

みなさんの開発チームにiOSエンジニアは何人在籍していますか？
中には少数のエンジニアで開発・運用しているケースもあるかと思います。

少人数体制では、チームにかかるリリース作業の負荷が大きくなりやすく、どうしてもリリース間隔が空いてしまい、頻度が低下しがちです。
しかしリリース頻度の減少は、ユーザーからのフィードバックを得る機会 = 仮説検証を通じたサービスの成長・改善機会の減少にもつながるため、可能な限り避けたいものです。

私が開発・運営に携わっているグルメサービス「Retty」のアプリチームは、iOSエンジニア2名を含む全3名という小規模チームながら原則「毎週リリース」を実現し、直近1年間のiOSアプリのリリース回数はのべ50回に達しました。

この継続的かつ高頻度なリリースによって、仮説検証や機能の軌道修正を機動的に行うことができ、ビジネス視点でも大きなメリットを得られていると実感しています。
もちろん、これは気合で成し遂げているわけではなく、開発メンバーの負荷を最小限に抑えながら「楽々」達成できるよう、さまざまな工夫とテクニックを活用しています。

本トークでは、毎週リリース実現のため、我々が実践してきた開発・運用手法や工夫についてわかりやすくご紹介します。
また高頻度リリースを実践するうえでの注意点や、直面した課題・失敗事例についてもお話しいたします。

「たくさんリリースして、たくさん学んで、たくさん成長する」
そんなアプリ開発・運用を目指す方にとって、きっと参考になる内容です。ぜひ本発表をご覧ください。

トーク内容

• 毎週リリースのメリット
• Retty iOSアプリでのリリース実績
• ブランチ・リリース戦略
• アプリ・API設計の工夫
• 自動化・CI/CDの活用
• リリースフローの最適化
• 毎週リリースでの注意点・失敗事例

iOSアプリ開発において、状態監視の実装方法は時代と共に多様化しています。従来のDelegateやKVOから、単純なクロージャ、Combine、AsyncSequence、そしてSwiftUIのObservationに至るまで、現在では開発者には数多くの選択肢が与えられています。

しかし、きちんと仕組みを理解せず「最新技術だから」「手軽に書けそうだから」といった理由で技術選定を行うと、思わぬ罠を踏み、結果としてプロジェクトに不適切な実装を生むことにもなりかねません。加えて、既存の手法を用いる場合でも、Swift Concurrencyへの対応という現代的な課題は避けて通れません。

本発表では、各状態監視手法の特徴や長所・短所を整理し、どのような場面でどの技術を選択すべきか、その実践的な指針を提案します。皆さんが日々の開発で自信を持って技術選定できるよう、その一助となれば幸いです。

ユーザーが投稿した写真を公開情報として提供するサービスでは、映り込みによるプライバシーの問題への対処が必要となることがあります。
私が開発運営に携わるグルメサービスRettyでも、店の雰囲気を伝える手段として飲食店の店内で撮影された写真を収集していますが、店員や他のお客さんが映った写真が投稿されてしまうことが大きな課題でした。
写真を適切に加工することでこの問題は回避可能ですが、外部アプリでの加工はアプリ間の移動が煩雑であり、さらに手動で人の顔に加工を施す作業負荷も高いため、これが店内写真の投稿率を下げる要因となっていました。

そこでRettyでは、アプリ内で加工が完結できるよう新たに「顔ぼかし」機能の提供を開始しました。
これは被写体を判別し、顔の部分だけにぼかしを入れる機能で、本機能によってユーザーは気兼ねなく内観写真を投稿することができるようになりました。
本機能の実装にはVisionFrameworkを用いており、オンデバイス判定による高速かつ高精度な顔判別と加工を行っています。
Apple標準のAPIのみを使用しているため、専門知識も不要でシンプルながらも必要十分な設計で実現することができました。

本トークではRettyでの「顔ぼかし」の企画からリリースに至るまでの流れをお話しながら、技術選定、設計、対処した課題についてご紹介します。
VisionFrameworkの活用事例として、みなさんのサービス開発にも役立てていただける内容となっています。

トーク内容

• Rettyの写真投稿と内観写真における課題
• VisionFrameworkについて
• ぼかし機能の設計と仕様
• リリースまでに発生した課題と対策
• 企画からリリースまでの総括

APIが新しいSpeechフレームワークでは大きく改善されたことをご存知でしょうか？AppleはSiriやキーボードに音声入力のインターフェイスを統合しています。新しいSpeechフレームワークはこれまで内部にあったAppleの音声入力の機能を公開することで、より高精度の文字起こしが簡単に、手軽に実装できるようになりました。

また、音声入力の価値は、LLMの登場によって再評価されています。ノートアプリや通話アプリでは、ミーティングノートを自動で作成することが次世代の標準機能とされつつあります。さらに、ライブ配信では文字起こしを活用したリアルタイム翻訳が増えてきており、音声入力がアプリのコア機能として位置づけられることが予想されます。

しかし開発者として、音声入力をアプリに持ち込むことを考えた時にどのようにアプリ全体を設計したら良いのか悩むことが多くあります。どのようにまず音声を取得するのか、リアルタイムと録音済みでの考慮する点の違いはあるのか、抽象化の観点はどうすべきか、Speechフレームワーク以外に同様の機能を提供するフレームワークは何があるのか、どのようにLLMと連携すべきなのか、など開発してみないと考えにくい観点がたくさん挙げられます。

本トークではこれらの疑問を解消してアプリに音声入力を持ち込むために必要な知識を包括的に提供します。

1. iOSで音声を扱うための基礎知識であるAVFoundationについて
2. 新しいSpeechフレームワークができること
3. 音声入力のWhisperKitとSpeechフレームワークの比較
4. 実例で学ぶSpeechフレームワークを使った音声入力アプリの実装方法

このトークを通じて、音声入力を活用したアプリの実装に挑戦してみましょう！

アプリ開発では、アプリと別のプロセスで動作する App Extension を開発できます。昔からある仕組みですが、近年特にアプリの機能をOSに渡すことでリッチな動きを実現する Widgets や Apple Intelligence (App Intents) で利用する機会が格段に増えています。この仕組みではアプリ本体とは別プロセスで動作するため、データの一貫性や安全な共有が求められます。しかし、 UserDefaults や FileManager、 Core Data、 Keychain など、共有・永続方法は多岐にわたります。また AppExtension は利用できるメモリにも上限があり、正しく設計しなければクラッシュやデータ破損、一貫性を損なうバグの原因にもなりかねません。

本トークでは、 App Extension を利用する際に安全かつ効率的にデータを扱うための指針について紹介します。基本的な設計に加え、実践的なTipsを幅広く紹介します。たとえば、起動処理で必ず行われるセットアップ処理に関する罠や、 App Extension 特有の制約に伴う DB のマイグレーションの扱い、 App と App Extension 間で発生したイベントをどのように通知しあうか、等です。

App Extension の活用が進む中、「データの正しい共有設計」はますます重要になります。 Widgets や Apple Intelligence にこれから対応しようとしている方にも、すでに導入済みで改善のヒントを得たい方にも役立つ内容です。

visionOS 26 で発表された「Apple Projected Media Profile（APMP）」 は、MP4／MOV ファイルに拡張メタデータを付与し、180°・360°映像を標準映像と同じ操作感で扱えるようにする新しい仕組みです。

高価な専用カメラが必要な「Apple Immersive Video」とは異なり、APMP ならGoProやInsta360など、個人でも手軽に入手できるカメラで撮影した映像を、そのまま Vision Pro の没入空間で再生できます。

本講演では、APMP の基本的な構造を説明し変換手順までを次のトピックで解説します。

• APMP が扱える映像フォーマットの種類
• QuickTime コンテナ内「vexu」ボックスの仕組み
• 標準映像をAPMP対応ファイルへ変換する方法

最後に、個人開発している visionOS 2向け 360°動画アプリをAPMP対応へ移行した際に、どのような修正が必要だったのかを、差分ソースコードを示しながら詳しく解説します。

ツールやビジュアライザなど大量データを扱うアプリでは、ユーザー操作によるメモリ不足でアプリの応答性が下がったり、Jetsamイベントによる強制終了が起こり、最悪の場合ユーザーデータの損失に繋がる可能性があります。クラッシュしてしまう前に防いだり、ユーザーに気付いてもらうためにはどうすると良いでしょうか。このトークでは、iOS・iPadOSのメモリやメモリワーニングの仕組みや、メモリ不足による強制終了を防ぐ知見について以下のような内容で紹介します。

• Jetsamイベントとは
• メモリワーニングによるメモリ不足の検知
• iPadOSのEntitlement(Increased Memory Limit, Extended Virtual Addressing)
• 実践例や失敗例の紹介

オープンデータとは、誰もが自由に使えるよう公開されたデータのことです。
気象、人口、交通、選挙など、行政機関が提供するオープンデータには、社会の課題や動きを読み解くヒントが詰まっています。
しかし、多くはCSVや表形式のまま放置され、活用されずに埋もれています。

このセッションでは、iOS 16以降で使える Swift Charts を活用し、こうしたオープンデータをアプリで「伝わる形」に変える方法を紹介します。

実際に気象データや交通データ、選挙・人口統計などを例に、データの取得、整形、そしてインタラクティブなチャート表示までをデモを交えて解説します。
たとえば、気象データを棒グラフで表示したり、通勤手段の変化をエリアチャートで見せたり、投票率を地図上にヒートマップで可視化したり。

「Swift Chartsを使ってみたくなる」「地域や社会のことをアプリで伝えてみたくなる」

そんな感覚を持ち帰っていただけるセッションです。

iOSアプリ開発においても、AIコーディングツールを活用して開発効率を向上させる事例が増えています。日々の業務でもさまざまな開発タスクでAIを活用していますが、私はその中でも特にFigmaのデザインデータをもとにSwiftUIコードを自動生成する取り組みに挑戦しています。

とはいえ、AIに「コードを生成してほしい」と指示を出すだけでは、期待どおりのコードを得ることは難しいのが実情です。特に独自のDesign Systemライブラリを使用しているような場合、適切なコンポーネントを使った狙いどおりのコードを生成させるにはいくつかの工夫が必要です。

このトークでは、安定的に品質の高いSwiftUIコードを生成するために行なった、以下のような試みについてお話しします。

• MCP Serverを用いてFigmaからデザインデータを正確に取得する
• Claude Code を使って既存のコードからSwiftUIとDesign Systemの関連性を学習し、ナレッジとして蓄積させる
• 生成されたSwiftUIのスナップショット画像とFigmaからエクスポートした画像データを比較し、AI自身に誤りを検知させ、自己修正を行わせる
• 自己修正と開発者からのフィードバックをもとにナレッジを自己更新させる
• AIを使ったコード生成における、学習 → 生成 → 検証 → 改善 のループの重要性
• 現時点における限界、理想と現実

AIコーディングツールの進化は非常に速く、追いかけるのが大変ですが、このトークを通じて、AIを活用した開発のヒントやアイデアを得て、日々の作業に取り入れるきっかけになれば幸いです。

本業iOSエンジニア、副業で弓削商船高専の教員の私が、iOS開発経験ゼロの高専生5名と共に全国高等専門学校プログラミングコンテストのテーマ「ICTを活用した環境問題の解決」に挑みます。
開発期間は6月から10月までのわずか4ヶ月。
この無謀にも見える挑戦のリアルタイムな奮闘記をお話しします。

本トークでは、以下の3つの視点から、私たちの挑戦の過程を共有します。

1. 社会課題からiOSアプリ構想へ
   紙の大量消費と個人情報漏洩という2つの社会課題を同時に解決するため、どのようなアイデアを経てiOSアプリの構想に至ったのか。
   そして、4ヶ月で開発を完遂するため、いかに機能を最低限の最低限まで絞り込んだのか、その要件定義のプロセスをお見せします。

2. ほぼオフライン環境のデモンストレーションを乗り越える技術設計
   コンテスト本番は運営側が用意しているインターネット環境は不安定、作品のデモンストレーションに使えるスペースも机一個分という縛りあり。
   そんな環境でも安定したデモンストレーションを実現するため、基本的な機能はローカル（サーバ含め）で完結するアプリ設計に舵を切りました。
   通常のアプリ開発とは一味違う、制約の多い環境下での技術選定やアーキテクチャ設計の勘所を解説します。

3. iOS初心者チームの育成とリアル
   iOS開発を知らない学生たちを、いかにして4ヶ月でiOSアプリを開発できるチームへと導くのか。
   技術コーチとして、PMとして若手育成の壁とそれを乗り越えるための工夫を、リアルな経験談としてお伝えします。

セッション当日は、10月のコンテストに向けて学生は最も修羅場の時期。
開発の最前線で"今"起きているたくさんの「つらみ」や学びを、熱量高くお届けする予定です。

※ なお6月末時点、プロダクトコードは1行も用意できてません。

「Write once, run everywhere」 - それはアプリケーション開発において、多くの開発者が追い求めてきた夢です。
モバイルアプリ開発の世界では、Androidの公式言語であるKotlinも例外ではありません。
Compose Multiplatform for iOSがStableとなり、アプリケーションの大部分をKotlinだけで開発する選択肢が現実的な視野に入ってきました。

しかし、過去の歴史が示すように、マルチプラットフォーム技術は常に諸刃の剣です。
技術選定とは、輝かしい未来を選ぶだけの行為ではないのです。チーム体制、事業フェーズ、プロダクトの性質によって、いつかその技術から「撤退」する日が来るかもしれません。
使用されていた技術の影響により部分的撤退が叶わなかったアプリも見受けられます。
本セッションでは、この予期せぬ「撤退戦」までを考慮に入れることの重要性を提起します。

本セッションではKotlin Multiplatformを主軸に、この「撤退戦略」を深掘りします。
まず、なぜKotlin NativeがネイティブAPIを直接呼び出し、ネイティブらしい振る舞いを実現できるのか解説します。そして、この特性が撤退時にどう活きるのかを明らかにします。
最後に、プラットフォームの専門家が変化の時代で自らの強みを最大限に発揮するための技術選定の指針を考察します。

トーク内容

• マルチプラットフォームにおける「共通化」の功罪
• なぜ技術選定で「撤退戦」を考慮すべきなのか？
• Compose MultiplatformとKotlin Multiplatformの現在地
• 撤退シナリオから見る、Kotlin Nativeの真価 Kotlin+UIKitの組み合わせ
• 変化の時代における、プラットフォーム専門家が活きる技術選択の指針

Swift TestingはWWDC2024でアナウンスされたテストフレームワークです。マクロを活用したAPIで、記述量を抑えつつ、parameterized testsやテストの並行実行もサポートされるものです。XCTestからのマイグレーションドキュメントも公式に準備されており、プロジェクトをSwift 6にさえできていれば、デメリット小さく良いテスト体験を享受できます。

一方で、課題になるのは「既存のテストをどう書き換えていくか」ではないでしょうか？プロジェクトによってはXCTestで記載されたもののみでなく、Nimbleのようなライブラリを用いて記載されたテストもあるでしょう。
これらの既存のテスト資産を効率よく、そしてより効果的なテストに変換することを皆さんは意識できていますか？マイグレーションドキュメントはXCTestとの対応表に過ぎず、「どう書き換えるか？」については焦点を当てていません。また、数個の単体テストを書き換えても、テスト実行時間の削減には大きな影響はなく、書き換える事自体のモチベーションが下がり、Swift Testingに置き換える事自体が後回しになっていないでしょうか？

そんな後回しになってしまう課題について、このトークではMCP ServerとこれをコントロールするAI Agentを導入することで、無駄な後戻りを小さくおおよそ自動でテストのマイグレーションを実行したケーススタディを紹介します。既存のswift-testing-revolutionaryやSwiftFormatのpreferSwiftTestingといったツールをそのまま使うのではなく、MCP Serverとして提供することのメリットについても触れ、Swift Testingに移行するモチベーションを上げる具体的なアクションの一つを皆さんと共有できればと思います。

10年前に誕生したUIKitアプリは、さまざまな課題を抱え保守性が悪い状態になっていました。状態管理のenumやフラグを抱えコードの見通しが悪くなったFat ViewController、ロジックを分離したが機能が積み上がるにつれて責務が混在したManager──そんなレガシーなアプリが生み出すバグと格闘する日々が続いていました。

本セッションでは、レガシーアプリを改善するためにアプリに生じるバグの傾向を分析し、「コードの見通しの悪さ」を生む構造的な原因に向き合う中で、SSOT(Single Source of Truth)を実現するための Store、状態管理であることを明確にするための ViewState など、iOSDC2023で紹介された「SVVSアーキテクチャ(Store・ViewState・View)」に辿り着くまでの過程をお話しします。

Fat ViewControllerからの段階的な分離、SwiftUI移行を見据えた土台作り──SVVSをスモールステップで導入するプロセスと、それによって得られた改善効果についてお話しします。

• レガシーUIKit MVC アプリが抱える課題
• アプリで頻出するバグの傾向分析
• 取り組む課題と実現したいことの整理
• Fat ViewController を段階的に改善した作戦
• SVVS になった後の SwiftUI 導入

位置情報を活用したアプリは便利である一方、権限ハンドリングやバッテリー消費といった数多くの課題が存在します。本セッションでは、実際のプロダクト開発で遭遇した問題とその解決策を具体的なコード例とともに紹介します。これにより、参加者が安全かつ効率的に CoreLocation を活用できるスキルを身につけることを目指します。

【話すこと】

• 位置情報のステータスの違いとリクエスト方法
• 位置情報変更時の効果的なデバッグ方法
• 位置情報によるアプリ起動のライフサイクル管理
• 移動経路取得のための実現方法と注意点
• バッテリー消費を抑えるための実践的手段

【対象者】
位置情報機能を実装予定の開発者、既存アプリの改善を考えている方、CoreLocationの課題に直面した経験を持つ開発者

CoreLocationに潜む課題を理解し、安心して位置情報を活用したアプリを開発できるスキルを身につけましょう！

AIエージェントの発展により、プログラミングの敷居は大幅に下がりました。プロンプトを書けばコードが生成され、どんどん実装を進めることができます。しかし、開発速度を上げることだけがAIエージェントの利点でしょうか？

AIエージェントを使えば未知の領域のプログラミングも十分な品質で実装が可能になります。
それまでは諦めていた不慣れな分野のプログラミングもアプリに取り込み、結果としてユーザー体験をよりよいものにできるでしょう。

私は7年間個人開発として風水アプリを開発を続けています。
このトークではその風水アプリにCursorを使って国際標準地球磁場 (IGRF-14)をSwiftへ実装し、MapKitを利用した偏角計算画面により風水アプリのUXを劇的に改善したプロセスを紹介します。
AIエージェントとの対話によって、IGRF-14モデルのPythonコードの理解からSwiftへのリファクタリングまでを一気通貫で実現し、リリースまで漕ぎ着けた一連の取り組みを解説します 。

「目次」
・地磁気モデル（IGRF）とは？
・IGRFモデルによる偏角の計算プログラムをCursorでSwiftへの変換
・生成されたコードの品質担保戦略
・OSSの公開とアプリ設計、Swiftらしいコードへのリファクタリング
・AIエージェント利用時の課題と解決策

AIエージェントの利用を考えている方へ具体的な事例を示し、Vibe codingの先にある、やりたいことをやり切る方法を具体的にお伝えします。

LLMの台頭は、これまで実現困難と見なされていた領域を一気に射程内へ引き寄せ、新たな価値創出の幅を大きく広げました。

その流れを受け、家計簿アプリを提供している弊社は昨年、LLMを活用したAIレシート読み取り機能をリリースしました。ユーザーがレシートを撮影すると、Vision frameworkが領域を検出してOCRを行い、抽出テキストをLLMで構造化することで金額・日付・店名を瞬時に取り出し、家計簿へ自動反映する体験を提供しています。

高精度を担保するために、カメラ映像からレシートを検出・追跡し、座標のブレが閾値以下になった瞬間に自動シャッターを切る仕組みを導入したり、得られたテキストは前処理してからLLMに入力することで推論の誤判定を低減しました。さらにInstrumentsでボトルネックを解析して処理レイテンシを最適化し、結果として他社アプリと比べても際立った読み取り精度を実現しています。

本トークでは、このようなレシート読み取り処理を構築する中で直面した課題と、それらを解決していく中で得られた実践的なノウハウを余すところなく共有します。
さらに発展的な内容として、WWDC25で発表されたRecognizeDocumentsRequestを活用したさらなる精度向上の展望と、Foundation Models frameworkによるオンデバイスで完結するレシート読み取りの可能性についてお話しします。

本トークが、ドキュメントOCRの更なる最適化やLLMをうまく活用した機能開発のための具体的なヒントとなりましたら幸いです。

Pull-Requestのレビューを依頼された際、レビューのために手元で作業中の内容を一旦スタッシュし、レビュー対象のブランチをpullして、Xcodeでプロジェクトをビルドするような経験はありませんか？

頻繁にブランチを切り替え、動作確認のためのビルドを行うと、数えきれないほどの時間がレビューのために使われることになります。

この課題解決のために動作確認用のTestflight版アプリを用意することも多いと思いますが、その場合もアプリのArchiveとアップロード、Testflight上で配信可能になるまで時間がかかります。
Testflight側のレートリミットも存在するため、Pull-Requestの内容が更新されるたびにTestflightにバイナリをアップロードするといったワークフローは組みづらいでしょう。

私たちのチームではこの課題に対して、手元でビルドすることなく、Testflightで配布可能になるのを待つことなく、Pull-Request上にコメントされたリンクをクリックするだけで動作確認できるワークフローを用いて大幅に時間と手間を削減しています。

本トークでは、私たちのチームで導入している動作確認を簡単に行えるようになるワークフローを他のチームでも導入できるように、以下の内容について紹介します。

• iOSにおけるビルド成果物の種類について
• 動作確認用のテストアプリの準備方法について
• Shopify製のツール「Tophat」を用いて、App Bundleを用いたシミュレーター上での動作確認方法について
• 検証したい対象と、それに応じたテスト版配布方法のプラクティスについて

このセッションを通して、Pull-Requestのレビュー体験を改善し、チーム全体の開発効率を飛躍的に向上させるヒントを得ていただければ幸いです。

音楽とプログラミングはまったく違うもの。芸術と情報工学の間に、共通点などない。
……と思われている方も多いようです。
しかしながら、それは大きな誤解なのです。
なぜなら、音楽は数学だから！
「ド ド# レ レ# ミ ファ ファ# ソ ソ# ラ ラ# シ」、誰もが知っているこの音の並びを生み出したのは、古代ギリシャの数学者ピタゴラス、と言われています。

プログラマと音楽は相性が良いのです。
私自身も、平日はプログラマ、週末はアイドルなどへの楽曲提供をする作曲家です。

プログラミングはコード(code)を書き、作曲はコード(chord)を使います。

この「コード」を中心にプログラマなりの作曲を考えてみましょう。
コードネームから構成音を求めるプログラムを作ることができます。
コード進行にはパターンがあり、デザインパターンやライブラリのように利用することができます。
コード進行からメロディを導き出して作曲していくことができます。

本トークでは

1. 作曲とはなんなのか
2. コードの仕組み
3. コード進行はパターンである
4. コード進行を演奏するiOSアプリを作る
5. コード進行から曲を作る

についてお話しします。

現代のServer-Sideにおいて、Observability（可観測性）は必須の存在です。マイクロサービスやCQRSなどの分散システム、サーバーレスモデルでは、ログ・メトリクス・トレースを集約して観測できることが運用上必須となっています。
Server-Side Swiftを採用する際、主軸として使う場合でもマイクロサービスの一部として導入する場合でも、OpenTelemetryなどの業界標準との連携は避けて通れません。
本トークでは、Apple公式のswift-log、swift-metrics、swift-distributed-tracingの役割と連携方法を解説し、OpenTelemetryを通じて様々な監視サービスと接続する方法を紹介します。

実践的なライブデモ
Vapor + AWS Lambdaを使用したCQRS/Event Sourcingシステムの実装を通じて、AWS CloudWatchとX-Rayによる分散システムの監視を実演します：

• 分散トレースによるリクエストの流れの可視化
• Lambda関数間の呼び出し追跡
• イベント処理の監視
• 処理速度のボトルネック特定

SwiftはiOSアプリ開発で培った型安全性と高いパフォーマンスをサーバーサイドでも活用できます。CQRS・Event Sourcing・Serverlessのような複雑な分散システムこそ、Swiftの強力な型システムとApple公式の監視ツールが真価を発揮します。
Server-Side Swiftの導入を検討している方、本格的な運用に向けて準備したい方に、実践的な監視システムの実装方法を提供します。一緒にServer-Side Swiftで本番環境に耐えうるシステムを構築する一歩を踏み出しましょう。

「アクセシビリティ機能を使用してこのコンピュータを制御することを求めています。」

macOSでアプリを初めて開いた際、このような許可ダイアログが表示されたことはないでしょうか。
ダイアログの内容からはどのような許可を求めているのか理解しずらいですよね。

実はこれ、かなり強力なコンピュータ制御の権限を得ようとしていることをご存知でしょうか。
この権限を使えばキーロガーや画面監視アプリなんて簡単に作れてしまいます。

そんなことを知らずに何気なく許可していた方は、本トークでmacOSのセキュリティリスクを再確認することができます。
アクセシビリティの許可をすることでどのような処理ができるのかをコードベースで理解し、そこからどのような危険性があるかを説明していきます。
ただし、危険とは言いつつも開発者としては非常に面白い機能も使えるようになるため、技術面でも興味深い内容となっています。

AIによって自動化が急速に進化する今だからこそ、コンピュータの制御を可能にするアクセシビリティの許可は正しく理解しておく価値があります。
きっとみなさんのMacにもアクセシビリティ許可をしているアプリがあるはずです。

ぜひご覧ください！