Repository navigation
Synching Apple Photos to NextCloud photos #3623
Description
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Photos in our digital library (Apple Photos) are documented with title, a description, keywords, and a date the photo was taken. This data is not automatically uploaded by a photo web service, and so is lost when moving the library to a web service. For example, Flickr accepts a jpeg for uploading, but the title and description must be added manually. This means that the thousands of photos with these items already added in our digital library must again be added to the web service. Apple “shared album” feature also removes titles and all user-added data before moving an image from a local Photos library to a shared album. Apple “shared library” successfully shares an entire library, but is limited to 5 shares. Hence, with these failures to preserve metadata, the motivation to build what is not found commercially.
Describe the solution you'd like
A clear and concise description of what you want to happen.
I have a project which reverse engineers Apple Photos on MacOS and have SQLite scripts and Python code which extract apple photos and metadata to a static website. The next step would be to integrate this "export" function to NextCloud Photos.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
The current project works well as an export function to an independent static website. I would like to integrate it into a larger working system such as NextCloud Photos.
Additional context
Add any other context or screenshots about the feature request here.
The existing software created this website used by a marine biologist, displaying 48K photos in chronological order and sorted into various albums.
Activity
hiSandog commentedon Jul 8, 2026
The scope would be easier to review if the first version defined a small acceptance contract for
Synching Apple Photos to NextCloud photos. I would call out the default behavior, the migration/backwards-compatibility story, and one or two cases that are intentionally out of scope so the implementation does not grow beyond the original request.frake65 commentedon Sep 10, 2026
I have a working macOS/PhotoKit prototype for a non-destructive Apple Photos import into Nextcloud. The client reads assets, keeps stable external identities, performs incremental inventory, collects album identities and memberships, and transfers binary data through ordinary Nextcloud Files WebDAV.
The main question is how to support multiple independent import sources and clients feeding the same Nextcloud instance — for example, two Macs with different Apple Photos libraries, and potentially other photo providers later. A local client cache alone cannot provide shared identity when another or newly installed client joins. Some stable relationship between an external source, external asset identity, and the resulting Nextcloud file therefore seems necessary.
Albums are equally important. Album names are not identities; external album identities and their relationship to imported assets need to remain stable across retries, client reinstalls, and multiple sources without clients interfering with each other. Equal album names from different sources must remain distinguishable, and missing source data should not imply destructive deletion. The current Photos-internal album mappers and commands do not appear to provide a stable external integration API.
Upload reservation, recovery, and race protection are useful additional robustness requirements, but secondary to identity and album consistency. Binary transfer could remain entirely on Files WebDAV; we are not proposing another upload API.
Would Photos be open to a small, generic external-source abstraction for stable asset and album identity/membership, while keeping binary uploads on Files WebDAV? Or would you prefer such state to remain entirely client-side?