Rollout the Red Carpet
Tired of having to wait for your app update to be reviewed and pushed out to users? How about those people who just don't update for ages? Rollout.io is here to save you!
Join the DZone community and get the full member experience.Join For Free
So you might have heard of Rollout.io before:
Update Live Mobile Apps
Instantly Fix Bugs|
Deploy code-level changes to native iOS apps, without waiting on the App Store.
All well and good then … except that swizzling only works in Objective-C and it’s $CURRENT_YEAR, who still writes Objective-C? Cha, we’d spend our ever so valuable blogging space on that right after an in-depth article on the state of 3270 emulation, amirite? (With all due respect to the author of that no doubt invaluable if you need it fine bit of work, mind you, just that most of the world has moved on a bit!) Well, look at what the boffins over Rollout way have come up with now:
I’m delighted to announce that Rollout now supports Swift apps!
After months of development, testing and tweaking we’ve just released our official Swift support.
If you’ve been waiting for Swift support in order to try out Rollout, either create a new app and install the SDK or upgrade your existing app with the latest SDK version…
Uh … yeah? And just how exactly did you get that to work?
The heart of Rollout’s Swift patching magic lies in a technique we call Pre-SIL instrumentation.
SIL stands for Swift Intermediate Language, it is generated from the Abstract Syntax Tree. This intermediate form is used by the Swift optimizer to perform Swift language specific optimizations prior to generating the LLVM IR.
Rollout instrumentation needs to happen before the optimization phase so it will work even if the method was inlined, the dispatching was de-virtualized and more (I’ll write more about optimizations in Swift in the near future).
To add this code instrumentation Rollout runs the following flow:
- Replace the swiftc compiler with a proxy script
- When swiftc compiles a file, intercept the file and instrument it
- Identify all methods in file
- Instrument all methods with the patching mechanism
All of the above needs to happen without a cost in compile time, runtime and most importantly maintaining a consistent debugging experience (as if Rollout didn’t touch your code)…
Well, brush our teeth and call us pearly. If that does indeed work as advertised, that is quite the leap forward for application maintenance, isn’t it? Looks like the free tier doesn’t support Swift so it’s not a completely trivial cost to adopt, but hey, it’s pretty cheap compared to the damage a broken app could do you!
Published at DZone with permission of Alex Curylo, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.