ServiceSoftware development
Desktop apps for Mac and Windows, with updates that install themselves
Our desktop app service builds applications that install on Mac and Windows computers, for jobs a web page does poorly: heavy rendering, working with large local files, using the user's own keys or hardware, or working offline. We build them with automatic updates, code signing and notarisation, and builds produced on GitHub Actions. Our own video app runs on both systems and updates itself.
What we do for you
- An honest check that a desktop app is needed, rather than a web app
- One codebase for Mac and Windows where the job allows it
- Automatic updates from a release channel you control, so users always run the current version
- Code signing on Windows and Apple notarisation on Mac, so installs are not blocked by security warnings more than necessary
- Builds for both systems on GitHub Actions, never on a developer's laptop
- A test release channel before each public release
- Local storage of user data and keys where privacy requires it
Who it is for
- Fits: tools that process large files or media locally (video, images, documents) where uploading everything would be slow or unwanted
- Fits: software that must use each user's own credentials or API keys on their machine
- Fits: teams that need a tool to keep working without a reliable connection
- Does not fit: most business tools that work perfectly in a browser — a web app is simpler to ship and update, see custom software
- Does not fit: native phone apps — we have not shipped native iOS or Android apps
What we built
Our own video app runs on Mac and Windows. Each user works with their own keys, the brief becomes a sourced script, the video is rendered locally on their computer in several formats, and updates are delivered automatically from our release channel. Shipping it taught us what makes or breaks a desktop app: update delivery, and one product that behaves the same on two operating systems. Signing and notarisation are planned into every client release from the start.
Getting past the operating system's security checks
On Mac, Apple explains that notarisation gives users "more confidence that the Developer ID-signed software you distribute has been checked by Apple for malicious components". The Apple notary service is an automated scan, not App Review; when the user first opens the app, the notarisation ticket tells Gatekeeper that Apple notarised it, and the launch dialog reflects that.
On Windows, Microsoft's guidance compares the options for apps distributed outside the Microsoft Store. An unsigned app gets a strong SmartScreen block; a self-signed one blocks installation for public users. With a trusted certificate or Microsoft's signing service, SmartScreen warnings can still appear for new files until reputation builds, and Microsoft notes that since 2024 Extended Validation certificates no longer bypass SmartScreen instantly. Packages published as MSIX through the Microsoft Store are re-signed by Microsoft. We choose the route with you and explain what users will see on day one.
How we build and release
- Scope. What must run locally, what can stay on a server, which systems and versions to support.
- Build pipeline first. GitHub provides macOS and Windows runners, and each run starts in a fresh virtual machine; we build, sign and notarise there so every release is reproducible.
- Update channel. The app checks a release feed you control and installs updates; a test channel receives them first.
- Test on real machines. Fresh installs and upgrades on both systems, including the security prompts a new user sees.
- Release. Public channel updated after the test channel has run cleanly.
- Maintain. Operating system updates, certificate renewals and dependency updates handled on schedule.
Desktop app or web app?
| Need | Web app | Desktop app |
|---|---|---|
| Instant access from any device | Yes | Needs installing |
| Updates | Immediate for everyone | Automatic, but users must restart |
| Heavy local processing (video, large files) | Limited | Yes |
| Offline work | Partial | Yes |
| Signing and store rules | None | Code signing, notarisation, SmartScreen reputation |
What you own
- The source code and build scripts, in your repository
- The signing identities (Apple Developer account, Windows certificate or signing service) in your organisation's name
- The update channel and its release history
- User data stays on users' machines or in your accounts, as designed
Questions we get
Will users see security warnings when installing?
On Mac, a signed and notarised app opens with Apple's standard first-launch dialog. On Windows, even signed apps can show SmartScreen warnings until reputation builds, unless distributed as MSIX through the Microsoft Store. We explain what to expect for your case.
How do updates work?
The app checks a release channel you control and installs new versions automatically. A test channel gets each release first.
Can it work offline?
Yes, if the job allows it: we design which parts run locally and which need a connection.
Do you publish to the Mac App Store or Microsoft Store?
Our own app is distributed directly with automatic updates. Store publication is possible but has its own review rules; we will tell you plainly if we have not done it for a given store.
Who holds the signing certificates?
Your organisation. Signing identities are in your name so you keep control of your releases.
Sources
- Apple Developer — Notarizing macOS software before distribution (checked 2026-10-06)
- Microsoft Learn — Code signing options for Windows app developers (checked 2026-10-06)
- GitHub Docs — Understanding GitHub Actions (runners) (checked 2026-10-06)