3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

FlutterAdvent Calendar 2023

Day 1

[初心者視点]作りたいアプリの難易度別でcompose multiplatformとFlutter難易度を比較してみた

Last updated at Posted at 2023-11-30

はじめに

初心者Androidエンジニアの私目線から
もはや定番となったFlutterと新進気鋭のcompose multiplatformを比較します。

目次はこんなん

  • 前提
  • ポートフォリオレベルでの実装の手間
  • ハッカソンレベルでの実装の手間
  • 個人開発レベルでの実装の手間
  • まとめ

前提

Compose Multiplatformは新しめの技術で、成熟しているFlutterと比較するのは不公平ですし
自分は元Androidアプリエンジニアなのでそう言う点でも不公平です。
まぁ差し引きしてみてください。

また私はFlutterもcompose multiplatformも業務で使ったことはないです。
Flutterはハッカソンに出た時に3回ほど使ったことがあり、compose-multiplatformに関してはチュートリアル終わって、遊びで一つアプリ作っている段階です。
要はかなり初心者なので、中級者の方が読んでもメリットはないと思います。

それぞれの技術の仕組みについての深い話はしません。ていうか難しすぎてわかりません。

あと、環境構築の手間も比較してみようと思ったのですが、両方ほぼ同じだったので割愛します。

ポートフォリオレベルでの実装の手間

チュートリアルで作るような、APIの呼び出しもしないレベルのアプリです。(状態管理とかもあんまり意識しない)
就活のポートフォリオとかのレベルかな。
このレベルだとどっちもめちゃくちゃ簡単に作れますが、若干ComposeMultiplatformの方が楽でした。
Kotlin自体の書き心地が良いので、Dartよりもシンプルにかけます。
UI部分も、Flutterは呪文が多くてめんどくさいです。
Flutterならスケルトンテンプレートを使えば、ほぼほぼ完成です。
compose multiplatformはまだテンプレートがないので、自分で作る必要がありますが、基本的なライブラリとかが入ったアプリを作ってくれるCompose Multiplatform Wizardや、KMP wizardがあるので、対して手間はかかりません。

HotReloadがある分Flutterの方が楽じゃんと言う声はよく聞くのですが、自分はあんまり感じないです。
プレビュー表示でリアルタイムな確認は行えるし、画面全体での確認をしたいなら
結局リビルドしないと信頼できない(変な挙動になってしまうことが多い)ので自分はHotReloadを使う機会があまりなかったです。
あくまで自分の個人的な感想です。

ハッカソンレベルでの実装の手間

FirebaseやSupabaseなどのmBaasを利用したり、簡単なAPIを叩いたりするレベルです。
状態管理やアーキテクチャをちょっとだけ意識しているレベルを想定しています。

結論としてはFlutterの方が楽です。

mBaaS、API周り

Flutterの方が若干楽です。
FirebaseもSupabaseもSDKがあるので、両方簡単に導入できるのですが公式のサポート具合が全然違いますね。
Flutter x Firebaseとかだとドキュメントみなくても言われた通りにやればできるし、ドキュメントもほとんど日本語化されてますよね。
Compose Multiplatform x Firebaseだとドキュメント通りにやってみて正しく動かないことが多かったです。
ドキュメントをみても動かないから、issueをみたりstack overflowを見に行く必要があります。

意外だったのは、Compose MultiplatformだとSupabaseの方がライブラリの安定性が高い気がします。公式のSDKさえみておけば全てわかるので楽ちんでした。

設計周り

Flutterの完勝です。
状態管理とかのライブラリや設計に関してはFlutterの方が圧倒的にドキュメントが多いので
比較にならないくらい楽でした。

Compose Multiplatformのアーキテクチャ調べているとKMPのアーキテクチャとか出てきて、頭が混乱します。
FlutterはBLoCとかProviderとか、ある程度「正解」的なものがあるので考えすぎなければ楽ですね。

UI関連

実はCompose Multiplatformの方が若干楽でした。
私が言いたいことをすべて言ってくれている記事があるので、そちらを参照してください。
もちろんWidgetの種類とかはFlutterの方が充実しています。
ハーフモーダルとかはよく使う系のUIがWidgetとしてすでに用意されているのはFlutterの良い点でした。
ただ個人的にはそれよりもコードの読みやすさとか、書きやすさの方が大事だと思うので、Compose Multiplatformの方が好きです。
(私はAndroidアプリエンジニアだったことがあるのでそれも影響している)

個人開発レベルでの実装の手間

これは、現在挑戦中なので正確にはわかりませんが、今の所Flutterの完勝です。

現状の開発状況だとCompose MultiplatformでiOSに対応するのは難しそうですね。
バグ引いて詰まることが多すぎて涙が出ます。
また、Compose MultiplatformのiOS側のパフォーマンスが目に見えて悪いので涙が出ます。(最近のアップデートで若干改善した)
ライブラリもFlutterと比べて少なすぎるので涙が出ます。
Androidアプリ開発で使ってきたライブラリがComposeMultiplatformに対応していないので涙が出ます。

まとめ

Flutterの方がどんなアプリを作るにしても、大体楽ですね。
一方ですでにjetpack composeをたくさん触っている人にとってはCompose Multiplatformの方が楽だと思います。
結論がめちゃくちゃありきたりな感じになってしまった。

ただし将来性と言うことだと、Compose Multiplatformもかなり期待できると思います。
まだComposeMultiplatformに対応していないライブラリがたくさんありますが、どんどん対応していくと思うのでそこに期待します。

どっちも発展途上で将来が楽しみだなぁと思いました。

3
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?