Migrating a large production app into flutter

Help General
1

Currently Im working on a pretty large native iOS codebase. Its not an app my team built from scratch, we inherited this codebase but its a massive codebase and as such Im sure there’s code paths and corner cases that we aren’t even aware of, and there’s very little documentation. Most documentation we have was me and another guy just reading through the project and documenting the flows

Now we’re evaluating an android port and since we’re familiar with flutter , that’s what we are using mainly to target android for now (but maybe someday replacing the ios app too). And I’m basically doing this android thing solo

So to those of you have handled similar migrations in the past - what was your approach? Do you start with replicating parts of the codebase or just ignore the codebase and look at the product only. Im also curious how AI can best be used to speed this up

2

I don’t “vibe code”, which to me is trying to come up with a single prompt that will magically build my app. I use software engineering instead, which starts from a PRD then expands into a sequence of discrete testable steps. I would use Gemini (in the form of Gemini CLI) to first analyze your existing ios codebase and reverse engineer the PRD that best describes the behaviors and flow that you desire, then use that PRD to plan the new flutter app.

2 Likes
3

Yeah I don’t either, so far my use of AI has been limited to pairing with it where I’d get AI to write snippets of code that I then use or I talk through an API design with an AI, I dont trust it especially for a production app to just write a massive app. The AI was just a tangential thought, Im more interested in the processes people follow when trying to do things like this generally

4

I would like to warn you if you are not already aware that some users can be incredibly sensitive to framework changes and the ways they can manifest at runtime, e.g. page animations, default timeouts for network calls, safe area behaviours at the edges.

When I went through this process the product was analysed and opportunities to improve it in one way or another were considered. My recommendation is not to try and be too strict about replicating past behaviour but also to be quite conservative about changing the user experience, although it is a function of the users you have now / expect to have in the future.

3 Likes
5

Thank you for the callout. The primary intention is to build this as an android app, currently there is no android app. Potentially also using it as the ios app is a future long term thing

6

This depends a lot on how much does this app rely on external services, APIs or some specialized algorithms. These things tend to be immutable, you just have to do it the same way as the other app. mark already mentioned that it’s important to don’t make the new app too unfamiliar. Since you are targeting an entirely new audience and using a different programming language, I don’t think it’s important to do everything like it was in the other programming framework. It’s an opportunity for improvements.