トーク

Apple pencil、活用できてますか？

Apple pencilは、2015年末にiPad Proとともに発売され、2018年末には第二世代が発売されました。長らくApple純正アプリ以外は対応に苦慮してきたと思われますが、WWDC2019でPencilKitが発表されたことにより、簡単にApple pencil対応が可能になりました。

ライブラリ自体は使いやすいものですが、具体的なノウハウについては情報が少なくて、実際につくってみると試行錯誤することになりました。そこで本トークで、開発ノウハウを共有したいと思います。

このトークでは、PencilKitを利用したノートアプリ（「Like a Paper」）を個人開発した経験から、Apple pencil対応の勘所を話します。具体的には、PencilKitでできること/できないこと、 PKDrawing から UIImage への変換、ダークモード対応の罠、 PKToolPicker のカスタマイズなどを扱います。

これまではmacOSのアプリケーションを開発しようと思うとAppKitというUIKitとは異なるframeworkを利用する必要がありiOSアプリの開発とは勝手が異なりました。​
そんな中WWDC 2018でmacOS Mojaveの一部のアプリケーションにUIKitをmacOSに対応したアプリケーションが搭載されることが発表されました。
さらに、翌年のWWDC 2019にてその機能が開発者向けに「Project Catalyst」として公開されました。
Catalyst対応はXcodeでチェックを一つ入れるだけで簡単にビルドをすることが可能です。
しかし、macOSらしいアプリケーションを作ろうと思うとすべきことが色々とあります。
WWDCでもサイドバーのUIをmacOSらしくする方法などが紹介されていましたが、WWDCで紹介されなかった機能がいくつもあります。
CatalystにおいてiOSには無い機能として「メニュー」、「Touch Bar」、「Toolbar」があげられます。
本トークではCatalystに対応した2つのアプリのリリース経験とCatalystに関する本を執筆した内容を基に、
対応方法の基礎から、先述したメニューやTouch Bar、Toolbarへの対応方法をご紹介します。

4月から5月にかけて、リバーシ（オセロ）のiOSアプリを題材に、みんなでリファクタリングに取り組んで知見を共有するオンラインイベント「Swift Zoomin' 」チャレンジを行いました。100人以上の方に参加していただき、その中から9名の方に成果を発表していただきました。

問題への取り組み方は人それぞれでしたが、それらを俯瞰して眺めるとアプリの設計に求められることが浮かび上がります。それは、

• 型を利用してエラーフローを減らす
• 依存性反転の原則を適用して
  • UIやファイルI/Oに依存しないテスタブルなコードを実現
  • ドメインロジックをアプリ固有のロジックから分離
• 状態遷移を書き出して整理
• データフローを制御してシンプルに

などです。これらは当たり前に言われていることですが、リバーシアプリという具体的な題材について考えることで、より現実感を伴って理解することができます。本トークでは、個々が行ったリファクタリングの結果を横断的に分析し、具体例に基づいてその効果を説明します。

【どうしてリバーシなの？】

何かを説明するときに、具体例を交えて説明することは重要です。しかし、設計というのは、アプリの持つ複雑さをどう扱うかという話なので、短時間で説明しようとすると次のような矛盾を抱えてしまいます。

• 実際のプロダクトのような巨大かつ複雑なコードベースは短時間で理解できない
• 例示のための単純すぎるコードは理解しやすいが、業務で直面するような複雑さを扱うことが難しい

リバーシなら、誰でもルールを知っているのですぐに仕様が理解でき、それでいて相応の複雑さを持っています。リバーシを題材にすることで、「業務で直面するような複雑さ」を扱いながら、「短時間で理解」できるように説明することを試みます。

株式会社ヤプリではプログラミング不要で高品質なネイティブアプリケーションを作成・配信できるサービスを提供しています。

CMSの設定にしたがってそれぞれ異なるプロジェクトを生成し、アプリケーションをビルド、コード署名をして、連携されているアカウントからAppStore（またはGoogle Play ストア）にアップロードします。

この一連の工程は今でこそ高度に自動化されていますが、最初からそうだったわけではありません。

