On iOS you can use method swizzling. I wrote up a blog post about a year ago[1], describing some of these methods for a similar-ish concept we built at a hackathon.
There are many ways to change the content and/or structure of an app. One app I worked on was essentially a fancy JSON parser- you could specify what view controllers to put where and what to put (some UIKit objects) in their views. Another app had a fixed structure but dynamic content (again, specified by a JSON file) that was downloaded regularly to keep the content up to date.
This won't work in production on iOS because it's against Apple's rules. They still have to review the app once to publish it at first. I know people who do have A/B scenarios and kill switches on features in apps that are deployed, but it's on the downlow. You don't want Apple knowing about it. Having a website that says "Skip the app store review line" isn't the best way to go about it.
They claim on their Kickstarter that they can get around this:
The Apple Review process restrictions are very specific. Apple forbids the dynamic loading of remote code. But this is not what Air-Control does, our library contains all the code it needs so no code is loaded dynamically. Our library only downloads content and configurations, which is permitted by Apple.
For a very similar use case we can reference our existing tool, nativeCSS, which is a dynamic styling library for iOS and Android. This is very similar to what Air-Control does, it downloads styles and applies them to a running app. This has been installed in a wide range of Apps, and has been approved by Apple since its launch in December 2012.
Whether or not Apple actually goes for this is another question entirely.
The App Store review guidelines present a large number of specific rules, but before that, they say right up front that "This is a living document, and new Apps ... may result in new rules at any time. Perhaps your App will trigger this." In other words, they reserve the right to reject any App at any time for any reason that strikes their fancy; the guidelines are just a list of reasons they've used in the past, presented for ready reference.
(And while the text of their license agreements is covered by NDA, versions that have leaked in the past have been even more explicit about Apple's right to kick apps and developers out of the app store at any time, for any reason.)
So, a library designed for the specific purpose of doing an end-run around the review process does not sound like a good bet.
How did Facebook do the "messages are no longer available in app after a certain date" switch? I manually update so even if they did have a kill switch it was in there for a month at least?
What it looks like they're doing is allowing people to make changes to the UI in real time, which is cool! What they don't seem to be talking about is avoiding the App Store to make code changes, which would be a problem.
I've been using similar A/B tools in my apps for for years and I know that making last minute changes can be painful.
I'm going to follow these guys and might even back them on kickstarter.
so is this like an OSB/Rules Engine/Scripted layer to control apps? put all your functionality in a dynamically callable format and then a processor control what happens all the time.. basically an interpreter for everything?
I use Google Tag Manager to achieve similar results using a combination of container configurations (featured content, colors, strings, navigation hierarchies, etc.) and macro/tag handlers.
This is one of the advantages gained by using a non-native toolkit to develop for these platforms. My platform of choice (MOAI) is Lua-based, and in my development environment I can treat all of the hosts that it runs on - Windows, Linux, OSX, Android, iOS, HTML5+javascript - the same. There is no walled garden in this technique - any time I want to test on a platform, I simply send the existing app a link to a new source bundle, and off we go.
The only time this doesn't work is of course the appstore-approval phase - things have to be precompiled and bundled properly into a signable package. Oh well, just a part of release engineering. But other than that, its just a push-button away to get new versions of my apps installed on all the test devices in the lab..
2. Quality issues - Either technical or UI
Here there as far as I know one unique company http://www.rollout.io that gives developers control over their production environment from hard core bugs hot-patching and UI changes to SDK control and analytic control.
I'm guessing all of these companies use the same technology which seems legit in regards to Apple, as long as none of them are using code injection.
19 comments
[ 2.9 ms ] story [ 48.1 ms ] thread[1] http://blog.fliptest.io/introduction/2013/06/12/how-we-built...
The Apple Review process restrictions are very specific. Apple forbids the dynamic loading of remote code. But this is not what Air-Control does, our library contains all the code it needs so no code is loaded dynamically. Our library only downloads content and configurations, which is permitted by Apple.
For a very similar use case we can reference our existing tool, nativeCSS, which is a dynamic styling library for iOS and Android. This is very similar to what Air-Control does, it downloads styles and applies them to a running app. This has been installed in a wide range of Apps, and has been approved by Apple since its launch in December 2012.
Whether or not Apple actually goes for this is another question entirely.
(And while the text of their license agreements is covered by NDA, versions that have leaked in the past have been even more explicit about Apple's right to kick apps and developers out of the app store at any time, for any reason.)
So, a library designed for the specific purpose of doing an end-run around the review process does not sound like a good bet.
How did Facebook do the "messages are no longer available in app after a certain date" switch? I manually update so even if they did have a kill switch it was in there for a month at least?
What it looks like they're doing is allowing people to make changes to the UI in real time, which is cool! What they don't seem to be talking about is avoiding the App Store to make code changes, which would be a problem.
I've been using similar A/B tools in my apps for for years and I know that making last minute changes can be painful.
I'm going to follow these guys and might even back them on kickstarter.
https://developers.google.com/tag-manager/android/v4/#get
Perhaps a dedicated product could make end-to-end scenarios more streamlined.
The only time this doesn't work is of course the appstore-approval phase - things have to be precompiled and bundled properly into a signable package. Oh well, just a part of release engineering. But other than that, its just a push-button away to get new versions of my apps installed on all the test devices in the lab..
1. Optimization - All mobile A/B testing platforms. (Manually or automatic) - http://www.appiterate.com,http://www.leanPlum.com,http://www... http://www.useartisan.com)
2. Quality issues - Either technical or UI Here there as far as I know one unique company http://www.rollout.io that gives developers control over their production environment from hard core bugs hot-patching and UI changes to SDK control and analytic control.
I'm guessing all of these companies use the same technology which seems legit in regards to Apple, as long as none of them are using code injection.
http://blog.air-control.com/air-control-and-the-app-store/
Ask me anything.
Cheers
Peter