Xamarin support in Blue Cedar release 3.15.0+


Release 3.15.0+ includes support for both Android and iOS apps developed with Xamarin. Xamarin is a development framework that allows developers to create native apps on multiple mobile platforms using the Microsoft .NET development framework and languages (for example, C#).

See https://www.xamarin.com/ for more information on Xamarin.

Apps developed with the core Xamarin framework are supported. However, Xamarin apps may include other APIs which are not supported, such as various C# HTTP clients.

This document describes the currently supported policies by release 3.15.0 when secure Xamarin apps.

Summary of policies

These policies are partially supported for Xamarin apps. Other Blue Cedar policies are fully supported for Xamarin apps.

Policy nameSupport status

Secure Web Stack

Trust Server Certificates

Client Certificates

  • Fully supported for apps using Android WebView or iOS UIWebView.
  • Not supported for apps using C# HTTP clients.

Support for Android WebView

Apps that use a WebView can take full advantage of all the Blue Cedar policies, especially policies that are related to HTTP networking (Secure Web Stack and Trust Server Certificate).

See https://developer.xamarin.com/guides/android/user_interface/web_view/ for more information on the APIs related to Android WebViews in Xamarin.

In such apps, all the features implemented by those policies are fully supported (Manual/Automatic proxy support, client certificate authentication, server certificates validation, Single Sign-On, etc...).

Issue: Programmatic WebView instantiation

The only use case that is not fully supported is when an app programmatically instantiates a WebView instead of using an Android layout. This is not a typical use case, since most developers create their user interfaces by leveraging the use of XML layouts.

For most Android apps, developers follow the best practice recommendation to use layouts to create the UI. This has the advantage of supporting device specific layouts with no code changes (tablet vs phone, high res vs low res, landscape vs portrait). That being said, it is possible to instantiate UI elements without using any XML layouts. In that case, a developer would just create an instance of a WebView, initialize it (which is what the layout would typically do), and insert it in the view hierarchy.

In the rare instance where a WebView is instantiated programmatically, there is a simple workaround developers can use to ensure that their app is supported.


The following code sample shows how a WebView could be instantiated programmatically:

protected override void OnCreate(Bundle savedInstanceState)


    WebView myWebView = new WebView(this);
    LinearLayout webviewLayout = FindViewById<LinearLayout>(Resource.Id.webview_container);

When apps use such code, Blue Cedar cannot intercept the WebView APIs because the app is using a WebView directly.


A workaround for this issue is to use a custom derived WebView class instead of a pure android.webkit.WebView.

The following code sample shows the same example modified to introduce an intermediate class instead of using the WebView directly:

protected override void OnCreate(Bundle savedInstanceState)


    WebView myWebView = new MyCustomWebView(this);  // custom WebView defined below
    LinearLayout webviewLayout = FindViewById<LinearLayout>(Resource.Id.webview_container);

public class MyCustomWebView : WebView

Using a class that derives from the WebView class instead of directly instantiating the Android.Webkit.WebView class is sufficient to make the app compatible with the Blue Cedar interception framework. 

Support for iOS UIWebView

Xamarin iOS apps that are implemented using UIWebView for displaying web pages are fully supported. However, apps that are implemented using the WKWebView and SFSafariViewController, two newer APIs introduced in iOS 9 that may be invoked from C# code, do not intercept all web requests and do not function as expected when secured. See Network traffic interception limitations for general iOS traffic interception limitations.

Support for C# HTTP clients

Some apps do not use WebView, and instead, use a C# HTTP client:

Since these APIs are implemented in C#, the current Blue Cedar interception framework cannot intercept any of the HTTP events, and as such, none of the following policies work with such clients:

  • Proxy: manual configuration
  • Proxy: PAC file
  • Client certificate authentication
  • Server trusted certificates
  • Single Sign-On

In Blue Cedar 3.15.0, there are no workarounds for supporting the Secure Web Stack and Trusted Server Certificates policies when an app uses a C# HTTP client.

It should be noted that such apps are still able to leverage the Secure Microtunnel policy to send any network traffic.

Support for some of these C# HTTP client will be added in future releases.

iOS app interception

The iOS support for Xamarin apps added in release 3.15.0 overhauls the low-level mechanism used to intercept app code from executing at startup. iOS apps built using Xcode versions from 2012 or older produce binaries with a startup mechanism that differs significantly from the current startup mechanism. The offending binaries will have the LC_UNIXTHREAD load command rather than an LC_MAIN load command. The differences between these two are significant enough that the new style of app code interception (required for Xamarin apps to work) cannot be used. Older apps that fall into this call will revert to the prior style of entry point redirection (UIApplicationMain style) if an LC_UNIXTHREAD command is encountered. They will behave as if the "Skip early initialization deferral" checkbox under advanced signing options is enabled.

Enabling "Skip early initialization deferral" can cause Xamarin apps to crash on startup. This option should only be enabled when recommend by Blue Cedar support.