トーク

SwiftはiOSやmacOSの他にも、LinuxやWindowsなどのプラットフォームで動作するプログラムを開発することができるクロスプラットフォームなプログラミング言語です。

Swiftを利用するとWebアプリケーションのバックエンドやWebブラウザのクライアントサイドで動作するコードを開発することができるようになります。

しかしこれらの分野はまだまだ環境が成熟していないため、iOSエンジニアがこれから始めるのには敷居が高いのが現状です。

本トークではサーバーサイドSwiftやSwiftWasmを使って、Swiftを中心としたWebアプリケーションの可能性を探ります。

よく慣れたSwiftという言語をそのままつかい、ネイティブアプリ以外のシステム上でどのようなコードが書けるのか、という知識を得ることができるでしょう。

アプリで画面を更新するためのトリガーとしてポピュラーなものは

• Pull-to-refreshなどのユーザーの明示的なアクション
• サーバー上などのデータが更新されたタイミング

の2種類に大きく分類できます。

ユーザーの明示的なアクションで画面更新する場合は比較的シンプルに実装することが可能ですが、サーバー上のデータが更新されたタイミングに同期して画面更新を行う場合、更新通知を受け取る方法やUI更新方法など、考慮することが増えて実装が複雑になりがちです。

そこでこのトークでは、リアルタイムでの更新が必要となる具体例を紹介した後に、サーバー上のデータをリアルタイムで同期するための設計/実装について、Firebaseを用いる手法、Push通知を用いる手法、WebSocketを用いる手法など、複数の手法の比較を行い、いかにしてリアルタイムで更新する画面を実装するかの解説を行います。

Xcode が遅い。とにかく遅い!! あああ!!!

皆さんはそんな経験ありませんか...?

iOS アプリの開発にはなくてなはならないツール、それは Xcode です。
しかし、Xcode がとにかく遅いのです。
アプリが成長し、ワークペースが巨大になり、多くのターゲットができるにつれてどんどん遅くなり、最後にはハングして終了すらできなくなってしまいます。
このセッションではそんな遅い Xcode を使えるように頑張った経験をもとに、Xcode のビルドの仕組み、そして Bazel などほかのビルドツールについても検証したいと思います。

対象とする方:

• Xcode が遅くて辛い方
• 大きなアプリを作っている方
• killall XCBBuildService が癖になってしまった方
• Xcode のビルドの仕組みをちょっと知りたい方

前提とする知識:

• Xcode

ZOZOTOWN iOSチームには、緊急性は低い（あるいは明確な納期がない）が重要度が高い「効果性の領域」と呼ばれる放っておくといつまでも解決されない課題を探し改善する取り組みがあります。もちろん、改善の取り組みをするからといって機能開発を止めることはありませんし、改善専門部隊がいるわけでもありません。
機能開発をしながら、限られたリソースで改善活動をし続けるために役立つポイントをご紹介したいと思います。

• まずは改善活動への命名をしよう
• 効率よく改善するために課題を見極める
• 課題を発見するための仕組み
  その結果、取り組みは2年間ほど継続しており、数値を2倍改善した実績もあります。 　
  改善したいけどどう始めていいか悩んでいる方必見です！

自分達のアイデアを形にして新しいサービスをラウンチするのは興奮するものですし、さらにそれを軌道にのせてマネタイズするまでのノウハウは開発者の成功の証として世に溢れています。一方、アプリケーションの開発を「続ける」ことは、そのような華々しさとは縁遠く、かつフリーウェアとなれば生計を立てる外でそれを実行する必要があります。
発表者は2014年にOSSのmacOSアプリケーションCotEditorの開発を引き継ぎ、以来おおよそ月に1回のリリースを8年以上続けています。OSS開発を続けるということはどういうことなのか、どうモチベーション維持をするのか、このトークではそんなCotEditorプロジェクトを続けている哲学を紹介します。以下のような話を含みます：
・開発の基本方針
・開発を続けるモチベーション
・ユーザからのフィードバックとの付き合い方

iOSにおけるIn-App Purchase(アプリ内課金)はiOS 3から利用可能であり、その歴史は10年以上に及びます。
この長い歴史の中で、Ask to BuyやUpgrade / Downgrade、お試しオファーなどの多くの仕組みが追加され、やれることが格段に増えました。
アプリ内課金をサポートするための仕組みも、Store Kit 2による実装方法の変更やアプリ内での返金機能をはじめ、Server NotificationsやTransaction Receiptのフォーマットの変更など、新しいものが次々にリリースされたり、StoreKit Testingによって自動テストが出来たりSandbox環境がアップデートされたりなど、課金のテストにまつわる状況も大きく変わりました。
本トークでは、20分間でIn-App Purchaseの激動の歴史をじっくり振り返っていきます。

Xcodeの複数バージョンを使い分けようとしたらDockに同じアイコンが並んでどれがどうだかもうわからない！

