Building Apps with App Designer

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production.

The reference material consulted while preparing these pages is listed in the section bibliography.

Written against MATLAB R2026b. App Designer and the ui functions need the MATLAB desktop (or MATLAB Online) and a display; GNU Octave has neither App Designer nor uifigure, so none of the code on this page was run. Every listing is marked "not run here" and is checked against the R2026b documentation instead. A small snippet that only builds a numeric array was run in Octave 11.3.0 where the page says so.

An app is a self-contained interface that performs operations in response to user actions: pressing a button, moving a slider, choosing an item. This page covers how to build one, with the interactive App Designer and with code, how callbacks tie the interface to your functions, what to use in place of the removed GUIDE, and how to test and share the result. The running example is a small viewer for the heatflow temperature field.

Ways to build an interface

The documentation separates two kinds of interface and, for apps, two ways to build them.

Kind Built with Main file

App

Interactively with App Designer, or programmatically with MATLAB functions

.mlapp (binary app file) or, since R2026b, an app code .m plus a configuration .xml (plain text app file); programmatic apps are .m script, function or class files

Live Editor task

Programmatically as a subclass of matlab.task.LiveTask, or by converting a selection of a live script that contains code and controls (since R2023b)

.m class file

App Designer, introduced in R2016a, is the environment the documentation recommends for building apps. It includes a version of the MATLAB Editor, links the layout and the code so that a change in one view updates the other, offers a larger set of components than older tools (date picker, tree, image and others), a grid layout manager and automatic reflow of the layout when the screen size changes. The programmatic way gives more control over the structure of the code, and it is the way to choose when the interface must be generated by code, versioned as ordinary functions or placed in a package. Both produce the same modern components, because the programmatic route uses uifigure, which the documentation names as the recommended function for new apps, while figure is the older container with its own component set. Tasks are covered in Live Scripts and the Live Editor.

Source: MATLAB documentation: Ways to Build Apps

App Designer

Open it with the appdesigner command or from the Apps tab. It has two views of the same app:

  • Design View: the canvas on which you drag components from the Component Library, a Component Browser and an inspector for properties. A grid layout (uigridlayout) positions components in rows and columns and lets the app resize.

  • Code View: the code editor. Code that App Designer generates is shaded and cannot be edited; the code you add (callbacks, helper functions, properties) is editable.

The components include containers (panels, tab groups, grids), common controls (button, edit fields, slider, spinner, drop-down, list box, check box, switch), axes for plots, a table, a tree, an HTML component and dialogs. The documentation gives an overview in App Building Components. For graphics, an app uses uiaxes instead of a classic axes, and the plotting functions accept the axes as their first argument: surf(ax,T), imagesc(ax,T), plot(ax,x,y).

An app made in App Designer is a MATLAB class that derives from matlab.apps.AppBase. The abbreviated shape of the file (illustrative; the generated file has more sections, and its exact contents depend on the release):

classdef HeatflowViewer < matlab.apps.AppBase

    properties (Access = public)
        UIFigure    matlab.ui.Figure
        Slider      matlab.ui.control.Slider
        UIAxes      matlab.ui.control.UIAxes
    end

    properties (Access = private)
        History     % n-by-n-by-nSteps array of fields
    end

    methods (Access = private)
        function startupFcn(app)
            % runs after the components are created
            app.History = rand(20,20,10);
            app.Slider.Limits = [1 size(app.History,3)];
            drawField(app, 1);
        end

        function SliderValueChanged(app, event)
            drawField(app, round(app.Slider.Value));
        end

        function drawField(app, k)
            imagesc(app.UIAxes, app.History(:,:,k));
            title(app.UIAxes, "Step " + k);
        end
    end

    % component initialisation and app creation and deletion are generated
    % by App Designer (createComponents, the constructor, delete)
end

