
Why Building a Mobile App is Hard - jamesjyu
http://blog.parse.com/2012/01/31/why-building-a-mobile-app-is-hard/
======
untog
Maybe I'm missing something here (and please tell me if I am) but isn't the
server side of apps the easiest part? It's the best practised part, at the
very least.

I've been making web sites for years, so the idea of a server running a
database and a back-end platform that works over HTTP is anything but alien.
I'm working on an app right now and got the backend stuff working very
quickly.

The client-side was an entirely different matter, however- synchronising local
data with remote was a challenge, but easily doable. Coping with zero network
connectivity, patchy geolocation, creating a touch-based UI.... _that_ is the
stuff we haven't faced before, and that's the stuff that is the most
challenging.

~~~
poutine
Indeed it's much easier if you're proficient in both.

I've written a number of non-trivial IOS apps that are heavily server based.
I've done both the server side (Ruby Sinatra API App, MongoDB, Varnish) and
the client side (Obj-C naturally) and consider myself equally proficient in
both.

The client generally takes much longer to write and debug than the server due
to all the little issues with having a smooth, non blocking UI, network
availability, juggling data and managing resources that you have with the
client app. Not to mention any custom UI controls you make.

~~~
SimHacker
Being proficient in both the client and server is like tying both your shoes
with two hands. But only being proficient in one is like trying to tie one
shoe with one hand, and get somebody else to tie your other shoe with one of
their hands.

------
nsxwolf
It's hard, but parse.com can make it a whole lot easier. Got it.

Your service is useful, but not all mobile backend requirements can be solved
with cloud storage of key/value pairs.

~~~
lacker
_Not all mobile backend requirements can be solved with cloud storage of
key/value pairs._

This statement is completely correct, which is why Parse is adding so many
features besides just key/value storage. You can already store relational
data, do geo-searches, user authentication, file storage, push notifications,
and lots of other stuff.

See: <https://www.parse.com/docs/ios_guide>

Our goal is to let you write _any_ application without running your own
server. If you think you can't build your application on Parse, drop us a line
at feedback@parse.com and we will be glad to either figure out how it can be
done, or put it on our todo list.

~~~
nsxwolf
These are also great features. But what happens to that customer that one day
realizes they need just "one more" feature - and that feature happens to
require they start running their own enterprise?

Not trying to be overly critical here, what you've built is very enabling for
a lot of app creators. But it seems to me that any really successful client of
yours will eventually outgrow your feature set and need to migrate to a custom
solution.

At that point I don't know how you hold on to those customers without needing
to build something like a Heroku.

~~~
lacker
_I don't know how you hold on to those customers without needing to build
something like a Heroku._

This is a good point. One convenient feature of the Parse platform is that
it's located on EC2, so developers can run their own servers on Heroku or just
EC2 itself with <2ms latency to Parse if they need to run any generic code. So
we can let Heroku build Heroku, and just make Parse work really well in
conjunction.

I think right now we have reasonable solutions for this. We would like the
solutions to be not just reasonable, but amazing. So there are a lot of other
ideas we have to make this sort of development easier. We're working on it.

~~~
olegp
Have you considered making or supporting a slimmed down open source version of
Parse? That way developers could self host and extend as necessary. Having the
option to self host would probably increase adoption of your core offering.

~~~
lacker
We're thinking about it. Some components would be easier than others to
decouple from our scaling systems, so it's a tricky technical question.

