It is actually not necessary.
I think this can be compared to calls or A/V in that both devices
are expected to be actively used while the transfer is happening. I
think this should be possible even on aggressive platforms like iOS.
Aggressive or not, it might actually be unnecessary, at least according to our vision of multi-device encryption.
We have discovered that whenever there are encryption session that are encrypted for one of your devices, and not the other, this leads to a horrible user experience that can't be recovered in no way. Grabbing the wrong device and seeing 'unable to decrypt message' which is decryptable on another of your devices is really, really bad and inconvenient, and we treat such incidents as a severe error.
So our solution is to require the sender to encrypt messages for all valid devices of the message recipient, warning the user really aggressively if one of those devices is not trusted (via fingerprint matching or our other method of verification via code), nudging the user to perform device trust procedure. This way, the only history you need to synchronize conversations that happened prior to addition of this new device just once, at device initialization. For this, you don't need to create some complex protocols that would continuously sync history.