トーク

SwiftUIが発表され早2年が経ちました。そんなSwiftUIですが、本番アプリで採用されているケースはまだまだ少ないかと思います。
お友だちやご家族と一緒にシェア買いができるアプリ「KAUCHE（カウシェ）」は、大部分がSwiftUI,Combineを活用して作られており、2020年9月にリリースしました。
そして、リリースから1年運用しています。
・SwiftUI,Combineを活用し、どのようなアーキテクチャで開発・運用しているのか
・SwiftUIで開発中に問題となった点
・運用している中でわかった良かった点・悪かった点
などをお話したいと思います。

I will explain stack memory basics using Swift, and highlight some of the pitfalls even experienced programmers may encounter when working with the stack.

Since stack memory is automatically managed, and Swift mostly uses heap allocated objects, most programmers don't require a deep knowledge of stack memory, despite using sites like "Stack Overflow" every day.

Being oblivious to stack memory is usually not a problem, however it is worth learning about, especially if interfacing with C code.

In my talk I will cover the following:

• What is the stack?
• Simple example of stack usage in C, with equivalents in Swift
• Why do we care about the stack in Swift?
• Examples of bad stack usage in Swift
• How to debug and avoid stack issues

巷ではApple Carが自動車業界の大変革を起こすのではと噂されていますが、そんな未来をちょっとだけ先取りして体験できるのが「テスラ」です。私はiPhoneが登場した時のような衝撃を受け、気づいた時にはテスラモデル3の購入ボタンを押していました。テスラ車にはテクノロジーに興味のある方なら誰もが興味を持つであろう機能が盛り沢山です。また、非公式ながら車体の情報を取得・操作するためのAPIや、ハードウェアの情報にアクセスするためのインターフェースが備わっていたりと、ソフトウェア開発者がテスラ車自体を拡張する余地がいくつかあります。「このAPIを使えば楽しそうなことができそうだな」とワクワクしながら考えることは、我々モバイルアプリエンジニアの最も得意とするところかと思います。このトークでは、実際にテスラを購入していじくり倒して得た知見をご紹介します。このトークを通じてテスラの面白さを知ってもらいつつ、まだ見ぬApple Car OS(?)アプリ開発の世界について色々と想像してみましょう。

アウトライン（検討中）

• テスラモデル3自体とその先進的な機能群についての紹介
• 非公式のTesla APIを使ったiOS/Apple Watchを開発し実際にリリースした話
• Tesla API の詳細
• 全ての走行データが蓄積されるのでログ好きにはたまらない話
• Webブラウザも備えているのでなんでもありな話
• 車載カメラに記録された動画でいろいろ遊べる話
• Apple Carを想像する

PickGo for Partnerは配送ドライバーのためのアプリとして2015年からiOS/Androidアプリを提供しています
そして2021年5月にFlutter化とFlutter版への完全移行を実施しました。
WebViewを利用しており、計画的には問題なく移行できる想定ではあったものの、既存で今もなおユーザーが利用しているアプリを移行するということはとても大変なもので技術力と精神力を大きく使ったと振り返ると思います。今回この移行で培った知見をまとめて皆様に共有することで、同じようなことをする方がより省力で移行が実現できるようにまとめたものです。

• 既存のネイティブアプリをなぜFlutterにフルリプレイスしたのか？
• 移行計画の策定と進め方
• 移行前に立ちはだかった問題
• 移行後の積み残しと今後の展望
• まとめ
  アプリ - https://apps.apple.com/jp/app/%E8%BB%BDtown-%E8%BB%BD%E3%82%BF%E3%82%A6%E3%83%B3-%E8%BB%BD%E8%B2%A8%E7%89%A9%E3%83%89%E3%83%A9%E3%82%A4%E3%83%90%E3%83%BC%E9%85%8D%E8%BB%8A%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9/id1053791248

寄付体験を身近にすることを目指して開発されたアプリ「dim.」

・SwiftUI 95%以上
・エンジニア1人
・開発期間2ヶ月
・リリース前に大きな仕様変更を2回行う
実はこんな条件下で生まれたアプリです。

