I am building a cross-platform app (web, Android, and iOS) for a client in FlutterFlow. We had all hoped that FlutterFlow would save development time, and I signed off on the idea as a developer largely due to the comfort I got from knowing I'd always have access to the source code if anything didn't quite work as needed "out of the box." But we're facing a lot of difficulty while testing the different builds of our app that FlutterFlow produces from our source code. I'll just focus on two specific examples, to try and keep this cry for help concise and digestible.
First, I put together a very straightforward, "by the book" file upload button, with files being stored on Firebase. I followed the available documentation just to get to a point where it all simply worked, at which point I would test it out, and then later work in all our project-specific customization and dressing. But we got stuck at testing; It all works fine with small-ish files, but files of 50mb or so crash Android builds. They upload fine in the web build. In this case, we're just using the "out of the box" upload actions. Not a single line of custom code.
Second, we have an audio player that needs to seamlessly loop audio files. I threw together a pretty straightforward implementation of an audio player based on the just_audio library, using the ConcatenatingAudioSource class to ensure that a playlist of a few loops would be treated by the audio engine as one seamless sequence. On Android and iOS, this works beautifully! But on the web, there is a noticeable gap between each segment, my theory being that there's no buffering ahead on web?
So whenever I want to demo the app for my client, I'm forced to present them with a minefield. They can't test, for example, uploading an audio file that then plays back on a loop, because the upload will crash on the platforms on which the player works perfectly, but the player doesn't work perfectly on the platforms where the upload doesn't crash.
I of course would appreciate any insight anyone has for either of these two specific issues, but more broadly, since there are many other little issues, I would like to know how much of a priority feature parity across platforms is to FlutterFlow's development team? In other words, if I'm patient, might I hope that informing FlutterFlow when certain features have platform-specific bugs or quirks after cross-compilation would lead to those bugs being fixed?
Or will developing on FlutterFlow always be a whac-a-mole game where I just have to try all of the different ways that something can be coded in Dart, until I stumble on a combination that just happens to not have bugs in any of the three platforms after cross-compilation?
Because if that's the case, I'm probably better off just maintaining a few different codebases, or switching to React Native or something. We all want FlutterFlow to work out, but the number of platform-specific bugs turning up in QA has us all feeling like the promise of FlutterFlow being an effective tool for building stable cross-platform apps doesn't really match up with the reality.
But if it's a matter of alerting FlutterFlow when these issues arise, and letting their dev team slowly but eventually fix these bugs for me, we could live with that.