Just stumbled over this one in a recent endeavour. The default behaviour of iOS is to use the title of the previous navigation controller as the text for the back button.


If you want a different text such as back you might find this recipe from Xamarin which works. But it does feel like a hack and it requires you to adopt this approach in every view.

Another approach is to set the NavigationItem.BackBarButtonItem attribute in the view controller:

NavigationItem.BackBarButtonItem = new UIBarButtonItem {Title = "Back"};

The set text will be displayed as the back button of the next view controller. In other words previous view controller always sets the back button text of the following.


If you are using a central point to generate your views e.g. a navigation service or factory you can apply this to every view you create. Which makes this approach a lot less error prone.

If you are using storyboards you have a further option. The title can be set directly in the designer under Navigation Item, Back Button.

Set back button title in Storyboard editor

Note this option is only available when you choose the (no longer recommended) push navigation for your segue.


In this post we saw how we can set the title of the back button. The title of the back button is always set in the preceding view controller.

Using a storyboard the title can be set directly in the storyboard designer.

You can find an entire little app sample on GitHub.


Traffic lights at the crossroads

In this post we look at getting notified when the user chooses to navigate back. If you have to be in control of your navigation under iOS I strongly recommend you check out using a modal navigation. But what if you simply want to track when the navigation hits the back button. Or uses the swipe gesture to go back to a previous page.

While there is no direct event, there a few ways to achieve this.

Custom NavigationController

One way is to subclass the UINavigationController:

public class AwareNavigationController : UINavigationController
    public event EventHandler PoppedViewController;

    public AwareNavigationController() : base() { }
    public AwareNavigationController(UIViewController rootViewController) : base(rootViewController) { }
    public AwareNavigationController(IntPtr intPtr) : base(intPtr) { }
    public AwareNavigationController(NSCoder coder) : base(coder) { }
    public AwareNavigationController(NSObjectFlag t) : base(t) { }
    public AwareNavigationController(string nibName, NSBundle bundle) : base(nibName, bundle) { }
    public AwareNavigationController(Type navigationBarType, Type toolbarType) : base(navigationBarType, toolbarType) { }

    public override UIViewController PopViewController(bool animated)
        PoppedViewController?.Invoke(this, null);
        return base.PopViewController(animated);

You can then start using the new navigation controller:

new AwareNavigationController(new ContainterViewController());

And hook up to it’s event:

public override void ViewWillAppear(bool animated)
    ((AwareNavigationController)NavigationController).PoppedViewController += ViewControllerPopped;

private void ViewControllerPopped(object sender, EventArgs e)
    Console.WriteLine("Going back Shell");

Use this approach if you want to register the navigation at a single point and provide this information as an event or even message. If you are writing a navigation service this approach will most probably be your best choice.

A couple of side notes when using this approach. Make sure to deregister the event handler. You will want to deregister the event handler in the ViewWillDisappear method. If you try to do this at a later stage I.e. ViewDidDisappear the navigation controller reference will already be null.


Alternatively to creating a custom navigation view controller you can override the following method in your ViewController:

public override void WillMoveToParentViewController(UIViewController parent)
    if(parent == null) Console.WriteLine("Going back Shell");

If the passed in parent view controller is null, the view is being removed from the view stack. Note that if you have child view controllers you will have to extend the method above or the children will not be notified:

public override void WillMoveToParentViewController(UIViewController parent)

    if (parent == null)
        var childVCs = ChildViewControllers;
        foreach(var childVC in childVCs)

        Console.WriteLine("Method override: Going back Shell");

I would recommend this approach when you are only need to detect the navigation in one or two ViewController's I.e. but do not require this event globally in the app.

Not recommended approach

If you have stumbled over the suggestion to simply check the attribute IsMovingFromParentViewController in the ViewWillDisappear / ViewDidDisappear, be aware that this is not recommended. While it might work at first, as soon as you need to detect the back navigation in a child view controller this attribute will always be set to true. Even if navigating to another view controller and not backwards.

public override void ViewDidDisappear(bool animated)
    // not recommended!
    if(IsMovingFromParentViewController) Console.WriteLine("Going back Shell");

Since one can’t forbid a ViewController to be used as child view controller, I would strongly recommend to stay away from this approach.


In this post the different ways of getting notified of a back navigation in progress have been shown. If you have to block the user from navigating back I strongly recommend you use a modal navigation in the first place.

Find a small sample app on GitHub.

Know another option not mentioned here? Or have any thoughts on the approaches. Let me know by posting a comment.



When developing an app your design might require to use a font that is not available from iOS out of the box. So let’s see how a custom font can be added to ones app and how to use it in a Storyboard or Code.

Adding the font

Assuming you already have the font, note that iOS supports fonts that are stored in TTF or OTF formats. Custom fonts are copied into the Resource folder of your iOS project.

image of ios project, showing the custom font file in a subfolder named fonts in the resoucres folder

Ensure that the properties of the font file are set to BundleResource.

Creating the Fonts subfolder is optional. But since the Resources projects tends to collect a couple of items in larger projects. Let’s tidy things up from the start Smile

To use the font we will have to update the Info.plist file with the following lines:


Note: At the time of writing in Visual Studio 15.5.4 you will have to open the Info.plist file in an XML Editor. For this right click the file and select “Open with…” then choose the XML (Text) Editor. In Visual Studio for Mac the GUI Info.plist editor supports editing the source directly.

Using custom fonts in Storyboards

After adding for example a UILabel to the storyboard, select it. In the options click on the font and choose the custom font.


Using custom fonts in Code

In code behind using a custom font is pretty straight forward. For example in a label we can set the Font attribute as follows:


