Visual Designer, Hot Reload and Beyond

In the last couple of years we’ve seen a massive spike in interest around “Hot Reload” thanks to the popularity of frameworks such as React/React Native and more recently, Flutter. The goal of Hot Reload is to allow developers to iteratively change their application code, whilst debugging their application – this cuts down considerably the debugging loop, since the application doesn’t need to be restarted after each change. For example, making a change to a Flutter app might be deployed inside the running application in less than a second; if the application had to be restarted it may be 20-60seconds. Further more, any state associated with the application would have to be recreated after the application was restarted. In this post, we’re going to compare the Hot Reload experience to that of using a visual designer, and the direction that app development tooling is going.

Visual Designer

Let’s back up a little and discuss the history surrounding visual designers. If you look at most app development platforms (excluding web), there is typically some form of a visual designer. For example, WinForms, WPF and UWP all have a visual designer where you can drag and drop elements in order to layout controls and pages. Visual Studio even ships with a companion tool called Blend, that’s specifically tailored to making it easier to design XAML based pages. Designers aren’t just a Windows thing; XCode and Android Studio both have designers for building apps for iOS and Android respectively.

Visual Designers are great if you happen to build developing applications for a single platform. However, if you’re using technologies such as React Native, Flutter, Xamarin.Forms or Uno, you’ll notice that there’s a distinct lack of designer support. As you can imagine, building a designer that is able to render the application running on each of these platforms would be remarkably difficult – due credit to the Xamarin.Forms team that did in fact have a designer that worked for iOS and Android.

As applications are increasingly build for multiple platforms, the lack of a visual designer meant that the developer cycle for building the user interface of an application became painfully slow. Not only did you have to restart the application every time you made a change, you also had to run the application across a variety of device types and sizes, to ensure your application looked and behaved correctly.

Further to the lack of designer support for cross platform, it was also very evident that even when building for a single platform, developers that were familiar with the platform would often bypass the designer in favour of had crafting the layout. In the case of the Windows platform (inc Xamarin.Forms and Uno) this maeant hand crafting XAML, which is both laborious and verbose.

In the case of Windows, as much of the design capabilities of Blend were added into the core Visual Studio product, there was an increased emphasis on getting XAML intellisense to work. This meant that at least the coding experience of writing XAML was more efficient.

One last note before we move on is that Microsoft invested heavily into Blend as an external designer oriented tool. However, this was largely a failure, not because the product wasn’t great or didn’t work, but because it lacked a target market. It wasn’t a design tool, in the traditional sense of Photoshop; nor was it a developer tool (as it didn’t have half the features of Visual Studio). The complexity of building apps using Blend, and specifically the complexity of templates, visual states etc, in XAML, meant that there was low uptake from designers, and developers preferred to stay in Visual Studio where they were at home.

The upshot is that visual designers don’t seem to be delivering on the value proposition of making it easy for developers to create the layout of their application.

Hot Reload

At this point let’s talk a bit more about Hot Reload – the goal is that in an ideal world you should be able to hit run/debug within the IDE that you’re using; the application will launch with the debugger attached, and then you can progressively make changes to your application. The ideal is that you can make any valid change to your application, and for the application to continue running, without losing any state. The reality is far from this. What typically happens is that there’s a limited set of changes you can make, often UI related, where hot reload works well. There’s another set of changes, eg adding files, renaming classes, methods, adding package references, that don’t always reload properly. This varies between technology but the upshot is that it’s far from the sales pitch of just running the application once.

The argument in favour of hot reload is that even if it only works say 50% of the time, isn’t this better than not having hot reload? And the answer is yes, definitely, and I think hot reload delivers significant benefits to app developers making it much quicker to iterate design changes.

In that case, what’s the issue – well the issue is that when hot reload doesn’t work, it generally leaves the developer scratching their head as to why their change isn’t propagating to the app. Often there may be no error output or highlighting indicating that there is an issue.

Ironically, often the issue with hot reload not working is that the developer has made some syntactical error which means the code won’t compile (and thus the app can’t hot reload). Wouldn’t it be nice if we could reduce the chance of this happening…. perhaps with say a designer….

Beyond Hot Reload

Now don’t get me wrong, I’m not advocating that we go back to having a visual designer. In recent times I’ve often campaigned against the likes of the Xamarin.Forms team from investing further into their designer experience. However, there must be a way that we can take aspects from tools like Blend and integrate them into the hot reload experience.

What I’m really talking about here is that the next generation of UI development tools will be around augmenting the running application using similar drag and drop metaphors that tools like Blend used.

For example, imagine that I have my running application and that I can simply drag a new control onto my running application and immediately start altering properties using the familiar Properties tool window.

This would work well for Windows/MacOS applications that operate in a multi-window environment but what about building iOS or Android applications. It’s not practical to augment the experience in those apps with control and/or property pickers. Instead, the tooling will need to make use of some form of application mirroring back into a design surface in the IDE – similar to how the iOS remote simulator that’s available for Xamarin developers works, or any other remote access tool, that’s capable of mirroring what’s on the screen. The following mockup shows a Windows application being mirrored into a design surface but the same concept could be extended to support iOS, Android and other platforms.

Summary

In the cross platform development space we’re gradually getting to the point where the offerings are sufficiently mature that developers can build apps that target the major platforms, iOS, Android, Windows, MacOS, without having to resort to writing much platform specific code, or having to rely on different technologies. The investments by both Google (Flutter) and Microsoft (Xamarin) will help drive better productivity through tooling such as Hot Reload, Live visual tree and property windows, and other technology specific tooling.

The next wave if developer tooling for app developers needs to focus on interactively building the user experience. This is where the separation between UI and code, for example offered by XAML, is important. In order to implement a truly interactive design experience, the tooling needs to be able to round trip the layout code, without affecting any custom logic the developer may have added.