Opening a mobile app from a link: the Xamarin way (URL-Schemes)

Launching an app from within another app, from a mail link or from a link in a web page can be a very useful feature.

Social networks use this function a lot. However, all apps which have some “sharing” feature can benefit from it.

How to implement the URL schemes in Xamarin? We have to use two different methods for Android and iOS.

This is the task at hand:

– We have an app called superduperapp that should be opened whenever, on a user’s device, a URL as “superduperapp://my_code_is_here” is clicked by the user on their iPhone or Android phone (or: opened by another app on the same device);

– The data following the URL “protocol” (the string “my_code_is_here” in this example) is read by the app, which creates its data context based on that code.

This is one of those times in which Xamarin iOS and Xamarin Android implementations have little in common, since we’re touching the foundations of how the device operating system communicates and deals with the apps.

Xamarin for iOS URL Schemes:

As a first thing, we have to “decorate” the iOS app with the new URL scheme. We do this in the Info.plist file.

Xamarin Studio has a good editor for this file. You have to go to the “advanced tab” and add a “URL Type”. The URL scheme should contain the URL type you want to link your application to. In our case, since we would like superduperapp to be opened by URLs as “superduperapp://my_code_is_here”, our URL scheme will be “superduperapp”.

Xamarin Studio for iOS screenshot

How to edit Info.plist in Xamarin Studio

The “role” field is apparently ignored by iOS, but it’s supposed to mean:

Editor=app can read and write the type of files individuated by the URL
Viewer=can only view that file type;
None=cannot use it (I guess this option is used when an app is updated and we want to delete the file association)

As a second thing, we have to override the OpenUrl method of the Application delegate class:

public override bool OpenUrl (UIApplication application, NSUrl url,
string sourceApplication, NSObject annotation)
Console.WriteLine (url);
/* now store the url somewhere in the app’s context. The url is in the url NSUrl object. The data is in url.Host if the link as a scheme as superduperapp://something_interesting */
return true;

That’s it. If you store the url data in a persistent object, you can then use it in your ViewControllers. It is not very elegant, but it could be just sufficient to grab the code passed to the app with the “Host” property of the url, like this:

PersistantClass.CodeEntered=url.Host; //PersistantClass would be your custom class to hold data

To test, we create a web page with a link as this:

<a href=”superduperapp://my_code_is_here”>superduperapp_link</a>

which visually translates into this:

Link with custom URL schema to open our app

A link with a custom URL looks exactly as any link. In it, we might have a personal URL scheme, as superduperapp in our case

When we click on the link on the simulator, the iOS app opens (well, of course we must have installed it first). The app delegate reads the URL in the OpenUrl overridden method. Later, we display – as a test – the code extracted from the link:

this is how the code shows once we open the app via the custom URL

iPhone or iPad app done in Xamarin, opened by custom URL

Please note:

The application name does NOT have to be the same of the URL scheme. You can register your app “uncommonApp” to deal with any URL: BeautifulThings://, http:// (if you’re making a browser), whatever://

Xamarin for Android

In Android, the procedure to register an app to deal with a type of URL is (you figured that out already) completely different from that of iOS. We have to work on the AndroidManifest.xml file (contained in the /properties folder).

A typical AndroidManifest.xml file will look like a bit this (depending on the permissions and features the app needs):

<?xml version=”1.0″ encoding=”utf-8″?>
<manifest xmlns:android=”; android:versionCode=”1″ android:versionName=”1.0″ package=”superduperapp.superduperapp”>
<uses-sdk android:minSdkVersion=”19″ android:targetSdkVersion=”19″ />
<application android:label=”superduperapp”></application>
<uses-permission android:name=”android.permission.CAMERA” />

Our task here is to tell the operating system that a certain activity of the superduper app will be able to deal with the links that have a URL scheme as, for instance, superduper://my_code_is_here .

In the application tag, we have to add an indication to the activity and to the associated URL type.

The activity name goes in the android:name attribute of the application tag. The URL scheme name goes in the android:scheme attribute of the data tag inside the intent-filter, inside the activity, inside the application… like so:

<application android:label=”superduperapp”>
<activity android:icon=”@drawable/Icon” android:label=”superduperapp” android:name=”superduperapp.urlentryclass”>
<action android:name=”android.intent.action.VIEW” />
<category android:name=”android.intent.category.DEFAULT” />
<category android:name=”android.intent.category.BROWSABLE” />
<data android:scheme=”superduperapp” />

We install the app on the device (it works also on the emulator).

As we did with iOS, we open our emulator and navigate to the address that contains the link

<a href=”superduperapp://my_code_is_here”>superduperapp_link</a>

Link in android device

Link to open android app from custom link

When we click, our app opens on the Activity we indicated on the AndroidManifest.xml file (superduperapp.urlentryclass).

The class reads the code that is after the superduperapp:// “protocol” string in the Intent object, with this code:

[Activity (Label = “urlentryclass”)]
public class urlentryclass : Activity
protected override void OnCreate (Bundle bundle)
base.OnCreate (bundle);
SetContentView (Resource.Layout.Main);

Intent outsideIntent = Intent;
AlertDialog.Builder CodeAD = new AlertDialog.Builder (this);

CodeAD.SetTitle (“Superduperapp”);
CodeAD.SetMessage (“Code: ” + Intent.Data.EncodedAuthority);
CodeAD.Show ();

