7 ms·

Show HN: Clutch.io helps you build iOS apps fast and update them instantly

290 points by ericflo 15y ago

ericflo 15y ago
We originally launched an app called "Can'tWait!" and we ended up having a really hard time iterating fast on the product after it was launched. Little-by-little over the course of several months, we ended up building all of this syncing and hybrid-integration stuff to help us iterate faster. At some point we realized we had gotten so much faster with these tools, that we had to make them available to everyone. Clutch.io is our MVP for bringing those tools to the world.
- deleted 15y ago
  [deleted]
- brianstorms 15y ago
  Eric, who did the video on the homepage? Did you guys do it yourselves, or farm it out? What tool(s) were used? I have a project that needs a video with that kind of look, and would love some pointers! Thnx
  - etmaguire 15y ago
    Hey there, we did all the videos ourselves. We created most of the graphics in Photoshop and animated them in After Effects, we recorded the voiceover in Audacity and did the final audio with music in garageband. Oh and we purchased the audio loop from audiojungle.com. Cheap but they have some decent stuff, you just have to find it ;) Hope that helps!
    - brainless 15y ago
      Absolutely loved the video. Thanks for telling us how you did that.
    - eberfreitas 15y ago
      We always get songs for our videos at AudioJungle. It's a great resource! Thanks for the tip about After Effects!
    - bambax 15y ago
      > showing you the most imPPPortant things (~00:52) You really should use an anti-pop filter; you can make one yourself with a pair of stockings and a wire hanger.
    - ed209 15y ago
      thanks for the info. recently spotted a question on quora on this exact topic in case anyone wants more tips http://www.quora.com/Is-there-a-cheap-way-to-make-an-explanatory-video-early-on-at-a-startup http://www.quora.com/Is-there-a-cheap-way-to-make-an-explana... I've linked to your comment here. Isn't After Effects expensive though?
    - user24 15y ago
      I was surprised to see "Go fuck yourself" on the video (0:39). Was that a mistake or a conscious decision? Otherwise, it's a very slick professional video.
- smashing 15y ago
  Is that your elevator pitch? Because its pretty good.
Sujan 15y ago
Nice. I don't agree really on your definiton or usage of "hybrid". For me, your are just a different form of hybrid. Let me explain: With Phonegap the "shell" or container is native, the rest is webview. So this is "hybrid". If I got your approach right your container includes a bigger bit of native logic and you sparkle some smaller html webviews through the apps. So Phonegap apps tend to be "little container, much webview" while yours are more "much container and app, little webview". Correct? But this is a detail, I still like the concept and page.
- ericflo 15y ago
  Thanks! I wish there were a better word. We actually struggle with this because when we initially explain the concept, people tend to gravitate towards thinking of it like PhoneGap. So, I wish a more descriptive word existed for what we've built, but I think "hybrid" is what we're stuck with--at least for a while.
  - gavingmiller 15y ago
    Can you elaborate some more on how clutch differs from phonegap. Or why I'd choose clutch instead of phonegap.
    - ericflo 15y ago
      There are two main differences: syncing of code, and philosophy. The main tangible difference is that we enable you to push out incremental updates to your app, immediately. And to do so in a way that your app feels completely native. PhoneGap does not offer this. The only way to do it with PhoneGap is to actually point their UIWebView instance at a URL on the live internet, which makes your app slow. That, or you'll have to build a lot of complicated syncing and caching and updating stuff, which is what we've built. The second difference is more philosophical. That is, for most apps, we don't believe that you should attempt to write a whole app inside a web view. It just leads to apps that don't feel native. So our approach, and the one that Clutch has been tuned for, is where you build most of your app using native tools. Then, you use Clutch to build out certain display areas using web tech. I hope that answers your question.