皆さんご存知の通り、SwiftUI はまだ実用レベルに達していないと言っても過言ではありません。が、実体験を元に「実用レベルに達していない」と口にしているエンジニアはどれほどいるでしょうか。
SwiftUI が未熟だという周りの声を鵜呑みにして逃げているだけではないですか？ SwiftUI を採用しない理由を明確に説明できることは非常に重要です。なぜなら、 SwiftUI が適している要件にも敏感に反応できるようになるからです。
このトークでは主に以下に関して実例と共に SwiftUI の現状をご紹介いたします。

・SwiftUI 採用の理由
→キーワード：チーム開発, デザイナー
・2回もの大型仕様変更への高速対応を可能にした SwiftUI レイアウトテクニック
→キーワード：Modifier, XcodePreviews
・粘ったけど、UIKit に浮気せざるを得なかった TextField
→キーワード：最小限に抑えた UIKit 利用術
・油断禁物！ SwiftUI 未対応ライブラリ達
→キーワード：Firebase, 計測ツール

このトークにより、SwiftUI をチームで採用するための説得材料を手にすることができます。また、 SwiftUI による開発方針を「チーム」という広い視野で考える“きっかけ”になるでしょう。

ある日フロントエンドエンジニアが、Unityを組み込んだiOSアプリの開発を行う業務が決まりました。そこからSwiftなどを習得し、先輩エンジニアの経験も伺いながら、Unity as a Libary (UaaL)を採用しました。

Unity as a Libraryは、フレームワークとしてUnityをネイティブアプリに組み込むことができる仕組みです。多彩な3D表現を得意とするUnityと、ユーザーフレンドリーで洗練されたUIを実現できるネイティブ実装のいいとこどりができます。

プロダクトとして、デザイン性と実用性が必要とされる中で開発した経験や、iOSアプリ初心者の視点からつまずいたポイントなどを意識して、以下のテーマをお届けします。

• Unity as a Libraryを採用するべき条件
• 巷にある先人方のUnity as a Libraryの実装方法を比較検討した結果
• 実用面とUXを考えて採用した、Unityの組み込み方法
• Unityとネイティブ(Swift)の間のやり取りについての検討と実装
• UnityのBuildで必要な操作を自動化したTip

このトークでは、モバイルアプリにデザインシステムを導入した話をします。

デザインシステムとは、デザインに関する原則やコンポーネントの実装をまとめたもので、有名なものではGoogleのMaterial Designなどがあります。デザインシステムは以下のような目的で作られています。

• ボタンの見た目など画面・サービスごとに違ってユーザーを混乱させない
• 同じような実装をまとめることで、コード量・メンテナンスコストを減らし、生産性を上げる
• 誰が実装しても同じものを作れる
• 統一したUIを提供することで、ブランディングを向上させる

弊社では、4つ以上のアプリを同時に開発しており、iOS・Android・Webのそれぞれのプラットフォームでサービスを展開しています。これまでは、各アプリでそれぞれUIの実装を進めていましたが、共通化できる部分も多くあります。すでにWeb版ではデザインシステムが開発・運用されていますが、どのようにしてアプリでも使えるように整備していったかをお話しします。

内容

• Figmaからのリソース自動書き出し
• Kotlin Multiplatform Mobileを使った共通実装の作成
• SwiftUI / UIKitでの実装
• (Jetpack Composeでの実装)

動画や音声については私自身これまではほとんど触れたことはありませんでしたが、これらを取り扱うサービス開発の中に身を置いた経験を通じて、アプリならでは機能ロジックとUI体験との調和を生み出すための奥深さや工夫の深淵を垣間見ることができた様にも感じました。その一方で、普段私達はiOSアプリを通じて多くの動画や音声に触れていてとても身近な存在ではあるのに、いざ実装しようとすると「あの機能と似たイメージのものを作りたいんだけど、どうすればいいんだろう...?」とその当時に知らなかった故にやきもきしていた経験もしました。

本発表では、

• Apple公式ドキュメントや掲載サンプルから紐解く押さえておきたい基本部分のご紹介
• 動画の再生や停止といった基本的なプレイヤーとしての操作実装や画面レイアウトに関する解説
• アプリがバックグラウンドに移行した際にも連続して音のみの再生へ移行する機能
• 他のアプリを利用しながら動画再生をするPicture in Pictureの機能と実装に関する部分
• 普段使い慣れている動画再生アプリ等でよくお目にかかる機能や振る舞いを実現する際のヒント
• 動画再生プレイヤーアプリに付随するUI実装や表現に関する説明

