トーク

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でも快適にコード読める技術の作り方を解説します。

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

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を使ったマルチスレッドプログラミングの新たな可能性に触れてみましょう。

＜これまでのあらすじ＞
2019年9月、iOSが13へと進化するその傍らで、ひっそりとiPadOSは生まれた。それはiOSにない特徴的な機能「Multiple Windows」、すなわち「複数のスペースで同じアプリを開いて作業する」機能を有していた。
2020年4月、Magic Keyboardが発売され、iPadはますますノートPCへと近づいていく。「モバイル」と「PC」の境界が消えつつあるこの世界の中で、Multiple Windowsへの対応の有無がアプリの使い勝手に大きな影響を与えようとしていた——

本トークでは、iPadOSのMultiple Windowsを使ってユーザーがどのような体験を得られるのかを紹介し、その後に実際にアプリをMultiple Windowsに対応させる方法について解説します。そこでは、UISceneを始めとするScene APIを整理して段階的に説明します。

・Multiple Windows…なにそれおいしいの？
・シーンは簡単、そう、iOS 13以降のみならね
・複数のシーンをサポート！戦いの始まり
・シーン状態の保存ならオレに任せろ
・プログラムから新しいシーンを展開！
・シーンのライフサイクル（ゾンビもあるよ）
・シンクロナイズドシーン《状態の同期》
・好きなシーンを選んでね

さあ、みなさん、iPadOSDCの時間です！

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

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

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

【アジェンダ】
・CIの概要とメリット
・ライブラリのセットアップ・ビルド・単体テストを実行するスクリプトの作成（Makefile）
・ビルド・単体テストを実行するCIの構築
・★キャッシュを使ってCIの実行時間を短縮する
・★静的解析（SwiftLint）を実行するCIの構築
「★」はGitHub Actions独自の機能を使う

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

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

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

本トークを聞いて、実際にCI環境を構築してくださると嬉しいです！

TL;DR
Googlerが解説するgoogle/bazelを活用したビルド速度の最適化と, その前提になるマルチモジュールの実践ガイドになります。

1. 実践マルチモージュル編
   「iOSプロジェクトをマルチモジュール化するとビルド速度が速くなるよ」という話はよく聞こえるが, 意外と実務に適用するには難関があります。マルチモジュール化を最小限の努力で実現するコツ, ファイルが分けてしまってgitから履歴が見えなくなった時の対処方法等を話ます。

2. ビルド編 - google/bazel
   マルチモジュール化されたプロジェクトだとbazelの恩恵を十分もらうことができます。LINEアプリ等が採用しているbazelの用いて既存の２倍以上のビルド速度を目指しましょう。

3. テスト編
   マルチモジュール化すると嬉しい所の一つがレイヤ毎にカバレッジが一目瞭然になること。ですが, 以前問題なかったはずの単体テストが動かなかったりする問題もあります。単体テストのトラブルシュートとテスト実行を速くするtipをシェアします。

もしもこんなことを言われたら「何言ってんだ、できねぇよ」と言うと思います。
しかしながら双方似ている部分があり、とっつきやすいのも事実です。iOSエンジニアの皆さん、Androidアプリも作ってみたくありませんか？

このトークでは、私がiOSエンジニアからAndroidエンジニアに転身した経験を活かし、iOSエンジニアにとってわかりやすい形でAndroidアプリ開発について説明してみたいと思います。もちろん40分ですべて熟知してもらうのは難しいです。なので、Androidアプリを作る上で要になる部分の解説や、躓いたときに自力で原因を探るためのデバッグ手法の説明に重点を置き、自走できる状態へ導きたいと思います。

目次

・Swiftと比較しつつKotlinを学ぼう
・基礎の基礎、Activity、Fragmentを理解しよう
・ConstraintLayoutでUIが組めるようになろう
・よく使うListViewとRecyclerViewを知ろう
・最低限のデバッグができるようになろう

iOS の UIKit は一見、文字入力のような基本的なことはとても簡単に行えるように思えます。

しかし、一度でも文字入力を扱ったことのある方は、その難しさと期待しない動作に頭を悩ましたことが一度はあると思います。

例えば、iOS のキーボードが文字入力に被ってしまう、キーボードの位置がずれる、変更したはずの文字が反映されない、日本語が入力できない...
実のところ、一般的に文字入力はとても複雑なユーザーインタラクションであり、さらに iOS はキーボードにも様々な種類があるため、一見すると正しそうな実装であっても、ドキュメントに記載のない様々な挙動により期待しない結果に終わってしまうことが多々あります。

このセッションでは、ほぼほとんどの方が経験する iOS の文字入力に関する些細な問題からとても大きな難題について、世界中で多くのユーザーが使う iOS アプリ開発や、iOS のキーボードフレームワーク「KeyboardGuide」などの開発など、これまで長い間蓄積してきた経験に基づいて、実際におこった問題を実例を踏まえて、その原因や対策を検証していきたいと思います。

