A EULA for a mobile app has to satisfy an app store's review rules. A EULA for a web app usually turns out not to be needed at all, since nothing gets installed. Desktop software sits in a different spot entirely: a user downloads an installer, runs it on their own machine, and ends up with a local copy of your binary sitting on their hard drive, sometimes with no internet connection in the room. That's the situation an EULA was originally written for, and it comes with mechanics none of the newer distribution channels have to deal with: an actual acceptance step inside the installer itself, a code-signing certificate that either reassures the user or throws a scary warning dialog, an auto-updater that can quietly replace your binary weeks after install, and, for some products, a license key that has to work on a machine that's never going to touch your activation server.
Why install-time acceptance is a different mechanic than a website checkbox
A web app's terms get accepted with a checkbox on a signup form, logged against a user account, done. Desktop software has to handle acceptance before your app even exists on the user's machine, which means the acceptance step lives inside the installer, not inside your product.
On Windows, this is usually an MSI or EXE installer built with a tool like WiX, Inno Setup, or InstallShield, and the convention is a license page early in the wizard with the full EULA text (or a scrollable box with a link to it) and an "I accept the terms of the License Agreement" checkbox that has to be checked before Next enables. That checkbox click is your acceptance record, though it typically isn't logged anywhere durable unless your app phones home at first launch to record it server-side.
On Mac, it depends heavily on how you're distributing the app. A signed .pkg installer built with productbuild supports a license pane the same way Windows does, definable with a Distribution.xml file that embeds your EULA text and requires an explicit Agree click before installation proceeds. But a huge share of Mac software ships as a plain .dmg with a drag-to-Applications window and no installer at all, in which case there is no acceptance step whatsoever. The user drags an icon, the app runs, and the first they see of your EULA, if they see it at all, is a link in the app's About panel or a first-launch dialog you build yourself.
That last branch is the one that catches teams off guard. If your Mac distribution is a .dmg, "the installer makes them click Agree" isn't true for you, and your EULA's enforceability rests on a first-launch acceptance dialog inside the app itself, or on a browse-wrap link on the download page, which is a meaningfully weaker acceptance record than a blocking installer checkbox. If your Mac EULA strategy currently assumes an installer step that doesn't exist for your .dmg build, that's worth fixing before it becomes a dispute where the acceptance record matters.
What code signing changes about the EULA, and what it doesn't
Code signing doesn't touch the license terms themselves, but it changes what the installer experience looks like around them, and it's worth addressing directly in the agreement because unsigned or improperly signed copies are exactly the scenario your anti-tampering and redistribution clauses exist for.
On Windows, an unsigned or newly-signed EXE trips SmartScreen's "Windows protected your PC" warning, and users have to click "More info" then "Run anyway" to proceed, a flow that trains a lot of users to click through security warnings without reading them, which is part of why the EULA's own acceptance checkbox matters independently of whatever the OS is warning about. A properly Authenticode-signed installer from an established publisher skips that warning, or shows a milder one with your verified company name attached.
On Mac, the equivalent is notarization: Apple has to scan and clear your signed app before Gatekeeper will let it run without a manual override, and an app that isn't notarized gets blocked outright on current macOS versions unless the user goes into System Settings to explicitly allow it. Both mechanisms exist to reassure users the binary hasn't been tampered with between your build server and their machine, which is exactly the guarantee your EULA's own integrity language should reference: state plainly that the agreement covers the software as distributed through your official, signed channels, and that a user running a modified, unsigned, or redistributed copy obtained elsewhere isn't covered by whatever warranty or support commitments the agreement makes.
Windows vs Mac Desktop Install Mechanics
| Windows | Mac | |
|---|---|---|
| Common installer | MSI/EXE (WiX, Inno Setup, InstallShield) | Signed .pkg, or plain .dmg drag-install |
| License acceptance | Checkbox in installer wizard | .pkg license pane, or none for .dmg |
| Signing mechanism | Authenticode certificate | Apple Developer ID + notarization |
| Unsigned-copy warning | SmartScreen warning, click through | Gatekeeper block, Settings override |
| Silent/unattended install | /quiet or /S installer switches | Command-line target, less standardized |
Auto-update consent needs its own clause, not a general amendment clause
Most desktop software today updates itself without the user re-running an installer, either silently in the background or with a "restart to update" prompt, and a generic "we may amend these terms at any time" clause doesn't actually cover what's happening: you're not just changing a document, you're replacing the binary running on someone's machine. A EULA written for a hosted product never has to address this because there's nothing local to replace.
The clause worth adding covers three separate things: that the software may check for and download updates automatically (and whether that check can be disabled), that installing an update may require an application restart or, on some platforms, elevated permissions, and that continued use of the software after an update constitutes acceptance of any changed terms bundled with that update. Products that phone home for update checks should also say so here rather than leaving it to the privacy policy alone to cover, since a user reading the EULA before installing is asking a licensing question ("what happens to my copy") not just a data question.
- We may update the software from time to time.
- Continued use means you agree to any changes.
- The software checks for updates automatically on launch; this can be disabled in Settings.
- Updates install automatically; a restart or security update may install without prompting.
Offline activation is a desktop-specific problem
Web and mobile software can assume a live connection to your servers essentially always. Desktop software, especially anything sold as a perpetual license rather than a subscription, still regularly runs on machines that are air-gapped by policy (regulated industries, government contracts, industrial control systems) or just offline more often than not (field laptops, older machines kept for one specific piece of legacy software). If your product uses license keys or seat-based activation, the EULA needs to state how activation works when the machine can't reach your activation server: whether you support a manual, file-based activation flow (generate a request file, email it, receive a signed response file), how many activation attempts a single key allows before it's flagged, and what happens when a user needs to move a license to a new machine, since deactivating the old install before activating the new one is usually the mechanism that keeps a per-seat license honest without requiring a live check-in.
This is also where a desktop EULA needs a termination and uninstall clause that a hosted product doesn't: what happens to the license, and to any local data or configuration files the app created, when the user uninstalls or when you terminate the agreement for a breach. Stating that uninstalling the software doesn't by itself terminate the license (in case a user reinstalls later) or that it does (in case you want reinstall to require a fresh activation) is a decision worth making explicitly rather than leaving unstated, since "what happens if they just delete the app" is not a question a EULA written for a subscription-only web product ever had to answer.
Building the acceptance flow around the document
None of this changes what an EULA fundamentally is: a license to a copy of your software, with restrictions on what the licensee can do with it. It changes where and how that license gets presented and accepted, and what it has to say about updates, signing, and offline use that a mobile or web-based EULA can leave out entirely. If your product spans multiple platforms, it's worth checking what a mobile app EULA or a web app EULA has to cover instead, since the underlying license terms may be shared across a desktop, mobile, and web build of the same product, but the acceptance mechanics and platform-specific clauses in this guide won't carry over to those other builds automatically.
Our EULA Generator builds a license agreement around the platform you're actually distributing on, including installer-appropriate license grant language, code-signing and integrity provisions, update-consent clauses, and activation terms for offline and air-gapped use, so the document you drop into your Windows and Mac installers matches how desktop software is actually delivered instead of reading like it was adapted from a SaaS terms template.
The information in this article is for informational purposes only and should not be construed as legal advice on any matter, and does not create a lawyer-client relationship.