Not run here. Points to take from it:

  • The app object (app) is passed to every callback and holds the components and any data you add as properties. App Designer uses a handle class (see Value and Handle Classes), so a change to app.History in one callback is visible in all the others. This is the usual way to share data inside a single app.

  • The startup function (startupFcn) runs after the components exist; it is where input arguments to the app are used and initial data is set. Startup tasks and app input arguments are documented under Program App Behavior.

  • Callbacks are methods that App Designer wires to component events. Add one by right-clicking a component in Design View, or in the component’s Callbacks list. A callback receives the app object and an event data object whose fields depend on the component; for a slider the new value is in event.Value for ValueChangingFcn, and the stored value is in app.Slider.Value after ValueChangedFcn.

  • Helper functions can be added in Code View, with private access, so that several callbacks reuse the same code.

Running the app is a matter of pressing Run in App Designer, or calling the app by name (HeatflowViewer) from the command line once the file is on the path.

Source: MATLAB documentation: Develop Apps Using App Designer

App file formats

The default file type is the binary .mlapp, which holds the layout and the code in one file. Since R2026b App Designer can save an app in a plain text format made of two files, an app code file (.m) and an app configuration file (.xml); both open in App Designer and in other editors. The motivation is the same as for live scripts: line-based comparison and merging under source control (see Projects and Source Control). If you keep .mlapp files in Git, register them as binary files, and use App Designer’s Compare and Merge tools (found under the Compare and Merge Apps topic) rather than a text merge. Settings and keyboard shortcuts are under App Designer Settings; compatibility between releases of App Designer is explained under Compatibility Between Different Releases of App Designer, so check it before sharing an app with colleagues on older releases.

Programmatic apps

A programmatic app is code that creates a uifigure and adds components to it. The functions you need most:

Function Role

uifigure

Creates the container window (the recommended figure type for apps).

uigridlayout

A grid layout manager; set RowHeight and ColumnWidth to fixed sizes, "fit" or weighted values such as "1x".

uiaxes

An axes for plots inside an app.

uibutton, uislider, uieditfield, uidropdown, uitable

Components; each is created with the parent (figure, grid or panel) as its first argument.

uialert, uiconfirm, uiprogressdlg

Dialogs and notifications.

A name-value pair such as ValueChangedFcn=@(src,event) connects a callback to an event. The documentation topics Create Callbacks for Apps Created Programmatically, Share Data Among Callbacks and Lay Out Apps Programmatically cover the options. Three ways to share data in a programmatic app are nested functions that share the variables of the enclosing function (shown below), a handle object passed to the callbacks, and the figure’s UserData/appdata; prefer the first two.

A field viewer for heatflow, written as one function file with a nested callback:

function fieldViewer(history)
%FIELDVIEWER Browse the temperature field of a heatflow run.
%   fieldViewer(history) shows history(:,:,k) as an image and lets the
%   user choose the step k with a slider.
arguments
    history (:,:,:) double
end
nSteps = size(history, 3);

fig = uifigure(Name="Heatflow field viewer");
grid = uigridlayout(fig, [2 1]);
grid.RowHeight = {"1x", "fit"};

ax = uiaxes(grid);
slider = uislider(grid, Limits=[1 max(nSteps,2)], Value=1, ...
    ValueChangedFcn=@(~,~) draw());

draw();

    function draw()
        k = round(slider.Value);
        imagesc(ax, history(:,:,k));
        colorbar(ax);
        title(ax, "Step " + k + " of " + nSteps);
    end
end

Not run here. A few points: arguments validates the input like in any function (see Argument Validation); draw is a nested function (see Local, Nested and Private Functions) so it sees slider, ax and history without any data-sharing machinery; the slider needs its upper limit larger than its lower, hence max(nSteps,2); and the callback uses the tilde placeholders (@(~,~)) because it ignores the source and event inputs. The end for fieldViewer is required because a nested function is used, which forces every function in the file to be closed with end.

The input is just a numeric array, and a snippet can make a test history in base MATLAB. The array building is the only part that can run without a display; the call to fieldViewer cannot. Run in Octave 11.3.0 (the fieldViewer call is left out):