対象とする方:

• iOS アプリ開発の経験がある中・上級者
• UITxtView に昔年の思いがある方
• UIKeyboardWillChangeFrameNotification などに昔年の思いがある方

前提とする知識:

• UIKit
• Foundation
• Unicode

ユーザーにアプリを快適に使ってもらうためには、機能が動くだけでなくアプリのパフォーマンスも重要です。
端末が熱くて持てない、動作がカクカクするなど快適に動かないアプリは、ユーザー体験を著しくそこなってしまい、ユーザの離脱にもつながっていきます。

このような事態にならないためにも、アプリのパフォーマンスの計測を継続的におこない、
問題がある箇所を見つけて適切に対処すること重要です。

iOSアプリ開発ではInstrumentsなどを用いてパフォーマンスを計測することができますが、手動で計測しつづけるのは困難です。
今回は自分たちでCPU使用率と端末温度の計測を継続的に実施する仕組みをInstrumentsを用いて作成しました。

これらの仕組みを用意するために、CI/CDサービスをどうするか、どのように操作をし続けるかなど、様々な課題がありました。
また、運用していく中では、Instrumentsのデータの見づらさや想定外のクラッシュなどいくつもの問題が発生しました。

本トークでは、実際にiOSアプリケーションのCPU使用率と端末温度を継続的に計測する仕組みを作成し、運用している環境をどう実現したかに加えて「乗り越えた課題」、そして「残る課題と今後」についてより詳しく話をします。

プロダクトが成長するにつれて、アプリ品質向上とリリーススピードを高めることは難しくなっていきます。機能や画面が増えるにつれてマニュアルテストを続けるのは時間的なコストが上昇し、リリーススピードが落ちてしまいます。そこでE2EテストとしてUITestを導入し、テストを自動化する方法が考えられます。Apple標準UITestフレームワーク、XCUITestを検討する方も多いのではないでしょうか？
しかし、やみくもに大量の画面によるテストケースをコード化しても再利用性のないテストになることは明白です。また、XCUITestフレームワークの特性を理解し、適切にUIコンポーネントを操作するにはちょっとしたノウハウが必要です。

方法の一つとして、PageObjectデザインパターンを導入しテストコードと画面構成を切り分けましょう。実装方針をチームで話し合うのも重要です。一般に参照系のテストは実装が容易ですが、ユーザー状態を変更するUITestは実装が難しい場合があります。プロジェクトの性質によって適切な優先順位をつける必要があります。
このトークでは自社アプリにXCUITestによるUITestを導入した経験をもとにUITestの実装ノウハウを共有します。またUITest実装を進めるにあたってXCUITestのトリッキーな挙動もわかって来ました。

• Accessibility Identifier場合やLabel重複の適切なQuery方法
• UIView.setAnimationsEnabledをfalseにするとポップアップが表示されない問題
• iOS 13とiOS 12でView階層が異なる問題

これらの問題の解決方法も合わせて共有できればと思います。

UITest導入と戦略と実践が学べ、UITest導入を検討している方にぴったりのトークです。

Swiftを用いたアプリ開発用にThe Composable Architecture（TCA）というのがあり、それがめっちゃ良いやん！と思うので紹介するトークです。

TCAは人間工学を考慮した一貫性のある方法でiOS（およびmacOS, tvOS, watchOS）アプリを構築するフレームワークです。

https://github.com/pointfreeco/swift-composable-architecture

TCAの良い点はRedux的にReducerを取り入れつつ、Reducerを画面ごとに用意し必要があればそれを別画面用に組み合わせることを前提としていることです。これによって巨大なグローバルなReducerを作ることはなく、Reducerを修正する場合に他の画面のコードを目にすることはありません。さらにロジックの繋ぎとしてうまくCombineフレームワークを使っているところも良い点でしょう。

Combineはリアクティブプログラミング(RP)フレームワークですが、他のRPフレームワークと同じオペレーターを使っても動作が異なることもあり、クローズドなフレームワークであることで不具合かどうか判断しづらいデメリットがあります。そのため、あくまで限定的にCombine利用するという点はTCAを使わなくても良い教材となるはずです。

SwiftUIを使ってどのような構成でアプリを作ろうかと考えている人にも参考になるトークとする予定です。

十分に発達した組織による開発では、本質的な機能間の疎結合化や逆コンウェイ戦略に則った組織構成への適応など、より高度な課題が様々出てきます。もちろんビルド・テスト時間の最適化といった個々の開発者の直接的な課題もその一つです。
どれだけアプリケーションアーキテクチャを洗練させ理解を進めても、これらの課題の解決は難しいでしょう。
そこでリードアーキテクトは、よりソフトウェア的なアーキテクチャを発展、また将来漸進的に進化できるように構成する必要があります。そのためには、構成要素を複数のモジュールに細分化し、組み換え容易にすることが重要です。

