flutter createする時にKotlinを選ぶ必要性がほぼなさそう

おおよそのFlutterアプリにおいてはKotlinを書くことはない
- 大抵のFlutter用ライブラリは FlutterApplication や FlutterActivity になにかを実装することはない
- Flutterアプリ側の事情でKotlinを書くことは稀
  - Communityが基本的なライブラリは提供している
  - Kotlinを書くことになったとしても、そのタイミングでKotlinをセットアップしても問題がない
KotlinのアップデートをFlutterアプリエンジニアが把握しなければならなくなる
- 何もしなければ古いKotlinをいつまでも参照する
  - jCenterの問題にどう対応するか、Androidのネイティブアプリの経験がないと大変かも……？
- Kotlinのバージョンアップによる、推奨導入方法の変化に対応する必要がある
- flutter create . をしてもKotlinのバージョン更新はしてくれない(ハズ)
使わないライブラリをアプリの依存関係に含めることによる、ビルド時間やビルドサイズの増加
- リリースビルドであればR8で基本的には削除されるが……

このためKotlinを「とりあえず」で追加するメリットはほぼなく、デメリットは数えられる程度にはあるのではないか、というのがここのところの感想。

Kotlin 1.4で追加されたTrailing Commaを導入したところ、古いKotlinを利用しているアプリでビルドができなくなった、という事象が最近あった。
プラットフォーム依存のコードを書かなければならないライブラリが、最新のKotlinを使いたいのは道理であって、古いKotlinにアプリ側が依存しておくべき理由もないので、各Flutterアプリが更新をするべき問題だろうなと思っている。

100%同意。

しかし、現実的には Issue であり Bug であると大量に報告されており、古いKotlinを利用していてライブラリの問題だと思う人も結構いる様子。(audioplayersには「ライブラリが信用できない」というIssueを立てる人もいたので、メンテナーのモチベーションに非常に悪く働いている気もしている)

koji-1009

flutter_auth_ui も同じような問題にぶつかった人がいたようなので、KotlinをやめてJavaを使うことにしてみた。

koji-1009

Dartが読み書きできればKotlinはまあ読めるだろうし、Javaも突っかかりながらも読めるだろう(冗長だけど)という印象なので、Android側は「Javaでもいいじゃん」というのがまとめ。

なお、Objective-Cはそうとも言えない……ので、iOSの場合は「とりあえずSwift」が良いと思っている。iOSの経験がある人ならSwiftを選ぶ/選ばないを判断できるけど、iOSの経験がない場合はSwiftにしておかないと、後からSwiftの導入するのも大変じゃないですかね。

koji-1009

結局、古いKotlinをライブラリが利用しているケースで問題が発生したらしく、JavaのテンプレートにKotlinのpluginが入るようになった。
Flutter 2.8まではビルドできていたプロジェクトでも、Flutter 2.10以降はビルドできないことがあるので、Kotlinを追加&定期的に更新する必要があることになった。

koji-1009

最新のFlutterプロジェクトだと、Kotlinを選ぶことになるので、この話はおしまい。。

このスクラップは2023/12/26にクローズされました