SupportApp: a menu bar app for Mac users and their help desks

What the menu bar app is for

Support App is a macOS menu bar app, and the README describes it as designed to assist organizations in three ways.

The first is user and help desk support. The app gives users and help desks easy access to basic diagnostic information, which the README says enables them to proactively address and resolve minor issues efficiently. That is the core use case: a user opens the menu, sees the state of the machine, and fixes a small problem without raising a ticket that a technician has to triage.

The second is access to support channels and resources. Users can reach support channels and company resources such as websites, applications and file servers through the app. In other words, the app is also a directory, and for many staff the only directory they will actually use.

The third is that it is a modern, native macOS application, with a visually appealing native experience that incorporates the corporate identity. The last part is the one that matters commercially. A support app that looks like the rest of the tooling an organisation has already branded is adopted, and one that looks like a third-party utility is not.

The screenshots in the repository show a light and a dark hero image, and the badge in the README shows SwiftUI with a macOS 14 minimum.

The application was publicly released in 2020, and the README states that it has since become a popular tool used within organisations all over the world.

Who builds it and what surrounds it

Support App is developed by Root3, an organisation specialised in managing Apple devices, based in Halfweg in the Netherlands. Root3 provides managed workplaces, consultancy and support services, and runs an App Catalog for third-party macOS app patch management, with the stated aim of helping organisations get the most out of their Apple devices and improve their security.

That context explains the shape of the application. It is not a consumer utility and it is not a general-purpose help desk. It is one piece of a managed Apple estate, built by the kind of consultancy that runs those estates for a living, and it addresses the problem that in a managed environment the people who need help are not the people who can install anything.

The documentation lives in the repository's wiki rather than in the README, which is the usual arrangement for a project with a long history and a user base of administrators rather than developers. The community around it is the Mac Admins Slack workspace, with a dedicated support-app channel, and GitHub issues for defect reports and feature requests.

The README's note and disclaimer is unusually direct about the status of the project. Root3 developed it as a side project to add additional value for its customers, it can be used free of charge, and it is provided as is without any warranty. That is an accurate description of the risk profile of adopting it, and an organisation that needs contractual support should treat that line as a fact rather than a formality.

Configuration profiles are the intended deployment route

The README states that the most straightforward and recommended way to configure the app is to use Configurator Mode, export a Configuration Profile, and use it with your Device Management Service.

That is a three-step workflow that any organisation already running macOS management will recognise. Configurator Mode is a mode inside the app in which an administrator sets the configuration, the app exports that configuration as a profile in the standard macOS profile format, and the device management service then pushes it to the fleet. The app is therefore not configured per user by hand, and the settings are not stored on each machine independently.

The repository supports that workflow with sample material. There is a directory of Configuration Profile Samples, a Jamf Pro Custom Schema directory for the teams whose management console wants a structured payload rather than a raw file, and an Extension Sample Scripts directory for the script extensions that such a deployment can carry alongside.

The LaunchAgent Sample directory is the piece that completes the picture. A launch agent is the macOS mechanism for running something when a user logs in, and shipping one in a configuration profile is the standard way to have a helper installed per user on a managed machine. The SupportHelper directory in the repository is the corresponding helper, and the presence of both is a sign that the app's installation model is built around profiles rather than around a downloaded installer.

Packaging, migration and the version 3 baseline

The repository carries the tooling that a deployment needs, and its names describe the workflow.

The pkgbuild directory holds the packaging assets and build_pkg_automated.zsh is the script that builds the package, which is what turns the application into something a device management service can distribute as a macOS installer. Screenshots holds the images the README embeds, src holds the Swift source, and the Configuration Profile Samples and Extension Sample Scripts directories sit alongside the packaging work as the configuration side of the same deployment.

Then there is migrate-support-2x-to-3x.sh, which is the clearest statement of the versioning situation. The release history shows 3.0.5 published on 2026-08-04, 3.0.4 on 2026-07-28 and 3.0.3 on 2026-04-17, so the 3.x line is where the project is now, and the migration script exists for organisations that were on the 2.x line. Combined with the macOS 14 minimum in the README, that gives an adoption team two things to plan: the operating system floor and the jump from the previous major version.

The release cadence is also worth noting, with two 3.0.x releases inside a week in late July and August 2026 and the last push to the repository matching the newest release, so the project is actively maintained rather than archived.

The privacy claim and the licence

The README has a privacy policy section with a single sentence in it: to protect your privacy, the Support App does not collect or send any personal data.

For an application that sits in the menu bar of every managed Mac and that displays diagnostic information about the machine, that is a meaningful property. A support tool that reported back to the vendor would be a telemetry channel on every workstation in the estate, and a tool that displayed other users' tickets would be a data leak waiting to happen. Neither applies here, and the absence of both is what makes it plausible to deploy one app to a whole organisation.

The trade-off is that the organisation owns the data rather than the vendor, which means an administrator is responsible for the content the app shows. A diagnostic view that reveals nothing to the vendor is also a view that reveals nothing to a central dashboard, so any reporting the organisation wants has to be built on top of the app rather than read from it.

The licence is MIT, with a LICENSE file at the root of the repository. MIT is permissive, with no copyleft obligations and no requirement to publish modifications, which suits an application that organisations will brand and internalise. That is a description of the terms rather than legal advice, and for a project that also states it is provided without warranty, an organisation's own procurement process is the right place to settle the remaining questions.

Where the Support App is the wrong tool

The first limitation is the one the disclaimer points at. This is a side project, provided as is and without warranty, so the risk of relying on it for a critical support path is yours. For a help desk that wants a supported product with a contract behind it, that is disqualifying regardless of how good the application is.

The second is scope. The app is the user-facing half of a managed estate, not the management system. It does not enforce policy, it does not install software and it does not report to the server that manages the Mac. Teams looking for a way to gather device state centrally, or to push configurations, are looking for the management service that the app's configuration profile is designed to be deployed by.

The third is the floor. macOS 14 is the minimum, so any estate still running older systems is out of scope, and the 2.x to 3.x migration adds a second piece of work for organisations that were on the previous line.

The fourth is that the app is a front end to content you supply. Support channels, websites, applications and file servers are only useful once they exist, are maintained and are reachable from the user's network. An app that lists internal resources which have been reorganised is worse than no directory, and the maintenance of that list falls to the administrator rather than to the publisher.

Finally, the support model is community. The wiki, the Mac Admins Slack channel and the issue tracker are genuinely useful resources with an active user base, but they are not a support agreement, and a question that matters only to your organisation will be answered, if at all, by volunteers.

Editorial conclusion

Adopt Support App if you run a managed Mac estate and you want end users to reach diagnostics, support channels and internal resources without opening a ticket first, and you are able to push a configuration profile to every machine. Do not adopt it as a replacement for device management, since it is the user-facing client of that system rather than the system itself, and do not treat it as a supported product, because the publisher states it is a side project provided as is without warranty. Verify first that every Mac in scope runs macOS 14 or newer, that your device management service can carry the configuration profile the app exports, and that the help desk content and links you configure point at services that actually exist in your organisation.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. root3nl/SupportApp on GitHub