最近ではAndroidアプリ開発の流れか、2〜20ほどのモジュールからアプリを構築している所謂マルチモジュール化に挑戦しているチームも多くなりました。
これを更に発展させ、数百のモジュールからアプリを構築するためには通常の開発手法では無理が出てくるため、現担当プロジェクトではビルドツールにBazelを採用しています。

BazelはGoogleが開発し、iOSアプリ開発ではUberやLyft、Pinterestといったモバイルアプリに力を入れているテックカンパニーでも採用されている多言語向けのビルドツールです。
もちろんiOSアプリ開発への導入ハードルはかなり高いですが、効率的なモジュール定義や、CIマシンを含め開発者全員が同じキャッシュを共有するRemote Cacheなどの強力な機能も持っています。

このトークでは、モジュールを数百に細分化することでどのような利点があるのか、Bazelを採用することで何が可能になりどのような相乗作用があるのかをお話します。

飲食店の予約台帳アプリであるレストランボードでは、電話応対業務をサポートする待望のCTIサービスをリリースしました。

このサービスでは、「CTI-BOX」と呼ばれる専用物理デバイスが店舗の固定電話とiOSアプリを繋ぐハブとなり、システム化を実現しています。
専用物理デバイスを採用したことで、iOSアプリとの連携や通話転送をするためのBLE/SIP/PSTNなど各種通信I/Fや、機器や設置環境の物理的な制約など、通常のアプリ開発とは異なる様々な困難がありました。

本セッションでは、CTIサービスを開発する上で発生したシステム・運用両面での課題と、それを解決するための技術的チャレンジについてお話しします。

この発表は、2016年のiOSDCで登壇した「Reactive State Machine」の続編です。
https://speakerdeck.com/inamiy/reactive-state-machine-japanese

前回お話しした Redux / Elm Architecture について簡単におさらいした後、
Swiftコミュニティが新たに開発した各種フレームワークについて紹介します。

• https://github.com/inamiy/Harvest
• https://github.com/pointfreeco/swift-composable-architecture
• https://github.com/bow-swift/bow-arch

これらのアーキテクチャを理解する上で重要な鍵となるのが「Optics」と「Comonad」です。
関数型プログラミング（とちょっとだけ圏論）の知見が、
iOSに限らずフロントエンド開発全般でどのように役立つのかを見ていきます。

また、これらの概念が Web (React) の世界でどのような類似点を持つのかについても、
合わせて比較検討を行います。

みなさんは、複数のiPhoneを、連携させたことがありますか？

一般的なアプリを作っていると、10台以上のiPhoneを同時に動かす必要はなかなかありませんよね。
そんなレアなニーズに2年以上本気でとりくんでいるフリーランスエンジニアが、実際に動く複数台同期ソルーションのすべてを解説します。

イベントなどでたくさんのiPhoneを同期させてみたい方、アプリに意外な追加要素をつけてみたい方、新しいiPhoneの使い方を考えてみたい方は必見です。

今回は録画での登壇が可能なので、実際にたくさんのiPhoneがsyncしているデモをお見せできるかもしれません。

（本セッションは、2018年のiOSDCで発表した「Synchronized iPhones」の続きですが、前回の内容を知らなくても楽しめます。）

機械学習の「画像生成」モデルもモバイルアプリ（iOS）にのせられます。これによりAI画像生成アプリをつくれます。例えばアニメキャラクターを生成したり、自撮り写真を西洋絵画に変換したりできます。
DCGAN、Pix2Pix、CycleGAN、UGATIT、これらはGANという画像生成技術の応用です。このトークでは上記モデルをモバイル用CoreML形式に変換し、iOS端末上で画像を生成する為の方法を紹介します。本番ではスムースに変換するためのTipsを盛り沢山でお話します。GANのコードを完全に理解している必要はありません。勘所をつかめば、TensorFlowやPytorchといったPythonベースのモデルをCoreML形式に変換して、アプリに組み込むことができます。
変換手順
1, トレーニング済みモデルを用意しよう
GitHubに多くの生成モデルが利用しやすいライセンスで公開されています。今回は、GoogleチュートリアルやGitHubのモデルを紹介し変換します。
2, 「Generator」を見つけよう
GANはGenerator（生成する）とDiscriminator（判別する）で構成されており、アプリで使用するのはGeneratorです。
何百行に渡るGANコードを全て理解する必要はなく、この「Generator」をソースコード内でうまく見つけるのが変換作業の勘所となります。そのコツを説明します。
3, CoreMLToolsで変換しよう
変換スクリプトはシンプルです。ただし変換オプションの指定も必要なので、元のモデルから必要なオプションを特定する方法を説明します。
4, アプリで使おう
Visionフレームワークを使用します。
画像形式の出力を取得するには、OSSを利用するか、モデル形式を少し変更する作業が必要です。その方法を説明します。