8 ms·

Build an iOS App on Heroku in 10 Minutes

132 points by matttthompson 14y ago

magicarp 14y ago
So with this, is Heroku going after Parse?
holgersindbaek 14y ago
This looks awesome. 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?
- matttthompson 14y ago
  Absolutely--you can use the same API without modification to write a web, Android, or Mac client.
  - holgersindbaek 14y ago
    That's cool. 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.
    - rhizome 14y ago
      One possible advantage would be to touch the ecosystem outside of Apple.
      - holgersindbaek 14y ago
        What do you mean by this?
      - objclxt 14y ago
        Parse has first-party SDKs for Windows Phone, OS X, iOS, JS, and Android. There are third-party interfaces for many languages (PHP, Ruby, etc). It's not an Apple-only solution.
      - matttthompson 14y ago
        Heroku is the platform of choice for thousands of iOS, Android, Windows Phone, (and mobile web, of course) applications. This screencast was merely a demonstration of what a rapid iOS development workflow with the Core Data Buildpack looks like.
    - josephlord 14y ago
      I think this and Parse are cool. This looks better for getting started quickly if you have a Core Data app. It should also be easier to customise although Parse can do more for you (user registration is built in) but you need to be on the paid ($199/month) package to use your own branded login I think. Also I can't quite tell but it might be possible to take the Heroku buildpack and deploy it on your own servers so i think you would have easier options to migrate away without a rebuild. This is worth something to me.
  - jemeshsu 14y ago
    I watched the video. How does one add user account support? For example to handle multiple users in your example task app.
pierrebouchet 14y ago
This looks like competition for Parse (and a few others I guess, but Parse was the first one I heard of). However I have tried neither. Is there anyone who's tried both? What are their pros/cons?
- cwilson 14y ago
  This isn't a purely technical pros/cons, but still a good way of looking at them both: - 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.
  - pierrebouchet 14y ago
    I'm in the "99% mobile" case. 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.
  - revicon 14y ago
    ymmv but we had a lot of problems with extreme slowness and downtime when using parse, it made development a bear and we were only using it for some testing. We wouldn't use it in production after our experience.
shaaaaawn 14y ago
this is perfect timing. We just spent the weekend getting an app deployed on heroku for desktop view. thanks! lumawake.us
iwaffles 14y ago
This seems like a really easy way for iOS developers to build/prototype apps with a cloud backend. Is there any security to this or is it just good for prototyping? What's to stop me from requesting user accounts with passwords?
- matttthompson 14y ago
  Probably not a great idea as-is, without some level of user authentication. I'm definitely working on a nice, integrated solution for that. In the meantime, you can mount Rack::CoreData (https://github.com/mattt/rack-core-data https://github.com/mattt/rack-core-data), which powers the Buildpack, alongside other authentication middleware to create a workable production application.
conradev 14y ago
Just as a general advisory, from AFIncrementalStore's README: > 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!
- conradev 14y ago
  https://github.com/AFNetworking/AFIncrementalStore/commit/530286d30e67758e6e276153f3356182419b6e2f https://github.com/AFNetworking/AFIncrementalStore/commit/53...
pooriaazimi 14y ago
Looks very nice, but I have a feeling that it's like iOS Storyboards: Great for simple demo apps, but very painful when you have slightly more complex needs. 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 http://restkit.org
- MaxGabriel 14y ago
  This is OT, but just in case there's a good solution, what were your problems with storyboards?
  - bengl3rt 14y ago
    Sometimes the app is not a strict tree of view controllers, but rather a graph containing some cycles. It is here that the whole metaphor of the navigation controller and the visual tools that Xcode gives you to automate it kind of break down and you end up writing lots of hairy custom code to manage your transitions. 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.
- matttthompson 14y ago
  > Great for simple demo apps, but very painful when you have slightly more complex needs. 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.
mmanfrin 14y ago
As someone who is just learning how to be okay at testing in rails/ruby, this both amazes and terrifies me.

132 points by matttthompson 14y ago

So with this, is Heroku going after Parse?

This looks awesome. 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?

matttthompson 14y ago
Absolutely--you can use the same API without modification to write a web, Android, or Mac client.
- holgersindbaek 14y ago
  That's cool. 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.
  - rhizome 14y ago
    One possible advantage would be to touch the ecosystem outside of Apple.
    - holgersindbaek 14y ago
      What do you mean by this?
    - objclxt 14y ago
      Parse has first-party SDKs for Windows Phone, OS X, iOS, JS, and Android. There are third-party interfaces for many languages (PHP, Ruby, etc). It's not an Apple-only solution.
    - matttthompson 14y ago
      Heroku is the platform of choice for thousands of iOS, Android, Windows Phone, (and mobile web, of course) applications. This screencast was merely a demonstration of what a rapid iOS development workflow with the Core Data Buildpack looks like.
  - josephlord 14y ago
    I think this and Parse are cool. This looks better for getting started quickly if you have a Core Data app. It should also be easier to customise although Parse can do more for you (user registration is built in) but you need to be on the paid ($199/month) package to use your own branded login I think. Also I can't quite tell but it might be possible to take the Heroku buildpack and deploy it on your own servers so i think you would have easier options to migrate away without a rebuild. This is worth something to me.
- jemeshsu 14y ago
  I watched the video. How does one add user account support? For example to handle multiple users in your example task app.

pierrebouchet 14y ago

This looks like competition for Parse (and a few others I guess, but Parse was the first one I heard of). However I have tried neither. Is there anyone who's tried both? What are their pros/cons?

cwilson 14y ago
This isn't a purely technical pros/cons, but still a good way of looking at them both: - 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.
- pierrebouchet 14y ago
  I'm in the "99% mobile" case. 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.
- revicon 14y ago
  ymmv but we had a lot of problems with extreme slowness and downtime when using parse, it made development a bear and we were only using it for some testing. We wouldn't use it in production after our experience.

shaaaaawn 14y ago

this is perfect timing. We just spent the weekend getting an app deployed on heroku for desktop view. thanks! lumawake.us

iwaffles 14y ago

This seems like a really easy way for iOS developers to build/prototype apps with a cloud backend. Is there any security to this or is it just good for prototyping? What's to stop me from requesting user accounts with passwords?

matttthompson 14y ago
Probably not a great idea as-is, without some level of user authentication. I'm definitely working on a nice, integrated solution for that. In the meantime, you can mount Rack::CoreData (https://github.com/mattt/rack-core-data https://github.com/mattt/rack-core-data), which powers the Buildpack, alongside other authentication middleware to create a workable production application.

conradev 14y ago

Just as a general advisory, from AFIncrementalStore's README: > 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!

conradev 14y ago
https://github.com/AFNetworking/AFIncrementalStore/commit/530286d30e67758e6e276153f3356182419b6e2f https://github.com/AFNetworking/AFIncrementalStore/commit/53...

pooriaazimi 14y ago

Looks very nice, but I have a feeling that it's like iOS Storyboards: Great for simple demo apps, but very painful when you have slightly more complex needs. 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 http://restkit.org

MaxGabriel 14y ago
This is OT, but just in case there's a good solution, what were your problems with storyboards?
- bengl3rt 14y ago
  Sometimes the app is not a strict tree of view controllers, but rather a graph containing some cycles. It is here that the whole metaphor of the navigation controller and the visual tools that Xcode gives you to automate it kind of break down and you end up writing lots of hairy custom code to manage your transitions. 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.
matttthompson 14y ago
> Great for simple demo apps, but very painful when you have slightly more complex needs. 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.

mmanfrin 14y ago

As someone who is just learning how to be okay at testing in rails/ruby, this both amazes and terrifies me.