You really should use an anti-pop filter; you can make one yourself with a pair of stockings and a wire hanger.
I've linked to your comment here. Isn't After Effects expensive though?
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.
Apple has banned similar updates mechanism already. I think, clutch will also face similar problem.
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.
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'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.
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?
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.
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.
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!
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.
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.
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!
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.
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.
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).
* 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"
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.
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!
"2.7 Apps that download code in any way or form will be rejected"
This clearly violates that!
Sencha Touch, Appcelerator Titanium and Phonegap
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).
1. Otherwise, it would be dynamic analysis.
The use of the header is irrelevant - using
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).
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.
Strict apps review process is a feature, not a bug (i am actually "apple hater", but I see why app store successful)
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.