Over a year ago, we published an article on how Rollout works under the hood. Since then we’ve improved and optimized our technology quite a bit, adding features like JavaScript based patches.****This is an updated version of the original article that reflects our current technology.**
You just finished fixing a critical bug in your iOS app and submitted to the App Store for approval. Congrats!
The problem is that can take anywhere from a couple of days to a couple of weeks before it’s approved! If this is an urgent bugfix, even a few hours can be an unbearable amount of time to wait.
That’s where Rollout comes in. With Rollout’s SDK in your app, you can instantly push code level updates, such as bug fixes or diagnostic code, to native iOS apps in production. Yes really, and totally legit by Apple’s guidelines. Rather than waiting for App Store approval to push code updates, with Rollout can you find and fix issues in live apps in minutes.
In this article, I elaborate in detail on how Rollout works it’s magic under the hood (techie stuff). At it’s core, Rollout utilizes three technologies to work it’s magic:
- Method Swizzling
- JavaScriptCore API
- Libffi
Method Swizzling
The heart of Rollout’s magic lies in a technique called method swizzling.
“Method swizzling is the process of changing the implementation of an existing selector. It’s a technique made possible by the fact that method invocations in Objective-C can be changed at runtime, by changing how selectors are mapped to underlying methods in a class’s dispatch table.” – NSHipster.
NSHipster has more on method swizzling in Objective-C. New Relic also has an excellent article that covers the right (and wrong) way to swizzle in Objective-C. In case you were wondering, Rollout swizzles the right way.
Let’s look at a specific example to see how method swizzling works in practice.
Say you have a method (we’ll call it Method A) that returns nil value in certain conditions. This causes your application to crash because the nil is pushed into an NSArray. This is what we call a bug.
Usually, you’d have to fix the bug in your code, then send the updated version to the App store, then wait for it to be approved and then wait for users to download the fixed version and then you still need to deal with users who are using your app but never downloaded the new version.
With Rollout, you login to your Rollout account, choose the method you want to update and simply write (using JavaScript) the updated logic that fixes the bug and the update will automatically be picked up by all your app users (more details on how users get the update a bit later).
In the case of Method A above, let’s create an update that replaces the nil value with an empty string. This will fix the app from crashing. The updated logic would look something like this (pseudo code):
var returnValue;
returnValue = self.originalImplementation(input);
if (returnValue === undefined) {
returnValue = '';
}
return returnValue;
The updated version of a method can do any or all of the following:
- Execute the original method
- Execute any other method anywhere in your app (even third party SDKs)
- Replace or modify any of the method’s input or output values
- Access any values from any object in your code
- ****Execute**** any JavaScript code
FYI, in the Rollout interface, we call the updated version of a method a “patch”.
Once the SDK has grabbed the update file, it makes a one-time modification to the app runtime code, effectively modifying the pointer to Method A so it now points to the new method we created.
Rollout utilizes The JavaScriptCore Framework. The Framework allows you to evaluate JavaScript programs from within an Objective-C or C-based program. It also lets you insert custom objects to the JavaScript environment. More details here.
In case you’re wondering, Apple specifically allows apps to download and execute code using Apple’s built-in WebKit framework or JavascriptCore API.
How does the App get the update?
Rollout’s SDK automatically checks to see if there are any updates (1) whenever the app is launched and (2) when the app enters foreground. This is done by making an asynchronous secure HTTPS request, in order not to cause any delay when the app starts. App update files are also cached. If a user does not currently have network connectivity the cached version of the update will be applied.
Furthermore, all app update files are signed using public / private key encryption. The SDK checks the update file and applies the update ONLY if it is authenticated.
How Rollout Swizzles, Without Modifying Your App Code.
Rollout lets you modify any method in your code, without needing to know in advance what methods you want to update and without making **any **modifications to existing code. Pretty cool 🙂
In order to accomplish this, Rollout’s SDK will generate a delegate method on the fly that behaves according to the platform and architecture specification (Procedure call standards or application binary interface, see here).
This method is generated on demand by the SDK. When the Rollout service calls for a hot patch the SDK checks the original signature of the method in Objective-c (see NSMethodSignature) and then behaves exactly like Objective-c blocks are generated, using closure. You can read more about it in Landon Fuller’s blog imp_implementationWithBlock.
FYI, a long time ago (in a galaxy for away) Rollout used to use static analysis and would modify the source code by adding “hooks” to use at run time. This is no longer the case as Rollout now utilizes libffi to dynamically do the same thing at runtime.
In the Rollout interface, Rollout knows all of an application’s methods by parsing the dSYM file that was uploaded to Rollout backend as part of the build script. Here is the Xcode build phase:
Screen Shot 2016-03-22 at 11.20.01 AM
In the SDK we then verify if method A needs to be replaced by the newly generated method, and follow through with the replacement using the swizzling mechanism. When the application then calls on method A to perform a task, the method created in Rollout will be executed instead. The new method then calls the original method and checks if the return value is nil, in which case, it would replace the value with an empty string.
Maintaining Performance
Rollout does not cause any performance issues. Rollout’s magic comes from activating mirror methods and executing swizzling, only if a method’s original implementation needs to be hot patched.
Rollout’s dynamic methods are constructed like the original method and the calling mechanism is static. We do not use NSInvocation to call the method but instead create the method as if it was created in compile time. The process of directly executing method A, becomes the indirect process of executing method B that then executes method A.
Swizzling fundamentally only adds one level to methods that are being pulled. If your environment doesn’t detect any hot patches, application runtime is not affected at all.
Another decision that we make concerns how Rollout’s SDK is loaded. The SDK is designed to help you solve mobile app issues as they happen. When your application starts, the SDK fetches any current configurations from Rollout’s end point, applying them immediately once they reach a device. This is done asynchronously to avoid any possible delays that may affect user experience. Lean more about our FAQs.
Summary
This article only scratches the surface of Rollout’s mechanism. I decided to focus on hot patching in order to keep things simple and provide specific use cases. The ability to apply behavior on top of an application’s code provides our customers with interesting opportunities, such as ad hoc log generation (in order to track issues, even in production environments), dynamic analytics, A/B testing, remote configuration and more.
Rollout is currently installed on millions of devices. We’ve streamlined pushing patches to users without harming the application delivery process or impacting end-users’ experiences.
Rollout in Action Video
If you want to see a video that shows Rollout in action by adding logging on the fly and actually fixing a live bug in production, check this out – it should help you understand exactly what Rollout can do and how it works:https://youtu.be/eS7-iBsdzT0?t=23s
Share this post: on Twitter on Facebook on Google+
网友评论