日本にiPhone 3Gが上陸した2008年から今日までの間でiOSは大きく変化してきました。
App Store、Siri、フラットデザイン、Touch ID/Face ID、ウィジェットなど今では当たり前となった様々な機能がいつリリースされたものか覚えているでしょうか？
そんなiPhone 3Gが日本に上陸してから現在の最新バージョンまでのiOSの歴史を、具体的な例も挙げつつ5分間で振り返ります。

概要

アプリの歴史が積み重なっていくと内部ロジックはどんどん複雑化していきます。

時として、予期せぬバグが生み出され、それが大きなトラブルに繋がることもあります。

突発的に発生しうるトラブルに対して、アプリとしてはどういった仕組みを準備しておけばよいのでしょうか。

我々のアプリで実際に発生した悲劇のエピソードとともに、トラブル時も適切に対処できるような、耐障害性の高いアプリの実現に向けてみなさんと考えていきたいです。

発表内容

• 小さなバグが生んだ悲劇
• より良いメンテナンスモードの設計
• 強制アップデート機能の設計とその勘所
• どうすれば障害を防ぐことができたのか
  • 目にみえないバグへのアプローチ
• 現状の課題と今後の展望

Real Time Messaging Protocol (RTMP) とは、Adobe が開発している、Adobe Flash プレーヤーとサーバーの間で、音声・動画・データをやりとりするストリーミングのプロトコル。
YouTube LiveやTwitchなどのライブストリーミングサービスで広く使用されています。

AppleのプラットフォームではRTMPプロトコルがネイティブにサポートされていないため、librtmpライブラリの使用が一般的ですが、私はSwiftでの実装に挑戦しました。
このトークでは、Swiftを用いてRTMPライブラリをゼロから設計し、実装した経験を共有します。
特に難しかった挑戦、それにどう対処したか、そしてプロジェクト全体を通じての学びを詳しく紹介します。

基盤開発やリファクタリングを主に行っているチームで、それまで取り組んでいたアジャイル方式のスクラムからカンバン方式に移行した話をします。
本トークではカンバン方式の説明およびカンバンを取り入れて良かったことなどを具体的な例を用いながらお伝えできればと思います。

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

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

宜しくお願いします。

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

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

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

宜しくお願いします。

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

皆さんは、macOS のスクリーンセーバを自作できることをご存知ですか？
実は、Apple から Screen Saver Framework が提供されており、ScreenSaverView を継承してカスタムスクリーンセーバを Xcode で開発できます。ただし、UIKit や SwiftUI でお馴染みのアニメーションは使えず、フレーム毎の座標計算が求められるなど、スクリーンセーバの開発には独自のテクニックが必要となる一面もあります。

このトークでは、 ScreenSaverView のライフサイクルやレイアウトテクニックを紹介しながら、5分という制限時間内で リアルタイムにスクリーンセーバを構築します。
トーク終了後には、きっと Screen Saver Framework の魅力に取り憑かれることでしょう！

• 怖くないニーモニック
• 文字出力と演算
• Swift とアセンブリ

Apple Silicon、皆さんはどれくらい使い倒していますか？
現代の令和においても、我々は CPU と非常に近い距離で対話する手段を持っています。それがアセンブリです。
アセンブリは機械語に非常に近い低水準言語であり、CPU アーキテクチャによって記述方法も異なります。Swift などの高水準言語では記述方法が言語のバージョンアップ以外で変わることは少ないため、この特性に疑問を持つ人もいるかもしれません。

本稿では、アセンブリを通じて Apple Silicon を操作する方法を紹介します。初めは仕事に直接活かせないように思えるかもしれませんが、Apple Silicon と近い距離で対話することは意義深いものです。きっと Apple Silicon がさらに魅力的に感じられるでしょう！

決済アプリなどで二次元コードを表示する画面になると画面全体が明るくなって眩しくて辛いことがありますよね...
ただ、画面を明るくしないと二次元コードを読み取る際にうまく読み取れずユーザーにストレスを与えてしまいます。

