Another app migrated to Flutter

  • we already have another app in Flutter, and it proved to be useful for us;
  • we have our own design system with Flutter implementation — we can reuse it instead of maintaining a native Android version;
  • we can unify architecture and share some code;
  • we can maintain a single codebase for Android, iOS and maybe even Web/Desktop.
  • the deadline was pretty optimistic (it always is);
  • since it’s a different language, you cannot just use the same tests, so there were regression bugs;
  • be ready for “what the hell is this doing here?” reactions.
  • The kiosk codebase is now 2x smaller. Of course, it’s not just about Flutter being so tremendous and concise (although it is). We could achieve some code reduction even after rewriting to the same language and framework, as it was basically a major refactoring. But it’s still pretty cool to know that we have more platforms to support and less code to maintain.
  • Custom keyboard implementation is much easier. We use a custom keyboard in the app rather than an external system keyboard: for granular control, security and a consistent look and feel. I remember we spent a lot of time explaining to native Android that the input field (despite being enabled and writable) doesn’t need to have the keyboard. In Flutter, it’s just a matter of 2 parameters (readOnly: true, showCursor: true) and providing a TextEditingController with custom functionality. Take a look at this excellent article for inspiration if you need to integrate a custom keyboard into your app.
  • A declarative and functional approach to UI. Without exaggeration, I think this is the best trend in front-end and mobile development of the last few years: 𝑈𝐼=𝑓(𝑆𝑡𝑎𝑡𝑒)
    Yes, now we have Jetpack Compose, so native Android development goes in the same direction. But back then, for our pretty complex registration card screen (that has a lot of dynamic form fields based on the nationality of the guest, the legal environment of a hotel, and a ton of other stuff), we ended up with a scary piece of code that no one wanted to touch. It’s still pretty complex in Flutter, but it is, at least, maintainable.
  • we fully control the deployment process;
  • we can do the “real” CI/CD without waiting for Google Play approval;
  • we can do some intelligent deployment. This “smart deployment” means that we don’t just force an update while a user is in the middle of the session, nor do we wait for the app to be closed (which doesn’t make sense for a single-app kiosk mode). Instead, our Kiosk app and DPC-app communicate with each other. DPC-app notifies Kiosk if the new version is available, and Kiosk notifies DPC-app when it’s ready to be updated (e.g. the current session has ended).
  • we need to maintain the code for the DPC app;
  • we lack some features like remote rebooting and don’t have resources to implement them;
  • as I mentioned, for iOS, we need to implement all this functionality from scratch.
  • wakelock allows preventing the screen from sleeping on Android, iOS, macOS, Windows, and web.
  • hand_signature will enable you to draw smooth signatures with a variety of draw and export settings — and also supports SVG.
  • native_device_orientation — reading device’s native orientation, either from UI orientation or from sensors.
  • kiosk_mode — this is our library for working with Lock Task / Guided Access modes on Android and iOS.



Head of Applications @ Mews

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store