Add an option to only upload *new* photos.

[stephan-neura]

Describe the feature you'd like

Add an option to only upload new photos.
This could be handled by date or by a list of already uploaded photos, or a pointer to the latest uploaded picture.

Additional context

I have several thousand photos in my library, and I do not want to upload all of them again.
They are already in the cloud, and sorted etc. there. Many of them are synced back using iTunes (see), and I do not want to upload them again.

If this option would also be valid for the photos, Mega app sees at all, it might make it more responsive.
Now it takes minutes to load the photos, when changing to the "Photos" tab.
I also don't need the photos there, therefore I have Photos app etc., which will always be better in the end. Mega should concentrate on uploading.

[Harryyan]

Thanks for the feedback @stephan-neura . Did you remove the uploaded photos from MEGA before your camera upload? MEGA won't upload duplicated photos again.

[stephan-neura]

No, I don't keep them in that folder but use it as an input for structuring, sorting out etc.
From competitors I know the photo upload like that:

• First you can choose if you want to upload all or new photos
• Let's say, I choose new only
• It then uploads every photo once, no matter what I do with it on cloud side
• It's easy to implement: The app has to remember the date of the latest uploaded photo only to resume where it ended last time.

[Harryyan]

Hi @stephan-neura, thanks again for your thoughtful input — we really appreciate the detailed suggestions and the comparison with other apps’ behavior.

You’re absolutely right that from a user experience point of view, being able to simply choose “upload only new photos” is very convenient. Internally, we’ve discussed similar ideas before, and while the concept of using the timestamp of the last uploaded photo seems straightforward, there are a few implementation challenges we’d need to solve carefully, especially since MEGA operates across iOS, Android, and web platforms.

Some of the key considerations are:
• Cross-device sync: Users may upload photos from multiple devices. If the “last uploaded time” is tracked only locally, uploads may become inconsistent or duplicated across devices.
• File metadata can’t be fully trusted: Photo timestamps may change when photos are edited, synced via iTunes, restored from backups, or imported via third-party tools — making purely timestamp-based logic unreliable.
• Privacy and platform differences: iOS has tighter constraints on photo access compared to Android, which affects how reliably we can scan and track upload state in the background.

That said, you’re absolutely pointing us in the right direction. We’re exploring a more robust hybrid approach that can balance performance, reliability, and privacy — potentially involving a combination of timestamps, content hashing, and server-side memory of upload history. We’ll definitely take your feedback into account as we evolve the camera upload logic.

Please feel free to share any more thoughts or examples — it helps us prioritize improvements that really matter to users like you.

Thanks again!

[stephan-neura]

Hi @Harryyan,

your reasoning makes sense to me.

A few thoughts on this, without being too deep into the implementation details of your app:

• If you would save the date of the last image on the device, that would be a 90% solution.
  It could also be set to the current timestamp when setting the "only upload new images" flag in menu.
  Disadvantages: There can be complications if meta data changes (if in doubt, a new upload would probably not be a drama)
  And there is the question of which date should be used. Created? Added? Personally, I would be happy with Created, if I then had to manually take care of images that are added e.g. via Airdrop or similar, that would be fine for me. But yes, it's a 90% solution.

• I assume by "cross-device sync" you mean that the same images come from several sources, e.g. because they were synchronized via the Icloud?
  I assume that the metadata differs in this case and therefore the duplicate detection via hash does not work?
  This is more complex, a hash over the image without metadata could help, but even then there could be scenarios where users would expect a different behavior.

• I guess it is in your interest to keep the amount of data stored on the server side to a minimum? That means, for example, a map for each device, the hash and the date of the last image. But you probably don't want to save the entire history of uploaded images. I would at least try to keep it as stateless as possible.

• As for the iOS restrictions, I would probably ignore that. If a user subsequently allows access to more images, then these will no longer be uploaded. A reset option in the menu could perhaps help here.

To summarize, I can see that this is more complex than you might think at first glance.
And I understand that you don't want to make a quick solution that you then have to constantly adapt.

For me personally, a simple approach plus understanding of how it works would be enough. I would be fine with manual intervention in special cases. But I'm probably not the standard user.

In any case, thanks for the effort and the prompt response.
If I can help you any further, just let me know.