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!
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.
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?
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.
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.
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).
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.
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.
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.
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.
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.
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 :(
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.
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.
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).
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!
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.
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.
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.
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).
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:
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.
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"
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?
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].
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!
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).
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.
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.
