There have been many attempts over the years to reduce network load, from MacOS Server caching updates for iOS devices, through to iTunes Sync over Wifi. But now with many iCloud Sync, Apple don’t appear to have made any attempts at making this “smarter”.
Depending on your sync goals, there’s one glaring flaw with using a portable device on battery to record content that is cloud synced, it inevitably pauses sync until the device is plugged in, whether you’re out on the street, or at home, it won’t matter. And it’s during this time that if something goes wrong with the device the content is lost.
Isn’t it about time that Sync was introduced as a service on all devices/OS’ so that when a device is on battery, but on the same network as another device (which is configured to sync the same content), it will then regardless of corded state, sync that new content to the other device via Bluetooth/Wifi (as appropriate). This serves to ensure that content is securely recorded in at least two locations, it reduces internet bandwidth/load, and is much more timely than double hopping all the devices up to the cloud and back down. The development logistics would be somewhat less complicated than developing an entirely new system beyond introducing “receive” sync capabilities on OS’ … from there they can either use network discovery, or a cloud based public/private IP matching system (that is, when a device contacts the sync server, it records the public IP, and if the private IP subnet matches with another device, then Sync is directed to the local device and not the internet).
The ultimate goal is to make sync more timely and more reliable using the local network where possible to ensure content is in multiple locations, especially if one of those locations is a corded device (e.g. iMac, etc).
Now, if this is meant to be already implemented and working, then I have absolutely no idea of determining if it’s working or not because I have many gigs worth of video on my phone sitting on the desk next to my iMac with sync paused because “reasons” …