What would it take to develop a “perfect” UI development tool for mobile apps?

Osman CELIK
3 min readSep 12, 2020

For more than 10 years now, we have worked in developing mobile app development products with a UI development tool.

We thought that we can contribute to the Flutter ecosystem with our experience so we took on the task of searching the market for visual design aids or UI development tools for Flutter app development.

Developers’ Stance on Visual Design Aids/UI Development Tools for Mobile Apps

However, even before going through the state of the market, we see that the developers are reluctant to use such tools even if they are provided by the frameworks themselves. Gaining the acceptance of developers is even tougher for third-party UI development tools.

Some developers are highly against visual design aids with high skepticism. Some developers are more embracing but they also have concerns. It’s very rare to see the developers use such tools without any reservations.

By the way, don’t forget to share your opinions on this subject in the comments.

The State of the UI Development Tools in the Flutter Ecosystem

When we looked at the vivid Flutter ecosystem, we saw that there are only a few attempts on providing facilitators for UI development.

This handful of tools are mainly divided into two categories:

  • Visual design to code export tools such as Adobe XD, Supernova
  • Drag&drop screen/widget designers such as Flutter Studio or Widget Maker

Looking at these tools in-depth, we observed the following points:

Visual design to code export tools

  • Require the design files to be perfect with best practices (e.g. using symbols or dedicated components)
  • Do not produce clean code — the code requires so many changes in complex designs that the developers may be better off by coding it from scratch
  • Cannot create pattern-specific code — if you have a specific development pattern in mind (e.g. MVVM or MVC) the generated tool may require rework to be suitable for that development pattern
  • Have difficult maintenance workflows, so they are usually utilized for the initial design (e.g. even when something small changes in the design, you may need to export the full project).
  • Have limited extensibility — similar to the item above, when you extend the design from the code for some reason, it cannot be reflected back to the design file exactly in the same way, so as the project progresses, the design file and the generated code may have discrepancies with the actual code, causing conflicts.
  • Lack the awareness for:
    - Theming — it is challenging to manage multiple configurations such as dark and light
    - Frameworks — custom objects and components require manual effort
    - Atomization — see below

Actually, the atomization seems to be the main point of the issues. If the generated code is sufficiently atomized, then the developers would have higher flexibility in using the generated code, but right now, the produced code is too generic and “whole”. You cannot cherry-pick easily due to the limited extensibility and scalability.

This is because the process is unidirectional (one-way) from design to code and any changes made in the code has a conflict potential.

For this purpose, such tools seem to be more suitable for use cases like

  • Prototyping
  • “Quick and dirty” apps
  • Learning app development

We would appreciate it if you can challenge us with your experience or confirm our findings.

The second category of screen/widget designers contained a few tools, but they were all in a proof-of-concept stage or only useful to develop a very small portion of an app, so these also struggle with atomization in the sense that everything is too disconnected.

The primary reason for this seems to be that these were very early attempts that predates Flutter Web, so it was a challenge to develop a WYSIWYG experience.

With Flutter Web, a bidirectional (two-way) UI editor seems possible, so that you can switch between code and the UI design freely. This has the potential to alleviate some of the concerns related to the code export tools.

So it makes sense to focus on developing a bidirectional Flutter UI development tool, but the main questions still linger:

  • Why are the current tools not preferred by the majority developers? (If not, why does it seem that way?)
  • What would be the expectations from the “perfect” drag&drop or code export UI development tool?
  • Would you use a bi-directional and properly atomizing tool?
  • What would it take to use such tools? Or is it a pipe dream?

What do you think about it? Share your opinions in the comments or just reach out to me.

--

--

Osman CELIK

Product guy and tech entrepreneur, 20+ mobility experience, father, motorcycle fan