Sujan 15y ago
You mention the facebook app directly on the line between hybrid and multi-platform (https://clutch.io/clutch-hybrid/ https://clutch.io/clutch-hybrid/). Do you know an examination or break-down of the facebook mobile app (or any of the others you mention in the graph) where I can read about how these apps really do it?
- ericflo 15y ago
  I'm not aware of any central place where you can go to learn more about all of the apps. But in the case of Facebook you can find out more how they do it here: * Go to https://apps.facebook.com/feightlive/ https://apps.facebook.com/feightlive/ * Go to the f8 | Developer tab * Click "Building Great Social Apps" * Hit "previous segments" * Go the end, "F8 inside HTML5 development at Facebook"
  - armandososa 15y ago
    direct link: http://www.livestream.com/f8socialapps/video?clipId=pla_e174c0e5-4d1d-4ca1-a4af-23edb3b9e616 http://www.livestream.com/f8socialapps/video?clipId=pla_e174...
  - Sujan 15y ago
    Thanks.
  - Sujan 15y ago
    Hm, actually he talked much and didn't say anything. After this presentation it could be a simple Phonegap container, some native plugins and the feed and stuff in a web view. Guess I have to go poke around myself.
DrJokepu 15y ago
Really cool stuff and I'm not trying to sound negative, but I can't help but think that if you guys get successful with this product (which I hope you will) one of your customers will sooner or later use it to work around the App Store submission process in order to violate the rules in a very visible manner (say for instance, to push porn to the App Store) and in response Apple will decide to reject every app based on your tool in the future. Do you think this is a possible course of events? Are you prepared for it somehow?
- ericflo 15y ago
  That's a valid point, and one we've actually thought about a decent amount. If we find anyone doing this, we will take steps on our end to make sure they stop. In the end, it's Apple's decision whether to ban a developer or not, no matter which tools or frameworks they use. A developer would not be wise to do this because they risk being banned from us as well as being banned from Apple.
  - deleted 15y ago
    [deleted]
  - rhizome 15y ago
    Oh no, the risk is much, much greater for you if you're planning on creating any more AStore apps using the developer id in this one.
    - ericflo 15y ago
      Every developer submits to the app store using their own id, not ours.
      - pooriaazimi 15y ago
        Flurry pissed Steve Jobs off, and he banned all analytics tools from the App Store for quite a long time (they could only be used for advertising purposes). SJ's own words, at D8 conference: http://itunes.apple.com/us/podcast/steve-jobs-at-d8-conference/id377953458 http://itunes.apple.com/us/podcast/steve-jobs-at-d8-conferen... They also banned interpreted codes (including Lua), but later relaxed this restriction: http://www.appleinsider.com/articles/10/06/11/apple_relaxes_ios_sdk_to_allow_lua_but_block_flash.html http://www.appleinsider.com/articles/10/06/11/apple_relaxes_... If you (or one of your customers) pisses them off, they'll ban all of you. You should be very careful.
charlietran 15y ago
Solid landing page and probably a neat service, but my good impression of your company deteriorated when I saw an image scroll by with "go fuck yourself" at 0:38 in your demo video. I'm all for lowbrow net humor, but its place is not within an otherwise professional looking site.
- ericflo 15y ago
  Whoops! That video is in the process of being updated, and that's one of the things that's being changed. I'll admit that I forgot about that detail, which was careless before showing HN :(
  - hinathan 15y ago
    Then again, people could stand to relax a bit. I thought it was kinda funny.
    - CGamesPlay 15y ago
      It was comically out of place, more than anything else.
  - underwater 15y ago
    You might also want to change "Html" to "HTML".
- damian2000 15y ago
  They are aiming for the brogrammer market ;-)
ajasmin 15y ago
Didn't Apple have some rules preventing apps from downloading code from the Internet?
- objclxt 15y ago
  They do, but this isn't really downloading 'code'. "Apps that download code in any way will be rejected", but you're not downloading it: you're executing JavaScript, which is totally permissible. To put it another way: this idea isn't unique, although the packaging might be - there are several frameworks that do similar things (some proprietary internal tools, similar to how this seems to have started) with live apps on the store.
  - greendestiny 15y ago
    Actually I think the rule is more like - the only scripting is javascript and it must be downloaded and executed by a UIWebkit view.
- bri3d 15y ago
  They allow data to be downloaded, and they allow web content (HTML + JavaScript) to be downloaded. Hence, it's possible to use a combination of native-interfaced templating and sandboxed JavaScript (i.e. "put native button with title n here and attach it to this JS action") to make native-feeling downloaded apps. Presumably these restrictions are designed so that the only code which hasn't been through their static analysis tool is sandboxed, and they trust their JS sandbox to keep the JS where it belongs. Just like most of the Apple restrictions, it's pretty arbitrary in practice, because their "prevent private API usage" static analyzer is not very good (Camera+ was able to use restricted APIs simply by invoking a selector constructed via interpolation).
  - pkghost 15y ago
    Apple's static analyzer will catch you if you import/include private framework headers, but it can't stop you from sending messages to private framework objects that are sitting around at runtime because it's a dynamically typed language, which means it resolves method calls at runtime, and static analysis can't touch runtime[1]. http://www.youtube.com/watch?v=otCpCn0l4Wo#t=21s http://www.youtube.com/watch?v=otCpCn0l4Wo#t=21s 1. Otherwise, it would be dynamic analysis.
objclxt 15y ago
I think it's an interesting product, but one of the biggest arguments for web technologies on native apps is reducing the cross platform burden. Your example uses Parse as the data backend - I think Parse would be far less well received if it only supported iOS. I wonder if you're considering supporting additional platforms? "Update your apps without pushing updates to the store" is a good problem to solve...but if you're going to extrapolate your native logic and encapsulate it in JavaScript I'd hope the next step might be an Android library to complement the iOS one.
- ericflo 15y ago
  We are planning an Android release. You will be able to re-use most or all of your web portions, which we're really excited about. Our bet is that today this will help some iOS developers enough to use, and when we release Android it will bring that many more developers into the fold.
  - objclxt 15y ago
    That's good news: I think with more than one platform the advantages of a web-based approach really become apparent.
  - SomeCallMeTim 15y ago
    Honestly, it's not useful to me until it's cross-platform, and your one "killer feature" that other enhanced JavaScript wrappers don't have is explicitly against Apple's developer TOS. I would worry about releasing this feature publicly at all, since it might jeopardize your existing apps when Apple realizes you're able to push changes to code. They used to ban all scripting languages in large part because they were worried about developers pushing new code to apps; after a lot of pressure from various directions, they relaxed the scripting language restriction, but it's still quite explicitly against the developer agreement to ever download new code to an app.
