トーク

私たちが日常でよく目にするバーコード。その裏には、見た目ではわからない微妙な規格の違いが潜んでいることをご存知ですか？

本 LT では、 STORES レジアプリの開発中に直面した「Vision フレームワークが 12 桁のバーコードを 13 桁として認識してしまう」という現象をきっかけに掘り下げた、バーコードの規格と Vision フレームワークの仕様について紹介します！

この現象により、 12 桁のバーコードで登録されている商品をスキャンしても、ヒットしないという問題が発生しました。
Apple の公式ドキュメントでは明示されていない現象で、「なんでや！」と言いたいところですが、バーコードの規格をよく見ると、Vision フレームワークはその規格の性質を利用して、認識していたことがわかりました。
(Google の API はちゃんと認識できるんだけどな…)

本 LT では、以下の内容について話します。

• UPC-A (12 桁) と EAN-13 (13 桁) バーコードの仕様
• Vision フレームワークの認識ロジック
• 正確なバーコードかどうかを判定するロジック
• 回避方法と実装テクニック

1 桁の違いがオペレーションを止めてしまう、現実世界とアプリを繋ぐアプリならではの知見を共有します！
皆さんもバーコードマスターになりましょう！

Swift Package Manager 5.6から登場した Build Tool Plugin。
ビルド時にコードやリソースを生成できる強力な機能として、登場から3年が経ち、多くのプロジェクトで利用が進んでいます。

そんな Build Tool Plugin、便利さの裏で「あること」を見落としていませんか？

Derived Data に出力される成果物。
それがどこまでアプリに影響を与えるか、普段どこまで意識してビルドしていますか？

今回の発表では、Build Tool Plugin を通して気づいた“とある落とし穴”と、それにまつわる 実体験からの学びを共有します。
思わず「ヒヤッ」としたその出来事、Derived Dataの奥底から灼熱の有明にお届けします。

「名前書くの、正直めんどくさい…」

きっかけは、そんな僕自身の心の声でした。
僕の学校の図書館は紙で本の貸し借りが管理されているアナログ方式。
図書の管理表に学籍番号や本のタイトルを書くのが面倒で、紙に何も書かずに本を持っていってしまって行方不明になるという問題が度々起きていました。

「それなら、俺が図書管理アプリ作ればいいのか」

そんな思いつきで勝手に作り始めた図書管理アプリ。
職員の方に軽い気持ちで見せたらビビるぐらい気に入っていただけて、気づけば学校を巻き込んだプロジェクトになっていました。

本セッションでは、趣味で始めたアプリ開発が学校の公式案件になるまでの道のりと、そこで待ち受けていた数々の試練。
そして、学生だからこそできた解決方法についてお話しします！

はじめてSNSアプリを作るとき、多くの開発者が直面する最大の壁。それがApp Storeの審査(App Review)です。

SNSアプリをApp Storeにリリースするには、他ジャンルのアプリ以上に厳しいApp Reviewの壁が立ちはだかります。
特に、ユーザー生成コンテンツ（UGC）を扱うアプリは、ユーザー保護の観点から求められる機能は多岐にわたり、設計段階から審査基準を意識していないと、何度もリジェクトされてしまうことも珍しくありません。

このLTでは、個人で開発したSNSアプリが何度もリジェクトされながらも、最終的にApp Storeに掲載されるまでの実体験をベースに、以下のような具体的なノウハウを共有します。

LTで話すこと：

• 実際にAppleにリジェクトされた理由と、それにどう対応したか
• App Reviewガイドラインに則った設計・実装で気をつけるべきポイント
• ガイドラインには明記されていないが、対応すべきこと

「はじめてのSNSアプリ開発」でつまずかないための実践的な知見を、リアルな失敗談とともにお伝えします。
今後、UGCを扱うアプリを作成する方の、少しでも力になれたら幸いです。

iOSアプリの配布方法というと「AppStoreで公開」か「社内配布（MDMやTestFlight）」の二択だと思っていませんか？ 実はAppleは、企業や団体向けに「Custom App（カスタムApp）」という第三の配布形態を提供しています。 この配布方法は、App Storeを利用しながら、あらかじめ指定した対象者のみにアプリを安全に届けることができる仕組みです。 業務アプリやパートナー限定アプリなどに非常に適していますが、認知度はまだ高くありません。

本セッションでは、AppStoreの配布方法の進化を振り返りつつ、Appleが提供する「パブリック」、「社内配布」、「プライベート（Custom App）」という3つの主要な配布手段の違いや選定基準、審査プロセス上の違い、組織的な利点や制約をわかりやすく整理します。 私が実際に全国約400店舗に向けた業務アプリの配布をCustom Appを用いて行ったので、それにまつわる経緯や運用方法を交えつつお話しできたらと考えています。

