トーク

皆さんは声優さんになりたいと思ったことはありませんか？例えば、自分が声を当てたキャラクターがゲームで活躍する妄想をすると、ワクワクしてこないでしょうか。しかし、アフレコの実力や膨大な文章の収録などの技術面・コスト面の障壁があり、素人がキャラクターに声を当てるのは簡単ではありません。

本トークでは、誰でも自分の声のキャラクターをアプリに登場させる手段として、iOS 17にて追加されたアクセシビリティ機能「パーソナルボイス」を使用し、ユーザの声で自由に語句を発話させる方法について説明します。また、「誰でもゲームアプリ声優になれるアプリ」のデモを通じて、パーソナルボイスの実際の活用例をご紹介します。

具体的には次のトピックについて話します：

• AVSpeechSynthesizerを使用して学習したパーソナルボイスで発話させる方法
• AVSpeechSynthesisVoiceで定義された他の音声合成機能との共存方法
• パーソナルボイスを活用したゲームアプリの実例
• パーソナルボイス導入における課題

このトークを通じて、iOSの「パーソナルボイス」の導入および利活用方法と、ゲームキャラクターに命を吹き込む新しい方法を理解していただけます。「パーソナルボイス」があなたのアプリに「自分の声での発話」という新しい価値をもたらし、多くのユーザの夢を叶える一助となれば幸いです。

みんなー リョムキャットのパーフェクトSwiftネーミング教室はじまるよー

Swiftの関数名、どのように命名していますか？
本LTではSwiftの関数名の命名時に考えるべきことについて紹介します。

弊社には全くコメントを使わずに名前だけで全てを表しているプロジェクトがあり、弊チームでも追随してコメントをなくしていこう！という風潮になりました。
コメントを完全に消すのはまだ議論の余地があるところですが、たしかにコメントがないと処理がわからない関数名は是正していくべきでしょう。
そこから命名について思い悩む日々が始まりました。

体を名で表すのは至難の技で、もはや芸術の域です。
そんな中、 Apple は Swift API Design Guidelines という指針を提示しています。このガイドラインを読み解きながら、Swiftらしい良い命名について一緒に考えていきましょう。
このLTを通じて、パーフェクトでSwiftライクなグッドネーミングセンスを身につけられます！

LTで話すこと：

• Swift API Design Guidelines で言及されている命名規則の紹介
• 自然に読める関数名にする工夫
• 英語力がなくてもいい感じの命名をするには

プロジェクトを進めていると、時折奇妙なバグに遭遇することがあります。。
今回のプレゼンテーションでは、最近出会った興味深いバグをいくつか紹介し、その解決策についてお話しします。
これらのバグはすべて、私たちのミステリーと挑戦の精神を刺激し、コードの再考を促すものでした。

1. 絵文字を表示するとレイアウトが崩れた！
2. 画面録画をするとレイアウトが崩れた！
3. 特定の条件ではアプリをバックグラウンドからフォアグラウンドに切り替えると画像が表示されない！

他にも興味深いバグがいくつかあり、その詳細についても触れます。

このような興味深いバグを通じて、私たちはコードの特異性を発見し、より良いソリューションを見つけることができました。
このプレゼンテーションでは、これらの挑戦的なバグに対する解決策と学びを共有し、共に成長する機会を提供します。

CarPlayとは車載ディスプレイでナビゲーションや音楽の再生が行えるものです。運転中に使用されることが多いため、CarPlayアプリは運転を妨げず、安全で使いやすい設計が求められます。
このトークでは、AppleのHuman Interface Guidelines（HIG）やプログラミングガイドを読み解き、ナビゲーションを行うデモアプリを通じて、使いやすく運転者にとって安全なCarPlayアプリの魅せ方を紹介します。

LTで話すこと：
・HIGから考えるCarPlayの最適な見せ方
・CarPlayアプリのパフォーマンス最適化
・実例で比較する安全な表示

iOS開発者なら誰しも一度は目にする、デフォルトの青いTint Color。この色が選ばれた理由について、考えたことはありますか？本トークでは、その裏に隠された秘密を探ります。

まず、Appleのデザイン哲学や他OSとの比較、歴史的な経緯に基づき選択の理由を明らかにしていきます。次に、青色が持つ視覚的な特性について、色彩理論や人間の視覚に関する研究を交えながら、なぜ青色が適しているのかを探ります。

