Multiple .storyboard files in a single app is a thing, and I’d encourage iOS developers to utilize this pattern more often than not.

I love Xamarin, but as I’ve mentioned before, I prefer to work with .xibs and .storyboards in Xcode Interface Builder opposed to Visual Studio’s built-in designer.

This video shows how you can use multiple .storyboards in your Xamarin.iOS (or just iOS) app, and create segues in Interface Builder directly to another .storyboard just like you would to a UIViewController.

Setup: Accounts & Subscriptions

To get started, you’ll need to create/login to a few accounts. (don’t worry, they’re all free)

Microsoft Azure

We’ll be using Azure Bot Service, so you’ll need an Azure account. If you don’t already have one, you can create a free Azure account here.

Microsoft Bot Framework

Create or login to your Microsoft Bot Framework account. Even if you already have an account, make sure to login, as it’ll simplify setting up your bot in Azure.

QnA Maker

Create or login to your QnA Maker account. Even if you already have an account, make sure to login, as it’ll simplify setting up your bot in Azure.

Azure Bot Service

Next, we’ll use Azure Bot Service to build our bot.

Create an Azure Bot Service

Click here to create a new Azure Bot Service resource in the Azure portal

App name: This will be your bot’s default name, and the first part of your bot’s url
Subscription: Choose the subscription you want to use from the drop-down
Resource Group: Leave “Create new” selected, and leave the value the same as App name
Location: Choose the location that best describes your current location

Click Create to create and deploy your new Azure Bot Service.

Configure your bot

Once your bot is finished deploying, open it in the Azure portal. You can click here to see a list of your resources where you’ll find your new Azure Bot Service.

Click Create Microsoft App ID and password

This should open a new tab displaying your new App name and App ID. (If you’re prompted to login, make sure you login with the same email address you used to create your Microsoft Bot Framework account).

Next, click Generate App ID and password to show a pop-up displaying your new password. Copy the password to your clipboard and click Ok.

Make sure to store the password somewhere safe now as you will not be able to see it again.

Click Finish and go back to Bot Framework. This should close the tab and return you to the Azure portal with new App ID already be filled in.

Paste your new App password into the password field. Then, under Choose a language, select the language to write your bot in.

Note: I’ll be using C#, but you should be able to complete this sample using NodeJS as well.

Choose the Question and Answer template under Choose a template, agree to the Terms of Use, Privacy Statement, and Code of Conduct for the Microsoft Bot Framework (Preview), and click Create bot.

You should be presented with a pop-up dialog to Connect Azure Bot Service to QnA Maker. If not, make sure you’re logged in to your QnA Maker account, and you’re not blocking the associated cookies

Leave (or select) Create new knowledge base selected in the drop-down menu and Click OK. You should see a green banner across the top of the Azure portal letting your know your bot is being provisioned.

Train your QnA service

Now that your bot is set up and pointing to a new QnA service, we’ll need to teach the QnA service some, well… questions and answers.

Click here to view a list of your QnA services, and select edit icon next to the service you just created. It’ll likely be name something like “Basic QnA KB-2017-05…“.

On the left hand side of the dashboard, select Settings

Paste the following urls into the URLs section. (Note: you’re free to use any FAQ urls you want, it won’t prevent you from completing this sample)

• https://docs.microsoft.com/en-us/bot-framework/resources-bot-framework-faq
• https://docs.microsoft.com/en-us/bot-framework/troubleshoot-general-problems

Click Save and retrain, then click Publish. You’ll be presented with a screen showing the changes to your services knowledge base that will be published.

Click Publish.

Test your bot

Return to your Azure Bot Service in the Azure portal and click Test in the top right to open a web chat with your bot.

• Type Hi in the chat window and press return
• Type What's the Direct Line channel? and press return

Create a Native Mobile App

To complete this step you’ll need to have Visual Studio for Mac. You can download and install it here.

