# How Modly's Auto‑Updater Works in Its Electron Application

> Discover how Modly's auto-updater leverages electron-updater for seamless updates in its Electron app. Learn about its handling of macOS builds, patch updates, and user prompts for major releases.

- Repository: [lightningpixel/modly](https://github.com/lightningpixel/modly)
- Tags: internals
- Published: 2026-08-15

---

**Modly implements automatic updates using the `electron-updater` library in the main process, disabling macOS support for unsigned builds while automatically applying patch updates and prompting users for major or minor releases via IPC messages to the renderer.**

The lightningpixel/modly repository contains a custom auto‑updater implementation that wraps `electron-updater` to provide platform‑aware update handling. Located in [`electron/main/updater.ts`](https://github.com/lightningpixel/modly/blob/main/electron/main/updater.ts), the module initializes when the application starts and manages the entire update lifecycle from detection to installation. This implementation specifically accounts for Modly's unsigned macOS builds while offering granular control over how different update types are handled on Windows and Linux.

## Platform Guard and Initialization

The updater first checks platform compatibility before enabling any functionality. Inside [`electron/main/updater.ts`](https://github.com/lightningpixel/modly/blob/main/electron/main/updater.ts), the code defines a platform guard that explicitly disables updates on macOS due to unsigned builds:

```typescript
export const updatesSupported = process.platform !== 'darwin'

```

When the application launches from [`electron/main/index.ts`](https://github.com/lightningpixel/modly/blob/main/electron/main/index.ts), it invokes `initAutoUpdater(getWindow)`, passing a function that returns the current `BrowserWindow` instance. If `updatesSupported` evaluates to `false`, the function exits early with a log entry and skips all updater configuration.

For supported platforms (Windows and Linux), the initialization configures the `autoUpdater` instance with specific behavior flags (lines 13‑22):

- `autoDownload = false` — Prevents automatic downloads, allowing the application logic to decide when to fetch updates.
- `autoInstallOnAppQuit = true` — Ensures updates install silently when the user closes the application.
- `disableWebInstaller = true` — Disables web-based installer downloads.

The module also attaches a shared logger from [`electron/main/logger.ts`](https://github.com/lightningpixel/modly/blob/main/electron/main/logger.ts) to the `autoUpdater` for unified logging across the main process.

## Update Detection and Classification

Once initialized, the updater listens for the `update-available` event to detect new versions. The implementation differentiates between patch updates and major/minor releases using version string parsing (lines 24‑40).

**Patch updates** (same major and minor version) trigger immediate automatic downloading. The logic treats these as safe to apply without user intervention.

**Major or minor updates** prompt user confirmation before proceeding. When detected, the main process sends an IPC message to the renderer via `webContents.send('updater:major-minor-available', { version })`, allowing the UI layer to display a dialog asking the user whether to download the new version.

This classification ensures that critical bug fixes arrive silently while significant version changes require explicit user consent.

## Download Completion and Silent Installation

After the main process downloads an update, the `update-downloaded` event fires. The handler in [`electron/main/updater.ts`](https://github.com/lightningpixel/modly/blob/main/electron/main/updater.ts) manages the transition from download to installation (lines 42‑48).

First, the renderer receives the `updater:applying` message to display an "Applying update…" screen, providing visual feedback during the brief installation window. After an 800 ms timeout to allow the UI to render, the updater calls `quitAndInstall(true, true)`, which closes the application and atomically replaces the executable with the new version.

The module also handles edge cases:
- `update-not-available` logs that the current version is up-to-date.
- `error` captures and logs any failures from the underlying `electron-updater` library (lines 51‑57).

## Recurring Update Checks

Modly implements a two-tiered checking strategy to ensure applications remain current during long-running sessions. Immediately after initialization, the code calls `autoUpdater.checkForUpdates()` to verify updates on startup.

Additionally, a recurring interval triggers a check every two hours for active sessions (lines 59‑67). This interval-based approach catches updates published while the application remains open without requiring user action or restarts.

The system also supports manual checks via IPC. When the renderer invokes the `'updater:check-now'` channel, the main process executes the same `checkForUpdates()` method used by the automatic timer.

## Summary

- **Platform restrictions**: Updates are explicitly disabled on macOS (`darwin`) due to unsigned builds, while Windows and Linux receive full auto-update support.
- **Granular update handling**: Patch updates download and install automatically, while major/minor updates require user confirmation through IPC messages sent to the renderer.
- **Silent installation**: Downloaded updates apply automatically when the user quits the application, with visual feedback provided during the 800 ms transition window.
- **Continuous monitoring**: The updater checks for new versions on startup and every two hours thereafter, with support for manual triggering via IPC.

## Frequently Asked Questions

### Why does Modly disable auto-updates on macOS?

Modly disables auto-updates on macOS because the builds are unsigned. The code explicitly sets `updatesSupported` to `false` when `process.platform === 'darwin'` to prevent update failures and Gatekeeper warnings on macOS systems. This ensures users on Mac only run versions they manually download and approve.

### How does Modly distinguish between patch and major updates?

The updater parses version numbers when the `update-available` event fires to compare the current and incoming versions. If the major and minor version numbers match, it treats the update as a patch and downloads immediately. If either the major or minor version differs, it sends `updater:major-minor-available` to the renderer process to prompt the user before downloading.

### What IPC channels does the auto-updater use to communicate with the UI?

The main process uses `updater:major-minor-available` to notify the renderer of significant updates requiring user consent, and `updater:applying` to signal when an update is being installed. The renderer can trigger manual checks via `updater:check-now`, which the main process handles by invoking `autoUpdater.checkForUpdates()`.

### How often does Modly check for available updates?

The application checks for updates immediately on startup and then repeats the check every two hours for as long as the application remains running. This interval-based approach, implemented in [`electron/main/updater.ts`](https://github.com/lightningpixel/modly/blob/main/electron/main/updater.ts) (lines 59‑67), ensures long-running sessions do not miss critical patches or releases.