このトークを通じて、Appleのデザイン哲学やその背後にある考え方を深く理解することができるようになります。そしてデフォルトの青色を軽視せず、その価値を再評価することで、より洗練されたデザイン選択ができるようになるでしょう。

「Simulatorアプリでマウススクロールを使えたらいいな」
普段アプリ開発をしている中で、このようなことを思ったことはありますでしょうか？

Simulatorアプリで画面をスクロールするには、マウスのドラッグ＆ドロップで操作する必要があります。
慣れてしまえばなんてことないですが、マウスをいちいち動かすのは地味に不便です。

本LTでは、この問題をmacOSのCore Graphicsの機能で解決していきます。
Core Graphicsを使えばユーザイベントを変換することができ、擬似的にSimulatorアプリ上でマウススクロールを使うことができます。

「Core Graphicsなんてグラフィック系のライブラリでしょ？」と思ったら大間違い。実はユーザイベントにも深い関わりがあるんです。
あなたの知らないmacOSのハック術、お教えします。

macOS上で動作するIMEを、Appleが公式で提供するInputMethodKitを利用して開発しました。

InputMethodKitでは主に、IMKInputController、IMKCandidates、IMKServerの3つのクラスを使って開発します。実際に開発をする中で、特にロジックが集中するIMKInputControllerのコードが肥大化していき、コードの見通しが悪くなるという問題に直面しました。

そこで、この問題を解決するためにThe Composable Architecture（TCA）を導入しました。

本セッションでは、これらの開発体験をもとに、InputMethodKitでよく使う項目に対しての解説と、UIKit/SwiftUIを使用していないコードに対してどのようにTCAを適用するかを中心に発表します。

スクロール。
それはUI操作の核とも言えるジェスチャーの一つであり、それを実現するためのフレームワークもまたiOSアプリ開発において欠かせない存在です。

しかし、SwiftUIのScrollViewはiOS13で登場した当初、非常に使いづらいものでした。
基本的なスクロールの機能は提供されていたものの、カスタマイズ性に乏しく、UIScrollViewで実現できた多くの動作を再現することは困難でした。

しかし時は2024年。iOS17の登場でScrollViewも進化を遂げました！

このセッションでは、iOS17で追加されたmodifierを中心に、SwiftUIのScrollViewがどのように進化したのかを具体的な例を交えてご紹介します。

このセッションでは、数値を文字列に整形する際に陥りやすい落とし穴について、具体例を交えて紹介します。

例えば、以下のような関数でパーセンテージの文字列を得ようとする場合を考えます。

func percentStr(_ rate: Double) -> String {
let value = floor(rate 1000) / 1000
let percentValue = value 100
return "(percentValue)%"
}

これを print(percentStr(0.523)) として実行すると、どのような出力が得られるでしょうか？

実際の出力は 52.300000000000004% となります。予想できましたか？

このセッションでは、数値を文字列に整形する際に私が陥った落とし穴について解説します。
具体的な内容は以下の通りです。

1.浮動小数点数の精度問題:
なぜ浮動小数点数がこのような誤差を生じるのか、その理由と背景について説明します。
2.NumberFormatterの活用:
NumberFormatterを用いた解決策を紹介し、どのように実装するかを具体的に示します。

このトークを通じて、皆様が同じような問題に直面した際の参考になれば幸いです。

iOS16(iPadOS)以降に提供させれているSwiftAPIであるRoomPlanはすごい速度でお部屋をスキャンしてミニチュアハウスを作れます。

普段地図や位置情報で楽しく遊んでいる私が、どのように自身の活動にiOSのアプリ作成を取り入れ、RoomPlanにより作成したデータを利用しているかを5分で話し切ります。
モバイルアプリケーションを専業とされている方のみならず、測量や建築、環境デザインに携わっている方など周辺領域に広く届くように、アプリケーション構築が気軽に行えることをお伝えすることもテーマの一つです。

旅行先でもスキャンがしたくてたまらないようなモバイルスキャン星人を増殖させます。

Swiftでテストを書く際、Xcodeに組み込まれたテストフレームワークである XCTest を利用することが多いかと思います。しかし、XCTest は当初、Swift ではなく Objective-C でテストを書くことを目的として作成されました。そのため、Swift5.5 から導入された Swift Concurrency への対応が不十分であるという問題点があります。

そこで登場したのが新しいテストフレームワークである swift-testing です。
swift-testing は、非同期プログラミングをより効果的にテストできるように設計されており、Swift6 からはこのフレームワークの利用がデフォルトになると考えられています。