「社内用アプリだけどAppStore配信もしたい」「審査が不安」「配布先を限りたい」──そんな悩みを持つiOSエンジニアやIT管理者にとって、“Custom App”は強力な武器になります。あまり語られることのないこの配布手法の実際を、現場の視点でお届けします。

みなさん、3日前に着た服装を覚えていますか？僕は覚えていません。
せっかく毎日服を選んで着ているのに、その記憶が残らないのは少し勿体ないと思いませんか？

この課題を解決するため、私はCoreMLを活用して全身写真からその日に着用したコーデのアイテムを自動で抽出し、まるで手元にクローゼットを持つような体験ができるアプリ”IRODORI”を開発しました。
このアプリは、DeepFashion2というファッションに特化したMLモデルを選定し、アイテム抽出をデバイス上で完結させています。そのため、外部サービスにユーザーの全身画像を送信することなく、安全に利用可能です。
また、一枚の画像から自動でアイテムを抽出できるため、手動での面倒な作業が不要となり、簡単にコーデやアイテムを管理できる点も魅力です。

トークでは、実例をもとにCoreMLを使いオンデバイス完結のiOSアプリを実装する上で試行錯誤した点をお伝えします。
・モバイルファーストなMLモデルの選定基準
・MLモデル(DeepFashion2) をCoreMLで使えるように変換する実装
・MLモデルを動かす上でのUI/UXの工夫

本トークがオンデバイスでMLモデルを動かすiOSアプリ開発の敷居を下げ、アイデアを思いつくきっかけになれたら嬉しいです。
今後加速すると予想されるオンデバイス×MLモデルでのiOSアプリ開発に備えましょう！

Vibe Cooking は、"ノリで料理する" がコンセプトのアプリです。このアプリでは、レシピ手順の読み上げや音声操作によるレシピ手順の移動で、調理中のハンズフリー操作を実現していました。

2024 年 9 月、Apple は、頷きまたは首振りのヘッドジェスチャを使用して Siri に応答する機能を発表しました。これは、新しいインタラクションの形であり、"ノリで料理する" がコンセプトである以上、ヘッドジェスチャによるインタラクションを実装しなければならないという使命感に駆られました。

このトークでは、AirPods を使ったヘッドジェスチャ検知の実装方法と、それが音声によるインタラクションとどのように異なるのか、Vibe Cooking の UX にどのような影響を与えたのかについてお話しします。

このトークでお話しすること

• CoreMotion を使った ヘッドジェスチャ検知の実装: 頷きや首振りのヘッドジェスチャをどのように検知し、アプリに組み込んだのかを解説します。
• ヘッドジェスチャによる UX の変化: ヘッドジェスチャが Vibe Cooking の UX にどのような影響を与えたのか、音声操作と比較しながら紹介します。

SwiftUIを使った機能開発が主流となり、複雑な動作も十分実装することができるようになりました。
iOS16以降ではmodifierが充実しており、大抵の機能はSwiftUIのみで実装可能です。
またWebSocketによる双方向リアルタイム通信もiOS13より標準でサポートされ、以前より導入しやすくなっています。

技術的には「簡単にできそう」に見えたリアルタイムチャット機能の実装でしたが、実際にプロダクションレベルで動くものを作ると想像以上に複雑でした。

このLTでは、実装過程で遭遇した「チャットUIのスクロール位置制御の困難さ」と「WebSocket通信のエラーハンドリングの複雑さ」について、実際のコード例を交えて紹介します。

SwiftUIでチャット機能を実装予定の方や、WebSocketを使ったリアルタイム通信を検討中の方に実践的な知見をお届けします。

去年 WKWebView 関連の開発をするとき、どうしても解決できない問題を発見しました。

当時作った issue： https://bugs.webkit.org/show_bug.cgi?id=274818 （クリックがランダムで反応しなくなる問題。）

それを頑張って調べて、WebKit のバグだと確認し、WebKit の Bugzilla に提出しました。
WebKit の開発者から、それはすでに別の PR で解決されていると言われ、でも再現できませんでした。

色々試した結果、それは WebKit のテスト用スクリプトに問題があると判明しました。
このスクリプトは、ローカルでコンパイルした WebKit を既存のアプリに取り込んで実行するスクリプトです。
実行する際、必要な環境変数の設定に失敗して、アプリは古い WebKit のままで実行されます。
このバグは将来 WebKit の修正に取り組む皆に影響するので、私は新しい Issue を作って、PR を出して、マージされました。

https://bugs.webkit.org/show_bug.cgi?id=275207
（SIP環境でDYLD_FRAMEWORK_PATHが設定できない問題）
https://github.com/WebKit/WebKit/pull/29578

この LT は、この問題発見から PR を出した流れとその中の面白いところを話します。