アプリケーションの内容によっては、最初に手作業でプロジェクト構成やソースコードを編集する必要があったり、バンドルIDやバージョンを事前に適切に設定しておかなければならなかったり、コード署名やPush通知の署名に必要なリソースをあらかじめ決まった位置に配置しなければならかったりする時代がありました。

アプリケーションは一つ一つすべて内容も提供元の会社も異なるので、工程の途中でさまざまな問題が発生します。
バンドルIDを間違えて設定してしまうと、別の会社のアプリを更新してしまうかもしれません。
そのため、最近まではこの作業はデベロッパーが担当する必要がありました。

サービスを発展させていくには自動化が不可欠です。
今でこそ、ほとんどのケースで誰でも簡単にアプリケーションをビルドして申請できるようになりましたが、その道のりは簡単ではありませんでした。

この講演では、ヤプリのサービスを支える自動化の仕組みと克服してきた問題、現在も取り組んでいる技術的な課題についてお話しします。
同様の問題を抱えている人はほとんどいないと思いますが、ビルドから申請までの一連の作業を自動化するにあたって、技術選択や問題解決の一助になれば幸いです。

iPadやiPhone、iPod touch が業務用端末として企業内や公的機関で活用されることは珍しくなくなりました。営業端末として、サイネージ端末として、顧客接客端末として、リモコン端末として...iOS端末の活躍シーンは業務の世界でも様々です。iOSが人々のライフスタイルを変えたように、iOSは企業のワークスタイルにも変革をもたらしています。

多くの組織でiOSが受け入れられているのは、Appleが業務活用を見越して様々な仕組みやサービスを提供してきたからに他なりません。ADEPやMDMはよく目にするキーワードですが、他にもABM・DEP・Single App Mod(SAM)・Managed App Configuration(MAC)・CustomAppといったものもあります。興味深いのは、アプリ開発者がこれらを理解していると、業務用アプリの開発・導入・保守・運用がとても楽になる(自分もお客様も)ということです。

iOSと共にこれらの仕組みやサービスも進化してきました。2020年は特にサービスの統廃合やAppleの方針転換など大きな変化の年となっています。例えば「法人向けアプリ＝ADEP(iDEP)」という理解ももはや過去のものとなってしまいました。

本トークでは、そんなエンタープライズiOSの最新事情と、各用語の詳細や関連性についてお話します。

2019年のWWDCで彗星のごとく現れたCombineフレームワーク。

RxSwiftやReactiveSwiftなどのサードパーティーライブラリが
これまで広く使われていましたが
Apple製の公式のリアクティブなフレームワークとして注目が集まりました。

私自身も注目をしており
「Combineフレームワークまとめ」というブログを書くなど
最新の動向を追ってきました。

そんなCombineも登場から1年が経過。

このタイミングで
Combineについて学び始める
あるいはもう一度学び直すのはいかがでしょうか？

このトークでは
2020年版Combineフレームワークまとめとして
Combineの基本的な使い方から
実施にどうコードを書いていくのかを中心として
皆様と一緒にCombineの使い方について一歩一歩見ていきたいと思います。

また、これで終わりにするのではなく
ここからさらに学習を進めるための有用なサイトやツールなども紹介もします。

• Combineは気になっていたけどまだ手がつけられていない方
• 去年試してみたけどもう忘れてしまったなぁと感じている方
• ある程度は知っているけど改めて基礎を復習したい方

そんな方々にご参加いただけましたら嬉しいです。

• お茶を飲みながらのんびり見る
• 家事をしながら聞き流す
• 一緒にコードを書いてみる

といった色々な方法でお気軽にご参加できる内容にしたいと思います。

そろそろCombine

ご一緒にいかがでしょうか？

近年のモバイルデバイスのプロセッサはマルチコア化が進んでおり、iOSデバイスも例外ではありません。たとえば、最新のiPhoneには6つのコアが搭載されています。

今後もコアが増えていくことは確実で、iOSエンジニアである私たちにとって多くのコアを活かすための知見はますます重要になっています。

そこで、このトークではGrand Central DispatchとSwiftを使ってソートや探索といった基本的なアルゴリズムを並行化する手法を学び、コアをもっと有効に使うための考え方を説明します。

