Differences between figure and uifigure (R2025a onward)

Now that Java graphics are gone starting in R2025a, is there any strict distinction between figure() and uifigure()? Some default settings are different, but these can be easily changed later on. For example, one can enable handle visibility in a uifigure to use standard plot functions. Objects created with either function have the same class (matlab.ui.Figure), and it seems like various tools (such as exportapp) have been updated to support both.

The only difference I have found thus far is that figures have a new toolbar whereas uifigures retain a more minimalist form. Even after enabling Toolbar/Menubar in a uifigure, the result is closer to a more traditional MATLAB figure. Personally, I find the new figure toolbar hideous.

For some years now, the advice has been to use uifigures for "apps" and figures for plotting. If this is how figures are going to look from here on out, I will be doing everything in uifigures.

Answer 1

[Adam Danz]

General purpose of uifigure and figure

Figures created using the figure function are configured for data exploration and visualization, while figures created using the uifigure function are configured for app building.

Difference between uifigure and figure

The difference between figures generated by uifigure and figures generated by figure has greatly decreased since R2016 when uifigure was released. As of R2025a, several key differences remain, hightlighted below.

See also the summary table in Differences Between Figures Created Using figure and uifigure in the documentation.

The figure toolstrip

Figures generated by the figure command display the new figure toolstrip (R2025a). The figure toolstrip is loaded with a lot of helpful features. If the toolstip is not desired, you can turn it off.

fig = figure(MenuBar="none");

However, this generates a figure outside of the new figure container environment thus opting-out of the performance enhancements delivered by the new environment. Toolstrip functionality such as plot edit mode and the property inspector will also not be available.

Current figure and HandleVisibility

Figures created using the figure command have HandleVisibility set to on and can therefore become the current figure by default (gcf), whereas figures created using uifigure have HandleVisibility set to off and cannot.

Docking behavior

Figures generated by uifigure are not docked to the figure container whereas figures generated by figure are. To generate a figure using the figure command that isn't docked to the figure container, set WindowStyle to normal.

figure(WindowStyle = "normal")

% alternatively,

figure(DockControls="off") % turns off ability to dock the figure

Additional information

Follow the Graphics and App Building Blog for an upcoming series of articles on this topic and please let us know if you're searching for any related information.

[Dan Dolan]

@Adam Danz How does MATLAB distinguish the origin of figure object? If I turned off the menu bars of a figure and turned on handle visibility in a uifigure, the two objects could be made to look very like one another. Clearly MATLAB knows the former could have a toolstrip while the latter cannot, as well as the differences in docking behavior.

When you say "opting out of the performnce enhancements...", does this mean that graphics are rendered more quickly in a figure than uifigure? Or does this just mean the user does not have the access to the toolstrip features?

[Walter Roberson]

@Dan

As of R2025a, figure() contain the following fields not present in uifigure():

AutoListeners__

CodeGenerationProxy

FigureCodeGenController

FigureToolstripStateListeners

MOLToolstripMggId

MOLToolstripShowCodeButtonStateListener

ModeManager

As of R2025a, uifigure() contain the following field not present in figure():

isUIFigure

[Dan Dolan]

@Walter Roberson That is a very useful observation. The metaclass function returns the same number (281) of properties for both figure and uifigure, but objects converted to a structure have a different number of fields (293 for figure, 287 for uifigure). The extra fields must get added dynamically after object creation.

The most obvious distinction is the presence or absence of isUIFigure, which works with isprop but does not show up with metaclass. Your comment largely answers my question, albeit with undocumented properties in an evolving graphic system. Any comments @Adam Danz? Will there always be two distinct figure types?

[Adam Danz]

> how to programmatically distinguish between figure and uifigure

This question has surfaced numerous times over the years. Look---here's a thread that's been active for 7 years and contains content from me as a user (prior to working at MathWorks).

https://www.mathworks.com/matlabcentral/answers/348387

