UICollectionViewCompositionalLayoutはiOS 13から新しく導入されたAPIです。このAPIを使うと、AppStoreアプリや写真アプリのような、異なる大きさのセルが混在したり縦スクロールの途中に横スクロールが出現するような、iOS 12以前では１つのセルに複雑なサブビューを配置したり、セルの上に別のコレクションビューを組み合わせたりということが必要だった非常に難しいUIが簡単に作れるようになります。

実際に昨年のWWDCでAppleは、AppStoreアプリのUIをこのAPIを利用して書き直すことでかなりの量のコードを削減し、シンプルでメンテナンスしやすい実装にできたと話しています。

私はこのAPIが出てきたことにより、ほとんどのUIはコレクションビューで作ればよいと考えるほどに、すばらしく柔軟で拡張性のあるレイアウトシステムだと考えています。

しかし非常にシンプルで強力というAPIなので、１つのレイアウトを複数の方法で記述できますが、まだまだ情報が少ないためより良い書き方はどれかということがわからないこともあります。
さまざまなUIをシンプルに記述することができますが、不可能なことやこのAPIを使わない別のやり方の方が望ましいケースももちろんあります。

今どきのアプリで実際に使われている複雑なレイアウトを例にこのAPIを使って実装し、ベストプラクティスや逆にあまり向いていないケースはどういうことがあるか、などについて解説します。
UIColletionViewCompositionalLayoutを使用すべきときとそうでないとき、使用する場合のレイアウトごとのより良い実装をサンプルコードを通じて学びましょう。

iOS開発をしていると様々な "*file" を利用することになると思います。Podfile, Cartfile, Gemfile, Brewfile。様々なツールが様々な方法で導入され、setup.shが肥大化していくことでしょう。その対策の一つとしてMintを使う方法があります。MintはSwift製CUIのバージョン管理ツールです。このツールを利用することでBrewfile（そして多くの場合はPodfileも）を滅殺することができるようになります。この原稿では

• Mintを導入する流れ
• Mintを導入した時に対応に困りがちなライブラリたちとその対策
• Bitriseと組み合わせた際に困ることとその対策
• Mintを導入すれば全てがうまくいくわけではない話

などについて記述します。

iOSアプリ開発をする際、私達の多くはXcodeを利用しています。しかし実際の開発ではXcodeだけではなく、zshやfishなどのShell上での作業も少なからず発生します。この原稿では、そんなShell上で行う作業を楽にして、アプリ開発を快適にする便利なShellの設定やShell Scriptをご紹介します。

• コマンド一発で適切なxcodeproj（もしくはxcworkspace）を開く方法
• carthageなどの時間のかかるコマンドが終わったら通知を送る方法
• GitHub上のP-Rに対して素早くチェックアウトする方法

などなど、開発を少しだけ快適にする便利なShell設定たちを導入して、快適なShell作業環境を手に入れましょう！

アプリ開発者視点で暗号化技術を見た場合、Keychainといった仕組みが既に用意されているため、開発者は所定の方法でデータを渡すだけで暗号化技術に詳しくなくても暗号化技術の恩恵を受けることができます。

ただ、指定した暗号化方式で特定のデータを暗号化したい場合など、開発者が能動的に暗号化処理を利用するケースが無いとは限りません。また、ライブラリなどで使っている暗号化方式の概要について問い合わせを受けるケースもあります(自分は数ヶ月前に経験しました)。

そこで、本稿では "Apple CryptoKit" という、 iOS13 / macOS Catalina 以降向けの暗号化処理用フレームワークを題材に、CryptoKitがサポートする代表的な暗号化技術について、概要や用途を簡単なコードを交えながらご紹介します。

本稿をきっかけに、暗号化技術やApple CryptoKitに対して興味をもっていただけたら幸いです。

コンテンツ(予定):

1. Apple CryptoKitと暗号化技術の概要
2. ハッシュ関数(SHA256)
3. メッセージ認証コード(HMAC)
4. 共通鍵暗号(AES)

Swift でリアクティブプログラミングのフレームワークを使う動機のひとつは、UI とモデルとのバインディングにあると考えています。これは、フレームワークとして Combine / ReactiveSwift / RxSwift のどれを使う場合でも同じことであろうと思います。

この記事では、これらのフレームワークを使って具体的にどのようにバインディングを行うのかを整理してまとめたいと思います。また、うまくバインディングを行うための Tips 情報も紹介します。

iPad アプリの開発では、Split View や Multiple Windows への対応が求められるようになってきています。このため、UI デザインレイアウトを考える際には、端末のサイズだけではなく、Split View 表示の際にどのようなサイズになるかを知っておいたほうが良いのは間違いありません。

