I'm developing an application, in iOS, that is required to connect to my Windows Server to poll for new data, update, etc. As a seasoned C# developer, my first instinct is to start a new project in Visual Studio and select Web Service, letting my bias (and comfort level) dictate the service layer of my application.

However, I don't want to be biased, and I don't base my decision on a service which I am very familiar with, at the cost of performance.

  • I would like to know what other developers have had success using, and if there is a default standard for iOS service layer development?
  • Are there protocols that are easier to consume than others within iOS?
  • Better ones for the size and/or compression of data?
  • Is there anything wrong with using SOAP?

I know it's "big" in comparison to protocols like JSON.

4 Answers 4


iOS applications run on constrained devices, which is the first and foremost thing to keep in mind. Those constrained devices are actually pretty capable, but do consider the following:

  • XML is non-trivial to parse. If the requests are small and the data payload is not structured, there is no inherent benefit to using SOAP.
  • Apple has reasonably set high expectations for how responsive a web bound application is, processing has to be really fast.
  • Question for you: does the iOS have good SOAP support, or do you have to roll your own?
  • REST style services (i.e. simple HTTP requests/posts with XML, JSON, or plain text responses) are usually low impact and easy to code on both client and server.
  • How do you intend to/do you need to implement security?

Each of these points and questions can help you come to the right answer for your application. I don't know enough about the iOS API to talk toward it's support for SOAP based messaging--but it's something you need to consider. Is there anything inherently wrong in SOAP? Not necessarily, but it is definitely like trying to kill a wasp with a sledgehammer in some cases. It'll get the job done but the collateral damage is significant.

You will want something that is easy to invoke and process on your target platform. This principle doesn't change if you suddenly decide to do Android apps in addition to the iOS apps. Your conclusion might change, but the reasoning to get to that answer will be the same.

  • +1 but, as a Monty Python fan, I prefer mosquito hunting with a bazooka ;)
    – JeffO
    Apr 6, 2011 at 17:29
  • Ooh, I like that... I'll have to use that one next time! Apr 6, 2011 at 17:38

As a .NET developer with several iOS apps out there (a few of which use a .NET backend) I would advise against using SOAP Web Services unless you have very specific needs that can only be met by using them.

If the question is just transferring data back and forth, then I'd suggest using JSON since it is almost 100% data and very easy to write and parse. Depending on your data, you may find that using XML bloats the size (and therefore the delay) of getting your data to unacceptable levels. What may not be noticeable on a multicore PC can often become impractical on a mobile device. Unfortunately, even though the device is far less capable, people's standards are generally even higher.

What I've done is to create an ASPX page that parses query string parameters to determine the request and then writes back to the response stream a JSON file. In fact, in one instance I have the server hit an RSS feed, strip the XML out and put it in a JSON format (cached locally) before returning it to the device just to speed up that process as well.

This process is actually very simple from both the server and app development perspectives. This may or may not work for your situation, but works very well for me.


JSON or POX is probably the best option. And there is quite a bit to be said for just serving the JSON out of either dedicated IHttpHandlers or a simple ASP.NET MVC app. But you could also use WCF plus webHttp bindings if you are more comfortable with that.


iOS you say... so a mobile application? What are the chances your app will some day be ported to Android, RIM, WP7 or other yet to be invented clients?

I would try to remain client agnostic where feasible, so my instinct would be to go for a REST API returning XML and/or JSON. I wouldn't rule out WCF, it does have a pretty good REST stry these days, but having used ASP.Net MVC for a couple of years I'd look at that first.

Your Answer

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

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