Why Building a Mobile App is Hard | Hacker News Reader

Why Building a Mobile App is Hard

blog.parse.com

43 pointsjamesjyu17 comments

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.

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.

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.

One piece you are missing is that the server side needs to be asynchronous. A well written mobile app will be doing things in the background as the UI can't be coupled to network activity. There can be network glitches, temporary disconnects, abrupt closes of the app etc.

If you have a crappy server API this pushes a lot more complexity onto the client, or it just makes for more ways to have different failures. A well designed server API works best with a well designed client, but being messy on either means more work on the other.

I've been doing client-side application development my entire career, so server side stuff is the largest hurdle for me. I've quit partway through 3 rails projects so far.

I suppose it is a matter of perspective- I am one of those people that transitioned from web sites to apps (well, I do both)... I hadn't thought about people that transitioned from desktop apps to mobile apps.

> was a challenge, but easily doable

How was it both a challenge and easy? Do you mean once you discovered the correct method the implementation was easy?

Effectively, yes. Thinking about syncing the data as a concept was challenging: how do I track which rows have changed? How do I confirm that the data transfer was successful? etc. etc. All new concepts that I didn't have to worry about so much with a web site.

The actual implementation was relatively simple though, and worked well. That said, I'll admit the sync functionality my app needs is about as simple as it gets. I'm sure there are more complex scenarios out there.

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.

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.

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.

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.

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.

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.

Do you have a "b2b" api so I can host most of the data and services in Parse, then have an external server handle the stuff you can't do? So you call back to my external server when something I'm interested in changes, and my server can push stuff into Parse and to the clients.

We do not have this right now - you have to call the external server directly, and then that external server can call Parse. We do want to make something like this work once we figure out how to do it right.

Well, the guys and gals at Parse have got to start somewhere.

If I was looking to make a minimum viable product to attract investors then I'd probably use a service like Parse to speed up development.

Once you're swimming in investor dollars you can worry about hiring people to build your own custom back end that has all the bells and whistles you want.

Reply on news.ycombinator.com