この記事では、iPad の Split View や Multiple Windows の表示ではどのようなサイズのウィンドウになるのかを、図で一覧表示したいと思います。iPad アプリ開発の際には、この記事を開いてリファレンス情報として使っていただければと考えています。

"Proxyman" は、macOS専用のプロキシツールです。通信を伴うモバイルアプリのリスエスト内容の確認やサーバからのレスポンスの書き換えなど、通信処理のデバッグやテスト用途において大変有用なツールです。

また、プロキシツールはインストール先のmacOSだけでなく、デバッグ対象のモバイル端末側にも設定が必要となり、設定手順が複雑になりがちなのがネックですが、Proxymanは丁寧なナビゲーションによって煩雑な手順が緩和されるような工夫が施されており、初めての方でも比較的導入しやすいツールとなっています。

本稿では、そんなProxymanの紹介や開発時に役立つ使い方についてご紹介します。

コンテンツ(予定):

1. Proxymanの概要とインストール・設定
2. SSL通信を閲覧してみよう
3. Breakpointを活用した通信内容の書き換え

昨年のiOSDC Japanで、"Heart of Swift"と題してレギュラートークを行いました。"Heart of Swift"は、Swiftが値型を中心とした特殊な言語であること、そして、そのSwiftを使いこなすために欠かせない、言語の根幹を成す（"Heart"となる）概念についてのトークです。本原稿では、ページ内のレイアウトを自由に組める特徴を活かして、見開き2ページで"Heart of Swift"の登場人物の関係性を図示し、全体を俯瞰できるようにします。

"Heart of Swift"では、WWDCでSwift Core Teamによって語られた二つの重要な概念、

1. Value Semantics
2. Protocol-oriented Programming

を軸に、Swiftの"Heart"の全体像を示しました。

この話には多くの登場人物が存在します。1については、structとミュータブル／イミュータブルクラス、値型のコレクション、inout引数やmutating funcなど、2についてはパラメトリック／サブタイプポリモーフィズム、リバースジェネリクス、Opaque／Existential Typeなどです。それらの登場人物は互いに関係し合っており、Swiftという特徴的な言語を形作っています。

言葉による説明を聞いて、その複雑な関係を頭の中に描き出すのは容易ではありません。昨年のトークの最後にはまとめとして図を示し、理解の促進を図りました。しかし、スライドの中に事細かに説明を書き入れられるわけではありません。登場人物の関係を図示し、説明を書き入れるのに、見開き原稿は最適なメディアです。大きなスペースを使ってその関係と説明文を視覚的に示し、Swiftの"Heart"について、読者のより直観的な理解を目指します。

WWDC19でAppleにより発表されたCombineフレームワークはリアクティブプログラミングを宣言的に行うためのフレームワークです。しかしリアクティブプログラミングに慣れていない開発者にとって、このフレームワークで登場するPublisherやSubscriber、Subscriptionなどのさまざまなパーツをすんなりと理解することは難しいのではないでしょうか。

本原稿ではそのCombineフレームワークの全体像について図を用いて解説します。

RxSwiftなどのリアクティブプログラミングに慣れている開発者にとっても、自分の知っている概念とCombineフレームワークのパーツ名を一致させることで、さらに違いを整理できるはずです。

iOSアプリ開発でよくあること（俗にいう「あるある」）を4コママンガでめちゃくちゃ面白く表現します。

【運営の方へ】
スベる可能性が高いので、紙面が余ったらご採択くださいｗ

※本原稿は、同様のタイトルで出したトークの原稿版です。

みなさん、iOSアプリ開発でCIを行っていますか？
なかなかCI環境を構築する時間が取れず、行っていない人も多いと思います。

でもご安心ください！
iOSアプリのCI環境は、どのような規模や種類のアプリでもだいたい同じです。
一度構築すれば他でも使い回せます。

本原稿ではFastlaneやCIサービス独自の機能をできる限り使わず、スクリプトベースでCI環境を構築する方法を紹介します。
そのため、どのようなCIサービスを使っていても取り入れやすいです。

【目次】
・ライブラリのセットアップ・ビルド・単体テストを実行するスクリプトの作成（Makefile）
・ビルド・単体テストを実行するCIの構築
・★キャッシュを使ってCIの実行時間を短縮する
「★」はGitHub Actions独自の機能を使う

【想定する読み手】
・iOSアプリ開発でCIしたことがない人
・CI環境の構築に苦戦している人

【ゴール】
・CIしたくなる
・CIの意味とメリットがわかる
・GitHub ActionsでiOSアプリをCIできる
・CIサービスにかかわらずiOSアプリをCIできる

