
Show HN: Clutch.io helps you build iOS apps fast and update them instantly - ericflo
https://clutch.io/
======
ericflo
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.

~~~
brianstorms
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
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!

~~~
bambax
> _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.

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

~~~
rhizome
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
Every developer submits to the app store using their own id, not ours.

~~~
pooriaazimi
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...](http://itunes.apple.com/us/podcast/steve-jobs-
at-d8-conference/id377953458)

They also banned interpreted codes (including Lua), but later relaxed this
restriction:
[http://www.appleinsider.com/articles/10/06/11/apple_relaxes_...](http://www.appleinsider.com/articles/10/06/11/apple_relaxes_ios_sdk_to_allow_lua_but_block_flash.html)

If you (or one of your customers) pisses them off, they'll ban all of you. You
should be very careful.

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

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

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

------
dave1619
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
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
I'm also confused as to what exactly clutch.io does. Are you hosting files for
us? Or just providing a sdk?

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

------
bmelton
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
I've always tried to say "sue doo" to be etymologically correct, but it always
seems to come out rhyming with pseudo. :)

------
charlietran
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
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
Then again, people could stand to relax a bit. I thought it was kinda funny.

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

------
janj
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
Gold has got unlimited apps compared to 2 apps for silver. But yeah agreed the
platinum pricing seems broken.

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

------
kissuidotnet
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!

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

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

------
markmccubbin
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
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
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!

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

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

------
Sujan
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
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
Can you elaborate some more on how clutch differs from phonegap. Or why I'd
choose clutch instead of phonegap.

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

~~~
physcab
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?

~~~
johnx123-up
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).

------
Sujan
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...](https://github.com/boilerplate/imgs/blob/master/clutchimgs/about/index.html))
If I am correct this is weinre. Is this normally a part of production apps of
clutch.io?

------
Sujan
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?

~~~
ericflo
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"

~~~
armandososa
direct link:
[http://www.livestream.com/f8socialapps/video?clipId=pla_e174...](http://www.livestream.com/f8socialapps/video?clipId=pla_e174c0e5-4d1d-4ca1-a4af-23edb3b9e616)

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

------
motti_s
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!

------
kinnth
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?

------
ianlevesque
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
Clutch.io would be even better if they offered the ability to easily do A/B
testing.

~~~
etmaguire
A/B testing is def on our roadmap

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

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

------
dain
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
It's a fixed monthly rate, so you're free to sell apps and not owe us a
percentage, or anything like that.

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

------
arturhoo
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
I just wrote up a few thoughts about this here:
<http://news.ycombinator.com/item?id=3800522>

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

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

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

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

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

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