- newhouseb 15y ago
  I'm really hoping Apple eventually migrates to automatic binary diff patch application much like how Google Chrome operates. Chrome has proved that you can get all the rapid iteration and development you could dream of without sacrificing performance.
mmmmax 15y ago
This is f-ing awesome, nice work. How long have you been working on it?
- ericflo 15y ago
  Thanks! It's hard to say how long we've been working on it because it evolved out of our last project. We split it out towards the end of last year and we've been in private beta for a few months working out the kinks.
lukifer 15y ago
The business model seems a little odd; I assume by "monthly users", you mean end users? And the only plan that supports unlimited users is custom-priced? I'm loving the platform as a concept, but to have a cap on the total number of users feels strange and scary. What happens if I go over this cap? Do users who stop using the app still count against the total? What about a single user with 2+ devices?
- ericflo 15y ago
  Yes, "monthly users" means end users. However, like you pointed out, we can't differentiate between a user and a device. Maybe our marketing should say "monthly active devices." In any case, this is good feedback for us to hear, because it could indicate that our pricing still needs work. Thanks! EDIT: Realized I forgot to answer your second question. If you go over your cap, users will still be able to use the app 100% uninterrupted--you just won't be able to push out any updates to those users.
  - ollerac 15y ago
    Ya, that part of the pricing page scared me too. I think adding a plan for unlimited users that had a set price would assuage many people's fears.
    - manmal 15y ago
      They have to first find out what pushing updates actually costs them in hardware and traffic costs (and perhaps even support costs). I'm sure they will add a fixed-price unlimited plan when they have found out.
matclayton 15y ago
Awesome idea, I've wanted something like this for iOS/Android for a long time. It would be nice to have a self hosted version, with a one off fee.
arturhoo 15y ago
I'm new to iOS development, can you briefly explain how your solution differentiates from the following: Sencha Touch, Appcelerator Titanium and Phonegap Thank you!
- ericflo 15y ago
  I just wrote up a few thoughts about this here: http://news.ycombinator.com/item?id=3800522 http://news.ycombinator.com/item?id=3800522
botj 15y ago
Ironically, the video cannot be played on a stock iPhone.
janj 15y ago
The pricing seems funny. The Gold plan is more than twice the price of the Silver plan but you get only twice the product. Similar but worse when going from gold to platinum.
- damian2000 15y ago
  Gold has got unlimited apps compared to 2 apps for silver. But yeah agreed the platinum pricing seems broken.
bmelton 15y ago
Wow. It hardly seems like there's been enough time between Convore and this for this to look as solid as it does. Grats ericflo and company. Any ideas on an approximate time table for when the Android version might be expected? (ballpark is fine, months vs years is the kind of answer I'm hoping to find.) Offtopic, I feel like I should start a poll for who says "sue dough" vs "sue doo". It struck me as funny when I heard it in the video backwards from how I say it.
- dsrguru 15y ago
  I've always tried to say "sue doo" to be etymologically correct, but it always seems to come out rhyming with pseudo. :)
IanDrake 15y ago
Neat idea. Pricing: The more end user seats you buy, the more expensive they are? Doesn't seem right.
dave1619 15y ago
Your pricing is seriously flawed IMHO. I was really interested in the concept of Clutch.io because we struggle with iteration speed on the iOS platform. But we've got users in the millions and it's scary what "custom" is going to charge. In the iOS/Android world, there are lots of apps with millions of users and I don't think you're pricing model reflects that. And it's not if you have millions of users that your app is raking it in either. It might be a free app and making nominal ad money, which a significant portion seems it would go to pay for Clutch.io.
- ericflo 15y ago
  This really was our first stab at it--I'd love to talk more with you about this. You can probably change our mind about the direction we've gone with the pricing. Please e-mail me ericflo at clutch dot io.
  - dave1619 15y ago
    I'm also confused as to what exactly clutch.io does. Are you hosting files for us? Or just providing a sdk?
    - ericflo 15y ago
      It's both an SDK and a web service. Clutch gives you some JavaScript primitives and iOS code to help integrate some HTML-based content areas into your app in a very seamless way. Whenever a user opens your app, Clutch checks for (and downloads asynchronously) any new web data you've pushed to our web service, which is ready to be shown the next time the user opens your app.
- lancewiggs 15y ago
  Same - users over 1 million, and a revenue model that won't support "call us" prices.
kbutler 15y ago
It sounds like it lets you build native apps with updatable HTML/JavaScript extensions. So in the spectrum of native <-> web-app, this is closer to native, like Titanium (but more so?) and PhoneGap (now Apache Cordova) is closer to the web-app side. It differs from the others in that it provides the dynamic update capability and is intended to be embedded as a part of a native application, rather than being the full application.
hippich 15y ago
IMHO, whole selling point of app store was manual, rigid review framework for each app. Now, even if Apple will not ban all apps built on top of clutch.io, quality of apps in store degrade for sure. Strict apps review process is a feature, not a bug (i am actually "apple hater", but I see why app store successful)
- ceejayoz 15y ago
  > IMHO, whole selling point of app store was manual, rigid review framework for each app. With half a million apps in the store, I wouldn't count on much more than a cursory review. From my reading of the Clutch.io home page, this is exactly how the current version of the Facebook app works. It changes functionality quite significantly without actual app updates.