このトークを観て、Grand Central Dispatchを使ったマルチスレッドプログラミングの新たな可能性に触れてみましょう。

Sansanでは大きく分けると法人向け名刺管理アプリケーションSansanと個人向けEightの2種類のプロダクトがあります。

今回はその2プロダクトのiOS開発体制やプロセスなどをまとめてご紹介したいと思います。

また直近リリースしたオンライン名刺機能は、約30日間で非常に多くの画面とロジックを実装しました。

どのような手法を取り入れながら、短期間での開発を行っていったかをご紹介したいと思います。

【話すこと】

• Sansanの開発体制・プロセスについて
• Eightの開発体制・プロセスについて
• オンライン名刺機能の開発について

ZOZOグループは日本最大級のファッション通販サイト「ZOZOTOWN」やファッションコーディネートアプリ「WEAR」の運営をしています。
それらの1000万人以上が利用するような巨大なサービスの改善を重ねながらも、ファッション業界に革命を起こすような「ZOZOSUIT」や「ZOZOMAT」などの全く新しいサービスのリリースも並行して行っています。
本トークでは、そのようなサービスを次々に出していくために、ZOZOのエンジニアリング組織として大事にしている考えや実際のiOSチームの取り組みについて、CTOの観点から紹介させていただきたいと思います。

じゃらんアプリはiOS/Androidともに2020年でリリースから10年を迎えました。
現在、このじゃらんアプリにおいて更なる開発効率と品質の向上を目指し、Flutterへの順次移行を進めています。

Flutterは、Googleが開発しているクロスプラットフォームのSDKで、2018年末にver1.0がリリースされました。
まだまだ新しい技術ではあるものの、日に日にFlutter開発の話題を耳にする機会が増え、盛り上がりを感じています。
しかし、国内でFlutterをプロダクションに採用している例はそれほど多くなく、実際採用してみてどうだったのかという情報を得にくいのではないでしょうか。

そこで本セッションでは、じゃらんでFlutterをプロダクションに採用して得られた知見についてお話したいと思います。
具体的には、以下の内容についてお話し致します。

1. Flutterを採用したことで、どの様な課題に直面しどう回避したのか。
2. Flutterを採用したことで、期待していたメリットを得られたのか。また、開発過程で特に実感したメリットは何か。

20xx年。

アプリ戦乱の時代。
各地では多くの戦い(申請)が行われていた。

戦果を上げる(申請が通る)ものもいれば、
負けて帰ってくる(リジェクトされる)ものもいた。

特にサブスクリプション地域(課金実装)では、
相手(Apple)との戦闘(やり取り)が激化しており、
兵士(エンジニア)はみな疲弊していたのだった。。。

これはそんな戦いを描いた１つの物語(アプリ審査過程の話)である。

課金ページの実装を専属で担当し、課金ページのレイアウト改変やA/Bテストを頻繁に行った結果、毎月のようにAppleからのリジェクトを経験しました。
メッセージで多くのやりとりを行ない、一般的には公開されていないような課金ページの細かなアンチパターンが蓄積してきたので、紹介していきたいと思います。

みなさんデバッグメニュー作っていますか？接続先のサーバーを切り替えられるようにしたり、特別な処理や表示をするための仕組みをアプリ内に実装したことがあると思います。こういった仕組みやデバッグメニューは開発中の動作検証にとても便利ですが、アプリごとに独自実装されることが多いため、使い方も実装方法もすべて異なってしまいます。これでは新しいメンバーが参加した際やQA時に毎回使い方を説明する必要があって大変ですし、各アプリでのメンテナンスコストもかさんでしまいます。

また、ユーザーが利用しない機能なので開発や改善の優先度も低くなり、気づいたら大きな負債になってしまうこともあります。負債が大きくなった結果、うっかりユーザーにもデバッグメニューが見える状態でリリースする事故がおきてしまうかもしれません。

これらの問題を解決するために、デバッグメニューを専用アプリとして切り出して管理する方法を実現しました。このトークでは、