このLTでは、以下の内容について紹介します。

• swift-testing と XCTest の違い
• swift-testing への移行作業
• swift-testing を使用する際のベストプラクティスとトラブルシューティング

Swift言語におけるエラー処理のメカニズムは、他のプログラミング言語と共通する命名や概念を持ちながら、その実装と性能の特性において独自のアプローチを取っています。本トークでは、Swiftのエラー処理の仕組みを具体的なコード例とそのコンパイル結果を通じて解説し、他の言語との比較を行います。

発表では、まずシンプルな例を通じて、エラー処理付きの関数がどのようにコンパイルされるかを示します。特に、throwキーワードの周辺で行われる処理、つまり通常の戻り値処理に加えたエラーオブジェクトの伝達、およびtry周辺でのエラー検知と分岐処理に焦点を当てます。

そしてコンパイル結果の観察から、Swiftが如何にして他言語と類似の構文を提供しながら、実行時の負荷を軽減しているかを明らかにします。比較対象としてJavaを挙げて、類似の構文を提供しながらもその実装方法と実行時の性能に違いがある点を簡潔に解説します。

このトークはさまざまなエラー処理方法を一通り学んだSwift中級者へ特にお勧めできるものです。
このトークを通じてtryを利用したエラー処理の性質をより深く理解し、さまざまあるエラー処理方法の中から状況に応じた適切な方法を選択できるようになると考えています。

iOS15とともに登場したScreen Time APIですが、皆さんは使ったことがありますか？
iPhoneにデフォルトで搭載されているScreen Timeではアプリの起動時間を制限したり、アプリの利用時間を取得することができます。
そんなScreen TimeはAPIが公開されており、アプリからも使用することができます。
APIを利用すると、アプリのロック画面をカスタマイズすることができたり、Screen Timeを利用する時間やタイミングをより細かく調整することができます。

Screen Time APIは便利なAPIですが、現状使っているアプリが少なく、あまりメジャーではないため知見があまり出回っておりません。また、ドキュメントに記載されていないが、知っておくべきポイントというのもたくさんあります。

このLTでは、Screen Time APIとはなんなのか、一体何ができるのか？、どのようにすれば使えるのかなどScreen Time APIを使うにあたって知っておくと便利なことを実際に生活習慣改善アプリを開発した話を交えながらお話しします。

その昔iPhoneのRAM容量は512MBや1GBしかなく、メモリ管理は非常に重要でした。しかし、近年では3~8GBの容量が一般的になり、メモリ不足に悩むことは少なくなりました。

それでも開発者にとって適切なメモリ管理は重要です。メモリリークや不要なメモリ使用を避けることで、アプリのパフォーマンスを向上させることができます。
iOS開発ではARC（Automatic Reference Counting）によってメモリ管理が自動化されていますが、オブジェクトが解放されずに残ってしまうケースがあります。

このトークでは、特に注意が必要な5つのポイントについて解説します。

1. クロージャ内self参照による循環参照
2. 親子クラスの循環参照
3. UIImage(named:)による画像呼び出し
4. URLSessionConfiguration = .defaultの指定
5. URLSessionDelegateのextension実装

これらのポイントを押さえて、アプリのパフォーマンスを向上させましょう！

プログラミングとかけまして音楽と解きます、その心は？
どちらもコード(code | chord)が重要です

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

音楽はセンスがないとできないというわけではありません。
コードネームから構成音を求めるプログラムを作ることができます。
コード進行やリズムにはパターンがあり、デザインパターンやライブラリのように利用することができます。
音楽にも理論があります。

本トークでは

1. コードネームから構成音を求めるプログラムを作ってみる
2. コード進行やリズムのパターンを利用する
3. 音楽理論は楽しい

についてお話しします

プログラマならではの視点で、音楽を楽しんでみませんか？

ある日、ショッピングアプリのQA中に1つのバグ報告がありました。
ショッピングアプリの主要な機能である「価格の絞り込み」や「カート投入時の数量」などで利用するTextFieldで一律「2」が入力できなくなっていました。
この致命的なバグに、全く想像もつかず、チーム全員が固まってしまいました。

最初に疑ったのはソースコードの実装。ですが、ソースコードには特に問題は見当たりませんでした。それでは、特定のOSの問題か？どうもこれも違うようでした。

いったいなぜ「2」が入力できないのか？
そして辿り着いた原因は、我々が全く想像しなかったものでした。

笑撃の結末を見逃すな！乞うご期待ください！