iOS Developing apps that need backend servers

[MaxFreud]

Hi all,

I brainstorm a lot of app ideas with my friends sometimes, but it seems like a majority of these ideas (useful apps in general) would require some sort of infrastructure (namely, a lot of servers) that is beyond my reach as an individual developer.

I was wondering if any indie developers here have found a way to solve this problem, especially since the app store is pretty saturated with all manner of stand-alone apps.

Cheers,
Max

 

[chown33]

Please give some examples of the kinds of servers you'd need.

Google's AppEngine is one way to have "servers". I was going to use it in a product recently (hardware, not an app), but changed the design so it wasn't needed.

I've also uses Amazon Web Services as "servers", both real and pretend. If it's just some public URLs that need occasional updating (public read, private write), the S3 service works well for that. If you need a real CPU, running your own actual server, replying with dynamic content, then the EC2 service works well. You can also combine them: EC2 transfers to and from S3 are free.

There are probably other options, too, but without knowing the kind of services you'd need, nor the scale involved, it's difficult to suggest anything.

 

[PhoneyDeveloper]

Having a web site/server costs 8.95/month. Anyone can have a server. The hard part is writing the code that runs on the server.

 

[dantastic]

Um, I've hosting through go daddy and it's a couple of dollars per year. I really can't see the problem...
You can use the one account for as many apps as you want

 

[RodThePlod]

I was wondering if any indie developers here have found a way to solve this problem, especially since the app store is pretty saturated with all manner of stand-alone apps.

Yup - very easy to do. My first app in the store back in 2009 used (and still uses) a mySQL database running via php scripts (on cron jobs) on a back-end server that I pay lass than £5 per month for. And I host other things on there as well.

If you're going down this route, make sure you app is fault-tolerant and that it will continue to work gracefully even when the server cannot be contacted (i.e. there's no internet connection).

In my case, I achieved this with lots of cacheing of data when the connection is available.

Cheers,

RTP.

 

[MaxFreud]

Thanks for all the helpful replies.

The original idea that got me thinking about this was a tool to monitor users' locations and give them info they'd be interested in about specific locations (very foursquare-esque) but I would need servers for push notifications and I doubted that a simple web server would handle the potential traffic (although I realize this was a stupid thought, as I should start small anyway and scale if needed).

You guys gave me some great ideas. Thanks!

 

[chown33]

The original idea that got me thinking about this was a tool to monitor users' locations and give them info they'd be interested in about specific locations (very foursquare-esque) but I would need servers for push notifications and I doubted that a simple web server would handle the potential traffic (although I realize this was a stupid thought, as I should start small anyway and scale if needed).

I don't see why it would need push notifications.

The user's app (i.e. the agent) watches the device's location. When it changes significantly enough, it sends an HTTP request to a server with the new location. The server's reply is a list of potentially interesting things in that vicinity, for however you want to define "interesting" and "vicinity".

The HTTP request could be anything that provides a position, such as lat/lon. The HTTP server itself could be serving nothing but static content, if the positions are arranged in a regular pattern. So it COULD be a "simple web server" if you build the app and the service that way.

When I say "static content" I mean the HTTP server itself need not generate dynamic content. It could be serving nothing but static resources. For example, it could be an S3 bucket with a bunch of public-readable content. There would be a backend process that runs periodically to update the contents of the static resources, as new content becomes available or old content drops out. Since the content is being served by the S3 service, not a dedicated web-server, you don't have to worry about whether the HTTP server gets overloaded or not.