について、簡単ではありますがご紹介と解説ができればと考えております。

本発表につきましては「機能を実現するための実装に関するはじめの一歩を踏み出す」ための難易度を想定しておりますが、実際に動作するサンプルコードを用いた検証や試行錯誤を通して感じた実装で押さえておくと役に立った部分や、実務を通して実装した知見等が少しでもお役に立つことができればとても嬉しく思います。

iOSアプリの開発している私たちは日頃CocoaPods, Carthage, SwiftPMなどのいわゆる「Package Manager」にお世話になっています。

Package Managerはソフトウェア開発をする上で欠かせない重要なものです。
しかし、「使い方は知っているが仕組みがどうなっているかはよくわからない・・・」という方も多いのではないでしょうか？

ここでは

• Package Managerとは何か？
• なぜPackage Managerを使うのか？
• iOSにおいてPackage Managerはどう進化してきたのか？
• CocoaPods, Carthage, SwiftPMはそれぞれどのような特徴があるのか？

といった点を整理し、基本的な概念や仕組みを理解していきたいと思います。

一緒にPackage Managerについて学び、より適切に選択・利用できるようになりましょう。

アプリの立ち上げの話はよくあると思いますが、クロージングの話を聞く機会はあまりないかと思います。

昨今サブスクリプション型のアプリも増えてきているなかで、実体験から語られるサービス終了の側面をともに見てみませんか？
実際にアプリのクローズに立ち会い、そこで考慮したこと、終了のフロー、App Store Connect上での操作したこと、その時の思いをまとめていきます。
自分が開発に携わったアプリが終わっていく姿を見たいエンジニアなどいないとは思いますが、いざその時が来たとき、正しい方法でスムーズに対応できるよう、知見を共有したいと思います。

従来、金融や通信サービスの契約における本人確認では、実店舗に行ったり、身分証の写しを送付するなどの煩雑な手続きが必要でした。それらの対面や郵送での本人確認に代わり、オンラインで完結する本人確認が身近な存在になってきています。すでに何らかのサービスで実際に体験された方も多いのではないでしょうか。

「eKYC」と呼ばれるオンライン形式での本人確認では、複数のベンダーさんが高い品質のSDKを提供しています。しかし、僕らはアプリ内でのより統一されたユーザー体験を実現するために自前での構築を選びました。

このセッションではiOSアプリでのeKYCの実装において得られた知見をお話しします。身分証や顔写真の撮影におけるVision.framework / ML Kitの活用など、体験を向上させるための技術面での工夫やTipsも紹介していく予定です。

【内容（予定）】

・eKYCの簡単な概要（社会的背景や従来の本人確認の課題）
・B/43での本人確認フローについての前提
・シームレスなユーザー体験を実現するためのプロダクト設計
・iOSアプリでのeKYCの実装における技術面での工夫
・自前で構築したeKYCを運用して得られた効果と今後の課題

Swiftではコードの自動生成ツールでボイラープレートを避けるということがよく行われます。
そして方法には様々ありますがXcode上で実行する場合は多くがファイル作成もしくはビルド時にコード生成をします。

しかし、ユースケースによっては実装中のコードからそれに対応するコード生成を行いたいこともあるでしょう。
例えばリファクタリングのためにProtocolで依存を切り出したり、Mockクラスを作る場合などがそれにあたります。

ここではSource Editor ExtensionとSwiftSyntaxを組み合わせたコード生成ツールの開発方法について解説します。
それらを組み合わせると、実装しながら同時にXcode上でコード生成を行うツールが比較的リーズナブルに開発可能です。

また、その方法によって実際に開発したリファクタリングツールを例として紹介します。
皆さんが開発環境改善をしたいと思ったときに検討する手法の一つになるよう話ができればと思います。

私たちのチームは今年の6月に新規レジアプリ「STORES レジ」をリリースしました。
世の中でお会計の際に使われているレジですが、レジの機能をアプリで置き換えるためには様々な周辺機器との連携が必要でした。

例えばSTORES レジではこんなハードウェアに対応しました。

• レシートプリンター
• バーコードリーダー
• キャッシュドロアー
• クレジットカード / 電子マネー決済端末

このトークでは具体的な対応内容や苦労した点、ハードウェア対応の全体像などをご紹介させていただきます。

