Androidエンジニアから見たMulti Platform

2019/07/24(水) Fintech,Python…気軽にくっちゃべる会＃2 発表資料

Transcript

1. Androidエンジニアから見たMulti Platform ウェルスタイル株式会社 古田土 翔大
2. 今日話すこと/話さないこと 話す マルチプラットフォームを使う理由 いくつかのプラットフォームの紹介 個人的なおすすめな使い方 話さない ゲーム系のアプリの話 各プラットフォームのノウハウ
3. 自己紹介 古田土 翔大 (git. hakuyoka, twitter: @boy_surface) ウェルスタイル株式会社　エンジニア ・Androidエンジニア（RailsもAWSもPHPも触る） ・家族SNS wellnote の開発と保守と採用 ・新しい技術をやっては捨てる人 ・最近はFlutterとRustをやってる オフィス見学とかやってます 来るとご飯おごってくれます（社長が
5. モバイルアプリを作る時いろいろ 1. Native Application 2. PWA or WebView 3. マルチプラットフォームフレームワーク Xamarin React Native Flutter Kotlin Native
6. 5分なので先に結論
7. Nativeで作るのが一番です
8. なぜマルチプラットフォームを使うのか？
9. 工数が足りないから ・銀の弾丸があればNativeで作った方がもちろん良い ・効率よく必要な速度でアプリを作るためには妥協は必要
10. 例えば、弊社 サーバサイド Android iOS モバイルエンジニアが足りないですよね。。。
11. ちょっとモックアプリ作ってよ Androidもこんな感じで こんなアプリ作って欲しいんだけど？ 雑にこんなアプリを作って！っていう人はいます
12. マルチプラットフォームの特徴 1. UIの観点 NativeのUIコンポーネントを利用するか 2. 機能の観点 Native or Webで動くかどうか NativeのAPIはどう呼び出すか 3. エコシステム どれだけの資産を使い回せるか ライブラリは豊富か
13. マルチプラットフォームの特徴 動作 UIコンポーネント APIラッパ エコシステム Xamarin Natvite Native あり .Net系も使える Flutter Native 独自 なし Firebase系が強い React Native Web Native なし Kotlin Native Native なし あり Java系も一部 PWA / WEB Web Web なし JSそのまま
14. 独断と偏見が入ります (５分なのでオススメのみにします
15. Xamarin • MicroSoft製の.Net系のフレームワーク • .Netの資産のがある というなら是非 • 抽象化のレベルが高いので慣れれば開発はしやすい • 逆に、マルチプラットフォームのために始めるの敷居が高いかも • 熱狂的なファンが多いイメージ ◦ ちょまどさんパワーで名前だけ知っている人もいる
16. React Native • FaceBook製のReactベースのライブラリ • Reactの知識がそのまま使える • 実績も多い (Facebook, Skype) • AirBnBショックがあったが、安定して使われている印象 • Webエンジニアだけで書けるかというと多分無理 　どこかでNativeの知識が必要になってくる それでも各プラットフォーム毎のモバイルエンジニアがいれば
17. Flutter • Google製のライブラリ • HotReloadで快適に開発できると評判 • Firebaseとの連携が厚い • マテリアルデザインな独自UI 弊社iOSエンジニア曰くの人はそんなにわからないかも？ • Dart言語 Java書ければ書けるが、モダンな言語とは言い難い 　マイナーな認識があるのかドキュメントは豊富 • ネイティブのAPIを叩く場合は、Nativeのコードが必要 ライブラリは多い方で探しやすい
18. Kotlin Native • JetBrainsのKotlinフレームワーク • Kotlin Native Multi Platformsで、iOS,Android共通ライブラリが書ける • Kotlinかけるエンジニアは割と多い • UIは各プラットフォームの実装が必要 • ドキュメントはあまり親切じゃない • まだ、少しバグい
19. PWA / WEB • Web技術だけでも作れる ◦ Webエンジニアだけで一番はまらない方法 • アプリがWebだけ完結できそうならあり • センサくらいのAPIは叩ける • NativeっぽいUIにするのは難しい • 全てのNativeのAPIを呼べるわけではない 特にバックグラウンド処理周りが弱い • Webだからってプラットフォームのアップデートは無視できない
20. 結局？
21. 開発、保守で工数が一番減りそうなもの ダメになったら潔く捨ててNativeで作り直そう
22. おすすめ • Flutter ◦ わかるエンジニアがいれば、爆速で開発して仮説検証まで可能 ◦ スタートアップでのアプリやモックアップに向いている ◦ 保守や大規模な運用は厳しめなので、ゆくゆくは Nativeに置き換えることも検討 • Kotlin Native Multi Platforms ◦ ドメイン層は普通は共通化できるので、そこまで共通化が可能 ◦ Nativeアプリがあるなら、Kotlinを書くことができるエンジニアはいる ◦ サーバサイドKotlinやっているとサーバサイド側がドメイン層も書ける ◦ モバイルエンジニアが UIに集中できる • PWA ◦ Native独自の機能が将来にわたり必要になることがない ◦ NativeっぽいUIである必要がない ◦ Webのシステムをとにかく App Store, Play Storeに載せたい
23. まとめ • 基本的にはNativeアプリを作る • マルチプラットフォームは、工数の削減のためにある • どのプラットフォームも使いよう 　開発、保守の工数が一番減るのが正義 • Flutterやろう！