iOSDC 2016 ベストトーク賞の感想と裏話

iOSDCの感想を書こうと思ってよく考えたら自分のブログを持っていなかった@inamiy です、こんにちは。
こういう時にQiitaは便利ですね。2年ぶりに投稿します。

先週、2016年8月19日〜20日にかけて開催された「iOSDC Japan 2016」というiOSカンファレンスで、「Reactive State Machine」をテーマに発表させていただきました。
嬉しいことに、多くのオーディエンスの方々から、厚さ3cm以上の肉スライドとして認められ、なんとベストトーク賞に選んでいただきました！ (賞金は1.70302628ビットコイン by bitFlyer社様)
投票して下さった方々、並びにイベントを円滑に運営して下さったスタッフの方々に、厚く御礼申し上げます。

• スライド
  • Reactive State Machine (Japanese) // Speaker Deck
• 動画:
  • iOSDC Japan 2016 | FRESH! by AbemaTV (3:00:00〜)
  • iOSDC Japan 2016 08/20 Track A / Reactive State Machine / 稲見 泰宏 - YouTube

• GitHub

  • inamiy/ReactiveAutomaton (ReactiveCocoa版)
  • inamiy/RxAutomaton (RxSwift版)
  • 個人用gistメモ

• 当日の雰囲気

  • Reactive State Machine-FRPでの最適な設計手法を探る- #iosdc #a - Togetterまとめ

  • #iosdc どっちも食べ物の話ししてて、えっ？iOS？ってなっていた pic.twitter.com/ONPliW2xf9

    — ジャンボ (@jumbOS5) 2016年8月20日

今回の発表は、普段なかなか話題に上がらない「関数型リアクティブプログラミング (RxSwift, ReactiveCocoa (RAC)) の問題点」のほか、「React.js + Redux（の問題点）」や「Elm」といった新しいプログラミングパラダイムについて幅広く紹介できたので、共感してくれる方が普段よりも多かったように思います。
現時点では、どれが正解と結論づけることはできませんが、それぞれの長所・短所を知ることは、今後のFrontend開発の動向を追っていく上で重要な手がかりになると思います。

発表のきっかけ

裏話をすると、今回の発表のきっかけは、2年前にQiitaに投稿した

• Swiftで有限オートマトン（ステートマシン）を作る - Qiita

が元になっています。
当時は、「Swiftのカスタム演算子をオシャレに使いたい」という謎の欲求があり、勢いでSwiftStateというライブラリを作りました。

その後、JavaScript方面でReduxが注目され、SwiftでもReSwiftというライブラリが登場しました。ちなみに、このライブラリをヘビーに使っているチームがFablic社で、今回のiOSDCでも@huinさんが導入事例を発表しています。

• iOS DC 2016 : フルSwiftでバイクフリマアプリRIDEを作って得た学び // Speaker Deck

そんな中、同社の@ninjinkunさんとアプリ開発と状態遷移の管理 - ninjinkun's diaryについて意見交換をする機会がありました。当時の私は、React.jsの「状態をimmutableにする」考え方や、Reduxで「アプリ全体の状態を集約する」という発想が、あまりにも非効率的でiOSの設計にそぐわない、と違和感を覚えました。例えば「RxSwiftであれば、ViewModelをいっそのことシングルトンしてしまって、必要な数だけVariableを生やしてデータフローを構築すれば、Reduxと実質同じような動作を簡単に達成できる」と考えました。この辺については、同ブログ記事でも取り上げられています。

状態遷移の管理という観点で捉えると、Flux、ステートマシン、MVVM、Promise、FRPは対象としている状態の大きさの違いなのかもしれないとも思う。Fluxはアプリという大きな単位で状態を管理するためのアプローチである。Promiseはもっと小さな単位の状態遷移、ステートマシンはその中間くらいというイメージを持っている。PromiseやObservableはまとめることでより大きな状態遷移を作ることもできるので、小さな状態遷移を積み重ねて大きな状態遷移を作るものとして考えても面白い。

つまり、アプリ全体の状態を「点在したVariableの集合」として扱うか、「状態コンテナに格納された唯一の(代数的データ型の)値」と見なすかの違いです。前者が「FRP + MVVM」、後者が「Model-View-Automaton」の世界です。

そして、それから「Redux = ミーリ・マシン」と気づくのに少し時間がかかってしまいましたが、ミーリ・マシンの「出力」の型にFRPを活用して非同期処理を克服するのは自然な流れでした。さらに調べていくうちに、このアプローチが（つい先日学んだ）Elmの設計とほぼ同じで、むしろ向こうの方が「FRP的な副作用管理を言語内仕様に組み込んでいる」時点で、何倍も上手だと思いました（参考：A Farewell to FRP）。

まとめ

というわけで、Elmについては（もう少し勉強しないといけませんが）、今回の私のプレゼン（とFRPそのもの）が無に帰するくらいの高いポテンシャルを持っていると考えています。現在のiOS開発ですぐに役立つ内容ではありませんが、iOSアプリ開発の未来を予測するのに役立ってくれれば幸いです。