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

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

clutch.io

290 pointsericflo88 comments

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.

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

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!

Absolutely loved the video. Thanks for telling us how you did that.

We always get songs for our videos at AudioJungle. It's a great resource! Thanks for the tip about After Effects!

> 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.

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-explana...

I've linked to your comment here. Isn't After Effects expensive though?

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.

Is that your elevator pitch? Because its pretty good.

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?

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.

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.

Every developer submits to the app store using their own id, not ours.

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-conferen...

They also banned interpreted codes (including Lua), but later relaxed this restriction: 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.

Anybody could do that with a UIWebView now, without this.

You can bypass apples static analysis as well by interpolating a selector at runtime. Camera+ did this to enable the volume button to be used for taking a picture.

I think to outright ban something like this, apple would have to see some really egregious exploitation.

I think to outright ban something like this, apple would have to see some really egregious exploitation.

Apple has banned similar updates mechanism already. I think, clutch will also face similar problem.

Clutch has nothing to do with this though. It's ALWAYS been possible to throw a UIWebView into your app, load a screen from a web server that you control, and replace it with porn after it's approved. Clutch simply adds a few tools on top of that to better integrate the UIWebView into your app.

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.

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.

That's good news: I think with more than one platform the advantages of a web-based approach really become apparent.

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.

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.

Apple already uses binary diffs. The only thing missing is a new UI (or lack thereof).

I'd be surprised if 'update apps automatically' doesn't become an option in iOS6 (probably after the iCloud backup completes), because having to keep going to the app store app is becoming a meaningless chore.

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?

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.

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.

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.

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.

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.

I'm also confused as to what exactly clutch.io does. Are you hosting files for us? Or just providing a sdk?

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.

Same - users over 1 million, and a revenue model that won't support "call us" prices.

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.

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

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.

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 :(

Then again, people could stand to relax a bit. I thought it was kinda funny.

It was comically out of place, more than anything else.

You might also want to change "Html" to "HTML".

They are aiming for the brogrammer market ;-)

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.

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

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.

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!

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.

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.

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).

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.

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!

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

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.

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.

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.

Can you elaborate some more on how clutch differs from phonegap. Or why I'd choose clutch instead of phonegap.

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.

Interesting. Excuse me for my ignorance here (I haven't fully looked at your product), but how do you push app updates? Is it like Heroku/git? Or do I have to "submit" it to you? Can you schedule when the update goes live?

I make a rough guess about the technology... It's like HTML5 based webapp relying on local storage. You change the remote HTML and clean the local storage for the update.

Like I mentioned in another thread, similar "push updates" mechanism have already been banned by Apple. (I don't know, why am I downvoted for informing HN users).

Could you elaborate on how it compares to Titanium? Thanks, great work.

In the imgs source html files there is always this call to http://127.0.0.1:41676/target/target-script-min.js#anonymous (see 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?

You mention the facebook app directly on the line between hybrid and multi-platform (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?

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/

* Go to the f8 | Developer tab

* Click "Building Great Social Apps"

* Hit "previous segments"

* Go the end, "F8 inside HTML5 development at Facebook"

direct link: http://www.livestream.com/f8socialapps/video?clipId=pla_e174...

Thanks.

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.

First, congratulations; this looks very impressive. Just signed up.

Second, how does this compare to Mulberry: 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.

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!

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?

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!

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

A/B testing is def on our roadmap

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

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.

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?

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

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

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!

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

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

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.

Actually I think the rule is more like - the only scripting is javascript and it must be downloaded and executed by a UIWebkit view.

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).

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

1. Otherwise, it would be dynamic analysis.

You can easily detect most trivial methods of performing direct message sends to private framework objects via static analysis - both the name of the class and the message are used as string data. You can even find a naive message send using strings and grep, regardless of the use or non-use of a header!

The use of the header is irrelevant - using

    [NSClassFromString(@"WebView") _enableRemoteInspector];

is going to show up the same way in a static analysis tool regardless of whether I made a WebView.h header defining +(void) enableRemoteInspector; or not - it compiles to the exact same thing!

You have to be at least one level more clever to defeat Apple's static analysis tool - it looks at the values of the objc_msgSend's message only. Hence, using methodForSelector defeats it - the static analyzer sees a "methodForSelector" message (which isn't blacklisted), ignores the parameters, and then sees a straight function call (also not blacklisted).

Twitter for Mac also does this to call private things on Snow Leopard.

https://github.com/twitter/twui/blob/master/lib/UIKit/TUIScr...

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

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

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)

> 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.

Reply on news.ycombinator.com