Organizing photos and videos alternatives: what you can drop

Photos and video are usually the largest single block on a Mac, and they are also the block people are least willing to touch. Looking for an alternative to whatever library app currently holds them turns up editors, self-hosted servers, cloud services, and advice to just use folders, all of which sound like answers to the same question and are not. The reason the search goes in circles is that a library application quietly performs several unrelated jobs at once, and a replacement typically covers two or three of them. Naming the jobs first makes the shortlist collapse to something manageable.

A library application is doing six jobs, not one

Pulled apart, the work looks like this:

• Ingesting from a phone or camera, without duplicating what was already imported
• Storing the originals somewhere with a predictable structure
• Generating and caching derivatives, meaning thumbnails and preview renders
• Browsing and searching, by date, place, face, or subject
• Editing, non destructively, with the edits stored separately from the original
• Syncing across devices and sharing with other people

Almost nobody needs all six from one application. Someone who shoots on a phone and never edits needs ingest, browse, and sync, and could drop the rest. Someone working with camera raw files and delivering to clients needs storage, edit, and derivative generation, and does not care about sync at all.

The reason this matters before comparing anything: two of these jobs are where the disk space actually goes, and they are not the two most people focus on. Originals are one. Cached derivatives are the other, and they are invisible because they live inside the library bundle. A library that reports 180 GB is not 180 GB of photographs. Some meaningful portion is renders that would rebuild themselves if deleted.

Where the bytes actually are

Before choosing a replacement, it is worth knowing which part is heavy, because different alternatives relieve different parts.

Video dominates almost every mixed library. A phone shooting in a high efficiency codec produces files that are large but manageable. The same phone recording in a professional codec produces files in a different class entirely, which is why Apple restricts the option by capacity: on 128 GB iPhone models ProRes recording is available only at 1080p at 30 or 25 frames per second, while 256 GB and larger capacities permit 4K. That restriction exists because of file size, and those files land on the Mac eventually.

Stills behave differently. Individually small, collectively enormous, and heavily duplicated, because burst mode and screenshots both accumulate without anyone deciding to keep them. The recoverable space in a stills collection usually comes from duplicates and from derivative caches rather than from deleting photographs anyone cares about.

A third category catches people out. Edits stored as separate rendered files, rather than as instructions applied to the original, double the storage cost of every image that was touched. Whether an application works the first way or the second is one of the more consequential differences between them, and it is rarely advertised prominently.

Working out which of the three is dominant takes one measurement rather than a guess. Compare the size the library reports against a rough count of originals, then look separately at how much of the collection is video by duration. Video usually accounts for most of the gap on any library that includes phone footage, and once that is established, the remedy is about video handling rather than about photographs at all. Deleting stills to make room in a library that is eighty percent video is effort spent on the wrong category, and it is a common way to spend a weekend without moving the free space figure.

Optimize versus download, and what each does to the disk

The built in route to freeing space does not involve leaving the library app at all. Apple offers two settings in the Photos preferences under iCloud, described as follows: Download Originals to this Mac stores the full-size versions both on the Mac and in iCloud, while Optimize Mac Storage stores smaller versions locally when space is limited and keeps the originals in iCloud.

That second setting is the single largest disk change available without changing applications, and it has a real cost. The local copy is no longer the original. Anything that has to open without a network connection, or be handed to an editing application that expects full resolution, needs the original present. Switching back to Download Originals restores them, but the restore takes time and the space comes back with it.

This is worth settling before evaluating alternatives, because it changes the problem. If optimizing storage solves the space issue and nothing else about the current setup is painful, there is no alternative to look for. If the space issue is solved but browsing thousands of items is still slow, or the originals need to live in folders that other tools can reach, that is a different problem and a different shortlist.

The alternatives, grouped by which jobs they take over

Option	Jobs it covers	How it is sold	Runs where
Built in Photos library	Ingest, store, derive, browse, edit, sync	Included with macOS	Mac, with iCloud
Lightroom Classic and the Photography plan	Store, derive, browse, edit	Subscription, bundle includes 1 TB cloud storage	Mac, desktop
Capture One	Store, derive, browse, edit	Subscription tiers, plus a perpetual licence option	Mac, desktop
Immich	Ingest, store, derive, browse, sync	Free, AGPL v3, self-hosted	Own server
PhotoPrism Community	Store, derive, browse	Free, AGPL, self-hosted	Own server
Plain folders plus a file manager	Store, browse	Included	Mac

