streamlining the update of spoke file

I have a situation where I do not use the mirrorsync method of distributing file updates.  Instead, after performing a sync, the spoke checks the hub to see if a newer version of the solution file is available, and if so, the user is prompted to perform the update.  If yes, the spoke database is closed, replaced with the new (empty) version from a container field on a hosted database, and then a second sync is triggered again to put all of the data back.  All of this is done in iOS devices, and all of this works as expected.  The only issue has to do with the amount of time it takes to perform a sync from scratch again.  I'm wondering if there would be any implication to this: once the sync is complete and if the user agrees to perform an update of the solution file, then the solution file exports all pertinent data locally on the iOS device, then replaces the file with the new empty version, then performs an import of all the data that had been previously exported, and then initiates the second sync.  The idea is that the export/import would be faster than the sync and might not be as painful for the user.

Edited March 13, 20196 yr by ShannonS
clarification