markmccubbin 15y ago
Eric, firstly I love your site, very nice landing page. I'm curious on why a developer would want to pay for your solution to what seems like a problem that most can easily solve themselves with very little investment ? (Dynamic updates, pre-caching HTML/JS and presenting it locally for rendering). The second component you offer on first blush is the JS wrapper / bridge to the native UI widgets which although might be nice to have most seasoned developers may find it a hard sell. Cross platform would be compelling although the concern there being that the JS bridge is (obviously) iOS centric and may be difficult on other platforms ( Android / Blackberry / win 7 ). Like I said, looks great I'm just curious what the value add would really be for a high volume application where cost to develop would be less than the pricing you offer (which is also of course recurring).
- ericflo 15y ago
  First, thanks for the compliment! However about the idea that people can easily build this themselves, I'm not quite convinced. I think it's possible to build 70% of the solution in a short amount of time, but that last 30% is so very fiddly (speaking from experience here.) Some of the big apps have built their own versions of this, and have gotten a piece of it wrong or have learned hard lessons along the way. It's things like race conditions when syncing, reducing bandwidth by downloading intelligently, etc. The other thing is that this is just the tip of the iceberg. The plan is to solve these same problems on Android, and then to include a comprehensive A/B testing suite, to build drop-in frontend components on top of this platform, and other cool stuff.
  - dustin 15y ago
    I like it. Looks slick and as a native iOs dev I'd strongly consider it when I want to work with more complex web views for rapid iteration. A lot of PhoneGap/Web View apps are second rate on the UI front, so if you can help developers improve that experience without a lot of work I'd say you're onto a winner. I also think you're on the right track with your A/B testing plans - doing this from scratch can be a huge chunk of work!
dain 15y ago
If we use your service do you have any terms for selling an app on the store? Do we have to give you a % or can we just freely do what we wish/if we pay your service?
- ericflo 15y ago
  It's a fixed monthly rate, so you're free to sell apps and not owe us a percentage, or anything like that.
ianlevesque 15y ago
Beautiful site, and neat idea, but I feel like we're all ignoring the elephant in the room here. Developers absolutely cannot use this service to deploy apps to the App Store. Right in the published review guidelines: "2.7 Apps that download code in any way or form will be rejected" This clearly violates that!
dwynings 15y ago
Clutch.io would be even better if they offered the ability to easily do A/B testing.
- etmaguire 15y ago
  A/B testing is def on our roadmap
matt312 15y ago
You folks may want to all-out forward clutchio.com to clutch.io. I curiously tried it out, and some may find Chrome's security alert scary.
kissuidotnet 15y ago
Looks really good! 1)really solid landing page! *really got me 2)love the "hybrid chart" (not being a techy, I got it) 3)I agree with some of the comments that I wasnt clear "where this fits", "Are you hosting files for us? Or just providing a sdk?" - but i sorta get it now. 4)It would be cool if I can build an APP entirely with Clutch.IO - though, I get it that Clutch.io isnt about that. Anyway. Thank you for doing such a great job with the site, et al!
alwillis 15y ago
First, congratulations; this looks very impressive. Just signed up. Second, how does this compare to Mulberry: http://mulberry.toura.com/ http://mulberry.toura.com/? I used Mulberry once at a hackathon and was able to create a decent demo app in a few hours using only web development tools and techniques. Thanks.
js4all 15y ago
I just tried your tutorial. It was a smooth ride. Everything worked great: creating the initial app, adding a screen and pushing updates.
kinnth 15y ago
Looks quite nifty but the app costs are really high! For a decent iPhone app your now looking at launching at free and you want to be in the millions of MAU and 100,000's of DAU to be a serious contender. This would make the app a very expensive service to base your service on?
rabc 15y ago
Cool! Another way to build crappy iPhone apps with HTML! App Store rules exist for a reason. There is better ways to make them reduce the approval time by not creating workarounds to build your app with limited HTML.
js4all 15y ago
So does this work for iPad or universal apps? If so, what needs to be changed?
motti_s 15y ago
Pushing updates is slow for a reason - it's because Apple wants to approve everything. I don't mean to sound negative but I see two scenarios, non of which is great: 1. You become a huge success and Apple is unhappy about people avoiding their scrutiny. 2. Apple doesn't mind you because you have limited traction. Having said that, I love the way you implemented it. Very clever! Good luck!
Sujan 15y ago
In the imgs source html files there is always this call to http://127.0.0.1:41676/target/target-script-min.js#anonymous http://127.0.0.1:41676/target/target-script-min.js#anonymous (see https://github.com/boilerplate/imgs/blob/master/clutchimgs/about/index.html https://github.com/boilerplate/imgs/blob/master/clutchimgs/a...) If I am correct this is weinre. Is this normally a part of production apps of clutch.io?

