FlutterアプリをSwiftUIに移行するとき、「移植」するのをやめた

個人開発を始めた頃はFlutterでiPhoneアプリを作っていました。

今は開発対象をiPhoneに絞っていて、既存アプリも少しずつSwiftUIへ移行しています。

最初は当然、

「Flutter版をSwiftUIで作り直す」

つもりでした。

画面を見ながら同じUIを作る。
Flutter側の処理をSwiftに置き換える。
機能もそのまま持ってくる。

でも途中で、このやり方をやめました。

移植するのではなく、もう一度設計することにしました。

Flutter版をそのまま正解にしない

既に動いているアプリがあると、それをそのまま再現したくなります。

画面構成もある。
機能もある。
データの持ち方も決まっている。

なので、それをSwiftUIに翻訳するのが一番早そうに見えます。

でも考えてみると、その設計はFlutterで作ったときのものです。

今はSwiftUIで作る。

しかもAndroid版を作る予定はなく、iPhone専用です。

だったら以前の構造をそのまま残す理由はあまりありません。

そこでFlutter版は、

完成形ではなく参考資料

として見ることにしました。

機能も一度見直した

移行するときは、既存機能をそのまま全部持ってくるのではなく、一度見直します。

残すもの。
改善するもの。
作り直すもの。
いったん入れないもの。

せっかく作り直すのに、昔入れた機能まで無条件に再実装する必要はありません。

以前は必要だと思っていたけど、今見るとそこまで重要ではない機能もあります。

逆に、今ならもっと自然に実装できるものもあります。

この作業を始めると、だんだん「移植」という感じではなくなってきました。

ほぼ新しいバージョンの設計です。

チケノートもSwiftUIでかなり変わった

ライブチケット管理アプリの「チケノート」もFlutterからSwiftUIへ移行しました。

ここでもFlutter版をそのまま再現するのではなく、SwiftUI版ではApple Musicとの連携まで入れました。

アーティストのアートワークを表示したり、曲を試聴できるようにしたり。

Flutter版にはなかった体験です。

ここまで変えると、

「Flutter版をSwiftUIに移植した」

というより、

Flutter版を元に、もう一度アプリを作った

という方が近いです。

古いコードは消さない

ただ、Flutter版を不要なものとして捨てたわけではありません。

以前の実装には、

画面構成
文言
操作の流れ
過去に考えた仕様

などが残っています。

コードそのものを再利用しなくても、そこには開発したときの知識が残っています。

なので旧版は参照できる状態にしておく。

でも、新しいコードを書くときの制約にはしない。

この距離感がちょうどよかったです。

AIにも「同じものを作って」とは頼まない

SwiftUIへの移行ではAIコーディングもかなり使っています。

ここでも、

「Flutter版を読んで、同じアプリをSwiftUIで作って」

とはあまり頼みません。

先にSwiftUI版でどう作るかを決める。

そのうえで必要なら旧実装を確認する。

という順番にしています。

既存コードを最初から大量に渡すと、AIもその構造を前提に考えやすくなります。

でも、その構造を残したいとは限りません。

だから、

旧アプリ＝正解

ではなく、

旧アプリ＝参考資料

くらいにしています。

Flutterをやめたという話ではない

Flutterが悪かったわけではありません。

AndroidとiPhoneの両方を作るなら、今でもかなり便利だと思います。

自分の場合は、今後iPhoneアプリだけを作る方針になった。

それならAppleの仕組みをそのまま使いやすいSwiftUIの方が合っていた。

それだけです。

技術選定は、

「どれが一番優れているか」

ではなく、

今の自分が何を作りたいか

で変わるんだと思います。

作り直すなら、過去の設計まで引き継がなくていい

既存アプリを別の技術へ移すとき、

同じものを再現することばかり考えていました。

でもせっかく作り直すなら、以前の設計まで全部引き継ぐ必要はありません。

残したいのはコードではなく、そこで得た経験です。

過去のアプリを移植するのではなく、

過去の経験を使って、もう一度作る。

今はそんな感じでSwiftUIへの移行を進めています。

個人開発したアプリはこちら
https://tsubasa-studio-web.pages.dev/