Some of that thread is no longer relevant in R2025a as undocumented functions or properties have changed. One of my responses attempts to combine various methods that work in a subset of releases.

There is no publicly facing programmatic means of identifying the source of the figure (figure vs uifigure) and there currently is no plans for removal of either function.

It would be helpful for you to contact tech support and share your need for a means of programmatically distinguishing between figure and uifgure along with use cases that motivate the need for such a feature.

[Adam]

So are we basically not 'supposed to' use a uifigure from the command line to e.g. just plot some data?

That would explain two of my irritations with uifigure at the moment, the first being that if I just create one without assigning its handle to a variable, in command window, I don't know how to get hold of it again, because gcf does not pick it up (obviously in proper code I always keep handles of graphics objects if I intend to access them again later, but for quick command line testing of ideas and code syntax I regularly use gcf/gca type functions).

The 2nd is something that seems to be ever more pervasive in Matlab, though I can't work out what has actually changed in other cases, which is that when I create a uifigure from the command window it grabs focus so I have to then click back on the command window to input my next instructions (old-style figure does not do this), which is very annoying (I feel as though this same 'focus grabbing' behaviour has changed when hitting breakpoints in code too, where the editor takes the focus instead of the command window, though that is not relevant here to uifigures, just that it is similarly infuriating behaviour that I feel didn't used to happen as much, anecdotally!).

When I'm creating an app, I will often switch to command window just to try some stuff out, so that is when I often explicitly create a uifigure rather than a figure, only to realise I forgot to assign its handle, which is when I find I can't get hold of it again to add components to.

[Dan Dolan]

The answer to your first irritation is simple.

fig=uifigure('HandleVisibility','on');

This allows function like gcf/gca to see the uifigure. A slightly fancier command:

fig=uifigure('HandleVisibility','on',...
    'Toolbar','figure','MenuBar','figure');

makes something very much like a classic MATLAB figure. I often tuck one of these into a SimpleFigure function for easy use.

The second irritation is a little tricker. MATLAB has always put newly generated figures on top, and you are correct that this can be a problem. Invoking the commandwindow() function takes you back to the command line, but I find that a slighly delay has to be added between to allow MATLAB to create the new figure.

>> fig=uifigure('HandleVisibility','on');pause(1);commandwindow();

Obviously this is not ideal. Pusing figures to one side of the display:

movegui(fig,'northeast');

can keep the command line visible (I usually keep mine on the left side), but once again the focus remains on that new figure. You could combine the two if that arbitrary, and probably system dependent, delay doesn't bother you.

[Walter Roberson]

findall(groot, 'Type', 'figure')

allows getting handles to uifigure .

On the other hand, if you have several uifigure, it might not be obvious which one is which.

By the way, one way to tell a figure() from a uifigure() is to check to see whether double() of the figure handle is an integer. figure() that you create in your code default to having integer handles (but figures created on your behalf such as bode plot, might not have integer handles.)

[Adam]

Yeah,

fig=uifigure('HandleVisibility','on');

does work, but then if I'm in 'thinking mode' anyway to store the handle like that I don't need gca/gcf, I just have to remember that I can no longer just lazily do stuff like:

figure;
...
gcf

to access the figure I created before (or just clicked on to make it active), when I use a uifigure instead. A lot of these things just come down to having to change habits ingrained over almost 20 years of working with Matlab, so it takes a while!

Answer 2

[the cyclist]

According to the Limitations section in the uifigure documentation, one cannot use the print() function on a uifigure.

[Dan Dolan]

That is interesting because another documentation page suggests that print can work on uifigures, and certainly seems to my Mac in R2025a. Either way, how does one determine if a given handle was created by figure or uifigure? Hypotehically, one could use try/catch blocks if there are commands that work on one type and fail on the other, but presumably MATLAB knows the answer behind the scenes. If nothing else, it has to know that figures can be docked into central container but uifigures cannot be.

[Adam Danz]

Thanks for pointing out the discrepancy beteween those documentation pages. Investigating.