290 points by ericflo 15y ago

We originally launched an app called "Can'tWait!" and we ended up having a really hard time iterating fast on the product after it was launched. Little-by-little over the course of several months, we ended up building all of this syncing and hybrid-integration stuff to help us iterate faster. At some point we realized we had gotten so much faster with these tools, that we had to make them available to everyone. Clutch.io is our MVP for bringing those tools to the world.

deleted 15y ago
[deleted]
brianstorms 15y ago
Eric, who did the video on the homepage? Did you guys do it yourselves, or farm it out? What tool(s) were used? I have a project that needs a video with that kind of look, and would love some pointers! Thnx
- etmaguire 15y ago
  Hey there, we did all the videos ourselves. We created most of the graphics in Photoshop and animated them in After Effects, we recorded the voiceover in Audacity and did the final audio with music in garageband. Oh and we purchased the audio loop from audiojungle.com. Cheap but they have some decent stuff, you just have to find it ;) Hope that helps!
  - brainless 15y ago
    Absolutely loved the video. Thanks for telling us how you did that.
  - eberfreitas 15y ago
    We always get songs for our videos at AudioJungle. It's a great resource! Thanks for the tip about After Effects!
  - bambax 15y ago
    > showing you the most imPPPortant things (~00:52) You really should use an anti-pop filter; you can make one yourself with a pair of stockings and a wire hanger.
  - ed209 15y ago
    thanks for the info. recently spotted a question on quora on this exact topic in case anyone wants more tips http://www.quora.com/Is-there-a-cheap-way-to-make-an-explanatory-video-early-on-at-a-startup http://www.quora.com/Is-there-a-cheap-way-to-make-an-explana... I've linked to your comment here. Isn't After Effects expensive though?
  - user24 15y ago
    I was surprised to see "Go fuck yourself" on the video (0:39). Was that a mistake or a conscious decision? Otherwise, it's a very slick professional video.
smashing 15y ago
Is that your elevator pitch? Because its pretty good.

Sujan 15y ago

Nice. I don't agree really on your definiton or usage of "hybrid". For me, your are just a different form of hybrid. Let me explain: With Phonegap the "shell" or container is native, the rest is webview. So this is "hybrid". If I got your approach right your container includes a bigger bit of native logic and you sparkle some smaller html webviews through the apps. So Phonegap apps tend to be "little container, much webview" while yours are more "much container and app, little webview". Correct? But this is a detail, I still like the concept and page.

ericflo 15y ago
Thanks! I wish there were a better word. We actually struggle with this because when we initially explain the concept, people tend to gravitate towards thinking of it like PhoneGap. So, I wish a more descriptive word existed for what we've built, but I think "hybrid" is what we're stuck with--at least for a while.
- gavingmiller 15y ago
  Can you elaborate some more on how clutch differs from phonegap. Or why I'd choose clutch instead of phonegap.
  - ericflo 15y ago
    There are two main differences: syncing of code, and philosophy. The main tangible difference is that we enable you to push out incremental updates to your app, immediately. And to do so in a way that your app feels completely native. PhoneGap does not offer this. The only way to do it with PhoneGap is to actually point their UIWebView instance at a URL on the live internet, which makes your app slow. That, or you'll have to build a lot of complicated syncing and caching and updating stuff, which is what we've built. The second difference is more philosophical. That is, for most apps, we don't believe that you should attempt to write a whole app inside a web view. It just leads to apps that don't feel native. So our approach, and the one that Clutch has been tuned for, is where you build most of your app using native tools. Then, you use Clutch to build out certain display areas using web tech. I hope that answers your question.

Sujan 15y ago

