HN Debrief

As a Windows user, it's a surreal way to install a program

  • macOS
  • Windows
  • Developer Tools
  • Design
  • Software Distribution

The post is a visual archive of old-school macOS installer disk images, the kind that open like a mounted drive and show an app icon next to a shortcut to Applications. It is partly nostalgia and partly an explanation of a long-standing Mac convention: many apps are distributed as self-contained .app bundles, so “installation” can be as simple as copying that bundle into /Applications instead of running a traditional installer wizard. People filled in the historical context that makes this design make sense to longtime Mac users. It descends from the days when software really was copied off floppies or CDs, and the disk image is a digital stand-in for removable media. That history also explains why developers liked .dmg files beyond simple packaging. They could stage a tiny piece of branded UI with a custom background, arrows, manuals, samples, and other extras.

If you ship Mac software outside the App Store, do not assume users understand the drag-and-drop .dmg ritual. Either add explicit guidance, use a simpler delivery method like a zip or self-moving app, or choose a .pkg only when you truly need system-level changes.

Discussion mood

Mostly negative on the usability of the .dmg drag-to-Applications flow, with a side of nostalgia for the craft and visual polish of old Mac installers. People liked the self-contained app-bundle idea and distrusted opaque installers, but kept coming back to two complaints: first-time users often have no idea what to do, and uninstalling on macOS is much messier than the icon metaphor suggests.

Key insights

  1. 01

    The Applications shortcut breaks the mental model

    What confuses newcomers is not the drag itself. It is the fake-looking setup where a downloaded disk image appears to contain your own Applications folder. That collapses the removable-disk metaphor right when the user is trying to form one. A tiny alias arrow is not enough to explain that Finder is showing a shortcut to a generic system location rather than contents inside the downloaded file.

    If you use a .dmg, do not rely on users recognizing Finder aliases. Add explicit text or avoid the alias trick entirely with a packaging format that does not depend on that bit of platform lore.

      Attribution:
    • pavlov #1
    • jeroenhd #1
    • zamadatix #1
  2. 02

    People routinely run apps from the mounted image

    This is not a theoretical UX nit. Admins and longtime Mac users said large numbers of users launch the app straight from the .dmg and leave the image mounted on their desktop. That means the common failure mode is not “they dislike the animation.” It is “they never completed installation at all,” which turns a branding flourish into operational confusion.

    Test your install path with someone new to macOS. If they can start using the app without ever copying it, expect support issues and change the flow.

      Attribution:
    • amaccuish #1
    • al_borland #1
    • newdee #1
  3. 03

    A self-moving app avoids most of this

    Several people pointed to the cleaner pattern used by some Mac apps: ship the .app directly, then on first launch detect that it is not in /Applications, offer to move it there, and restart from the new location. That preserves the app-bundle model without forcing users to decode a mounted disk image, while still giving developers a way to package extras when they genuinely need a .dmg.

    For standalone desktop apps, consider delivering a plain .app or zip plus a first-run move prompt. It keeps the Mac-native model and removes the most confusing step.

      Attribution:
    • philistine #1
    • simongr3dal #1
    • zbentley #1
  4. 04

    PKG trades clarity of action for opacity and risk

    People were not asking to replace every .dmg with a .pkg. The objection to package installers is that they are harder to inspect, often require elevated privileges, and can install all sorts of background components outside the app bundle. One commenter also noted a practical edge case for developers: signed installer packages can become unusable when the signing certificate expires, unlike a signed app bundle.

    Use .pkg only when your software truly needs to install system-level components. For ordinary apps, a bundle-based install earns more trust because users can see what is being copied and where.

      Attribution:
    • cosmic_cheese #1
    • ianmurrays #1
    • cantSpellSober #1
    • lapcat #1
  5. 05

    Mac uninstall is where the neat story collapses

    Dragging an app to Trash removes the bundle, not the rest of its footprint. Commenters listed the usual leftovers in ~/Library/Application Support, Preferences, Caches, LaunchAgents, plus system-level locations under /Library. On newer macOS versions this spills into visible user-facing clutter, like broken Login Items and stale background task entries, not just hidden disk usage.

    If you build Mac software, document how to fully remove it and clean up background items on uninstall. If you manage Macs, plan for an app-removal tool or your own cleanup scripts.

      Attribution:
    • jeroenhd #1
    • SebastianKra #1
    • mschuster91 #1
    • eddythompson80 #1
  6. 06

    The design is an artifact, not an answer

    The strongest defense of .dmg installs was historical, not ergonomic. It made sense when apps were copied from physical media and when a mounted image felt like a floppy or CD on the desktop. That explanation helps you understand the convention, but it also undercuts any claim that it remains the best default for modern users who have no reason to think of a web download as removable media.

    Do not mistake legacy familiarity for intuitive design. If your product depends on an old platform convention, assume many users will not share the context that once made it obvious.

      Attribution:
    • numpad0 #1
    • mig39 #1
    • epihelix #1
    • bigyabai #1
  7. 07

    Package managers have become the sane default for technical users

    A lot of the nostalgia in the post landed with people who no longer use this flow at all. They install through Homebrew on macOS, winget on Windows, or distro package managers on Linux. The practical point is that graphical install rituals now matter most for less technical users, which raises the bar for making them obvious, because the users most willing to tolerate quirks have already routed around them.

    If your audience is developers, offer a first-class package-manager path. Then optimize the GUI path for clarity, not cleverness, because it is increasingly serving the least forgiving users.

      Attribution:
    • jiehong #1
    • phtrivier #1
    • magic_hamster #1