Now we’ll create a native iOS and Android app to interact with our bot. I’ve created a custom Project Template for Visual Studio that sets everything up automatically. We’ll set that up first.

Install NomadCode.ProjectTemplates extension

Here’s how to install NomadCode.ProjectTemplates:

1. Download the .mpack file under the Downloads section of the latest release of NomadCode.ProjectTemplates
2. Launch Visual Studio for Mac, open the Visual Studio menu and select Extensions…
3. In the bottom left of the Extension Manager dialog, click Install from file…
4. Choose the .mpack file you downloaded in step 1
5. When prompted, select Install
6. Once installation is complete, click “Ok” and close the Extension Manager dialog

Create new App

Now we’ll create our mobile app solution.

In Visual Sudio for Mac, got to File -> New Solution… (or Shift + ⌘ + N). Then, in the New Solution dialog’s left column, select App (under Multiplatform) then Native Bot (iOS, Android) and click Next.

Note: Depending on the version of Visual Studio for Mac, this project type may be under Other -> Miscellaneous -> General instead

Finally name your project, choose a location, and click Create.

Enable Direct Line channel

Your app will communicate with your bot via the Direct Line channel, so we’ll need to enable that back in the Azure portal.

Return to your Azure Bot Service in the Azure portal, and click CHANNELS in the top right to configure the channels your bot supports. Under the Add a channel section, select the Direct Line channel.

This should open a new tab to Configure Direct Line. If it does not, make sure you’re logged in to your Microsoft Bot Framework account, and you’re not blocking the associated cookies.

