How Updates Work in Atmos

Atmos keeps its update system intentionally lightweight.

There is no giant update dashboard, no complicated release channel selector, and no noisy constant polling. Instead, the app checks a small update endpoint, compares versions, and surfaces the result in a compact way through the interface.

This guide explains how updates work in Atmos, what users actually see when a new version is available, and which hidden details matter when you are trying to understand the app’s update behavior.

Where update information comes from

Atmos gets its update information from a remote update endpoint.

That endpoint returns a small metadata block including:

• the latest version
• the download URL
• release notes
• whether the update is marked critical

This means the app does not need a full update framework just to know whether a newer version exists. It only needs a reliable source of version information and a place to send the user for the new build.

What the app compares

When Atmos checks for updates, it compares:

• the current app version installed locally
• the version returned by the remote update endpoint

If the remote version is newer, Atmos marks the update as available.

If it is not newer, the app marks itself as up to date.

This sounds simple, but it is important because the system is based on real version comparison rather than on a vague “latest build” guess.

How version comparison works

Atmos compares versions numerically by segment.

So a version like:

• 1.0.1

is treated as newer than:

• 1.0.0

This matters because update systems can behave badly if they compare version strings naively. Atmos is doing a proper numeric segment comparison instead of treating version numbers as ordinary text.

When Atmos checks for updates automatically

Atmos checks for updates on launch, but not every single time the app starts.

Instead, it remembers the last successful check timestamp and skips the automatic check if the last one happened within the previous 24 hours.

That means the default behavior is:

• launch the app
• if more than 24 hours have passed since the last check, ask the update endpoint
• otherwise, skip the automatic network check

This keeps the updater lightweight while still making sure users eventually hear about new releases.

Hidden behavior: manual checks ignore the 24-hour wait

The 24-hour rule only applies to the automatic launch check.

If the user opens the Updates page and taps Check for Updates, Atmos performs a fresh check immediately.

This is useful because it means the app can stay quiet by default while still allowing users to verify update status on demand.

That balance is one of the better design decisions in the updater.

What users see in the Settings page

The Updates page in Settings is the main user-facing view for update state.

Depending on the result, the page can show:

• checking
• update available
• up to date
• not checked recently

This is helpful because the page does not only answer “yes or no.” It gives a little context about what state the updater is currently in.

What happens when an update is available

If Atmos finds a newer version, it stores the remote update metadata and marks:

• updateAvailable
• the latest version string
• the release notes
• the download URL
• whether the update is critical

At that point, the Settings page can show a more explicit update state, including the version that is available and any attached release notes.

This makes the update page feel informative instead of purely transactional.

Release notes are part of the update flow

Atmos can display release notes directly from the update metadata.

That means the app does not just say “an update exists.” It can also explain what changed.

This is especially useful for smaller releases, because users can decide whether they want to update right away based on what the release actually includes.

It also makes the update experience feel more polished than a bare download alert.

Critical versus normal updates

The update metadata includes a critical flag.

This lets Atmos distinguish between:

• a normal available update
• a critical update

A critical update is not just another version bump. It is meant to be surfaced with higher urgency.

That means the visual treatment and the wording can become more forceful when the critical flag is set.

Hidden behavior: critical does not change the version logic

It is important to understand what the critical flag does and does not do.

It does:

• change how strongly the app surfaces the update

It does not:

• bypass version comparison
• invent a newer version when one does not exist

So critical is an urgency layer on top of update availability, not a replacement for the underlying version check.

What users see when no update is needed

If the remote version is not newer than the installed app version, Atmos marks the app as up to date.

The Settings page then shows a reassuring current-state message rather than leaving the status ambiguous.

This is a small thing, but it helps. Users do not have to guess whether the app failed to check or simply found nothing new.

What happens on network or parsing failure

If the app cannot reach the update endpoint cleanly or cannot parse the response, it falls back to an “up to date” style state instead of surfacing a scary failure by default.

That means transient network issues do not turn the updater into a noisy error generator.

This is a deliberate user-experience tradeoff. The app prefers calm fallback behavior over making every temporary connection issue feel like a product problem.

How the update button changes

The primary button on the Updates page changes based on the current state.

If an update is available, the button becomes a download action.

If no update is currently available, the page shows a Check for Updates action instead.

This makes the screen easier to read because there is always one main next step rather than several competing buttons.

What the download action actually does

When a user chooses the update action, Atmos opens the configured download URL using the system browser.

That means the app is not directly self-patching in place. It is pointing the user toward the correct download destination for the new version.

This is a simpler and more controllable model for a desktop app distributed outside a fully managed app store update system.

Hidden behavior: the interface can surface update availability outside Settings

The Updates page is the detailed destination, but the rest of the app can also reflect update availability.

In the current product flow, update state can also affect how the settings entry itself looks, such as badge-style visibility when a newer version exists.

This matters because users do not necessarily need to open Settings first in order to notice that an update is waiting.

What the server-side update block controls

On the release-management side, the update system is driven by a small update object on the server.

That block defines:

• the latest version string
• minimum OS metadata
• the download or release URL
• the release notes
• whether the release is critical

This means a new update can be announced by changing the server-side metadata instead of shipping a new app build just to teach the old build where to look.

That is one of the main advantages of this architecture.

Why the update system feels simple in the app

The updater is simple from the user’s point of view because most of the complexity is pushed out of the interface.

The app mainly needs to:

1. decide when to check
2. ask the endpoint
3. compare versions
4. show the result
5. open the download URL if needed

That makes the user experience easy to understand while still giving the developer enough flexibility to change release metadata remotely.

What users should expect from Atmos updates

In everyday use, users should expect:

• one automatic check at launch when enough time has passed
• a quiet app when nothing new exists
• a clear status in Settings when a new version is available
• release notes when provided
• a browser-based handoff to the update download

That is a good fit for a compact macOS utility that wants to stay out of the way most of the time.

Useful hidden details in the update flow

Here are the details most users are likely to miss:

• Automatic update checks are rate-limited to once per 24 hours.
• Manual checks from Settings can happen immediately.
• The updater compares version segments numerically, not as plain text.
• Release notes come from the remote update metadata.
• Critical updates are an urgency flag layered on top of normal version comparison.
• The app opens a configured download URL rather than silently self-patching in place.

These are the details that make the update system feel stable and predictable.

Final thoughts

Atmos uses a small, clean update model that fits the rest of the app. It checks infrequently by default, lets the user force a fresh check when needed, compares real versions properly, and keeps the visible update experience compact.

Once you understand the 24-hour launch check, the manual refresh option, the critical flag, and the browser-based download handoff, the update system becomes very easy to reason about.

In the next tutorial, we will cover one of the most easily misunderstood systems in the app: how Atmos license states, grace periods, and access control work.