1) Parse is more full-featured. Parse includes significant automatic support for things like modeling users, comes with UI components for e.g. sign up, and includes e.g. a UITableViewController subclass to automatically support things like automatic paging.
2) While Parse's documentation is superb, these features come at the cost of flexibility (though you don't have to use all of them, of course -- it could just be a REST backend if you wanted it to be, like the heroku buildpack seen here). You'll tie your iOS app to Parse with PFObjects, whereas you're much more flexible with a backend agnostic approach that you'll get just using a REST web service.
3) The Heroku buildpack will probably tie better to CoreData. There might be a clean approach for this with Parse (when I used it I was pretty new to iOS) but I ended up having PFObject and Core Data representations of objects, which is rather clunky. Conversely, if you aren't using Core Data, this build pack wouldn't be helpful for you.
Some conclusions: 1) people who are learning to write iOS apps and don't have experience writing a web server should probably use Parse because it will be easier. It is my suspicion, as a few others have commented, that you will run into problems like "Oh, how should I deal with user accounts and passwords" that Parse will handle, but you'll have to figure out if using the buildpack. The buildpack comes with all the advantages you'd associate with Heroku -- other people know what those are better than me.
Let me also say that Mattt Thompson is an inspiration (check out his github and NSHipster.com, which are fantastic and foreshadowed this project) and I predict this buildpack will be as awesome as he can make it.
- They are both well backed (Heroku by Salesforce money/profits, Parse by great investors), have awesome founders, talented employees, and are both YC companies.
- Parse is pretty much 100% mobile focused. This is their bread and butter.
- Heroku is Polyglot and spans dozens of platforms on multiple OS's, with no real focus.
I think this comes down to where you run the rest of your stack, how tightly you want things integrated, and which service is the easiest to use and most reliable. Is mobile 99% of what you do? Parse is probably the best choice. Is mobile 25% of your business and you're already using Heroku for everything else? I could go either way here. We use Heroku and AWS to drive 100% of our platform, but we're also not mobile (yet). I personally know the Parse guys and they are outstanding at what they do and growing at a phenomenal rate, so when we do dive into mobile I'll likely be giving them a shot first.
It seems Parse offers many nice features in addition to transparent-ish "cloud" persistence, e.g Push notifications, etc.
Heroku's approach is really interesting. The idea of building a db model from the CoreData model is (I think) really elegant, but: - I'll also need to write an Android app - AFIncrementalStore is more generic but Parse's specialized classes seem more "plug-and-play".
I'll try Parse first.
Parse is moving onto Heroku's turf as well as Heroku is moving onto Parse's.
For example I don't know how it can handle the following (kinda conventional for a web app) situation: Multiple users, some are admins and some are regular users, with some shared "data" (like, an item for sale) between the two. Moderators can add/remove/edit items and edit/remove users, users can browse/buy items, etc. - I think if you're building an app like this, you really have to roll your own CRUDful server (with ruby or whatever)...
Oh, and BTW, RestKit[1] is probably much more mature and feature-rich than AFIncrementalStore.
[1]: http://restkit.org
Unlike Storyboards, the effort you put into writing against a REST API isn't wasted if you decide to roll a new, more complex REST API (which Heroku is fantastic for).
The whole point is to get the developer up-and-running as quickly as possible. Code for the API you'll eventually have, but get by with a rough scaffolding so you can experiment and iterate rapidly.
Sometimes things are presented modally here but get navigated to normally over there - and once again you're mixing metaphors, implementing some navigation in the storyboard and some of it in code.
I thought the same thing would be true with Auto Layout, but luckily that one seems to have been a bit more "baked" when it shipped, insofar as I've not had any trouble implementing complex views with it WITHOUT ever writing any code.
What would you do if you wanted to create a web-app version of your mobile app as well?
Would you hook it up to the api that is generated?
Is there any examples out there on how to integrate it with a web-app as well?
What's the big advantage in relation to Parse? I love Heroku, but Parse seems like a really smooth solution for iOS/Mac.
Is there any security to this or is it just good for prototyping? What's to stop me from requesting user accounts with passwords?
In the meantime, you can mount Rack::CoreData (https://github.com/mattt/rack-core-data), which powers the Buildpack, alongside other authentication middleware to create a workable production application.
> This is still in early stages of development, so proceed with caution when using this in a production application. > Any bug reports, feature requests, or general feedback at this point would be greatly appreciated.
While it is a great library already, and built up from solid core frameworks, it has its share of bugs and rough edges!
lumawake.us
