Advanced macOS -> Immich Sync: Fixing Timezones, Stacking, and Metadata Loss for Apple Users

[the80hz]

Hi everyone!

I’ve been using Immich for a while now, and while it's an incredible piece of software, I found that the mobile app sync has some significant limitations when dealing with the Apple Photos ecosystem. These issues were partly discussed in Discussion #21251, which served as the starting point for my deep dive into this.

As a "Power User" who cares about metadata integrity, I struggled with several "pains" that the mobile app currently doesn't solve:

1. The UTC+0 Screenshot Trap: iOS screenshots lack proper EXIF timezone headers. When uploaded via the mobile app, they often default to UTC+0, completely breaking the timeline for users in other timezones.
2. Missing Originals & Zero Stacking: The mobile app usually uploads only the "current" version of a photo. If you have a Portrait mode shot, a cropped screenshot, or a filtered photo, you lose the original version on the server. Consequently, there’s no automatic stacking—you’re stuck with just the edited "flat" file.
3. Lost Filenames (DJI Mimo, etc.): Assets saved from 3rd party apps (like DJI Mimo) often have their original filenames mangled or replaced by generic iOS naming conventions during mobile upload, making it impossible to search for original source files.
4. Ignored Custom Geotags: If you manually adjust a location or date within the iOS/macOS Photos app (custom geotagging), the mobile app often ignores these database-level changes and reads the original (often empty or incorrect) file EXIF instead.

The Solution: A macOS-to-Immich Bridge

To fix this, I developed a tool that uses your Mac as a "Source of Truth" instead of the iPhone. It leverages the power of osxphotos to extract the full metadata from the Photos.app database and immich-cli to upload it correctly.

Check it out here: https://github.com/the80hz/immich-osxphotos-sync

How it solves the Pains:

• True Metadata: It exports sidecar XMP files for every asset, ensuring Immich gets the exact timestamps, timezones, and custom geotags you set in Apple Photos.
• Automatic Stacking: The script identifies pairs of (Original + Edited) assets, uploads both, and uses the Immich API to stack them automatically. Your timeline stays clean, but your originals are safe.
• Filename Preservation: It preserves the originalFileName metadata, even for files coming from DJI or other external sources.
• State Sync: It preserves your Favorites and Album assignments even if you are replacing existing "mobile-uploaded" assets.

I believe this is a vital "missing link" for users who want the best of both worlds: the magic UX of Apple Photos and the freedom/privacy of Immich.

I’d love to hear your thoughts or feedback!

Mobile IOS App: Messy timeline after mobile upload (timezone issues, wrong datetime - look seconds).

Reupload: Clean timeline after using Immich-osxphotos-sync with automatic stacking.

Notice the restored GMT+04:00 offset and the automatic stacking of original and edited versions (see the thumbnails in the bottom-left corner). The script identified the pair and used the Immich API to link them together.

A quick note on immich-go:

I’m well aware of immich-go, and it’s a fantastic tool for bulk migrations. However, it didn't solve my specific "Active Sync" needs for a few reasons:

1. No In-place Replacement: immich-go is designed for importing new data. It doesn't have a mechanism to identify an existing "messy" mobile upload, delete it, and replace it with a "clean" version while preserving the asset's state (Favorites, Album assignments, etc.).
2. XMP/Metadata Integrity: In my testing, immich-go sometimes struggled with complex XMP sidecars generated from Apple Photos' database, leading to metadata drift or ignored custom geotags.
3. The "Bridge" Workflow: My goal was a bridge that works alongside the mobile app, not a one-time migration tool.

If anyone is interested in the technical deep dive on why osxphotos + immich-cli handles Apple's metadata more reliably for this specific workflow, I’m happy to discuss it further!

[the80hz]

I really envy Android users sometimes. They don't have these kinds of fundamental hurdles that are so 'fun' to solve with creative crutches! :D