Android modal dialogs and the Delphi question: Are true modal dialogs ever coming back to FMX?

For years, Delphi developers coming from VCL have had to unlearn one deeply ingrained assumption when moving to FireMonkey (FMX): there is no such thing as a truly modal dialog on mobile platforms. No blocking ShowModal, no linear control flow, no “wait here until the user clicks OK”.

What Android Has Always Meant by “Dialog”

Android has supported dialogs since day one. The official documentation is very clear about what these are and, more importantly, what they are not.

An Android dialog:

• Is a UI overlay that blocks user interaction with the underlying activity.

• Is implemented via Dialog, usually AlertDialog, and typically hosted by a DialogFragment.

• Is lifecycle-aware, meaning it can be destroyed and recreated at any time (rotation, backgrounding, process death).

Crucially:
Android dialogs are modal only in the UI sense — never in the control-flow sense.

There is no supported API that blocks the main thread and waits for a dialog result. The Android UI thread must never block. Results are delivered via callbacks. This is not an implementation detail. It’s a core architectural rule of the platform. FMX follows this rule exactly. That’s why:

Form.ShowModal(
  procedure(Result: TModalResult)
  begin
    ...
  end
);

exists on Android — and why classic VCL code like this does not:

if Form.ShowModal = mrOk then
  ...

This isn’t Delphi being awkward. This is Delphi obeying the platform.

What Changed in Android 16 (And What Didn’t)

Now to the DelphiPraxis excitement.

Android 16 introduces desktop-style windowing on large screens:

• Multiple resizable windows

• Title bars

• Overlapping app windows

• Taskbar-like behavior

• Stronger focus and input management

On tablets (and especially Samsung DeX-like environments), apps now behave like desktop applications. When one of these windows opens “on top” of another, it looks and feels like a modal dialog.

That’s what people are seeing — and they’re not wrong visually.

But here’s the key point:

Android 16 does not introduce a synchronous, blocking dialog API.

What changed is window management, not threading semantics.

Under the hood:

• The UI thread is still event-driven.

• Activities and fragments still must not block.

• Dialogs still return results asynchronously.

So when someone says “Android 16 finally has modal windows”, what they really mean is:

Android now allows desktop-like window behavior where a window can visually dominate and restrict interaction with others.

That’s a UX evolution — not a programming model reversal.

The Real Question: Can FMX Ever Return to VCL-Style Modal Dialogs?

Let’s be blunt.

On mobile platforms (Android / iOS): No

Not in the way VCL developers mean it.

Blocking modal dialogs depend on:

• A single-threaded message loop you’re allowed to block

• A stable process lifetime

• No forced destruction/recreation of UI objects

Mobile platforms explicitly reject all of that.

If FMX were to fake synchronous modal dialogs on Android, it would require:

• Nested event loops

• Reentrancy hacks

• Undefined behavior during lifecycle events

• Crashes during app suspension or rotation

That would be irresponsible framework design. Embarcadero is unlikely to ever do this — and they’d be right not to.

On desktop platforms using FMX: Maybe — but it’s complicated

This is where Android 16 does matter philosophically.

FMX is a single framework spanning:

• Windows

• macOS

• Linux

• Android

• iOS

Because of that, FMX deliberately adopted the lowest common denominator UI model: async, non-blocking dialogs.

Android’s move toward desktop windowing raises an interesting possibility:

Could FMX offer true synchronous modal dialogs on desktop targets only, while keeping async behavior on mobile?

Technically? Yes.
Architecturally? Painful.
API-wise? Dangerous.

You’d end up with:

• The same FMX call behaving synchronously on Windows

• Asynchronously on Android

• Subtle bugs when code is ported

• Conditional logic everywhere

That’s exactly the fragmentation FMX was designed to avoid.

The More Likely Future for Delphi FMX

Here’s the realistic outlook:

1. FMX will stay async-first.
   That decision is baked into its DNA now.

2. Android desktop mode may allow richer FMX window behavior.
   Multiple forms, floating tool windows, better tablet UX — this is where Android 16 helps Delphi the most.

3. VCL will remain the king of true modal dialogs.
   If you want blocking dialogs, linear control flow, and compiler-enforced discipline — VCL is still the right tool.

4. The gap will not close — it will be formalized.
   FMX is not “VCL on mobile”. It’s a different model, and Android 16 doesn’t change that, it just makes FMX less visually constrained on tablets.