So to start off, I'll mention that you've been a bit vague on the details of your client/server app. You haven't mentioned what kind of data you'll be serving (static vs dynamic). Along the same lines, you haven't described the architecture of your iOS client. Will your clients periodically poll for new data (pull), or will you need to send them realtime updates every now and then (push). Having said that, here are a few things to consider:
What are the limitations of HTTP POST and GET requests?
For the most common types of applications utilizing the client/server architecture,
GET requests are quite adequate. Most webservices are built on this model. This works fine for if/when your app needs to periodically send or receive data from the server. You app has to be able to efficiently utilize battery life and this is a reasonable archtitecture for this scenario.
If your app somehow deals with realtime data, polling is no longer an option. If, for example, you build a chat application. You cannot expect to continuously poll for new (chat) messages and also reasonably conserve battery life. This is where push technology comes into play. Now how would you use push technology along with regular HTTP
GET? Quite simple. Whenever your server has something new for the client, it sends a wakeup signal to your app, at which time your app initiates a
GET and fetches this new data (like it normally would). Both iOS and Android have this feature in the form of Apple Push Notifications and C2DM.
If you plan to create a production application in the App Store, I would not recommend you host your server at home (I cannot stress this enough). Now no matter where you plan to host it, you have a few things to consider:
- Do you have the expertise to administer/maintain/patch this server?
- If at home, will you have a contingency plan for your app in the scenario your your network goes down (or gets saturated), etc?
- Are you reasonably comfortable administering an Apache HTTP server and are you able to fine tune it for if/when your app grows?
- If you go with Amazon EC2, are you comfortable administering/maintaining/patching a (CLI) Linux server?
- Have you considered an alternative like Google App Engine (or a similar service)?
Building a webapp that can serve
HTTP requests on App Engine is quite simple and you have the option of using Java, Python, and a few other languages. The advantage here is that if/when your app becomes popular, App Engine will take care of the scaling for you with no more effort on your part. Also, if your app is small enough, you can quite easily stay within the free tier which would satisfy your price requirement (see pricing).
My final recommendation to you would be to use a service like App Engine just because all the nitty gritty details (below your app layer) are abstracted for you and it's something you won't have to think about. You won't have to worry about physical hardware (server at home) or scalability (server on EC2) - all this will be magically handled for you!