＿人人人人人人＿
＞　もう嫌だ!　＜
￣Y^Y^Y^Y^Y￣

アプリのアイコンを自由に変更できるmacOSの素晴らしい仕組みを使って、俺得なCLIツールをSwiftで開発しました。
しかもアイコンのテンプレートはみんな大好きSwiftUIで作れるようにしました。

• auramagi/NewIconの紹介
• ArgumentParserでCLIツールを作る
• mintで配布する
• Swiftを動的ライブラリとしてビルドしてdlsymでランタイム時にロードする

参考） https://github.com/auramagi/NewIcon

SwiftUIが発表されてからすでに3年が経ちました。
しかしいまだに開発現場から採用が難しいという声が聞こえてきます。
UIKitとSwiftUIの併用も可能ですが、実際に採り入れてみるとさまざまな問題が発生しました。
このセッションではそれらの問題を解決する手法を紹介します。

• レイアウト・プレビュー
  • UIView / UIViewControllerをSwiftUIの中で使うとき
  • RepresentableKitの紹介
  • ViewをUIKitで使うとき

近年、Human computer interaction（HCI）の研究分野では機械学習を利用しスマートフォンのインタラクションをより豊かにする研究が多く行われています。

・音声認識を利用しスマホで叩いた物体を認識
・画像認識を利用しApple Pencilの機能を拡張
・イヤホンのセンサを活用した行動認識

これらの研究を応用することで例えば、スマホで欲しい物を叩くだけでECサイトでその物を注文できるようになったり、非接触でモバイル端末の操作ができたりと今までのアプリに無いようなインタラクションを実現できます。本セッションではそのような研究事例を紹介し、実際にCreateML/CoreMLで機械学習を使った面白いインタラクションをいくつか実装してみます。

昨年から、iPadのSwift PlaygroundsでiOSアプリの開発ができるようになりました。この際、従来のプロジェクト形式とは異なる「.swiftpm」拡張子のプロジェクト形式が使われるのはご存じでしょうか。実はこの「.swiftpm」は、Xcode 13.2以降で「Swift Playground App」としてXcodeでも作成できるようになっています。

この新しいプロジェクト形式は、どのようなもので、何ができるのでしょうか。従来のプロジェクト形式とは何が違うのでしょうか。

「Swift Playground App」の具体的な情報はあまり公開されていませんが、私が手探りながら調査した知見をご紹介します。

Swift-DocCは、Swiftフレームワークやパッケージのためのドキュメント作成ツールです。Swift-DocCの面白い特徴に、チュートリアルを作成できるという点があります。

このチュートリアルの作成方法の詳細は、今回のパンフレット記事に掲載します。
https://fortee.jp/iosdc-japan-2022/proposal/dfd8c56c-468a-4115-804c-d1ca103eed62

本トークでは、具体的なチュートリアルの作成過程をライブコーディングで紹介します。
パンフレット記事とともに実際のチュートリアルの動きを見ることで、より理解を深められます。

iOSアプリ開発にSwift Package Manager（SwiftPM）を活用するパターンを見かけるようになってきました。アプリ内のモジュール分割をSwift Packageを使って実現するパターンです。

この際、Swift 5.5以前のSwiftPMはビルド時に（SwiftGenなどで）コード生成する、などの処理を記述できませんでした。そのため、Xcodeプロジェクトのビルドスクリプト機能を使う必要がありました。
しかし、Swift 5.6でSwiftPMにプラグイン機能が追加されたことで、Xcodeのビルドスクリプト機能に頼る必要がなくなりました。

本トークでは、SwiftPMのプラグイン機能について解説し、iOSアプリ開発でSwiftPMをより一層活用するためのプラクティスをお話しします。

0.01秒が結果を左右する陸上競技の世界ではタイムはとても大切なものであり、日々の練習でもストップウォッチは欠かせません。
iPhoneにもストップウォッチがありますが、陸上競技の現場では画面上にあるボタンを押すことの難しさが致命的な欠点となり、実用に耐えないのが現状です。
そんな問題を解決するために音量ボタンで制御可能なストップウォッチアプリを作成したところ、App Store Reviewガイドライン違反で公開が停止…
どうすれば物理ボタンを使わずに全力疾走中でも使えるストップウォッチが作れるのか？
ストップウォッチのUXを最大限に高めるために検証した様々な対策を陸上競技歴15年の私が紹介します。

目次（予定）
・なぜ物理ボタンを使ってはいけないのか？
・実際に作ってみた
a.近接センサーを使う
b.加速度センサーを使う
c.音を使う
d.etc
・結果：一番良いインタラクションは？