The result when running app with the combined storyboard and new label is:

Custom Font Screenshot


In this blogpost we went through the steps that have to be taken to add a custom font. Note that fonts are loaded during the start up of the app and if you go bonkers with them you might notice some performance impact.

You can find a small sample on GitHub. For setting the constraints in the code defined UI PureLayout.Net was used.



If you haven’t heard or dived into .Net Standard you are in for a treat. In short it provides a way to share code across platforms but in contrast to the PCL it gives you so many more platform specific features. For an in depth overview check out the official docs.

Note: If you are starting a new Project today with Visual Studio (VS) 2015.4, you will not be able to select .Net Standard by default. But the new templates for .Net Standard will be included in Visual Studio 15.5.

Creating the .Net Standard Class Library

Migrating an existing app to .Net Standard is pretty straight forward. Step one add a .Net Standard Library to replace your PCL project.

The VS Add New Project dialog, under Visual C# select Class Library (.Net Standard)

Migrating your source code

Then drag and drop all of your existing files from the PCL project to your .Net Standard library. Note that you don’t want to copy the packages.config or any of the files under properties.


Now you can delete your PCL project that you have migrated. If you do so from Visual Studio note that the Project is still available in the file system. Which means you still have it if you forgot something, but also means that you will have to delete it later on if you want to remove it from the source control workspace.

Next step is to add all the NuGet packages you have used in the PCL project. If you are having trouble adding some of the packages look out for NuGet packages that are no longer needed due to .Net Standard support such as file system access. In other cases it could be because the NuGet package has not (hopefully yet) migrated to .Net Standard. In that case check out this post and don’t forget to ask the maintainers of the project when the project will be available for .Net Standard Winking smile

Hooking up the projects

You can now add the reference to the .Net Standard in your Android and iOS project. If you created a new namespace I strongly recommend you refactor them after adding them to your projects. Or else your refactoring tool of choice will only do half the magic and you will still have some work left to do.

If you are using a UWP project please read the section bellow as you will need to make some additional steps to make it work.

Fixing the csproj for Xamarin Forms

Unfortunately when moving a Xamarin Forms app over to .Net Standard you will get weird compilation errors. The cause of this is that the XAML files are referenced in the csproj file:


Simply remove them as they are not needed and the compile errors should be history.

When using UWP

If you are using UWP as a target (I.e. using the default Project provided up to VS 2015.4). You will have to remove and add the project anew:

If you are unsure if you really have to update your UWP project. Check if you have a project.json file in your UWP project. If the answer is yes, I’m afraid you will have to follow the following steps.

  1. Remove the UWP project from the solution in Visual Studio
  2. Rename the UWP project folder in the file explorer
  3. Add a new UWP project in Visual Studio (with the same name as the one just removed)
  4. Set the minimal supported Windows 10 version to the Fall creators update

    VS Dialog Window with Target and Minimum Version set to Fall Creators Update
  5. Add any NuGet references the just removed project had (you can peek into the project.json file in the renamed location if you are unsure which packages to add)
  6. Copy and paste all your UWP files (except the project.json)
  7. Add a reference to the Standard Library project

If you know an easier way to upgrade a UWP project, please let me know in the comments bellow Smile


In this post we went over the steps required to migrate an existing PCL project to .Net Standard. All the steps were done with Visual Studio 15.4.


PureLayout is a library for iOS developers that allows to create UI views in code behind with ease. With PureLayout.Net this option is now available for Xamarin.iOS.

Since PureLayout.Net is based on the idea of defining your UI in code you might be tempted, especially as a C# developer, to dismiss it as an utterly bad idea. Because defining UIs in code is such a no-no right? Well actually no, not under iOS. The standard approach under iOS is to use the Storyboard to define your UIs and your screen flow. This is great at first since it is very much like Windows Forms with all it’s drag and drop goodness. The problem arises in two areas:

  1. Having more then one person editing the Storyboard
  2. Sharing standard values such as Margins over the entire UI

TL;DR;Define your UIs in a reusable way that allows to share design standards and reduce duplication within UI work. Enable collaboration on UIs without the fear of merge conflicts by using PureLayout.Net. Which you will be able to use in no-time.

Since the storyboard is one large (generated) XML file. Any change to the UI is stored in a single location. In a larger project this will mean that whenever two or more people will want to make changes to the UI a merge conflict could arise. Should a merge conflict arise… Well to put it short you are out of luck. Since the XML gets generated it is not human friendly to merge. An error while merging will result in the entire UI of the app being in tatters. Now one could mitigate this problem to a certain degree by using XIBs. But those come with some extra glue code to get it running. Plus there is still this second point.

If you are working on a larger app, you will (want to) have some sort of a style guide. In it you will define a set of defined constants for your colours, margins, text sizes, fonts etc.. Going with the Storyboard or XIB designer will not provide you with a central coded style file. The only way to define and distribute the style is in a written text document such as a Word-, PDF-File or a Wiki page. This approach comes down to every one, who works on the UI, needing to know this document. The current version may I add and apply the styles. This can be a challenge to say the least.

All this can easily be avoided by using PureLayout.Net. - Which I hope does not come as surprise at this moment Winking smile

Where to get it

Simply add the NuGet package to your iOS project and you will be all set:

Install-Package PureLayout.Net

How to get started

A getting started guide can be found on the projects GitHub page.

Thank you

I would like to point out that PureLayout.Net is only a wrapper around the existing PureLayout library written Objective-C. Therefore a big thank you to Tyler Fox the creator and Mickey Reiss for currently maintaining the library.

Further I would like to thank Samuel Debruyn for helping me a lot on the topics of wrappers with his blog post.