4 ms·

Why Building a Mobile App is Hard

43 points by jamesjyu 15y ago

nsxwolf 15y ago
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 15y ago
  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 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 15y ago
    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 15y ago
      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 15y ago
        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 15y ago
        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.
  - SimHacker 15y ago
    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.
    - lacker 15y ago
      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.
- arctangent 15y ago
  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.
untog 15y ago
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.
- cristoperb 15y ago
  > 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?
  - untog 15y ago
    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.
- seanalltogether 15y ago
  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.
  - untog 15y ago
    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.
deleted 15y ago
[deleted]

43 points by jamesjyu 15y ago

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 15y ago
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 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 15y ago
  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 15y ago
    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 15y ago
      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 15y ago
        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.
- SimHacker 15y ago
  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.
  - lacker 15y ago
    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.
arctangent 15y ago
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.

untog 15y ago

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.

cristoperb 15y ago
> 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?
- untog 15y ago
  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.
seanalltogether 15y ago
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.
- untog 15y ago
  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.

deleted 15y ago

[deleted]