トーク

昨年のiOSDC JapanではARKit 6のLocation Anchorをはじめとする“Visual Positioning Service/System”のVPSの世界を紹介しました。
その後、Geospatial Creatorが登場したことにより、VPSを生かしたコンテンツ作りがより身近に、よりお手軽になりました！
文字通り街中をキャンバスとして、現実世界とバーチャルな世界を統合できます！

VPSの最新動向にあわせて、Geospatial Creatorの基礎からVPSコンテンツの具体的な制作方法までお伝えします。百聞は一“体験”にしかずなので、iOSDC Japanの会期中は、実際に会場付近などでGeospatial Creatorを使ったVPSコンテンツをお試しいただけます！

iOSDC Japan 2020、2021で発表してきた『iOSではじめるWebAR』シリーズの最新版です！

先日のWWDC23でVision Proが発表されましたが、あわせてSafariのレンダリングエンジンであるWebKitがWebXR Device APIに対応することも公開情報として発表されました。

これまでSafariがWebXR Device APIへの対応を明言してこなかったことも、3Dモデルを表示するAR Quick Lookやmodel要素もすべてはこのVision Proを見据えてのものだったと今ならわかります。

Safariが歩んできたWebXRのこれまでと現状、そしてきたるべきSpatial Webの世界を見据え、想定されるWebXRのこれからをお伝えします。

Swift Concurrencyは、強力な型システムによって、同時並行処理時のデータ競合防止の静的な保証を目標としています。
しかし、クラッシュの発生や期待したスレッドで処理が実行されないなど、実際はさまざまな問題が起きます。これは、デフォルトではSwift6未満で完全なSendabilityチェックが行われない、既存のシステム(DispatchQueueなど)に対してコンパイラが静的に安全性を保証できない、などの原因が考えられます。
そこで、これを補完するための多くのツールが、公式から提供されています。
本トークでは、
「事前に防ぐ」
「問題をすぐに検知する」
「原因を調査する」
という3つのポイントで活用できる、さまざまなツールについて見ていきます。
Swift Concurrencyをより安全に利用し、既存のコードとよりスムーズに連携するためにできることを一緒に整理してみませんか？

KotlinMultiplatformForMobileの導入によりアプリ開発者はビジネスロジックの差異という問題を乗り越える事が出来ましたが、一方で独自の問題も待ち構えています。
KMM内でerrorがthrowされそれがKMM内で適切にハンドリングされなかった場合にアプリはクラッシュし、おまけにそのクラッシュはkonan::abort()という一つのクラッシュに纏められてレポートされます。
どの処理でクラッシュしたか詳細なStackTraceは提供さておらず、この状態からクラッシュを解消するための道筋を立てる事は困難でしょう。
本セッションではそのような原因不明な闇のクラッシュに対し、起きる前後それぞれで出来ることを考えていきます。

40分拡大版ではそも何故Kotlin側でerrorがハンドリングされない設計になってしまうのか、検査例外に関する歴史を踏まえた考察もしていきます。

コードを読んでいる時、

「これは何をしてるんだろう？難しいなあ…」

と、内容がわからないもどかしさを感じたことはありませんでしょうか？僕はよく感じています。
これは、いわゆるコードの「複雑さ」から来ています。しかし、複雑かどうかは人によって異なりますし、また状況次第で変わります。
今回は、この「複雑さ」に焦点を当て立ち向かうためのコードの読み方について、みなさまと考えていきたいと思います。

日々の業務では、コードを書くよりも読む時間のほうが多い傾向にあり、コードの読み方を鍛えることで、日々の開発効率をより改善できる可能性があります。

• これまでコードの読み方についてあまり意識したことがなかった
• 読んでいるコードがわからずもどかしいと感じたことがある

そんな方々が、新しい視点を知り、コードに感じる複雑さを軽減できるようになるためのヒントを得る機会になりましたら幸いです。

SwiftUIでTCAを効率的に適用するためのモジュール化の原則を紹介します。

iOSプロジェクトの規模が大きくなるにつれて、複雑さは指数関数的に増加します。 この複雑さをコントロールするために、高い凝集力と低い結合を持つモジュールの編成方法を紹介します。
このトークでは、Github上のリポジトリを検索するサンプルアプリでTCAプロジェクトをモジュラー化するための実践的な方法について説明します。

堅牢なモジュールを構築するための原則について説明します。

• 高い結合力 低い結合力
• 懸念事項の分離
• 依存関係の逆転
• テスト容易性

対象者

• SwiftUIを使用しているチーム
• TCAの採用を検討しているチーム

本プレゼンテーションでは、以下の内容に焦点を当てます。

• TCAプロジェクトの長所と短所
• モジュール化の利点と注意点
• 堅牢なモジュール構築のための原則

AppleのGPU向けプログラミングインターフェースMetalと、画像処理で一般に用いられる形態学（Morphology）を駆使し、麻雀牌の画像からその種類を見分けることに挑戦します。

「分類」と聞くと、機械学習や学習データが必要なのでは？と思う方もいるかもしれませんが、今回はあくまで画像処理だけのアプローチにこだわります。 (学習データなどは使いませんが、いくつかの制約を課します。)

宜しくお願いします。

(本セッションを聞いて下さる方へ: 麻雀のルールを知らなくても全く問題ありません。)

RunCatはMacのメニューバーにCPU使用率に応じて走るネコを表示できる個人開発のユーティリティアプリです。
開発/運用が5年目となるRunCatの歴史を振り返りつつ、技術的な課題や工夫、知見を詳解します。

・OSごとに変わるメニューバーの仕様
・ランナーの作り方とリソース節約の工夫
・アプリ内課金のProduct IDにまつわる失敗
・システム情報の取得に関する苦労
・アプリ自体のCPU使用率を下げる工夫
・バージョンアップによるマイグレーションの難しさ
・ユーザーからの不具合報告対応のコストを減らす工夫
・開発者向け機能から生まれた自作ランナー登録機能
・無学によるスパゲッティコードとリアーキテクト

などなど、可愛いだけじゃないRunCatの裏側を覗いてみませんか？

SwiftUIが発表されてから5年目に突入し、様々な応用方法がコミュニティに出回っています。
そんな中、便利ではあるものの、SwiftUIの仕組み上よろしくない実装をしているケースを見かけます。
この様な実装をしないために、初心に戻ってSwiftUIの基礎を学び直してみませんか？

このトークは次の様なテーマを取扱い

• Viewが再生成・再描画されるタイミング
• 再描画を減らすポイント: View Identity
• SwiftUIの裏側にあるUIKit

これらのテーマごとに

1. WWDCのセッション等を引用しながら、仕様を確認
2. どのようにコードを書くべきか考察

の2ステップを繰り返す内容になっています。

既にSwiftUIを使っている人でも、このトークで基礎を再確認することで
より描画パフォーマンスの良い書き方や、新しい視点での実装ができるようになることでしょう。