WWDC24で登場したEmbedded Swiftによって、ついにSwiftでも組み込み開発ができる時代がやってきました！これによりSwiftらしい書きやすさ・安全性をそのまま活かして、直感的にデバイス制御できるのが大きな魅力です。

このLTでは、Embedded Swiftを使ってLEDやセンサを動かしてみた実例を紹介します。さらに、Appleが推進しているスマートホーム規格「Matter」と組み合わせて、iPhoneのホームアプリから操作するデモも行います。

具体的には、以下のような操作を紹介します
● ホームアプリからLEDライトの明るさを調整する
● 温度センサの値をリアルタイムに取得し、ホームアプリから確認する

普段アプリ開発をしている方の中には、「組み込みって難しそう…」と思っている方も多いかもしれません。しかしEmbedded Swiftを使えば、Swift開発の延長でハードウェアの世界にぐっと近づけます。このトークを通じて、ハードウェアの世界に一歩踏み出してみませんか？

光学式マウスの仕組みを知っていますか？
マウスの底にあるLEDで机の表面を照らし、その模様の変化を毎秒数百〜数千回のスピードで撮影。
画像同士を比較して「どっちに動いたか」を計算し、カーソルを動かしているんです。

カメラと画像処理で動きを検出する、まさに小さな画像認識システム。
これってiPhoneでもできそうですよね？
そう思い、意気揚々と始めた「iPhoneを光学式マウスにするアプリ」の開発。
このトークではその過程で得た様々な知見を皆さんに共有します。

このトークを通じて、iPhoneの新たな可能性を探る楽しさを一緒に感じていただければ幸いです。

皆さん、最近健康診断は受けましたか？
実はアプリでも健康診断は行われているんです。

起動時間やHang率など、パフォーマンスデータは自動で記録されています。
ただし、それを確認するにはXcode Organizerを開いて自分で見に行く必要があります。
でも、わざわざ開くのは面倒だし、忙しいとつい忘れてしまいます。
そのまま見逃してしまえば、アプリからのSOSに気づけないままに…。
・バッテリー消費が激しい
・スクロールがカクつく
・画面がフリーズする
こうした不調が続けば、ユーザーのiPhoneからあなたのアプリが静かに削除されてしまうかもしれません。

本トークでは、App Store ConnectAPI × GitHub Actions で構築する自動パフォーマンス監視体制について、5分で解説します。

Next Talk's HINT：
・App Store ConnectAPI（perfPowerMetrics）
・GitHub Actions
・Xcode Organizer

「目的地に行ったらスマホ制限解除」というアプリを作っていた時の話です。

開発は順調でした。近所のジムで何度テストしても完璧に動作。「位置判定範囲200mで実装完了！」そう思っていました。

ところが、友人からの一通のメッセージで事態は急変します。
「代々木公園の中にいるのに判定されない！バグってない？」

まさか、そんなはずは...。慌てて現地に向かい検証すると、確かに公園内部で全く反応しません。一方で、同じコードを使ったジムでは相変わらず正常動作。

いったい何が違うのか？
・GPS精度の問題？→同じ精度設定
・デバイスの問題？→同じiPhone
・通信環境？→どちらも良好
・コードの問題？→全く同じ実装

同じ位置判定機能なのに、なぜ場所によって動いたり動かなかったりするのか？

調査を進めるうち、ある重要な事実に気づきました。そして最終的に辿り着いた解決策は、なんとAIに「ある質問」を投げかけることでした。

この奇妙な現象の正体とは？
そして「ある質問」とは一体何だったのか？

同じような位置判定機能を実装している方、実は知らずに同じ罠にハマっているかもしれません。実際コードとデバッグの軌跡をお見せしながら、この謎解きの全貌をお話しします！

Swift初学者でAVFoundationを使用したイコライザーアプリ開発に挑戦をしていたところ
MIDIコントローラの接続を実装してみたくなりました！

本トークでは、CoreMIDIフレームワークを使用し、アプリに接続されたMIDIデバイスからコントロールチェンジ（CC）メッセージを受信し
それをアプリ内の任意の処理に割り当てる実装の流れと、SwiftUI・音声処理・ハードウェアをつなぐ設計上のポイントなどを共有します。
音声・音響・映像を扱うアプリのMIDIコントローラー拡張が必要な時、プロジェクトへ応用していくための小さなヒントになれたら幸いです。

話す内容：
・CoreMIDIにおけるMIDIClientRefとMIDIInputPortRefの基本構成
・MIDIPacketListからのCCメッセージの解析と値の取得方法
・各CC番号とEQスライダーの動的なマッピング設計
・SwiftUIと組み合わせたリアルタイムなUI同期
・自分専用の機器を想定したプリセット対応