コンテンツ

• ハードウェア対応の概要
• CoreBluetooth Framework の使い方と具体的な実装例、ハマったところ
• External Accessory Framework の使い方と具体的な実装例、ハマったところ
• MFi登録申請の概要と流れ、弊社での具体的な対応例
• ハードウェア対応で苦労したこと

ハードウェア対応？そんな仕事しないし...と思っているそこのあなた！
いつかあなたのプロジェクトにもハードウェア対応が必要になるかもしれません！
そんな時に役に立つTipsをお話しします！

iOS で使えるライブラリを作ったからみんなに使って欲しい、仕事の成果をオープンソースで公開したいということはよくあると思います。
Swift Package Manager の登場や Xcode への GitHub の統合などでオープンソースのライブラリの利用はとても簡単になりました。
しかし、そういったオープンソースのライブラリを提供するのはまだ簡単ではありません。

実際に使いやすいライブラリを提供するには、ライブラリそのものの API のデザインだけでなく、
ライブラリを運用するためのバージョンの管理、CI の設定、ドキュメントの作成や、内部のレポジトリと外部のオープンソースのレポジトリの差異、
Issue の管理のなど多岐にわたる問題への対応が必要になります。

このセッションでは、実際に業務の成果をオープンソースとして公開した「Twitter Text Editor」の経験を踏まえて、API のデザインから運用のためのツールの作成などをまとめていきたいと思います。

対象とする方:

• オープンソースのライブラリを使った iOS アプリの開発の経験がある方
• ライブラリの開発に興味がある方

前提とする知識:

• Git
• GitHub
• Swift Package Manager
• Xcode

At Apple, we believe that privacy is a fundamental human right.
（WWDC 2021 Apple’s privacy pillars in focus より）

プライバシーは基本的人権であると、Appleは明言します。

WWDC 2021の中でもプライバシーに関わるアップデートやセッションがありました。
昨年は App Storeにおける「プライバシー表示」が開始され、iOS14.5から開始されたATT（App Tracking Transparency）は、現在進行形で巷を騒がせています。

このように年々重要性が高まっているプライバシー保護ですが、私たちアプリ開発者は一体何を行えばよいのでしょうか。
また、数ある制約の中でどのようなユーザー情報を活用していけるのでしょうか。

幸いにも、私たちはAppleというプラットフォーム上で生きています。
そこには多くの制約がありますが、裏を返せば、私たちはその制約によってユーザーのプライバシーを侵害してしまうリスクから守られています。

ユーザーの利益を損なわないために、また、私たち自身を守るためにも、まずはAppleが示すプライバシー保護について学びましょう。

本トークでは、アプリ開発に関わるプライバシー保護についてお話します。
WWDC 2021 にて発表された最新情報に触れつつ、Appleが重要視するプライバシー保護の4本柱について説明します。
そして、私たちアプリ開発者が対応しておくべき事項を紹介した上で、変化していく環境にどのように適応していくか、について考えます。

iOSDC Japan 2020で発表した『iOSではじめるWebAR』のアップデート版です！
ChromeもMicrosoft EdgeもFirefoxも“標準”でWebXR Device APIに対応する中、長らく未対応の続く我らがWebkit、そんなWebXR領域では何かと足が遅く見えるWebKitでも 1 年も経てばいくつか変更が入っています。

まずはWebKit Feature Statusで“WebXR Device API”がIn Developmentステータスになっていること！いつSupportedステータスに変わるかわかりませんが、少なくともSafariでWebXR Device APIが使える未来が予定されていることだけはわかります！

そしてiOS 14.5で突然SafariのExperimental Featuresに追加されたWebARのためのものと信じているmodel要素！これはiOS 14.5時点では要素そのものは認識されるものの肝心の3Dモデルは表示されませんが、今後デファクトスタンダードになるかもしれない要素が登場したと言えます。

そうした事例を挙げながら、多くの人が毎日触るであろうSafariにおけるWebARが今どのような状況にあり、何ができるようになっているのか、次のようなトピックスを解説します。

• iOSとWebARのこれまでとこれから
• WebXR Device APIの概要とその動向
• WebXR Device APIに頼らないWebAR
• iOSでも動くWebARを用いた最新事例10選
• WebARコンテンツの開発手法

