トーク

結婚したことでパートナーが持っていた電子ピアノが我が家にやってきました！
電子ピアノといえばガジェット！ピアノ未経験とはいえ、エンジニアとしてはこれは触ってみるしかない！
ということで、ピアノ経験者監修の電子ピアノと連携するiPadアプリを実装しました

この電子ピアノはMIDIという規格を通して他のデバイスへ叩いた鍵盤の情報などを連携することができます
今回はこのMIDIをSwiftから利用し、その情報を表示するアプリの実装の概要について紹介します！
具体的には…

1. Core MIDIの概要
2. ピアノ鍵盤のUI実装のこだわりポイント
3. 鍵盤の打鍵の強さを取得する仕組み

発表では実装したアプリが実際にピアノと接続しながら動く様子をお見せします！
この発表を通して、電子楽器とアプリ連携の世界に一歩足を踏み出してみましょう！
またこのデモの中でピアノ完全未経験の発表者がどれほどピアノが上手く弾けるようになっているかにも注目です

SwiftのData型はバイナリデータを扱うための型です。
RandomAccessCollectionなどの便利なプロトコルに準拠しているおかげで、気軽にバイナリデータの読み書きができます。

でも「ほぼUInt8の配列でしょ」と思っているとそんなことはなく、Data型にしかない、面白くも「あぶない」特徴がいくつかあります。
それらを知らないとプログラムをクラッシュさせてしまうこともしばしば。

コードレビューでこの関数をLGTMしてしまいそうになったら、ぜひこのトークを聴いてください。

func getUInt32(from data: Data) -> UInt32 {
　switch data.count {
　case 0:
　　return 0
　case 1:
　　return UInt32(data[0])
　case 2, 3:
　　return UInt32(data[1]) * 256 + UInt32(data[0])
　default:
　　return data.withUnsafeBytes { $0.load(as: UInt32.self) }
　}
}

Swiftが好きだけど何もわからん。自分よりSwiftを愛してて詳しい人ばかり。つらい。

Swiftコンパイラを勉強しようとして返り討ちにあった方は多いでしょう。どこから手をつけるとよいかもわからん！
「型推論ハンズオン」[omochi 2019]はSwiftの型推論にフォーカスして学ぶ合宿用ハンズオンです。未実装の部分に正しいコードを書いて型推論器を完成させ全テストをパスできたらクリアです。SwiftSyntaxを使った本物そっくりの言語が題材で、Swiftを理解したい私にはありがたい教材です。

私は「Swiftの型推論を学ぼう」[omochi 2024]を聞き、発表の元ネタであるというこのハンズオンで勉強することにしました。合宿は5年前に終了しているため1人で挑みます。

あれ？ハンズオン壊れてるよ？テスト通すどころかハンズオンをコンパイルできなくて挑戦できないよ？？
果たして私は5年前のハンズオンをSwift 5.10に対応させSwiftの型推論を†完全理解†できるでしょうか？

話すこと

• Swift 5.10対応にもコンパイラの知識を要するハンズオン
• コンパイラは入出力を理解すれば大丈夫（本当に？）
• 生存戦略：サポートを受けて成功体験を積む
• ソロ攻略の感想

ジオフェンスとは、特定の地理的エリアにデバイスが入ったり出たりしたことを検知できる仕組みです。

iOSでは、中心の緯度経度と半径を指定するだけで簡単にジオフェンスを設置できます。この機能はアプリを起動していなくても検知が可能で、アイデア次第で便利なサービスを提供できます。

しかし、iOS/Android両方開発してみると、各OSごとの挙動の違いがあったり、確認方法にも工夫が必要です。

今回のトークでは、ジオフェンス機能をiOS/Androidの両OS対応した際の経験をもとに、以下のポイントについて詳しくお話しします：

・ ジオフェンス機能の仕様の違い
・ デバッグの際の工夫とTips
・ 開発時に苦労したこと

UndoManagerは、アプリにUndo・Redo機能を提供してくれる強力なクラスです。
特にnote アプリのようなエディタアプリにとって、Undo機能は必須の機能の一つといえます。
しかし、意外とUndoManagerを使いこなしているアプリは少ないのが現状です。

本トークでは、UndoManagerの基礎から、実際のアプリへの導入方法、そしてその際のはまりポイントまで、実体験に基づいて解説します。

[内容]

1. UndoManagerの概要とUndo・Redo方法
2. 導入時に遭遇したはまりポイントと解決策

一緒にUndoManagerをマスターし、アプリのユーザー体験を次のレベルへ引き上げましょう！

WWDCに行くためには多くの壁が存在します。航空券、入国審査、言語、治安、飯が合わない、などなど。やらないとそもそもアメリカ入国もアウトになるものもあれば、ハックすればより自分の旅が快適になるものもあります。また、限られた予算内でどう頑張って渡航するかも重要になります。いろいろと山積みで頭を抱えますよね？

皆さん、大丈夫です。ここに経験者がいます。入国審査のときに審査官に嘲笑され、タイムズスクエアで屈強なアニキに囲まれCDを買わされ、「お前の英語よくわからん」とドライバーに無視され、かの遠い地で日本を懐かしみ枕を濡らした経験のあるのは、この男！安い航空券を取るという特技だけでなく、多くの失敗をアメリカで学んだ男が、今年のWWDCをたのしみつつ、どうハックしてアメリカツーリズムを乗り越えたか。めくるめく５分間で話していきます！

もちろん、来年からWWDCに行く人のためになったり、すでにWWDCに行った人にもプラスになる情報が盛り沢山！ぜひご覧ください