そこで iOS 16から使える Metalフレームワークの機能 Extended Dynamic Rangeです！
EDRを使うことで、一部分だけ最大輝度で表示することができ、眩しさを感じさせません。
さらに、画面を明るくしたり暗くしたりするちょっと大変な処理も消し去ることができます。

ぜひ、ユーザーに良い二次元コード体験をさせられるようにEDR導入しませんか？

このトークでは以下の構成でお届けします！

• EDRの仕組み・メリデメ
• EDRの実装方法
• 注意事項

このセッションを通じて、Core ML Stable Diffusionの利用方法を簡単に深く学び、iOS上でAIを活用することができるようになります！
わくわくするAIの世界を楽しく体験しましょう！

1. Core ML Stable Diffusionとは何か？
   　どのように機能するのかを、専門的な言葉をなるべく使わず基本概念やメリットを理解できるように解説します。
2. 手順と実践例
   　具体的な手順と実際のコード例を通じて、iOSアプリに組み込む方法を学びます。
3. デモとエクササイズ
   　参加者が自身のデバイスで手軽に試せるデモやエクササイズを用意します。
4. ユーザーエクスペリエンスのアイデア
   　Core ML Stable Diffusionを使って実現可能なユーザーエクスペリエンスのアイデアを共有します。

iOSではリストの子要素をスワイプするUIをよく見かけます。
SwiftUIでは、Listに子Viewを列挙することでリストを実現でき、その子Viewに対してswipeActionsを利用しスワイプを可能にします。
しかし親ViewがList以外の場合、子ViewにswipeActionsを利用しても、スワイプは適用されません。
よって、親ViewにListを使わずに構築しているリストなどの子Viewにスワイプを適用する場合、swipeActionsを適用できないため独自実装が必要となります。

本トークでは、Listではない親Viewの子Viewにスワイプを適用するために独自実装したSwipeableStackを紹介します。
SwipeableStackの実装内容と使い方を具体的に解説します。

Alamofireを使って通信処理を実装しているアプリ世の中には結構あると思います。
Alamofireはv5.5.0でSwift Concurrencyに対応されており、いくつかのmethodが存在しています。
このトークではAlamofireでのSwift Concurrencyに対応された実装の紹介と、具体的な実装方法などを踏まえて紹介したいと思います。
説明内容
・AlamofireのSwift Concurrencyのメソッド紹介
・実装前と実装後の具体的な比較をもとにした実装方法の紹介

みなさんHuman Interface Guidelines読んでますか？
HIGにはAppleのプラットフォームで優れた体験を生み出すための豊富な知識が詰め込まれたガイドラインです。
2022年6月以降内容をアップデートしさらにパワーアップしております。WWDC2023ではついに日本語にも対応しました。
そんなHIGですが、なかなか量が多く、読むのに時間がかかります。忙しい開発者の方々は呼んでる時間なんてないよ😭という人も多いでしょう。
そんな方に向けて本稿では特に私が大事だと感じた部分を抜粋し標準アプリの実例を備えて解説させていただきます。
・ 標準アプリの実例を踏まえて大事だと思ったところを説明します。
・ すぐにでも明日の開発に役立つよう業務に役立つ内容に焦点を当てます。
・ 実際にアプリケーションを開発する上で役に立った点などを説明いたします。

私達はTVerという動画配信サービスを開発・運営しており、昨年4月に一部システムを内製化しました。
しかしモバイルアプリケーションについてはほぼ全ての開発をパートナーのお世話になっており、自社のiOSエンジニアはまだ1人もいません。

内製であれ外部への委託であれ、サービスを提供する以上は私達がサービスへの責任を全て負う必要があります。
本トークではiOSアプリケーション開発への専門知識が無いSREの私がNew Relicを導入し、動画配信サービスならではのサービス品質可視化と改善を行っている話をします。

聴講対象

・ オブザーバビリティの導入を検討しているiOSエンジニアおよびSRE