You mention the facebook app directly on the line between hybrid and multi-platform (https://clutch.io/clutch-hybrid/ https://clutch.io/clutch-hybrid/). Do you know an examination or break-down of the facebook mobile app (or any of the others you mention in the graph) where I can read about how these apps really do it?

ericflo 15y ago
I'm not aware of any central place where you can go to learn more about all of the apps. But in the case of Facebook you can find out more how they do it here: * Go to https://apps.facebook.com/feightlive/ https://apps.facebook.com/feightlive/ * Go to the f8 | Developer tab * Click "Building Great Social Apps" * Hit "previous segments" * Go the end, "F8 inside HTML5 development at Facebook"
- armandososa 15y ago
  direct link: http://www.livestream.com/f8socialapps/video?clipId=pla_e174c0e5-4d1d-4ca1-a4af-23edb3b9e616 http://www.livestream.com/f8socialapps/video?clipId=pla_e174...
- Sujan 15y ago
  Thanks.
- Sujan 15y ago
  Hm, actually he talked much and didn't say anything. After this presentation it could be a simple Phonegap container, some native plugins and the feed and stuff in a web view. Guess I have to go poke around myself.

DrJokepu 15y ago

Really cool stuff and I'm not trying to sound negative, but I can't help but think that if you guys get successful with this product (which I hope you will) one of your customers will sooner or later use it to work around the App Store submission process in order to violate the rules in a very visible manner (say for instance, to push porn to the App Store) and in response Apple will decide to reject every app based on your tool in the future. Do you think this is a possible course of events? Are you prepared for it somehow?

ericflo 15y ago
That's a valid point, and one we've actually thought about a decent amount. If we find anyone doing this, we will take steps on our end to make sure they stop. In the end, it's Apple's decision whether to ban a developer or not, no matter which tools or frameworks they use. A developer would not be wise to do this because they risk being banned from us as well as being banned from Apple.
- deleted 15y ago
  [deleted]
- rhizome 15y ago
  Oh no, the risk is much, much greater for you if you're planning on creating any more AStore apps using the developer id in this one.
  - ericflo 15y ago
    Every developer submits to the app store using their own id, not ours.
    - pooriaazimi 15y ago
      Flurry pissed Steve Jobs off, and he banned all analytics tools from the App Store for quite a long time (they could only be used for advertising purposes). SJ's own words, at D8 conference: http://itunes.apple.com/us/podcast/steve-jobs-at-d8-conference/id377953458 http://itunes.apple.com/us/podcast/steve-jobs-at-d8-conferen... They also banned interpreted codes (including Lua), but later relaxed this restriction: http://www.appleinsider.com/articles/10/06/11/apple_relaxes_ios_sdk_to_allow_lua_but_block_flash.html http://www.appleinsider.com/articles/10/06/11/apple_relaxes_... If you (or one of your customers) pisses them off, they'll ban all of you. You should be very careful.

charlietran 15y ago

Solid landing page and probably a neat service, but my good impression of your company deteriorated when I saw an image scroll by with "go fuck yourself" at 0:38 in your demo video. I'm all for lowbrow net humor, but its place is not within an otherwise professional looking site.

ericflo 15y ago
Whoops! That video is in the process of being updated, and that's one of the things that's being changed. I'll admit that I forgot about that detail, which was careless before showing HN :(
- hinathan 15y ago
  Then again, people could stand to relax a bit. I thought it was kinda funny.
  - CGamesPlay 15y ago
    It was comically out of place, more than anything else.
- underwater 15y ago
  You might also want to change "Html" to "HTML".
damian2000 15y ago
They are aiming for the brogrammer market ;-)

ajasmin 15y ago

Didn't Apple have some rules preventing apps from downloading code from the Internet?

objclxt 15y ago
They do, but this isn't really downloading 'code'. "Apps that download code in any way will be rejected", but you're not downloading it: you're executing JavaScript, which is totally permissible. To put it another way: this idea isn't unique, although the packaging might be - there are several frameworks that do similar things (some proprietary internal tools, similar to how this seems to have started) with live apps on the store.
- greendestiny 15y ago
  Actually I think the rule is more like - the only scripting is javascript and it must be downloaded and executed by a UIWebkit view.
bri3d 15y ago
They allow data to be downloaded, and they allow web content (HTML + JavaScript) to be downloaded. Hence, it's possible to use a combination of native-interfaced templating and sandboxed JavaScript (i.e. "put native button with title n here and attach it to this JS action") to make native-feeling downloaded apps. Presumably these restrictions are designed so that the only code which hasn't been through their static analysis tool is sandboxed, and they trust their JS sandbox to keep the JS where it belongs. Just like most of the Apple restrictions, it's pretty arbitrary in practice, because their "prevent private API usage" static analyzer is not very good (Camera+ was able to use restricted APIs simply by invoking a selector constructed via interpolation).
- pkghost 15y ago
  Apple's static analyzer will catch you if you import/include private framework headers, but it can't stop you from sending messages to private framework objects that are sitting around at runtime because it's a dynamically typed language, which means it resolves method calls at runtime, and static analysis can't touch runtime[1]. http://www.youtube.com/watch?v=otCpCn0l4Wo#t=21s http://www.youtube.com/watch?v=otCpCn0l4Wo#t=21s 1. Otherwise, it would be dynamic analysis.

objclxt 15y ago

I think it's an interesting product, but one of the biggest arguments for web technologies on native apps is reducing the cross platform burden. Your example uses Parse as the data backend - I think Parse would be far less well received if it only supported iOS. I wonder if you're considering supporting additional platforms? "Update your apps without pushing updates to the store" is a good problem to solve...but if you're going to extrapolate your native logic and encapsulate it in JavaScript I'd hope the next step might be an Android library to complement the iOS one.

ericflo 15y ago
We are planning an Android release. You will be able to re-use most or all of your web portions, which we're really excited about. Our bet is that today this will help some iOS developers enough to use, and when we release Android it will bring that many more developers into the fold.
- objclxt 15y ago
  That's good news: I think with more than one platform the advantages of a web-based approach really become apparent.
- SomeCallMeTim 15y ago
  Honestly, it's not useful to me until it's cross-platform, and your one "killer feature" that other enhanced JavaScript wrappers don't have is explicitly against Apple's developer TOS. I would worry about releasing this feature publicly at all, since it might jeopardize your existing apps when Apple realizes you're able to push changes to code. They used to ban all scripting languages in large part because they were worried about developers pushing new code to apps; after a lot of pressure from various directions, they relaxed the scripting language restriction, but it's still quite explicitly against the developer agreement to ever download new code to an app.