• デバッグメニュー専用アプリを作り、対象アプリの状態を再ビルドなしで切り替える方法
• AdHoc, InHouse, SimulatorだけでなくApp Store版でも対象アプリの状態を切り替える方法
• デバッグメニュー専用アプリを作ることによるメリットとデメリット

についてお話します。

最近のモバイルアプリは、1つのアプリ内で多彩な機能を持つものが一般的となってきています。
機能が増えることによってコードベースは肥大化し、ビルド時間の増加や設計の複雑化へと繋がります。

そこでマルチモジュールを採用することで、差分ビルドによるビルド時間の短縮や、モジュール間が疎結合となることでより堅牢な設計への期待が高まります。

しかしながら、長年運用しているサービスにマルチモジュールを導入しようとしても、
どこからモジュールを切り出して良いのか分からない、
既存コードの結合度が高くモジュールへの分割が難しいなど、
導入への障壁が様々考えられます。

また、サービス運営をしていく上で新規機能の開発を止めることも許されず、リファクタだけに工数を割くことも容易ではありません。

そこで我々は、新規開発する機能をモジュールとして切り出すことでマルチモジュール化への第一歩を踏み出すということを実践しました。
このトークでは、7年以上続くアプリの新規機能開発からマルチモジュール化を実践していく中で感じたメリット、デメリットや今後の展望についてお話します。

iPadOS 13.4でついにマウスやトラックパッドを接続可能になったことでキーボードとマウスが揃い、iPadは以前よりもさらに作業・創作用マシンとしての真価を発揮できるようになりました。
このトークではマウス・キーボード対応アプリで抑えるべきポイントについてまとめます。

多くのアプリはマウスやキーボード対応をしていなくても大きな問題になることはありませんが、ドキュメント編集アプリなど、閲覧にとどまらない機能を提供するアプリではマウスへの対応を行うことがその使い勝手に大きく影響します。
また実際にテキストエディタでマウス対応を行った経験を踏まえて、マウス対応そのもの以外にもマウスやキーボードをフル活用するアプリで対応しておくと良いAPIについても合わせてお話しいたします。

• iPadOSにおけるマウス・キーボード
• マウス対応のための準備
• まず抑えるべき簡単な変更
• マウスカーソルの変更について
• マウス操作とタッチ操作を振り分ける
• あると嬉しいコンテキストメニュー
• iOS/iPadOSとキーボード
• シフトキーを使った範囲選択
• ショートカットコマンドなど

今や技術面で何か画期的なことが達成される場合、十中八九、機械学習／ディープラーニングが利用されています。大学で専門的に機械学習を学ぶ人も多く、技術書でもオンライン講座でも機械学習系は非常に人気です。今や猫も杓子も機械学習を学び一見レッドオーシャンとなっている機械学習分野ですが、我々iOSエンジニアには実は「機械学習のブルーオーシャン」が残されています。それがCore MLです。

『Core ML？触ってみたことあるけど、簡単だし、今更トークで聞くことなくない？』

と思われた方もいるかもしれません。しかし、多くの人が触ったことがあるのは、CoreML.framework止まりです。

CoreML.frameworkは既存のモデルをiOSで扱う際に利用するフレームワークに過ぎず、実はそれはCore MLのポテンシャル全体からみれば氷山の一角にすぎません。たとえば近年のWWDCでは毎年多くのML関連の新機能が発表されますが、CoreML.frameworkのレイヤーだけ知っていてもその機能の多くは活かせず、そもそも具体的に何がどこまでできるということすら理解は難しいと思われます。

Core MLはCore MLのモデルフォーマットと、そのモデル作成を担うCore ML Tools（coremltools）を理解してこそその真価を発揮できます。そして、iOSで最先端の機械学習モデルを効率的に動作させるには、このCore MLの全体を理解しつつ、iOSアプリ開発についても熟知し、その上で機械学習にも理解がある必要があるので、機械学習の専門家でも簡単には参入できないブルーオーシャンとなるわけです。

本トークではiOS×ML分野で仕事をするために必要な技術領域全体について解説します。

AVAudioEngineが登場してから長らく、C言語のAudioUnitのAPIのように入出力のそのままのデータをダイレクトに扱うことができませんでした。それゆえにいまだにC言語のAPIを使っているままの方も多いと思います。