【使っているツール・ライブラリ】
本原稿では以下のツールやライブラリを使います。
使っていなくても応用できるように説明しますが、知っていると原稿を理解しやすいです。
・Mint
・Bundler
・Carthage
・CocoaPods
・XcodeGen
・xcpretty

本原稿を読んで、実際にCI環境を構築してくださると嬉しいです！

LSP（Language Server Protocol）はIDEで必要とされるソースコードのオートコンプリートやシンボルの定義元にジャンプするなどのプログラムを解析して情報を提供する機能をサービスとして実現するものです。
IDEで必要とされる機能というものは、プログラミング言語が変わってもやりたいことはほぼ同じです。LSPが登場する以前は言語ごとのIDEがそれぞれ実装して提供していました。
LSPは、このような言語が変わっても共通して求められるIDEの機能を抽象化して開発ツールから使えるようにする仕様です。

SwiftのLSP実装はSourceKitを利用して作られているのでSourceKit-LSPと名付けられています。
SourceKit-LSPを利用すると例えばVS CodeなどのXcode以外のエディタでも、LSPに対応していればXcodeが提供するような入力補完や定義元にジャンプするなどの機能を利用できます。
LSPは非常に複雑なIDEの機能を、APIを利用するように簡単に使えてしまう技術といえます。

Xcode以外のエディタでXcodeの機能が利用できることは便利ですが、コードを読むときにも必要だと思いませんか？

LSPはどんなソフトウェアからも使えます。
LSPを利用するブラウザ拡張を作成すると、GitHubでコードを読むときにも定義元へのジャンプなどXcodeを使って読み進めていくときと同じ体験を提供できます。

この講演では実際に私が作成したSourceKit LSPを利用するブラウザ拡張を用いて、GitHub上のコードをブラウザでコードジャンプを駆使しながら読み進める様子をお見せしながら、さらなる応用としてサーバーサイドからLSPを利用することで、iPadでも快適にコード読める技術の作り方を解説します。

AltSwiftUIは、iOS11をサポートするために構築されたSwiftUIに触発されたオープンソースフレームワークです。このフレームワークのAPIは、SwiftUIと非常によく似たスタイルと構文に準拠しているため、SwiftUIの知識を再利用できます。

●AltSwiftUIについて
https://altswiftui.com/

●GitHub
https://github.com/rakutentech/AltSwiftUI

●Agenda
1.18:20-18:40　AltSwiftUIの紹介動画配信（20分/ニコ生にて配信）
--------Zoomに移動をしていただきます--------
2.18:40-18:50　AltSwiftUIのワークショップ（動画で紹介するRamen Xcode Project)を利用します（10分）　
3.18:50-19:00　楽天のアプリ紹介
　-楽天市場アプリ（5分）　発表者：Sato Seiju
　-Rakumaアプリ（5分) 　発表者：Sato Yukihiro
4.19:00-19:10　Q&A（10分）

※紹介動画は英語ですが、日本語字幕がついております
※ニコ生で配信をする動画の最後にZoomのURLを記載しております
Agenda2はKevinが発表/担当をするため通訳が付きます（ご安心ください！）
Agenda3は日本語での発表となります
Q&AではZoomのチャットより文章にて質問の投稿をお願いいたします

AVAudioEngineでは様々なエフェクトを簡単に入れることができます。しかし、中には自分で独自のエフェクトを作りたいという場合もあるでしょう。今回はAVAudioEngineを使って、AVAudioPCMBufferを加工する例を説明しながら、カスタムエフェクトの作り方について解説していきます。
また、後半はAVAudioEngineでManualRenderingModeを使って、AudioUnitからマイクの音声を取る方法や、AVAudioRecorderのようにAVAudioEngineから音声ファイルを保存する方法についても解説していきます。
iOSのメディア周りにご興味がある人は楽しめるトークです。ご期待ください。

所 友太 / Spinners Inc.
2020年におけるHomeKitの総括。

みなさんにあまり知られていないだろうHomeKitの入門からオープンソース化されたHomeKit ADKまで20分に凝縮してお届けします。

• HomeKitざっくり入門
• HomeKitにおけるBridgeの概念
• HomebridgeでHomeKit未対応の製品をHomeKit対応
• HomeKit Accessory Development Kitで作る自作アクセサリ

トビラシステムズ株式会社では、アプリ内に迷惑電話フィルタ機能を実装しています。
弊社では3年以上に渡り多くの電話番号情報を提供するためにCall Directory Extensionと向き合ってきました。
何かと制限が多いCall Directory Extensionに多くのデータを安全に入れるために実践してきたTipsをご紹介します。