お話すること

・ TVerにおけるiOSアプリ開発の課題
・ オブザーバビリティの実装と効果
・ 動画プレイヤーの観測

お話しないこと

・ TVerにおける具体的なiOSアプリの実装

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

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

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

タクシーアプリ『GO』では、現在大規模な英語への対応作業を進めています。
日々追加される案件開発や差し込みでの対応と並行しながら、既に存在する大量の画面をPdM・デザイナーと適切に連携を取りながら複数言語に対応させていく作業はかなり難易度の高い作業です。
現在タクシーアプリ『GO』では外部文言ツールとGitHub Actionを組み合わせた文言管理を行っていますが、現在の運用に方法を採用するまでには様々な課題が有りました。
そこで本セッションでは、多言語対応に本格着手した際に発生した課題や問題点に対してどのように対応してきたか、及び現在の運用にしてどのような問題が解決されたのかなど、多言語対応にどのように開発チームが対応してきたのかをお話いたします。

Swift Playgrounds Appを使用することで普段のアプリ開発するWorkspace上で、簡単にDemoApp, PreviewAppを作れるよっていう話をします。
マルチモジュール構成やSwiftPackageを使ったマルチモジュール構成での開発も増えてきたかと思いますが、
デモアプリの開発でXcodeProject(.xcodeproj)を使うと、WorkspaceとProjectを行ったり来たりしないといけなかったり(複数Window)、WorkspaceやProjectを複数開いた場合に共通するpackageの依存が解決されないや、デモアプリのProjectで検索がうまく動かないなど(特に移行期など)が発生します。

1Workspaceで、Package内のモジュールの開発build、Appのbuild、デモアプリのbuildまでできる環境便利です。

アプリケーション等のプログラムを実行する際最初に呼び出される処理や関数のことをエントリーポイントと呼びます。
Objective-C時代はmain.mというファイルが必要でしたが、Swiftになって @UIApplicationMain が登場しエントリーポイントが隠蔽されるようになりました。
更に、SwiftUIや @main の登場により @UIApplicationMain を deprecated にしようという動きもあります。

本トークではそんなエントリーポイントの変遷を紐解いていくことで、エントリーポイントについての理解を深めていければと思います。

「エントリーポイントについて理解するとAppDelegateをモック化できる」
「AppDelegateをモック化できるとどうなる？」
「知らんのか」

「副作用の少ないテストが書ける」

「お前も Swift Playgrounds を使った開発者にならないか？」（１年ぶり２回目）
　
昨年の「iPadOSDC Japan 2022」では、Swift Playgrounds を知ってもらうために、 Xcode との機能差分やメリット・デメリットを紹介しました。
本セッションでは、その中でも触れた内容の１つをさらに掘り下げます。
　
Swift Playgrounds では、プロジェクトファイルを持たずに、Package.swift を起点に開発することになります。
これをうまく活用することで、Xcode と併用して Feature 単位でのマルチモジュール開発が可能になります。
　
ただし、これは完全に機能するわけではなく、まだ問題点もあるので、実際のプロジェクトを通して経験したことも含めて、お話ししていきます。

背景

最高のユーザ体験は、単に素晴らしいデザインや機能性だけでなく、異なるデバイス間でも一貫性と流動性を持つことが求められます。特にiPhone AppをiPadやMac Catalystに単純に移植するだけでは、ユーザーに違和感を与えることがあります。

本トークでは異なるAppleデバイス間での一貫した体験を提供するためのデザイン戦略と技術的なアプローチを解説します。
ソースコードはSwiftUIを前提とし、UIKitは本トークでは扱わないものとします。

Agenda

1. iPad, Mac Catalystでビルドする
2. Stage Manger対応(デザインとコードの両方面)
3. インタフェースデザインの最適化
4. App Iconのデザイン
5. デバイスの独自機能の利用(写真、ドラッグ&ドロップ、キーボード、カーソルなど)
   and more...