history = zeros(5, 5, 3);
for k = 1:3
    history(:, 1, k) = 100;
    history(2:4, 2:4, k) = 10 * k;
end
disp(size(history))
disp(squeeze(history(3, :, 3)))

Octave 11.3.0 output (MATLAB layout may differ):

   5   5   3
   100    30    30    30     0

Source: MATLAB documentation: Develop Apps Programmatically

App Designer or code

Aspect App Designer Programmatic

Layout work

Visual, with a live canvas

By hand, with uigridlayout

Code structure

A generated class, with the generated part shaded

Whatever you write: function, script or class

Source control

.mlapp is binary; the plain text format (R2026b) is text

Plain .m files

Reuse

Custom UI components and helper functions

Ordinary functions and classes

Many teams build the layout in App Designer and keep the numerical code in separate functions that the callbacks call (for heatflow, a callback calls heatflow.Simulation rather than containing the stepping code). That keeps the logic testable without a display. App Designer’s guidance on organising data with classes follows the same line: separate the algorithm from the interface.

GUIDE has been removed

GUIDE, the older drag-and-drop tool that produced a .fig file and a code file, was removed in R2025a, together with the guide function. Existing GUIDE apps still run, but you can no longer edit them in the drag-and-drop environment. The release notes recommend one of three routes depending on how often the app changes:

Situation Recommendation

Ongoing development

Migrate the app to App Designer with the GUIDE to App Designer Migration Tool for MATLAB (a File Exchange tool).

Occasional editing

Edit the app code file that GUIDE created.

Only running

Keep running the app.

A figure-based app that uses figure and uicontrol is an older style; the documentation has a topic on updating such apps to use uifigure, because the two figure types support different components and properties. Older books describe GUIDE and uicontrol extensively; use them for reading existing code, not for new work.

Source: MATLAB release notes (the removal is announced under R2025a; the GUIDE Migration Strategies topic was not reachable at the address tried)

Testing apps

The documentation has a Test Apps topic for programmatic testing of apps (App Designer apps and programmatic apps). The details were not checked for this page. A general approach that works without a display: keep the logic in functions and test those with matlab.unittest (see Unit Testing with matlab.unittest). Interface tests need MATLAB with a display or a virtual display in CI (see Continuous Integration). Not run here.

Sharing apps

  • Hand over the files. Send the main interface file and the supporting files (for an .mlapp, the one file, plus any functions it calls, which must be on the path).

  • Package it. App Designer can package an app into an installer file directly from its toolstrip, and a package (a .mltbx file, see Packages and the MATLAB Package Manager) can bundle apps with their dependencies and examples.

  • Deploy it. A web app that runs in a browser, or a standalone desktop application, requires MATLAB Compiler. That product is outside the base MATLAB documented here; see Toolboxes and Add-On Products.

Pitfalls

  • Mixing figure types. figure and uifigure support different components and properties; do not add uicontrol objects to a uifigure, and use uiaxes rather than axes there.

  • Editing generated code. In App Designer the shaded code is generated; make changes through Design View or the inspector.

  • Binary files in source control. A merged .mlapp is unreliable. Use the plain text format (R2026b), or work on one copy at a time.

  • Long callbacks block the interface. A callback that runs for seconds freezes the app; use a background pool (see Background and Asynchronous Execution) and the Interrupt Callback Execution options.

  • Logic inside callbacks. Code in callbacks cannot be tested without the interface; move it to functions.

  • Releases. An app saved in a newer App Designer may not open in an older one; see the compatibility topic before sharing.

Where older books differ

Davis (MATLAB Primer) and similar books teach GUIDE and low-level uicontrol, uimenu and callback strings on classic figures. GUIDE has been removed (R2025a) and App Designer, with uifigure, is the recommended route since R2016a. The older figure based interfaces still run but are no longer the model to copy.

See Also

References