Desktop development is where Flutter will grow up

By: Herodion Victor Momoh

Last year, I spent three weeks trying to get a floating window to stay on top of other applications on a Mac.

That is the kind of problem a typical macOS developer can probably solve during a lunch break using native development tools. With Flutter, it became a much more complicated exercise.

Flutter is an open-source software development framework created by Google that allows developers to build applications for multiple platforms from a largely shared codebase, rather than writing an entirely separate application for each platform. That cross-platform capability is one of its biggest attractions.

Or at least, that is what Flutter promises.

However, there is a gap between what cross-platform development promises and what desktop software actually demands. That gap became particularly clear to me while building PraxiByNC, a timer application for lawyers.

First, it is important to acknowledge the advances Flutter has brought to software development. The framework’s central proposition is simple: write much of your application once and deploy it across phones, tablets and computers without having to rebuild everything separately for each platform.

Before tools such as Flutter became popular, a small startup that wanted both an iPhone and Android application might have needed separate development teams or would have had to build and maintain much of the same product twice. Flutter made that process considerably more efficient.

But a phone and a laptop are not the same kind of tool. Neither are the things people expect to do with them.

When people sit down at a laptop to work, their expectations are different from when they are casually using a phone. Desktop users expect to resize and rearrange windows, work across multiple applications, connect multiple monitors and interact with features that are deeply integrated with the operating system.

This is where cross-platform frameworks can encounter limitations.

Flutter is particularly good at rendering an application’s interface within its own window. But some desktop applications require much more than drawing an interface. They need to interact with the operating system and respond to events happening outside the application’s own window.

I discovered this while building PraxiByNC, a timer application for lawyers. Lawyers often track billable time in precise six-minute intervals. For an application like this, it is not enough to know that the timer is running. The software may also need to know which application the user is working in and respond when that context changes.

That requirement pushed me beyond Flutter’s standard application layer and into the native operating system.

The challenge is not that Flutter is incapable of communicating with the operating system. It can do so through platform-specific integrations and method channels. The challenge is understanding where Flutter’s cross-platform layer ends and where native operating-system code has to take over.

It is a bit like asking someone to describe what is happening in the room next door without giving them a direct line of sight. Flutter can make the request, but the operating system often has to provide the information.

That distinction helped me understand what was happening.

Imagine two people talking through a small slot in a wall. On one side is Flutter, doing what Flutter does. On the other is Swift, Apple’s programming language for developing software that runs natively on its platforms.

The slot is a method channel.

Flutter can pass a request through the channel, Swift can process it using native APIs, and the result can come back to Flutter.

That works well when the application needs to ask a question and receive an answer.

PraxiByNC, however, needed something more continuous. The application needed the operating system to report changes as they happened, rather than waiting for Flutter to ask for them.

Once I understood that distinction, several things became clearer. The native side of my application could monitor information provided by macOS about running applications and then forward relevant changes to Flutter in real time.

That brings me back to the floating-window problem.

Keeping a window pinned above other applications requires access to a macOS window-management feature that is outside Flutter’s ordinary UI layer. The native side of the application has to make that change using Apple’s APIs, in my case through Swift.

But this does not mean Flutter disappears from the equation.

Under the hood, the application still has a standard macOS window, while Flutter is responsible for rendering the interface inside it. The two layers can communicate while the application is running. Flutter can effectively ask the native side to change a window property, and the native code can make that change at the operating-system level.

When something goes wrong in that sequence, however, the resulting behaviour can be difficult to diagnose. In my case, troubleshooting the floating-window problem took three weeks.

This is not to say that Flutter is the wrong tool for desktop development. It is not.

Rather, developers building desktop applications with Flutter need to understand where Flutter’s responsibilities end and where the operating system’s responsibilities begin. The distinction matters because desktop software often depends on capabilities that cannot be abstracted away completely by a cross-platform framework.

That, for me, is the bigger issue.

Much of what I learned while building PraxiByNC, I learned the hard way because I found relatively little documentation that explained these desktop-specific challenges in a practical, end-to-end way.

There are plenty of resources explaining the basics of Flutter. What I found less often were practical guides to building applications that have to run reliably for hours, work across multiple monitors, respond to operating-system changes and behave consistently for users who cannot afford unpredictable software.

The optimistic part is that Flutter continues to evolve.

What has not always kept pace, in my view, is the broader understanding of what desktop software demands from an engineer.

The drawback is not necessarily Flutter itself. It is the collective misunderstanding of what desktop development requires.

Until that understanding catches up, developers may continue building Flutter applications that look at home on a Mac but do not always behave like applications designed specifically for the Mac.

Closing that gap is the conversation the Flutter community needs to have more seriously.