Against the grain

  1. 01

    Application bundles are more intuitive than split filesystems

    Coming from systems like RISC OS, the Mac idea that an application is a self-contained directory you can move around feels cleaner than both Windows installers and the Unix tradition of scattering files across /bin, /lib, /share, and user config directories. That framing shifts the problem from “Mac installs are weird” to “desktop operating systems never converged on a model that matches how ordinary people think about software.”

    If you are designing software distribution, preserve the bundle concept even if you drop the .dmg ritual. Users understand portable, self-contained artifacts better than a filesystem scavenger hunt.

      Attribution:
    • Kim_Bruning #1
  2. 02

    Manual copying exposes what installation really is

    A smaller group argued the Mac flow is valuable precisely because it does not pretend installation is some magical privileged process. Dragging a bundle into Applications makes the operation legible. You can see the artifact, choose where it lives, and infer that removing it mostly means deleting that bundle. Compared with Windows installers that can write anywhere and do anything, the Mac approach can feel more honest even when it is awkward.

    There is product value in making install actions visible and reversible. If you replace drag-and-drop with a one-click flow, keep that transparency instead of hiding everything behind an opaque installer.

      Attribution:
    • kingkongjaffa #1
    • TZubiri #1
    • vintagedave #1
    • isoprophlex #1

In plain english

.dmg ↩
A macOS disk image file that mounts like a virtual drive and is often used to distribute Mac apps.
.pkg ↩
A macOS installer package format used for wizard-style installations, especially when software needs to place files outside the app bundle.
/Applications ↩
The standard macOS folder where applications are commonly stored for system-wide use.
Finder ↩
The macOS file manager and desktop shell, similar to File Explorer on Windows.
Homebrew ↩
A popular package manager for macOS and Linux that lets users install software from the command line.
LaunchAgents ↩
macOS background task definitions that run programs automatically for a user session.
winget ↩
Microsoft’s command-line package manager for installing and updating software on Windows.

Reference links

Mac installer inspection and cleanup tools

  • Pacifist
    Mentioned as a tool for inspecting what macOS installer packages contain and do.
  • Suspicious Package
    Suggested as an alternative utility for examining macOS .pkg installers before running them.
  • AppCleaner
    Recommended as a free utility to remove leftover files when uninstalling Mac apps.
  • Pearcleaner
    Linked as a free app-removal tool for cleaning up Mac application remnants.

Apple packaging guidance

Historical context and references