This is the result:

this is the screenshot of the Android app opened by the custom URL scheme

the Android app opened by our custom URL

Please note four things:

1 – in Xamarin Android, it is better to keep solution, project and class name in lowercase. I have had lots of issues when this wasn’t the case and I’m not entirely sure I was typing the names wrong. I think something may work incorrectly when you use class names LiKe_tHiS.

2 – the application name does NOT have to be the same of the URL scheme. You can register your app “uncommonApp” to deal with any URL: BeautifulThings://, http:// (if you’re making a browser), whatever://

3 – you don’t have to run the app to register the new association. Installation is enough.

4 – the URL association won’t work if you type the URL in a browser. It has to be a link in a web page or in an email.

Xamarin.Forms: what about performance agains Xamarin.iOS “Classic”? Is it faster or slower?

As of the 1st of August, 2014, Xamarin issued the version 1.2.2 of the platform (version 1.2.1 proved really buggy. Luckily, the Xamarin guys patched it well).

I can now test how Xamarin Forms performs (in terms of speed) compared to a “classic” Xamarin iOS development.

I did a very similar test to the one we did on Android.

It is, in “Release” mode:

1. I create a scrollview for 50 times.

2. To every scrollview I add: 20 labels, 20 textfields with a placeholder, 20 buttons with an event handler.

3. all the labels, textfields and placeholders are removed from the scrollview and destroyed (except for the 100th iteration)

4. the scroll is removed from the root view (except for the 50th iteration)

Xamarin.iOS “Classic” (with iOS designer on visual studio, “release” configuration):

average of 3710 milliseconds on the iPhone 5 64 bit “simulator”

average of 14050 millseconds on the iPhone 5 “classic” device

Xamarin.Forms “Classic” (with iOS designer on visual studio): 

average of 141 milliseconds on the iPhone 5 64 bit “simulator”

average of 609 millseconds on the iPhone 5 “classic” device


So, in terms of how fast it is, on iOS Xamarin Forms beats Xamarin “classic” as it happens with Android, at least when it comes to standard UI buttons, labels and textfields.

This is the code:

“iOS Classic”

Code to test classic iOS development with Xamarin, in particular creation and destruction of subviews

Xamarin.iOS speed test code


Code to test performance of Xamarin Forms on iPhone and iPad

Xamarin.Forms test code

Xamarin Forms performance compared to “Classic” Xamarin development

How does the Xamarin Forms technology compare to the “classic” Xamarin technology on Android?

The “forms” technology has been out since May 28th, 2014 (

On July, 13th, 2o14, the 1.2.1 version of Xamarin.Forms was issued as a hotfix to 1.2.0.

The pros and cons of the philosophy of cross-platform “Forms” will not be discussed now. Let us evaluate the performance of the “forms” paradigm to check if it is as fast as the “old” one.

Of course, I focused on the UI, because the rest of the platform does not change (much).

I tested Android and iOS UI performance (i.e.: the speed) on:

– Genymotion emulator for Android (based on VirtualBox)

– Android “official” emulator (4.4.2 on Intel fast HAXM)

– Android machine (4.1)

In a later post, you will see the same with:

– iOS simulator

– iPhone 5

What did we precisely test?
We tested what, in our experience, is the hardest UI task: the dynamic creation and destruction of elements.

The task is the following:

  • Create (or individuate) a “main view”
  • Add a scrollview to the mainview
  • Add a vertical “stack” layout view to the scrollview
  • Add dynamicaly 100 labels, 100 textfields, 100 buttons with click event handlers
  • delete all of the labels and textfields except for two
  • add another label
  • destroy the “main view”, re-do another four times

At least part of these tasks is asynchronous, so these tests cannot be considered as a reliable proof that Xamarin.forms is faster than “classic” Android development, but… I am very confident now.

How did Xamarin.Forms perform on Android?
Very well, and I have to say surprisingly because it’s supposed to be an abstraction on an abstraction (it probably isn’t!).

The new technology seems to be at least as fast as the old one. Xamarin.Forms seems to have speed on its side.

I do have to say that of course we could not do the exact same things on the two platforms (for instance: in one platform you can plainly replace the child of a view; in the other, you first have to remove the children).

I tried to hone the code so that it gave the best results for both platforms.

GenyMotion: Xamarin Forms (KitKat on windows, i5, 8Gb) is better than Xamarin “classic” (and Genymotion is better than the Intel emulator)

Xamarin.Forms: average of ten tests: 195  milliseconds (three times faster than before, apparently)

Xamarin Android “classic”: average of ten tests: 773  milliseconds

Intel Android Emulator (KitKat on windows, i5, 8Gb): Xamarin Forms is still better than Xamarin “classic” 

Xamarin.Forms: average of ten tests: 566 milliseconds (still four times faster than before, apparently)

Xamarin Android “classic”: average of ten tests: 2100 milliseconds

A real Android device: Xamarin Forms is still better than Xamarin “classic” 
We also tested the performance of Xamarin.forms on an Android device (a 7 inch Samsung Tab2)

Xamarin.Forms: average of ten tests: 302 milliseconds (still four times faster than before, apparently)

Xamarin Android “classic”: average of ten tests: 909 milliseconds


the code for Xamarin forms performance test

Xamarin forms speed test


The Code for XAMARIN “Classic”:

the code to test the speed of Xamarin Android

Xamarin classic Android speed test