iOS - Core Data and Server Database Synchronizatio

This question already has an answer here:

Client-server synchronization pattern / algorithm? 6 answers

I am starting to setup the core data model for a large scale app, and was hoping for some feedback on proper synchronization methods/techniques when it comes to server database and offline capabilities.

I use PHP and mySQL for my web server / database.

I already know how to connect, receive data, store to core data, etc etc. I am looking more for help with the methodologies and particular instances of tracking data changes to:

A) Ensure the app and server are in sync during online and offline use (i.e. offline activity will get pushed up once back online). B) Optimize the speed of saving data to the app.

My main questions are:

What is the best way to check what new/updated data in the app still needs to be synchronized (after offline use)?

(i.e. In all my Core Data Entities I put a 'isSynchronized' attribute of BOOL type. Then update to 'YES' once successfully submitted and response is sent back from server). Is this the best way?

What is the best way to optimize speed of saving data from server to core data?

(i.e. How can I only update data in Core Data that is older than what is on server database without iterating through each entity and just updating every single time)? Is it possible without adding a server database column for tracking update timestamps to EVERY table?

Again, I already know how to download data and store it to Core Data, I am just looking for some help with best practices in ensuring synchronization across app and server databases while ensuring optimized processing time.

I store a last modified timestamp in the database on both the core data records on the phone, and the mysql tables on the server.

The phone searches for everything that has changed since the last sync and sends it up to the server along with a timestamp of the last sync, and the server responds with everything that has changed on it's end since the provided sync timestamp.

Performance is an issue when a lot of records have changed. I do the sync on a background NSOpeartion which has it's own managed object context. When the background thread has finished making changes to it's managed object context, there is an API for merging all of the changes into the main thread's managed object context - which can be configured to simply throw away all the changes if there are any conflicts caused by the user changing data while the sync is going on. In that case, I just wait a few seconds and then try doing a sync again.

On older hardware even after many optimisations it was necessary to abort the sync entirely if the user starts doing stuff in the app. It was simply using too many system resources. I think more modern iOS devices are probably fast enough you don't need to do that anymore.

(by the way, when I said "a lot of records have changed" I meant 30,000 or so rows being updated or inserted on the phone)