Arduino® App Lab: check what travels with your board app

Arduino Team, App Release introduction dialogue, CC BY-SA 4.0. Original file unchanged. Original announcement. Licence. Actual Arduino-supplied App Release introduction dialogue in the 22 October 2026 App Lab 0.11 announcement. Its product wording describes the intended workflow; current documentation still specifies board, dependency and installation requirements. The capture build/date is unstated. This is not a PING test or a screenshot of App Lab 0.12.0. Arduino® is a trademark of Arduino S.r.l.; no endorsement is implied.

A board app that works on a maker's desk still needs a clear handover. Is the other person meant to edit the project, or run a fixed version? Arduino App Lab gives those jobs different packages. Understanding what travels inside each one is useful before sending a classroom demonstration, a workshop project or an installation to another board.

Arduino introduced App Releases in its App Lab 0.11 announcement on 22 October. The corresponding GitHub release was published on 23 October. Checked on 6 November, the main download page labels App Lab 0.12.0; this guide is not announcing a new release or treating 0.11 as the latest version. It follows the current documented handover workflow. October announcement · Current downloads.

Choose an editable project or a fixed release

The current Manage Apps documentation describes Export App as a way to back up code or share it in a ZIP archive. The export dialog offers an option to include data associated with the app. Importing a valid archive adds the project and its files, Bricks and sketch libraries to the receiving app library. Choose this route when the recipient needs to continue development. Manage Apps reference.

An App Release instead uses an .ard file. The documentation describes a packaged, read-only version, built for a chosen board type, with the Python environment and Brick container configuration resolved. Installed releases can be run; Copy and edit App creates a separate editable copy. The fixed original and the development copy should therefore have different roles in the handover.

Write down the target and prerequisites

The manual limits a release to the type of board selected as its Target: its example says a release built for UNO Q cannot be installed on VENTUNO Q. It also specifies Arduino App CLI 0.14 or later on the board for release creation and installation. A compatible desktop download alone does not establish that the receiving board meets those requirements. PING has not installed App Lab or tested a board.

The package can still need a download

Read the current dependency rules alongside the introductory dialog's simpler product wording. For catalog and Hugging Face models, the .ard file lists what is needed; the required container images and models download during installation or first run. Models trained in the user's own Edge Impulse project are included. Models used by Custom Bricks are neither listed nor included and need separate installation on the target board, according to the manual.

The Install app dependencies option starts those downloads during installation and requires an internet connection. Turning it off postpones the download; it does not remove the requirement. For a workshop, confirm what the receiving board needs before the session. Keep the board type, package revision and required external resources beside the handover note rather than promising that one file will work without preparation.

Decide what data belongs in the handover

Review the Include data associated with the App choice before exporting or building a release. A demonstration may need example data without needing a whole working dataset. The documentation separately says installed releases allow changes to secret Brick variables such as API keys. Agree how the receiving team supplies its own configuration instead of assuming that copying a package settles accounts, permissions or access to a model.

Only install releases from a source you trust. Arduino's manual warns that an .ard file can execute commands with full access to the board's system. A read-only application package does not mean the actions it performs have been independently approved. Keep the author, source and intended purpose identifiable when sharing it.

For a maker working between a school in Accra, a workshop in Nairobi and a collaborator in London, the practical questions are specific: which board is receiving the app, who needs an editable copy and which downloads can be completed before the demonstration? These are illustrative collaboration settings, not a claim about regional service availability or measured connectivity. Ask the receiving person to confirm the actual setup.

Keep a development archive, identify the fixed release and record the receiving check separately. These are PING's suggested handover habits, not a guarantee that any particular project deploys successfully. For another maker-file boundary, read PING's Steam Frame CAD explainer.