newhouseb 15y ago
I'm really hoping Apple eventually migrates to automatic binary diff patch application much like how Google Chrome operates. Chrome has proved that you can get all the rapid iteration and development you could dream of without sacrificing performance.

mmmmax 15y ago

This is f-ing awesome, nice work. How long have you been working on it?

ericflo 15y ago
Thanks! It's hard to say how long we've been working on it because it evolved out of our last project. We split it out towards the end of last year and we've been in private beta for a few months working out the kinks.

lukifer 15y ago

The business model seems a little odd; I assume by "monthly users", you mean end users? And the only plan that supports unlimited users is custom-priced? I'm loving the platform as a concept, but to have a cap on the total number of users feels strange and scary. What happens if I go over this cap? Do users who stop using the app still count against the total? What about a single user with 2+ devices?

ericflo 15y ago
Yes, "monthly users" means end users. However, like you pointed out, we can't differentiate between a user and a device. Maybe our marketing should say "monthly active devices." In any case, this is good feedback for us to hear, because it could indicate that our pricing still needs work. Thanks! EDIT: Realized I forgot to answer your second question. If you go over your cap, users will still be able to use the app 100% uninterrupted--you just won't be able to push out any updates to those users.
- ollerac 15y ago
  Ya, that part of the pricing page scared me too. I think adding a plan for unlimited users that had a set price would assuage many people's fears.
  - manmal 15y ago
    They have to first find out what pushing updates actually costs them in hardware and traffic costs (and perhaps even support costs). I'm sure they will add a fixed-price unlimited plan when they have found out.

matclayton 15y ago

Awesome idea, I've wanted something like this for iOS/Android for a long time. It would be nice to have a self hosted version, with a one off fee.

arturhoo 15y ago

I'm new to iOS development, can you briefly explain how your solution differentiates from the following: Sencha Touch, Appcelerator Titanium and Phonegap Thank you!

ericflo 15y ago
I just wrote up a few thoughts about this here: http://news.ycombinator.com/item?id=3800522 http://news.ycombinator.com/item?id=3800522

botj 15y ago

Ironically, the video cannot be played on a stock iPhone.

janj 15y ago

The pricing seems funny. The Gold plan is more than twice the price of the Silver plan but you get only twice the product. Similar but worse when going from gold to platinum.

damian2000 15y ago
Gold has got unlimited apps compared to 2 apps for silver. But yeah agreed the platinum pricing seems broken.

bmelton 15y ago

Wow. It hardly seems like there's been enough time between Convore and this for this to look as solid as it does. Grats ericflo and company. Any ideas on an approximate time table for when the Android version might be expected? (ballpark is fine, months vs years is the kind of answer I'm hoping to find.) Offtopic, I feel like I should start a poll for who says "sue dough" vs "sue doo". It struck me as funny when I heard it in the video backwards from how I say it.

dsrguru 15y ago
I've always tried to say "sue doo" to be etymologically correct, but it always seems to come out rhyming with pseudo. :)

IanDrake 15y ago

Neat idea. Pricing: The more end user seats you buy, the more expensive they are? Doesn't seem right.

dave1619 15y ago

Your pricing is seriously flawed IMHO. I was really interested in the concept of Clutch.io because we struggle with iteration speed on the iOS platform. But we've got users in the millions and it's scary what "custom" is going to charge. In the iOS/Android world, there are lots of apps with millions of users and I don't think you're pricing model reflects that. And it's not if you have millions of users that your app is raking it in either. It might be a free app and making nominal ad money, which a significant portion seems it would go to pay for Clutch.io.

ericflo 15y ago
This really was our first stab at it--I'd love to talk more with you about this. You can probably change our mind about the direction we've gone with the pricing. Please e-mail me ericflo at clutch dot io.
- dave1619 15y ago
  I'm also confused as to what exactly clutch.io does. Are you hosting files for us? Or just providing a sdk?
  - ericflo 15y ago
    It's both an SDK and a web service. Clutch gives you some JavaScript primitives and iOS code to help integrate some HTML-based content areas into your app in a very seamless way. Whenever a user opens your app, Clutch checks for (and downloads asynchronously) any new web data you've pushed to our web service, which is ready to be shown the next time the user opens your app.
lancewiggs 15y ago
Same - users over 1 million, and a revenue model that won't support "call us" prices.

kbutler 15y ago

It sounds like it lets you build native apps with updatable HTML/JavaScript extensions. So in the spectrum of native <-> web-app, this is closer to native, like Titanium (but more so?) and PhoneGap (now Apache Cordova) is closer to the web-app side. It differs from the others in that it provides the dynamic update capability and is intended to be embedded as a part of a native application, rather than being the full application.

hippich 15y ago

IMHO, whole selling point of app store was manual, rigid review framework for each app. Now, even if Apple will not ban all apps built on top of clutch.io, quality of apps in store degrade for sure. Strict apps review process is a feature, not a bug (i am actually "apple hater", but I see why app store successful)