On the Configure Direct Line page, click + Add new site in the left column and enter `Mobile App into the Name your site field and click Done.

You should now see two Secret keys. Click Show next to one of the keys, Copy the key to your clipboard, then click Done

Add Direct Line Secret to Mobile App

Now that we have the secret, return to Visual Studio for Mac and open (if it’s not already) the app solution we created earlier.

In the Solution Explorer open the Keys.cs located in the Keys directory of the Shared project, and paste in the Direct Line secret for the value of DirectLineSecret on line 16.

Build and Run the App

Finally, build and run the app on the iOS Simulator and interact with your bot:

• Type Hi in the chat window and press return
• Type What's the Direct Line channel? and press return

This post looks at a couple examples of how this simple practice removes the need for unnecessary strings and leads to cleaner code.

Storyboard Identifier

In the first example I’ve added a new UITableViewController to my storyboard, set the Class to CustomTableViewController and the Storyboard ID to “CustomTableViewController”

I can now programmatically create a new instance of CustomTableViewController using its Storyboard ID:

var storyboardId = "CustomTableViewController";
var controller = Storyboard.InstantiateViewController (storyboardId) as CustomTableViewController;

Everything works as expected, as long as I have a view controller in my storyboard with a matching Storyboard ID, and there isn’t a typo in the string.

However, if I know that the Storyboard ID is the same as the type’s name, I can use the typeof operator and get rid of the string altogether:

var storyboardId = typeof(CustomTableViewController).Name;
var controller = Storyboard.InstantiateViewController (storyboardId) as CustomTableViewController;

Or even better, write an extension method like this:

public static T Instantiate<T> (this UIStoryboard storyboard)
	where T : UIViewController
=> storyboard.InstantiateViewController (typeof (T).Name) as T;

And cut the code down to:

var controller = Storyboard.Instantiate<CustomTableViewController>();

Now, I not only got rid of the string identifier, but I’ll also get build-time checking that my custom type inherits from UIViewController.

Reuse Identifier

An even more common example of benefiting from this practice, is in the context of Reuse IDs on UITableView or UICollectionView cells. Take the UITableViewCell subclass below.

public class CustomTableViewCell : UITableViewCell
{
	public void SetData(Item item) => titleLabel.Text = item?.Name;
}

In my storyboard, I’ve set the CustomTableViewController’s prototype cell’s Class to CustomTableViewCell:

Then set the cell’s Reuse ID to “CustomTableViewCell”

Normally, my CustomTableViewController (or UITableViewDataSource) GetCell override would look something like this:

public override UITableViewCell GetCell (UITableView tableView, NSIndexPath indexPath)
{
	var reuseId = "CustomTableViewCell";

	var cell = tableView.DequeueReusableCell (reuseId, indexPath) as CustomTableViewCell;

	cell?.SetData (Items [indexPath.Row]);

	return cell;
}

However again, if I know that the Reuse ID is the same as the cell type’s name, I can get rid of the string, and write another extension method:

public static T Dequeue<T> (this UITableView tableView, NSIndexPath indexPath)
	where T : UITableViewCell
=> tableView.DequeueReusableCell (typeof (T).Name, indexPath) as T;

And cut my GetCell override to the code below, with the build-time checks:

public override UITableViewCell GetCell (UITableView tableView, NSIndexPath indexPath)
{
	var cell = tableView.Dequeue<CustomTableViewCell>(indexPath);

	cell?.SetData (Items [indexPath.Row]);

	return cell;
}

Dig it?

You can find a the extension methods mention above and several more including support for collection views, here.

Mobile applications written in C# using Xamarin are native — just as native as iOS apps written in Swift or Objective-C, and Android apps written in Java.

If you’re intrigued (or disagree), read on. If you did read on, and you still disagree, email me. We’ll get to the bottom of this ;)

Approaches to Writing Mobile Apps

Okay, let’s break it down. When you, your company, your wife - whatever, decide to build a mobile app, you’ve got a few options. And like most things in life, each choice, or approach, is going to have pros and cons.

Since we’re comparing Xamarin to “native”, let’s start out with the approach that undoubtedly yields a 100% native app. I tend to call this approach Indigenous Native, or simply writing the native app with the “indigenous” language and toolset. An example of this approach would be writing an iOS app in Swift using Xcode.

Indigenous Native

This approach is going to yield a fully native app that performs and responds the way the user expects it to. Perfect.

However, the approach is also going to yield a unique codebase for each platform the app will support. If the app is written for iOS and Android, the iOS version must be written in Swift or Objective-C using Xcode, then the Android version must be written from scratch in Java using Android Studio or Eclipse, leaving you with two separate codebases, and likely two separate teams writing and maintaining them.

Kind of sounds terrible. But a truly native application is so important to a mobile app’s success — both consumer apps and business apps — that people and companies commonly write and maintain two completely separate codebases for the same app on iOS and Android.

That’s why the “short version” simply states that Xamarin is native. That’s the most important part.

Xamarin

Xamarin is the only other approach to building mobile apps that yields a fully native app and does so without limiting the developer to a subset of the native SDKs. To understand how that’s possible, let’s break down what Xamarin is and a little bit of how it works.

Xamarin is essentially made up of two parts — the first of which is a collection of one-to-one bindings for the entire iOS, Mac, and Android SDKs. What does that mean?

One-to-One Bindings

Well Xamarin didn’t reverse-engineer all the frameworks and libraries you’d use to write native iOS and Android apps. Instead, they simply exposed those APIs to C#. When you call an iOS or Android API in your Xamarin app in C#, you’re calling the exact same API of the exact same framework or library you would call using the “indigenous” languages.

So with just this “first part” of Xamarin, you now have access to everything you would if you were writing your app in Objective-C, Swift, or Java. Anything that can be done in an iOS application using Objective-C or Swift, and anything that can be done in an Android app using Java, can be done in C# using Xamarin. There is no exception.

These one-to-one bindings cover 100% of the public APIs Apple and Google have exposed to developers to write iOS and Android apps respectively.

To put this in context, you could literally take an iOS app written in Swift, or a Android app written in Java, and rewrite it line-for-line — using all of the same objects, methods, properties, etc. — in C# with Xamarin and end up with the same app with the same UI, the same performance, the same… well, you get it.

Those of you that’ve been paying attention may have just realized that Xamarin doesn’t sound all that cross-platform at all. If you’re just calling the same APIs in a different language, you’re not going to share any code…?

You’re right. The way I see it, Xamarin is not really a “cross-platform solution”, but there is a cross-platform “component” to Xamarin — and that’s the second part — Mono.

Mono

Mono is an implementation of the .NET base class libraries that’ll run natively inside of your Xamarin app.

There’s plenty of information out there on Mono — if you want to find out more, I’d encourage you to Google it — but in the context of Xamarin, Mono means you can write portable .NET code in C# (or F#) and share it across your native iOS, Mac, Android, Windows apps.

Anything you can do using the .NET base class libraries — or with any third-party portable .NET library — you write once and share that code and functionality across a iOS, Mac, Android, and Windows. A couple of common examples of this are the service layer and data access layers of your application.

The title of this post is Xamarin vs. Native, so I’m not going to spend as much time on the remaining approaches.

I’m going to lump everything else into two remaining buckets: Hybrid and Web. There are several solutions out there that create a pretty big spectrum, but I’ll be talking about these two categories at such a high level, it won’t really matter.

Hybrid

First let’s talk Hybrid. Usually these solutions are truly “write-once-run-everywhere” and frequently written in a familiar language like JavaScript.

The two biggest benefits to using a hybrid solution are 1) the time it takes to produce a functional app and 2) the ability to use existing skills (JavaScript).

Additionally, some Hybrid solutions can compile to a native or near-native app. And depending where on the spectrum the solution sits, this is going to mean much better performance than a webpage disguised as an app (see below).

But I want to clarify what I mean when I say “compile to a native or near-native app” because the word “native” gets thrown around a lot.

“Native binary” does not necessarily mean a “native app” in the same sense as the two previous approaches. If a Hybrid tool exposes 60% of the iOS and Android SDK through its own “write-once-run-everywhere” APIs, it may compile the resulting app to native binary, but the app is still going to look and feel like it was developed using 60% of the SDK.

To put this in context, let’s look at the very specific example: the best way to do animations inside of an iOS application is to use the animation framework that Apple created and distributed to developers to do animations in iOS apps. Using anything else is either going to yield subpar animations, perform poorly, or simply be an abstraction that is actually using the same animation framework behind the scenes.

Without access to 100% of the APIs in 100% of the frameworks shipped with the iOS SDK, you are going to be limited. Now, that example was specific to iOS, but the concept is equally true for Android.

Every Hybrid solution is going to have some level of this “least common denominator” type limitation. The only two approaches that expose 100% of the SDKs are Indigenous Native and Xamarin.

Web

In the context of the blog post, Web refers to everything from responsive or mobile websites, to apps made of wrapped websites.

And on this approach, I’ll very be brief. There is absolutely a place for responsive or mobile web, but let’s not call it a mobile app. Why? Well, let’s be honest, just because the app can open up the camera, it’s still just a webpage.

The End

Hopefully this short write-up puts Xamarin in perspective for those interested.

I’m obviously a fan of Xamarin, and that’s really because I love native iOS and Android development, and I really like C#.

However, I prefer to work with .xibs and .storyboards in Xcode Interface Builder opposed to Xamarin Studio’s built-in designer.

Within Xamarin Studio you can open these files in Xcode easily using the “Open with…” action menu, but I wanted it to use Xcode by default.

Yesterday I wrote a simple add-in for Xamarin Studio that sets Xcode Interface Builder as the default designer for .xib and .storyboard files.

You can check out the source or just follow these steps to install the add-in and use in Xamarin Studio:

1. Download the .mpack file of the latest release
2. Launch Xamarin Studio, open the Xamarin Studio menu and select Add-ins…
3. In the bottom left of the Add-in Manager dialog, click Install from file…
4. Choose the .mpack file you downloaded in step 1.
5. When prompted, select Install

With the add-in installed, double-clicking .xib and .storyboard files will open them in Xcode Interface Builder. Xamarin Studio’s designer can still be used via the “Open with…” action menu.