The pattern in that table is the useful part. The editors cover the middle four jobs and deliberately do not cover sync from a phone. The self-hosted options cover ingest and sync and are weak on editing. Plain folders cover almost nothing except storage, which is exactly why they are the most durable option: nothing about a folder of files can stop working.

Immich describes itself plainly as self-hosted photo management, "available as open source under the terms of the GNU AGPL v3 License," and free. PhotoPrism's Community edition is likewise AGPL licensed and self-hosted, with paid memberships available above it. Both require running a server, which is a real ongoing cost in attention even though the software costs nothing.

On the subscription side, the shapes differ in a way worth noticing before the monthly figure. Adobe's Photography plan bundles Photoshop, Lightroom across devices, Lightroom Classic, and 1 TB of cloud storage, so part of what looks like software cost is storage cost. Capture One sells subscription tiers under several names and also keeps a perpetual licence available, which matters for anyone who dislikes the idea of an archive that stops opening when payment stops. Prices on both are shown in local currency and vary by region, so the figure on the page depends on where it is loaded from. What does not vary is the structure: one is storage bundled with software, the other offers a way to own the software outright.

The one job that resists being dropped

Five of the six jobs have straightforward substitutes. Sync from the phone does not.

Photographs are created on a phone, and getting them onto a Mac reliably, without duplicating what came across last time and without losing anything when the cable is unplugged midway, is genuinely hard to build. The built in library solves it because the operating system and the phone are made by the same company. Self-hosted options solve it with a background uploader app, which works but depends on that app being allowed to run in the background indefinitely. Editors mostly do not attempt it.

This is why most workable setups end up hybrid rather than replacing anything wholesale. The phone keeps syncing into the built in library, which stays small because the originals are offloaded. Anything worth keeping long term gets exported once into a dated folder structure on a drive, where a file manager and ordinary tools can reach it. The library becomes an inbox rather than an archive.

Getting at that archive from a phone afterward is the part people forget to plan, and it determines whether the archive gets used or quietly abandoned. Approaches to reaching a Mac's files from a handheld device are covered on the From iPhone and iPad page.

What breaks when the library is left behind

Moving out of a library application is not free, and the costs are predictable enough to check in advance.

Edits are the first casualty. Adjustments stored as instructions inside one application's database do not travel. Exporting produces rendered files that carry the look but not the ability to revise it. Anything still likely to be revised should be exported in both forms, or left where it is.

Album structure is the second. Albums are database rows, not folders. An export usually flattens everything into one directory or a date hierarchy, and the grouping that took years to build evaporates. Some applications can export album structure as folders, and checking whether that is possible before committing is worth the five minutes.

Face and subject recognition is the third. That index is rebuilt per application, and search by person disappears the moment the library is left unless the destination offers its own equivalent.

There is a fourth cost that only appears months later. Once files sit in folders, nothing prevents the same photograph existing in three places, because folders have no concept of a catalogue. The library was quietly preventing that. Replacing it means taking on duplicate detection as an explicit task, run on a schedule against the archive, rather than something the application handled invisibly. Anyone exporting out of a library should plan that step at the same time, not after the first year of drift.

Set against those, what is gained is that the files become ordinary files. They can be copied, renamed in bulk, checked for duplicates, backed up with any tool, and read in ten years by anything. A folder of dated files with sensible names is the format with the longest expected life, and it is the only one that does not depend on a company continuing to exist. Handling that kind of archive day to day is what a file manager with a built-in terminal is aimed at, since renaming, deduplicating, and verifying are all command shaped tasks performed against a visible folder.

What to change first

Run Optimize Mac Storage and measure the result before shortlisting any alternative, because it frequently solves the actual complaint and costs nothing to reverse. If space is no longer the issue but the archive still needs to live in folders that other tools can reach, export once into a dated structure and treat the library as an inbox from then on. Comparisons of how different tools handle that kind of folder archive are on the Compared with other file managers page, with Atriens listed alongside them.