I haven't used the buildpack, but based on working with Parse and watching the screencast, here are some guesses:
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.
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.