ceejayoz 15y ago
> IMHO, whole selling point of app store was manual, rigid review framework for each app. With half a million apps in the store, I wouldn't count on much more than a cursory review. From my reading of the Clutch.io home page, this is exactly how the current version of the Facebook app works. It changes functionality quite significantly without actual app updates.

markmccubbin 15y ago

Eric, firstly I love your site, very nice landing page. I'm curious on why a developer would want to pay for your solution to what seems like a problem that most can easily solve themselves with very little investment ? (Dynamic updates, pre-caching HTML/JS and presenting it locally for rendering). The second component you offer on first blush is the JS wrapper / bridge to the native UI widgets which although might be nice to have most seasoned developers may find it a hard sell. Cross platform would be compelling although the concern there being that the JS bridge is (obviously) iOS centric and may be difficult on other platforms ( Android / Blackberry / win 7 ). Like I said, looks great I'm just curious what the value add would really be for a high volume application where cost to develop would be less than the pricing you offer (which is also of course recurring).

ericflo 15y ago
First, thanks for the compliment! However about the idea that people can easily build this themselves, I'm not quite convinced. I think it's possible to build 70% of the solution in a short amount of time, but that last 30% is so very fiddly (speaking from experience here.) Some of the big apps have built their own versions of this, and have gotten a piece of it wrong or have learned hard lessons along the way. It's things like race conditions when syncing, reducing bandwidth by downloading intelligently, etc. The other thing is that this is just the tip of the iceberg. The plan is to solve these same problems on Android, and then to include a comprehensive A/B testing suite, to build drop-in frontend components on top of this platform, and other cool stuff.
- dustin 15y ago
  I like it. Looks slick and as a native iOs dev I'd strongly consider it when I want to work with more complex web views for rapid iteration. A lot of PhoneGap/Web View apps are second rate on the UI front, so if you can help developers improve that experience without a lot of work I'd say you're onto a winner. I also think you're on the right track with your A/B testing plans - doing this from scratch can be a huge chunk of work!

dain 15y ago

If we use your service do you have any terms for selling an app on the store? Do we have to give you a % or can we just freely do what we wish/if we pay your service?

ericflo 15y ago
It's a fixed monthly rate, so you're free to sell apps and not owe us a percentage, or anything like that.

ianlevesque 15y ago

Beautiful site, and neat idea, but I feel like we're all ignoring the elephant in the room here. Developers absolutely cannot use this service to deploy apps to the App Store. Right in the published review guidelines: "2.7 Apps that download code in any way or form will be rejected" This clearly violates that!

dwynings 15y ago

Clutch.io would be even better if they offered the ability to easily do A/B testing.

etmaguire 15y ago
A/B testing is def on our roadmap

matt312 15y ago

You folks may want to all-out forward clutchio.com to clutch.io. I curiously tried it out, and some may find Chrome's security alert scary.

kissuidotnet 15y ago

Looks really good! 1)really solid landing page! *really got me 2)love the "hybrid chart" (not being a techy, I got it) 3)I agree with some of the comments that I wasnt clear "where this fits", "Are you hosting files for us? Or just providing a sdk?" - but i sorta get it now. 4)It would be cool if I can build an APP entirely with Clutch.IO - though, I get it that Clutch.io isnt about that. Anyway. Thank you for doing such a great job with the site, et al!

alwillis 15y ago

First, congratulations; this looks very impressive. Just signed up. Second, how does this compare to Mulberry: http://mulberry.toura.com/ http://mulberry.toura.com/? I used Mulberry once at a hackathon and was able to create a decent demo app in a few hours using only web development tools and techniques. Thanks.

js4all 15y ago

I just tried your tutorial. It was a smooth ride. Everything worked great: creating the initial app, adding a screen and pushing updates.

kinnth 15y ago

Looks quite nifty but the app costs are really high! For a decent iPhone app your now looking at launching at free and you want to be in the millions of MAU and 100,000's of DAU to be a serious contender. This would make the app a very expensive service to base your service on?

rabc 15y ago

Cool! Another way to build crappy iPhone apps with HTML! App Store rules exist for a reason. There is better ways to make them reduce the approval time by not creating workarounds to build your app with limited HTML.

js4all 15y ago

So does this work for iPad or universal apps? If so, what needs to be changed?

motti_s 15y ago

Pushing updates is slow for a reason - it's because Apple wants to approve everything. I don't mean to sound negative but I see two scenarios, non of which is great: 1. You become a huge success and Apple is unhappy about people avoiding their scrutiny. 2. Apple doesn't mind you because you have limited traction. Having said that, I love the way you implemented it. Very clever! Good luck!

Sujan 15y ago

In the imgs source html files there is always this call to http://127.0.0.1:41676/target/target-script-min.js#anonymous http://127.0.0.1:41676/target/target-script-min.js#anonymous (see https://github.com/boilerplate/imgs/blob/master/clutchimgs/about/index.html https://github.com/boilerplate/imgs/blob/master/clutchimgs/a...) If I am correct this is weinre. Is this normally a part of production apps of clutch.io?