We are developing an iOS application that needs to synchronize with a remote server using web services. The existing web services have an "operations" style rather than REST (implemented in WCF but exposing JSON HTTP endpoints). We are unsure of how to structure the web services to best fit with iOS and would love some advice. We are also interested in how to manage the synchronization process within iOS.

Without going into detailed specifics, the application allows the user to estimate repair costs at a remote site. These costs are broken down by room and item. If the user has an internet connection this data can be sent back to the server.

Multiple photographs can be taken of each item, but they will be held in a separate queue, which sends when the connection is optimal (ideally wifi).

Our backend application controls the unique ids for each room and item. Thus, each time we send these costs to the server, the server echoes the central database ids back, thus, that they can be synchronized in the mobile app. I have simplified this a little, since the operations contract is actually much larger, but I just want to illustrate the basic requirements without complicating matters.

Firstly, the web service architecture: We currently have two operations: GetCosts and UpdateCosts.

My assumption is that if we used a strict REST architecture we would need to break our single web service operations into multiple smaller services. This would make the services much more chatty and we would also have to guarantee a delivery order from the app. For example, we need to make sure that containing rooms are added before the item.

Although this seems much more RESTful, our perception is that these extra calls are expensive connections (security checks, database calls, etc). Does the type of web api (operation over service focus) determine chunky vs chatty? Since this is mobile (3G), are we better handling lots of smaller messages, or a few large ones?

Secondly, the iOS side. What is the current advice on how to manage data synchronization within the iOS (5) app itself. We need multiple queues and we need to guarantee delivery order in each queue (and technically, ordering between queues). The server needs to control unique ids and other properties and echo them back to the application. The application then needs to update an internal database and when re-updating, make sure the correct ids are available in the update message (essentially multiple inserts and updates in one call).

Our backend has a ton of business logic operating on these cost estimates. We don't want any of this in the app itself.

Currently the iOS app sends the cost data, and then the server echoes that data back with populated ids (and other data). The existing cost data is deleted and the echoed response data is added to the client database on the device. This is causing us problems, because any photos might not have been sent, but the original entity tree has been removed and replaced. Obviously updating the costs tree rather than replacing it would remove this problem, but I'm not sure if there are any nice xcode libraries out there to do such things.

I welcome any advice you might have.

  • You might want to look at Service Stack. It's a bit neater in its approach to these kinds of things - much easier to implement and deploy than WCF.
    – Kyle
    Jun 14, 2012 at 17:32
  • @KyleHodgson We are reviewing both ServiceStack and MVC4 Web API for the backend. iOS sync is still our primary issue. I agree though, WCF config isn't fun.
    – Rebecca
    Jun 20, 2012 at 15:10

1 Answer 1


On mobile based device Andriod/iOS limiting bandwidth is key. We used WCF JSON (if I was doing it now would use WebAPI MVC4) and Msmq to ensure message delivery. Server pushes data to mobile device by placing into a Msmq. Wcf always reads from Msmq for any requests Mobile device stores data in SQLite and uses local queue to send and relieve data.

I am not familiar with IOS but I assume local data store can be used as a queue

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.