【サマリー】

• 各OSごとのパフォーマンス
• 差分データの更新のTips
• メモリ管理
• 更新途中でキルされるとCall Directoryがクラッシュする問題

J2ObjC とは Java で書かれたコードを Objective-C に変換するコンパイラです。

マルチプラットフォーム開発として、ロジックのみを共通化する仕組みとしては、Kotlin Multiplatform Project (Kotlin/MPP) などが有名ですが、Kotlin/MPP はまだライブラリが充実しておらず、共通ロジックを書く上で他言語にはあるようなライブラリを用いて開発したい場合に、障壁が多く難しいといった課題があります。

J2ObjC では Java のコードを Objective-C に変換して用いることができるため、既存の Java の資産を用いて開発することが可能です。もちろん各種 Java の OSS ライブラリを (条件はありますが) 使う事が可能であるため、比較的自由度が高い共通ライブラリを作成することが可能です。

私の個人開発のアプリでは、共通ロジックが非常に複雑で、それを構成するために様々な既存のライブラリが使用できることが予め分かっていました。そのため、マルチプラットフォーム開発における技術策定では、いかに共通ライブラリを既存のライブラリを用いて簡潔に記述するか、が重要な要素として存在しており、J2ObjC を採用し、実際に iOS アプリをリリースまで行いました。

トークでは、採用した理由から、リリースまでの体験談、またその過程で得られた知見についてお話します。

予定している内容

• J2ObjC を採用した理由
• J2ObjC 環境構築
• 発生した問題とその対処

対象

マルチプラットフォーム開発に興味があり、Java資産を持っており、めげない心を持っている iOS/MacOS 開発者

「iOSから連絡先をサーバーに同期させたい」
用件を受け、iOSにはContact APIがあるから楽勝でしょ、と思ったあなた。
しかしながら連絡先の構造はそんなに簡単なものではありません。
ミドルネーム？Suffix？振り仮名？旧姓？
そんなハマりやすい連絡先処理の説明やVCard変換など、
サーバーのテーブル設計にも役立つiOSのContact APIについてお話しします。
(Androidの連絡先にも若干触れる可能性あり)

定期的に配信されるコンテンツがあるサービスでは、自動ダウンロードの機能がより良いユーザー体験を提供します。
ユーザーは常に安定した通信環境にいるとは限らず、大きいコンテンツの取得には通信的な負荷もかかります。
例えば、新聞紙面の画像はサイズが大きい複数枚の画像で構成されており、ダウンロードには多くの通信量や実行時間が必要となります。
あらかじめ大きいコンテンツを自動でダウンロードしておく仕組みは、ユーザーがアプリを継続的に利用するにあたり非常に重要な役割を担います。

iOSではバックグラウンドでコンテンツをダウンロードするためのAPIが複数用意されています。
しかし、バックグラウンドでタスクを動かすタイミングや時間はOSによって制御されており、ユーザーが調整できる箇所は限られています。
それぞれのAPIが抱える制約を理解し、コンテンツの性質に応じて適切な選択をしなければなりません。

本セッションでは、大きい画像コンテンツを対象にした自動ダウンロード機能について説明します。
実装の過程で直面した問題への対策やアプリやサーバーサイドを含めた全体のアーキテクチャを解説するとともに、日本経済新聞 紙面ビューアーにおける新聞紙面画像での運用事例を紹介します。
大規模サービスにおける運用を通じて得られた安定して自動ダウンロードを成功させるための課題の解決方法を説明します。

アプリの運用を続けていくと、成長に合わせて機能も増えていきます。
機能のリリースを優先した運用を続けた結果、月日が経過してふと気づいたときにアプリのパフォーマンスが低下していたという経験はないでしょうか？

このトークでは、4年間運用されて表示パフォーマンスが低下していった詳細画面を題材に、原因の特定から最大で表示速度が200%改善するまでを以下のような観点を踏まえて紹介します。

第1フェーズ（調査）

・表示速度をどのように計測するか
・何が原因で表示速度が落ちていたか
・そもそもどのようなViewの構成だったか

第2フェーズ（最短リリースを目標とした改善）

・どのようにViewを生成していくか
・データの受け渡しをどのように繋げていくか

第3フェーズ（画面回転も考慮した改善）

・改善するためにどのようなViewの構成に変えていったか
・Viewに紐づくデータはどのように定義したか

まだしばらくはUIKitも現役なはずなので、これから改善をやってみようという方も新規の実装をしていこうという方にも、参考になる知見を紹介できればと考えています。