Practical Uses for the Mono Interpreter on Xamarin.iOS

At the Queensland C# Mobile Developers meetup group's May 2019 Meetup, I gave a talk on the recently announced Mono interpreter and mixed-mode execution support for Xamarin.iOS entitled "Practical (and not so practical) Uses for the New Mono Interpreter". The talk covered a little of the basic theory behind the function of the interpreter in Xamarin.iOS, but focused mainly on demonstrations of its use in practice through several demos. These demos are outlined below and slides available at the end of the post.

Improved Dev Build Iteration Time

Enabling the interpreter on iOS disables the AOT compilation step for any interpreted assemblies. Since performance is not typically the primary concern at development time (and Debug builds already don't represent Release performance), trading AOT performance for reduced build times is an attractive option when iterating on development of device based features. The timesave when skipping AOT can be substantial, as demonstrated by my completely unscientific and inadmissable measurements that if nothing else are at least indicative.

Comparison of debug build times including the AOT step and without

Practicality: 10/10 highly recommended, few downsides

Hot Reload

The interpreter allows for 'execution' of IL without JIT'ing, allowing us to use the perform code-based hot reload on device-only features using tools like Continuous. In the talk I demonstrated the improved performance of hot reload on the device for frameworks like SpriteKit. I've written more about hot reload and the interpreter in an earlier blogpost

Comparison of simulator vs device performance

Practicality: 7/10 highly recommended, but seemingly a lost art

Hot Patching

Truly transparent hotpatching is something that would likely require crazy runtime-level acrobatics. However, rolling your own hotpatching implementation is viable with support from the interpreter (whether it is advisable is an entirely different question). A home grown hotpatch implementation relies on abstraction or dedicated patch interception mechanisms. Fortunately, .NET and MVVM development favours abstraction-oriented patterns like DI and VM-based navigation, which are good examples of abstractions that can effectively be patched. In the talk, I demonstrated the remote hotpatching of two apps:

  • AR Bound, which was patched to include a new menu screen and two new demos Overview of hotpatch architecture for ARBound

  • A basic Prism app, which was patched with a replacement service layer implementation, and a replacement XF Content Page + ViewModel. Overview of prism hotpatch implementation

Whilst very effective, hot patching comes with a host of risks and uncertanties. The author struggles find the bravery within to try using this technique outside of a dev/QA environment.

Practicality: -7/10 (yes negative) so enticing, so scary

Embedded REPL

Though the interpreter as exposed through Xamarin.iOS is an IL interpreter, we can approximate a C# REPL by making use of the Mono Evaluator, which compiles and loads IL generated from C# source code. With mixed-mode execution, this IL can then be executed by the interpreter. For this use case I presented a demo of a REPL that could perform various C# evaluations - including UI - but also interact with the current app context.

Although I forgot to present it (😅), the demo included a basic remote execution capability as well, powered by SignalR.

Whilst the practicality of typing code on soft-keyboard is low, the fun factor is very high.

Practicality: Int64.MaxValue/10 REPLs are scientifically proven to be the coolest things in the known universe.

Slides

Links for the slides are below.

Slides (46): PDF