Ik sla een laatst gewijzigde tijdstempel op in de database op zowel de kerngegevensrecords op de telefoon als de mysql-tabellen op de server.
De telefoon zoekt naar alles wat er is veranderd sinds de laatste synchronisatie en stuurt dit naar de server samen met een tijdstempel van de laatste synchronisatie, en de server reageert met alles wat er is veranderd sinds de verstrekte synchronisatietijdstempel.
Prestaties zijn een probleem wanneer veel records zijn gewijzigd. Ik doe de synchronisatie op een achtergrond NSOpeartion die zijn eigen beheerde objectcontext heeft. Wanneer de achtergrondthread klaar is met het aanbrengen van wijzigingen in de beheerde objectcontext, is er een API voor het samenvoegen van alle wijzigingen in de beheerde objectcontext van de hoofdthread - die kan worden geconfigureerd om eenvoudig alle wijzigingen weg te gooien als er conflicten zijn veroorzaakt door de gebruiker verandert gegevens terwijl de synchronisatie bezig is. In dat geval wacht ik een paar seconden en probeer dan opnieuw te synchroniseren.
Op oudere hardware was het zelfs na vele optimalisaties nodig om de synchronisatie volledig af te breken als de gebruiker dingen in de app gaat doen. Het gebruikte gewoon te veel systeembronnen. Ik denk dat modernere iOS-apparaten waarschijnlijk snel genoeg zijn, dat hoef je niet meer te doen.
(Trouwens, toen ik zei "veel records zijn veranderd" bedoelde ik ongeveer 30.000 rijen die worden bijgewerkt of ingevoegd op de telefoon)