SwiftのCodableはすごく便利な機能です。しかしながら時にCodableが得意ではないフォーマットを扱うことはみなさんもあるはずです。もしAPIのJSONならCodable向きにスキーマを調整できるケースも多いはずなのですが、このトークではそのような調整がそもそも不可能な例として、Appleの独自ファイルフォーマット (Apple Watchの文字盤ファイル) を見ていきます。どのようにSwiftコード側でCodableを整えていくかのテクニックをお伝えします。

Apple Watchの文字盤ファイルでなにをするの？

文字盤ファイルを取り出して解析した人はおそらく世界に1人しかいないので簡単に説明します。アレには、文字盤の種類(写真とかSiriとか)や、左上には天気があり下にはカレンダーがある、といったデータが詰め込まれています。

そして、文字盤ファイルは取り出してシェアできます。それを解析して再合成してみました。1個の文字盤を1個のCodableなstructで表現し、Swiftらしさのある整った読み書きしやすいコードにします。そこで出てくるテクニックは他のファイルをCodableで定義するのにも役立つでしょう。

文字盤ファイルのここが難しい！

文字盤ファイルにはJSONの部分もありますが、その全体は複数のJSONやplistが画像リソースとともに詰まったフォルダ構造をしています。個別のJSONやplistには、変数名として使えないキー名が出てくるだけではなく、Unix Epochの日付とCore Data由来の2001年でオフセットされた日付の混在や、Objective-C時代のシリアライズなど、普段のCodableだったら扱いたくないような要素が次々に出てきます。これらをスマートに乗り越えていきましょう。

StoreKit はアプリ内課金を実現するためのフレームワークです。StoreKit の API は取り扱いが難しく、難しいが故に 3rd party のライブラリを介して利用したり、いざアプリに組み込んだ際には考慮漏れや原因の特定が困難な不具合に苛まれる事があったかと思います。

そんな中、 WWDC21 にて Apple より StoreKit 2 の発表がありました。 API は刷新され、非常に取り扱いやすくなりました。本セッションでは、これまでの StoreKit の API の取り扱いの難しさを振り返りながら、 StoreKit 2 でどのように変わるのかを解説します。

noteのiOSアプリはここ1年間で大きな変化を遂げました。
元々30%程度だったSwift率が90%を超え、デバイスもiPhoneの縦画面のみの対応でしたがiPadの複数ウィンドウにも対応しました。
このように目に見えるカイゼンを進めてきた私たちですが、あるきっかけで目に見えない課題があることを知りました。
アクセシビリティ機能を駆使して私たちのアプリを利用してくれている方からお問い合わせをいただいたのです。
この方の日頃の利用方法についてインタビューさせていただくことになり、今まで見えていなかった課題に気づくことができました。
そこでアクセシビリティの有識者に力を借りながら、Voice OverやDynamic Typeといったアクセシビリティの助けとなる機能にも対応をはじめました。
・Voice Overを利用するとさわれると思っているUI要素にさわれない
・わかりやすいと思っていたボタンなのにVoice Overを通すと何のボタンなのか理解ができない
このトークではこういった課題を認知して、実際に対応したことをまとめてお話します。

iOS端末の業務利用現場では、MDMを使ってアプリ配布やOSレベルの設定を遠隔で行います。しかし実際にはそれだけは不十分で、配布したアプリの設定がそれぞれ必要になります。例えば、接続先サーバなど各アプリ固有情報の入力です。大量のiOS端末を配布する場合、その設定作業だけで途方も無い労力を要します。

これらを自動化する方法はないのでしょうか。

その期待に応えてくれるのが「Managed App Configuraiton」です。Managed App Configuration を使えば、MDM上で登録する key-value を Dictionary としてアプリと一緒に配布できます。その情報を使ってアプリは起動直後の初期設定を自動で行えるというわけです。

Managed App Configuration は少しのコードを追加するだけでどんなアプリでも使えます。ADEPによるInHouseアプリはもちろん、AppStore申請する公開アプリやカスタムAppでも利用可能です。

現在、多くのMDMが Managed App Configuration に対応していますが、残念ながら業務用アプリの多くは対応していません。本トークでは業務用アプリで Managed App Configuration をどのように使えるのか、具体的な実装や設定の仕方、活用方法をご紹介します。