React NativeやFlutterなどを使ったマルチプラットフォームアプリ開発は、1つの言語でiOSとAndroidの両方を同時に開発できるとても魅力的なアプリ開発の選択肢です。
しかし、UIデザインの視点から見るとそう簡単にはいきません。それぞれのOSはそれぞれのUIガイドラインを持っており、開発者はそれに沿ったデザインの実装が求められます。
本セッションでは、マルチプラットフォーム開発におけるUIデザインの違いを踏まえた各OSでの実装のポイントや落とし穴をいくつかご紹介します。

目次（予定）
Human Interface Guidelinesとマテリアルデザイン
デザイン実装におけるポイント・落とし穴
・そのアイコン、マテリアルデザイン？
・3ボタンナビゲーションを忘れるな
・ここまで違うの？DateTimePicker
・それぞれのOSで効果的な通知を！

WWDC2021にて簡潔かつ堅牢に並行処理を記述できるSwift Concurrencyが発表されました。
WWDCのセッションを通してSwift Concurrencyを学ぶことができますが、実世界の問題に対してどうこの技術が使えるかという文献はまだ少ないのではないでしょうか。

このセッションではSwift Concurrencyを用いて実装された実プロダクトで利用されているLoggerの実装を基に、どのように技術を適応したかを紹介します。
また、Swift Concurrencyに触れたことがない人でも理解できるように適宜Swift Concurrencyについての説明も行う予定です。

なお引用する予定のコードはすべてOSSとして公開中しています。
https://github.com/k-kohey/Parchment-swift

DAppとはビジネスロジックやストレージが分散されたアプリケーションです。
ブロックチェーンを使って実装されることが多く、DAppには下記のような利点があります。

• ブロックチェーンが稼働している限りダウンしない
• ストレージの更新等の操作がすべて保存・参照できる
• 中央集権的な管理者であってもコンテンツを消したり情報を改竄する等の破壊的な操作ができない

このDAppをiOSアプリで構築する際には下記の点が障壁となります。

• Swiftで実装された文献が殆どない
• ブロックチェーンと開発に必要なツールの知識が一定必要となる

このセッションではこの障壁を減らすべく、iOSエンジニアの視点からEthereumを使ったDAppの開発に必要な知識と作り方を紹介します。
なお、DAppを作ったことがない人・業務でブロックチェーンを使っていない人を聞き手に想定しています。

タクシーアプリ「GO」は地図をベースとしたアプリです。地図には Google Maps SDK が利用されています。

Google Maps SDK で提供される機能を駆使して、さまざまな情報を地図上で表現しています。
その実装は難しいこともあり、あらゆる工夫を凝らして実現されているものもあります。

「GO」での実例を元に、実装上のハマりポイントや苦労して実現したところ、開発時に遭遇した不思議な現象などを紹介します。

・地図上を走るタクシーの動態表示
・近くの道路に自動的に引き込ませる機能
・ルートのグラデーション表示
・タクシーを配車できないエリアを明示する
・地図の中心点を変えずに、複数の地点が収まる形にズームレベルを調整する
・地図のパフォーマンスを下げて省電力で動作させる
・カラースキームで地図の雰囲気を変える
・Google Maps における緯度経度の不思議

etc..

チームリーダーになってしまって困ってしまった開発者はいませんか？元々リーダーシップの訓練も受けてないし経験もないのに任命されてしまって困ったことはないですか？

ここでは、（クセのある）開発者と長年仕事をしてきたプロジェクトマネージャーが経験に基づいて、これだけは最低限実行していけばリーダーとしてチームを回せる以下の５ヵ条を紹介します！
・チームビルディング
・役割分担
・デイリーのポイント
・振り返り
・心が折れないために

開発者の皆さん、リーダーやマネージャーに対しての進捗報告、相談に困ったりしていませんか？説明が長くなってしまったり、細かい部分を突っ込まれたり、最悪なケースではちゃんと進捗出してるのに評価してもらえない事もありますよね？

ここでは、（クセのある）開発者と長年仕事をしてきたプロジェクトマネージャーが経験に基づいて、チームで仕事をする際に必要な以下のポイントをお伝えします！
・うまくいかないケースとは？
・チケットの立て方
・チケットの回し方（ステータスや担当者の変え方など）
・進捗状況の可視化のポイント

大規模なアプリを複数人で安定して開発するためには、アプリの設計や実装をある程度統一させることが望ましいです。特定のアーキテクチャの導入もその手段の一つでしょう。
アーキテクチャに沿ったボイラープレートコードを適用することで、実装に統一性をもたせることができます。

タクシーアプリ「GO」の iOS プロジェクトにも様々なボイラープレートコードが存在します。

開発を進めていく中で、ボイラープレートコードの一部の命名を変更する必要が出てきたり、部分的に新たなボイラープレートの追加・削除が発生することがありました。
これらの作業は難しくはありませんが、ボイラープレートコードの量が多いとその手間は無視することができません。単純な作業であれ、開発効率を下げる要因の一つとなり得ます。

この課題をどのように解消し、ボイラープレートコードとうまく付き合えるようになったのかを具体例を交えて紹介します。