あ、WWDCに行けるかどうかのハックはありません、運です。

シングルトンはGoFのデザインパターンのひとつ。
インスタンスがひとつしか存在しないことを保証したもの。

しかし、とある日、確実に正しいコードのシングルトンなのに、その状態が共有されていないことに気づいたのです。
おかしい、そんなバカな、そう思いながら、恐る恐るシングルトンのインスタンスのメモリアドレスを確認しました。

違うんですよ、アドレスが…

このトークではコードは間違いなく正しいにも関わらず、シングルトンのインスタンスが複数作られてしまう怪奇現象について、iOSのビルド設定の観点から説明します。

あなたのシングルトンは本当にひとつですか...？

皆さんは昨年のiOSDCのロゴは覚えていらっしゃるでしょうか？
同心円とその中心から放射状に伸びる線から構成され、色が塗られている箇所と塗られていない箇所に分かれたあのロゴマークです。
(参照：https://iosdc.jp/2023/)

このデザインを見たときに、ふと思った方もいるのではないでしょうか？
「このデザインには意味があるのではないか？」
「何か隠されたメッセージが潜んでいるのではないか」
と。

かくしてロゴに秘められているであろうメッセージを解読しようと試行錯誤する日々が続いたのです。
仕事の合間に。そしてレギュラートークの準備の合間に。

そしてiOSDC Japan 2023の最終日、ついに私は真実に辿り着くことができました。
本LTではそこに辿り着くまでの試行錯誤と、このLTのために丸一年秘密にしていたロゴに関する真実をお話します。

私はiOSアプリの多言語化対応において、LinterをRubyで自作して書きました。
本セッションでは、そのLinterを汎用化したGitHub Actionsに進化させ、Marketplaceに公開して使えるようにするまでをお話します。
といってもまだ公開しておらず、もしこのセッションが採択されたら公開に向けて動きます。そうです、登壇駆動開発です。その時間経過も含めてLTらしく話します。
真面目な話をすると、意外と自作で色々スクリプトを作っているiOSプロジェクトは多いんじゃないかと考えており、それらOSSのタネが開花するきっかけになるとよいなと考えています。

SFSpeechRecognizerは音声認識を利用して音声をテキストに変換することができます。
この技術を活用して、視聴者のデバイス上で完結する自動字幕起こし機能を実装しました。
本セッションでは、その過程で直面した課題とその解決方法について共有したいと思います。

紹介トピック

• 自動字幕起こし機能の概要
• SFSpeechRecognizerの実装方法とその制限
• デバイス上で処理できる言語の条件

手塩にかけて育てたミュージックライブラリがぶっ壊れた経験はありますか？私はあります。

5年前、OSX Catalinaの登場時にiTunesが廃止され機能ごとにアプリが分かれました。
その後、新しいミュージックアプリでは様々な問題が起こりました。

• アルバムアートワークが消えた
• 読み仮名のコピーができない
• ジャンルが勝手に書き換わる

(※全部筆者が経験したことです)

万単位にのぼる楽曲を1個1個精査して正しい状態に復旧するのは当然ながら非現実的です。
更にミュージックアプリの使い勝手の悪さも相まって泣き寝入りを余儀なくされました。

ですが、そこに救世主が現れました。そう、 ScriptingBridge です。
しかし ScriptingBridge はObjective-CがベースなのでSwiftで扱うには一工夫が必要です。

本セッションでは、macで他アプリケーションと連携するための仕組みである ScriptingBridge を使ってミュージックライブラリから楽曲情報を取得・編集する方法と、それによって壊れた楽曲情報を半自動で復旧した話をします。

「Vimは設定している時が一番楽しいんだよ（ウホーレン）」

有名なテキストエディタのひとつに「Vim（ヴィム）」があります。
私はVimが好きです。もっというとVimから派生した「Neovim（ネオヴィム）」が大好きです。

私はNeovimを使ってiOSアプリ開発できないか、日々模索しています。
Microsoftが公開している「LSP（Language Server Protocol）」や「DAP（Debug Adapter Protocol）」などのプロトコルを使い、かなりいい感じにコーディングできるようになってきました。

NeovimにはLSPやDAPのクライアントプラグインが存在します。
それを使うことで、Appleが公開している言語サーバー（SourceKit-LSP）や、サードパーティ製のLLDB拡張（CodeLLDB）をNeovimから呼び出して使えます。
つまり、Neovimで補完やシンタックスハイライト、ブレークポイントを貼ったデバッグなどが可能になります。

本LTでは、まず私のNeovimによるSwiftのライブコーディングをお見せし、次にそれを実現するための技術をキーワードベースで紹介します。

「必要なものはvimrcだけだったのです。必死に積み上げてきたvimrcは決して裏切りません（ウェルン）」

Apple Vision Proの発表と同時に紹介された空間ビデオ機能。 iPhone 15 Proで撮影した動画を3Dで確認できるものですが、この仕組みはiPhoneに搭載された2つのカメラの距離差を利用して物体の距離感を計算し実現しています。

実は、この技術は陸上競技においても使われています。走幅跳などの長さの競技では、高精度なステレオカメラを用いて跳躍後に離れた場所から正確に距離を計測できるようになっています。
そして、昨年までのiOSDCでは走りがメインでしたが、僕は跳躍種目の方が得意です。

2眼のiPhoneを使えば、このシステムを模倣できるのではないか？実際にメジャーで計測するのと比べてどれくらい差が出るものなのか？
陸上競技歴17年の私が実際に体を張って検証した結果を動画で紹介しながら、全力疾走のスピード感はそのままに全力の跳躍と同じ迫力で紹介します。