しかし、iOS13ではAVAudioEngineにAVAudioSinkNodeとAVAudioSourceNodeというNodeが追加されました。これらはダイレクトにオーディオデータを扱うことのできるものです。もうレガシーなC言語のAPIを使い続ける理由は無くなりました。

そしてC言語のAPIはDeprecatedになっています。AVAudioEngineに乗り換えなくてはいけないのは時間の問題です。

このトークではこれらの新しく追加された機能の使い方を解説します。後々慌てることのないよう早めに対応していく手助けとなれば幸いです。

ベジェ曲線は、シトロエン社のド・カステリョとルノー社のピエール・ベジェにより考案されました。
ベジェ曲線はアプリのアイコンやアニメーション、ポスターなど様々な箇所で用いられ、私たちの身の回りは実はベジェ曲線で溢れています。

本トークではベジェ曲線を定義から追いかけ、iOS でベジェ曲線を扱うための API である UIBezierPath や Path に絡めながらその魅力をお伝えできたらと思います。

ARKitによりiOSにおけるWebAR表現が豊かなものになりました。

ネイティブアプリに比べると制限のあるWebARですが、iOSのバージョンアップに伴いできることも少しずつ増えています。

iOS 12.2でモーションセンサーまわりに大きな制限が入り、もはやiOSにおけるWebARは終わったのか…と悲しみに明け暮れた日もありましたが、iOS 13ではあるべき姿として帰ってきました。しかし、その結果としてiOSのバージョンごとの差異を吸収する対応が必要になっています。

本セッションでは、そんなiOSにおけるWebARの変遷を振り返りながら、時にAndroidにおけるWebARと比較しつつ、具体例を交えてiOSのWebARを紹介します。

みなさんは「エラー」の取り扱いをどうされていますか？

APIからのエラーレスポンス、予期せぬ操作によるエラー、JSONパースエラー、などなど、色んなところで発生するエラーを適切にハンドリングするのは難しいと感じています。

例えば、クリーンアーキテクチャなどのレイヤーが複数存在しているような場合、レイヤーをまたいだときのエラー変換がボイラープレート化し、ユースケース個別のエラー処理に悩むことが多いです。

トークでは、弊社のアプリ (iOS, Android) を事例として、実際に試行錯誤した経験談、また、その過程で得られたエラーアーキテクチャの設計への知見ついて、お話しします。

皆さんはカンファレンスで、スピーカーになりたいとは思いませんか？

カンファレンスにスピーカーとして参加することは楽しいです！好きなことについて、国内外の多くのエンジニアの前で話すことはとても興奮します。それだけではなく、他のすごいスピーカーとディナーを食べながら仲良くなり、議論したり‥。普通のカンファレンスの参加だけでは体験できないことが多く、一度登壇したら二度とプロポーザルを出さずに参加できなくなります。私はtry! Swift Tokyo、NYCでの登壇を通じ、それらの楽しさに目覚めました。

しかし、CfP (Call for Porposal) への応募は難しく感じてしまいます。興味や憧れがあっても「応募できるほどのiOS/Swiftの知識やバックグラウンド、技術力がない」と思い、やめてしまうかもしれません。自分の伝えたいことをうまく表現できないような、もったいないプロポーザルの書き方をしてしまうかもしれません。色々な面でCfPへの挑戦って心配ですよね？

このトークでは、それらの心配を払拭することを通じて、採択される可能性が十分にあるプロポーザルを作る方法の考察について話します。具体的には、

• あなたの今持っているiOS/Swiftの知識・技術をプロポーザルに落とし込むには？
• 「聞き手の体験」によりそうプロポーザル/ トーク内容を作るには？
• あなたが伝えたいことを「聞き手が興味を持つ内容」に昇華させるには？
• 僕が採択されたプロポーザルを書くときに「気をつけた/ 考えた/ 気づいたこと」

これらのポイントを深堀りしていき、採択されるプロポーザルに必要なことについて一緒に学んでいきます。

このトークを聞いてプロポーザルの書き方を学び、あなたも次のiOSDCのステージに立って好きなことを広めてみませんか？