Today we announce the public release of Unity 4.6.2, available for download as of right now. It is the first public release with iOS 64-bit support, using our new IL2CPP technology.

IL2CPP is an innovative scripting technology developed in-house by Unity. It delivers greatly improved performance for all scripting inside your projects, and is compatible with the current Mono-AOT solution used on iOS builds.

IL2CPP enables us to rapidly port our scripting solution to new platforms (like our WebGL support) and architectures, of which ARM64 (the architecture that underpins 64-bit on iOS devices) is one. With Unity 4.6.2 you’ll thus be able to make a Universal build that works on both 32-bit and 64-bit iOS devices.

Impressive performance improvements

During our alpha and beta cycles we’ve benefited from lots of really useful feedback from the Unity Community. And, users testing our iOS 64-bit and IL2CPP support frequently reported their scripts running much faster with the new scripting backend.

For example, Andrew Witte, who was running the RayTraceBenchmark on his 32-bit iOS device, achieved the following:

Of course, what we care about most is your scenarios, but during our benchmarking we also saw significant performance improvements.

This is the simple total time of a JPEG Encoder written in UnityScript:

This is the Mandelbrot benchmark that is part of the Unity benchmark used for testing WebGL; it shows a significant performance increase on IL2CPP:

Get started with iOS 64-bit support

In this new build, enabling the IL2CPP scripting backend and iOS 64-bit support on your project is just a couple of clicks away. In the Player Settings for iOS you’ll find two new dropdowns: “Scripting Backend” and “Architecture”.

Switching the scripting backend to IL2CPP unlocks the 64-bit iOS support. By default it builds for “Universal” Architecture, which means your builds will include both the ARMv7 and ARM64 binary slices in your application.

If your existing project depends on native plugins, you might need to upgrade them to a version that supports 64-bit iOS and IL2CPP. We partnered with Unity plugin developer Prime31 to get all their plugins upgraded for use on iOS64. You can download them here.

Once this is done, export your project to Xcode. Note that because IL2CPP outputs scripts as C++ into your Xcode project, you’ll need to set the configuration to Release to utilize the full performance optimization of the Clang compiler on the IL2CPP generated code.

You can see how to set it up in the following two screenshots from Xcode 6:

Now you’re ready to run your application on a device. Use the Architecture “Universal” player setting, and the appropriate code will run automatically whether you’re using a 64-bit or 32-bit device. You can get a more detailed iOS 64 bit upgrade guide from the Unity manual.

Things to be aware of:

• WebRequest/WebClient API is currently available but not functioning. Anything requiring asynchronous sockets through Delegate BeginInvoke/EndInvoke currently doesn’t function. We will address this in an upcoming patch release.

• Delegate BeginInvoke/EndInvoke will not work though other delegate functions are working well. We will address this in an upcoming patch release.

• RakNet networking has not yet been ported to IL2CPP, and causes issues if you or 3rd party assemblies reference it. We will address this in an upcoming patch release.

• Stripping is always performed when on the IL2CPP backend. This might necessitate workarounds to prevent stripping of used types.

• When stripping is set to micro-mscorlib, compilation might fail on missing types. We are planning to completely disable its selection for IL2CPP in a future build.

• Xcode takes longer to build. The main reason being that there is a far greater amount of source code to compile.

• Managed Debugger is not supported. We have it on our roadmap. In the meantime, beta users have had great success debugging their script code using the Xcode debugger.

• Enabling the Xcode Internal profiler will result in compilation errors when using the IL2CPP scripting backend.

We are very aware that some of the items on the above list will cause shipping delays for some. Ever since Apple’s Oct 20 announcement that new iOS apps uploaded to the app store must have 64-bit support, we’ve been working around the clock, picking off bug-reports at an unprecedented rate while pushing out new builds weekly.

Everyone working on this deeply cares about getting every single issue resolved as quickly as humanly possible.

If you already have your iOS project on the App Store, we recommend that you keep shipping updates using the Mono backend on ARMv7. Apple states that you can continue to do this up until June 1. We further recommend that you commence internal testing of your project using the IL2CPP backend as soon as practically possible.

We’re continuing our weekly builds and you can check out our patch releases regulary on http://unity3d.com/unity/qa/patch-releases. Please feel free to reach out to us on this forum thread http://forum.unity3d.com/threads/unity-patch-releases.246198/. We answer queries daily.

Android 5.0 Lollipop introduced a complete refresh, known as Material Design, to the Android user interface which generated rapid adoption throughout the development community. Until Google introduced revision 21 of the Android Support v7 AppCompat library, Material Design themes, controls, and features were utilized only if you wanted to target devices running API 21.

We recently took a look at how this library gave developers an opportunity to add the ActionBar to applications targeting older devices all the way back to API 7. However, now you can use this updated library to add Material Design to any of your applications and use new controls like the new Toolbar, which replaces the ActionBar. Let’s see how easy it is to get started with the new Support Library v7 AppCompat by updating our Toolbar example.

Getting Started

To start integrating AppCompat into your Android project you will want to install the Support Library v7 AppCompat from the Component Store or directly from NuGet. This will also install the Support v4 Library, which is required because it provides controls that help maintain backwards compatibility.

Since you will now be able to target older versions of Android, you will want to adjust your Minimum and Target Android version under Android Application in the project options.

Updating to Material Theme

There are many differences to the actual resources that are embedded into your app when you use the AppCompat library. This means that the actual themes and attributes are completely different between normal Material and AppCompat themes. You will find three new themes that you can inherit from:

Dark: Theme.AppCompat
Light: Theme.AppCompat.Light
Light with Dark ActionBar: Theme.AppCompat.Light.DarkActionBar

To use one of these themes, you’ll want to create two folders under your Resources folder named values and values-v21 where you will create a styles.xml where you can customize your applications theme. In our values/styles.xml you will create the base theme of your application and then set custom attributes. You will see that these attributes are different than using the standard Material Theme since they have dropped the android: prefix as they are now part of your application.

values/styles.xml

<resources>
  <style name="MyTheme" parent="MyTheme.Base">
  </style>
  <!-- Base theme applied no matter what API -->
  <style name="MyTheme.Base" parent="Theme.AppCompat.Light.DarkActionBar">
    <item name="android:windowNoTitle">true</item>
    <!--We will be using the toolbar so no need to show ActionBar-->
    <item name="windowActionBar">false</item>
    <!-- Set theme colors from http://www.google.com/design/spec/style/color.html#color-color-palette-->
    <!-- colorPrimary is used for the default action bar background -->
    <item name="colorPrimary">#2196F3</item>
    <!-- colorPrimaryDark is used for the status bar -->
    <item name="colorPrimaryDark">#1976D2</item>
    <!-- colorAccent is used as the default value for colorControlActivated
         which is used to tint widgets -->
    <item name="colorAccent">#FF4081</item>
     <!-- You can also set colorControlNormal, colorControlActivated
         colorControlHighlight and colorSwitchThumbNormal. -->
  </style>
</resources>

Then, inside of your values-v21/styles.xml, you’ll set a few more custom attributes that can take advantage of transitions on devices running Lollipop:

<resources>
  <!--
        Base application theme for API 21+. This theme replaces
        MyTheme from resources/values/styles.xml on API 21+ devices.
    -->
  <style name="MyTheme" parent="MyTheme.Base">
    <item name="android:windowContentTransitions">true</item>
    <item name="android:windowAllowEnterTransitionOverlap">true</item>
    <item name="android:windowAllowReturnTransitionOverlap">true</item>
    <item name="android:windowSharedElementEnterTransition">@android:transition/move</item>
    <item name="android:windowSharedElementExitTransition">@android:transition/move</item>
  </style>
</resources>

The last step is to open your AndroidManifest.xml under the Properties folder and add reference to your new theme under the application node with android:theme="@style/MyTheme".

Integrate Toolbar

Perviously, we saw how to integrate the new Toolbar into your application. The core of that remains the same, except that you will now directly reference the new Toolbar widget from the Support Library:

<?xml version="1.0" encoding="utf-8"?>
<android.support.v7.widget.Toolbar xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:local="http://schemas.android.com/apk/res-auto"
    android:id="@+id/toolbar"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:minHeight="?attr/actionBarSize"
    android:background="?attr/colorPrimary"
    local:theme="@style/ThemeOverlay.AppCompat.Dark.ActionBar"
    local:popupTheme="@style/ThemeOverlay.AppCompat.Light" />

Note here the use of custom themes directly for the Toolbar and the use of custom attributes. These are a change form the normal use of the Toolbar when not using AppCompat.

Update that Activity

The core of any Android application are Activities. When you start using AppCompat, you simply need to update your activities inheritance.
From:

public class MainActivity : Activity

To:

public class MainActivity : ActionBarActivity

You can now setup your Activity to set the SupportActionBar with the new Toolbar that you have embedded into your layout. I prefer to use an alias to ensure the correct Toolbar is always referenced:

using Toolbar = Android.Support.V7.Widget.Toolbar;

Then you simply need to find the Toolbar, set it, and access it in your OnCreate:

protected override void OnCreate (Bundle bundle)
{
  base.OnCreate (bundle);
  // Set our view from the "main" layout resource
  SetContentView (Resource.Layout.main);
  var toolbar = FindViewById<Toolbar> (Resource.Id.toolbar);
  //Toolbar will now take on default actionbar characteristics
  SetSupportActionBar (toolbar);
  SupportActionBar.Title = "Hello from Appcompat Toolbar";
  //..
}

There you have it, you can now run your newly Material Themed Android application on devices that aren’t running Lollipop!

Learn More

You can get the full source code for this project in the Support v7 Sample gallery. There you will also find other awesome examples of more Support v7 libraries such as CardView, RecyclerView, and Palette. During Evolve 2014, Jérémie Laval and I gave two talks on Material Design from Concept to Implementation. (Part 1 and Part 2) that are available to watch now.

Discuss this post in the Xamarin forums.

Earlier this month, I recorded a webinar showing an overview of what the new Unified API means for developers and how you can seamlessly migrate your existing apps to guarantee their longevity. As we approach Apple’s deadline for supporting 64-bit in new app submissions, iOS developers around the world are ensuring their apps will continue to be accepted into the App Store by making the necessary changes to enable the support. Xamarin developers will need to follow suit by making sure they’ve updated their apps to use the new Unified API, which replaces the Classic API.

During the webinar I demonstrated the migration process on an app I developed some time ago that needed to be migrated to the Unified API. The app in question is called Dutch Spelling, a language learning app originally built in just 2 hours! It’s available to download from GitHub in order for you to follow the guide I’ve created for you below.

Dutch Spelling’s business logic is contained within a library that is referenced from the language specific project. This approach allows me to add new features and fix bugs in only one project, while maintaining the language based content of the app separate.

Migration to Unified.

The migration process from the Classic API to our new Unified API couldn’t be any simpler. If you’ve cloned Dutch Spelling onto your machines, you’ll notice that it currently has two branches. The master branch is our Unified API and the second branch uses the Classic API. I’ve taken this approach with my other iOS apps such as My StepCounter, as it allows you to see the differences in the solution before and after migration.

You’ll want to ensure you’re on the Classic-API branch before starting the migration. Open the project in your favorite IDE (in my case it’s Xamarin Studio) and double check that everything builds as expected. If it doesn’t, please create an issue on GitHub for me to investigate.

Migration Tool

Let’s select the ‘Dutch Spelling’ project and click ‘Project’ > ‘Migrate to Xamarin.iOS Unified API’. You’ll be presented with a dialog explaining what the migration tool will do to your project. You will want to click ‘Migrate to Unified API’.

Xamarin Studio

Visual Studio

With this, your project will now reference Xamarin.iOS instead of MonoTouch and our Spelling.Core project will be marked as incompatible. This project is now using the Unified API and we don’t need to touch it again, however, we will now need to run the same process on Spelling.Core, and then we’re done.

If the migration tool doesn’t successfully migrate your project, or you’ve got a complex situation, you can manually migrate to the Unified API. Our documentation team has written a fantastic step-by-step migration guide.

Learn More

To learn more about the Unified API be sure to read through the full documentation. To see a full migration of Dutch Spelling in action, check out my Unified API Webinar recording online.

Danny Dura of Graphium Health talked to us about how his company is working to create better care for patients by bringing data and analytics into the peri-operative (surgical) healthcare space via mobile technology.

The Graphium Health app offers a better experience for both patients and providers by creating effective ways for providers to use the mobile devices they already have in their pockets to track patient data and analytics. Used by doctors, nurses, and other medical staff in hospitals nationwide, the app replaces paper charting with a more secure, accurate, and efficient way to keep track of patient information in an easy, usable format that doesn’t distract from providing top-notch care.

To understand the how the app streamlines care for both doctors and patients, we took a walk through the app with Danny:

I love that Graphium worked to make the app accessible and intuitive for health professionals, while increasing the efficiency and security of the process.

Learn More

To learn more about Graphium Health, or request a free trial, you can visit their website here.

To get started developing with the Xamarin platform, check out our developer documentation, or get live online training with Xamarin University.

Since the introduction of the Xamarin MVP program in 2013, our MVPs have been busy sharing their love and understanding of mobile app development with a growing community of more than than 880,000 Xamarin developers worldwide. Supporting this growth are amazing community members who show their passion for all things C# and F# by sharing their experience and knowledge with the world.

Xamarin MVPs have earned recognition for significant contributions to the community, including:

• Writing great articles, books, and blog posts
• Speaking in public and online
• Sharing and building amazing libraries
• Helping developers online in our forums, on Twitter, Stack Overflow, and other communities
• Shipping awesome apps

Today, we’re extremely excited to recognize and welcome our latest Xamarin MVPs, below, for their remarkable contributions to the community!

	Enrique Aguilar			Laurent Bugnion
	Tomasz Cielecki			Jesse Liberty
	Jon Lipsky			Roger Peters
	Rachel Reese			Brent Schooley
	Ed Snider			Michael Stonis
	Alec Tucker

If you know of an outstanding developer who would make a great Xamarin MVP, please nominate him or her here.

From the sophisticated opinion of the trendsetters to Forbes, the Selfie Stick is the recipient of scorn and ridicule.

One of the popular arguments against the Selfie Stick is that you should build the courage to ask a stranger to take a picture of you or your group.

This poses three problems.

First, the courage/imposition problem. Asking a stranger in the street assumes that you will find such a volunteer.

Further, it assumes that the volunteer will have the patience to wait for the perfect shot ("wait, I want the waves breaking" or "Try to get the sign, just on top of me"). And that the volunteer will have the patience to show you the result and take another picture.

Often, the selfista that has amassed the courage to approach a stranger on the street, out of politeness, will just accept the shot as taken. Good or bad.

Except for a few of you (I am looking at you Patrick), most people feel uncomfortable imposing something out of the blue on a stranger.

And out of shyness, will not ask a second stranger for a better shot as long as the first one is within earshot.

I know this.

Second, you might fear for the stranger to either take your precious iPhone 6+ and run, or even worse, that he might sweat all over your beautiful phone and you might need to disinfect it.

Do not pretend like you do not care about this, because I know you do.

Third, and most important, we have the legal aspect.

When you ask someone to take a picture of you, technically, they are the photographer, and they own the copyright of your picture.

This means that they own the rights to the picture and are entitled to copyright protection. The photographer, and, not you, gets to decide on the terms to distribute, redistribute, publish or share the picture with others. Including making copies of it, or most every other thing that you might want to do with those pictures.

You need to explicitly get a license from them, or purchase the rights. Otherwise, ten years from now, you may find yourself facing a copyright lawsuit.

All of a sudden, your backpacking adventure in Europe requires you to pack a stack of legal contracts.

Now your exchange goes from "Can you take a picture of us?" to "Can you take a picture of us, making sure that the church is on the top right corner, and also, I am going to need you to sign this paper".

Using a Selfie Stick may feel awkward, but just like a condom, when properly used, it is the best protection against unwanted surprises.

You’re at the end of your mobile development cycle and just need to test your app before submitting to the app store. After testing on a handful of devices, you find several showstopper bugs that push your ship date out to weeks past your deadline. Is there a better alternative to this “build then test” workflow that slows your time to market, forces rework, causes bugs, and costs you money?

Download this infographic to learn why shifting your testing processes “left” in the development cycle to the start of your mobile project makes it faster and easier to find bugs before your users do.

Docker seems to be the new trend in application virtualization, and it is growing so fast that even Microsoft is getting ready to run Docker containers on Azure. They are also getting Windows ready to be dockerized.

This blogpost explains how to run a pre-built Plastic server Docker image that we have published at https://hub.docker.com. It explains the container structure we’ve prepared and how to isolate the server container from the data container to ease upgrades.

Meeting Docker

I’ve been playing with Docker these days, studying the integration possibilities it offers and finding an initial approach to wrap our beloved Plastic SCM server in a Docker container. And after some hours toying with our own Docker containers, I must say that I’m very excited about its potential!

But first things first: what’s actually Docker?

Docker: Sharing standardized module containers

Docker, as they define themselves, is an open platform for developers and sysadmins to build, ship and run distributed applications. It allows developers to create their own isolated environments according to their needs, define communication points (disk volumes or TCP/UDP ports) and save these settings into a Docker image.

Once the image has been set up, any other developer or sysadmin can run a new instance of the image, instantiating it into a Docker container.

Each one of those containers is run and virtualized on top of the Docker server, ensuring there’s no interference between them or the host OS.

Also, any change made in a container is persistent: all containers have their own local filesystem, which is managed by Docker. It won’t be accessed by any other container unless explicitly told to do so.

Last year at GDC Microsoft announced DirectX 12. During yesterday’s Windows 10 media briefing, Phil Spencer of Microsoft mentioned that Unity is going to add support for DirectX 12. Here are some more details we can share with you today!

Direct3D 12 is a new graphics API with the promise of reducing driver overhead and allowing better use of multi-core systems. In those aspects it is comparable to AMD’s Mantle and Apple’s Metal.

The architecture of Direct3D 12 differs greatly from that of Direct3D 11 both in the way memory is accessed and GPU commands are issued. Rather than having a single context on which to set states and issue draw calls, we can now build command lists on multiple threads and retain them over multiple frames if necessary, saving precious CPU cycles and eliminating the dreaded my-render-thread-does-most-of-the-work problem. This has the potential to both reduce total frame time and increase battery life.

3DMark have ported one of their benchmarks to DirectX 12 and reported a 50% improvement in CPU utilization. See this blog post for more details.

Tested on GIGABYTE BRIX Pro (Intel Core i7-4770R + Iris Pro Graphics 5200)

Intel have also demonstrated what can be done on a Surface Pro 3 with Intel HD4400 graphics. This blog post has all the details.

Close up of another CPU/GPU power graph taken during a locked framerate Intel Asteroids demo showing over 50% CPU power usage reduction

Direct3D 12 is expected to run on all Microsoft devices: mobiles, laptops, desktops and Xbox One, all of which Unity already supports. It is only logical for us to adopt the new universal API. However a significant amount of work is required to reap all the benefits this architectural switch can provide and that is why we have started early. Over the past several months we have worked closely with Microsoft to bring Unity to DirectX 12 and our initial port is now passing over 95% of our graphics tests.

Passing all the tests is only the first step. Once we are happy with the implementation feature-wise we shall move on to the new features of Direct3D 12 and invest heavily in optimization. There is ongoing work to allow our renderer to better use multiple cores which will apply directly to Direct3D 12 and hopefully provide the promised performance improvement. Right now, it’s too early to discuss performance due to the alpha state of Windows 10 and DirectX 12 drivers, however we are happy with the numbers we’re seeing.

Both Nvidia and Intel have given us ample support, and we now have code running on both Nvidia and Intel hardware. All of our demos are behaving well on Direct3D 12. That makes us very confident that your games will too.

Currently our plan is to release DirectX 12 support early in the Unity 5 cycle (well in time for the release of Windows 10), and to target standalone builds and Windows Store Apps first. Then we’ll follow up with Windows Phone and Xbox One support, aligning with the plans Microsoft has for their platforms.

Keep checking our blog for more DirectX 12 news. We should have more announcements in the next few months. In the meantime you can find more general information on the subject on the Microsoft DirectX 12 blog.

When developing mobile apps, you often run into an instance where your app needs some kind of authentication mechanism to protect its contents. Some mobile app developers choose to create their own repository to create a username/password based solution. Others choose a social media authentication provider such as Facebook, Twitter, or LinkedIn. Using Xamarin.Auth makes authenticating to services such as these extremely simple to implement.

However, in the case of enterprise apps, people don’t want to remember ‘yet another’ username/password combo and social media authentication is the least expected solution. Users expect their organization account to allow them to use different resources and apps within their system. Welcome to the world of Azure Active Directory (or Azure AD for simplicity).

Azure AD allows developers to secure resources such as files, links, and Web APIs using the same organizational account that employees use to sign in to their systems or check their emails. This should sound a bit familiar, as it is the same authentication mechanism behind Office 365.

Let’s take a look at how to integrate Azure AD into your mobile app with two simple steps.

Step 1: Registering the application with Azure AD

1. First navigate to https://manage.windowsazure.com and log in with your Microsoft Account or Organization Account in the Azure Portal. If you don’t have an Azure Subscription, you can get a trial from http://www.azure.com
2. After signing in, go to your Active Directory (1) and select the Active Directory where you want to register the application (2)
   
3. After selecting the desired Active Directory, ‘Add‘ a new application by either clicking the link at front or at the bottom. Then select ‘Add an application my organization is developing‘
   
4. On the next screen, give your app a name. In my case it is ‘XAM-DEMO‘. On this screen, make sure you select ‘Native Client Application‘ as the type of application.
   
5. On the final screen, provide a ‘Redirect URI‘, which is unique to your application as it will return to this URI when authentication is complete.
   
6. Once the app is created, navigate to the ‘Configure‘ tab. Write down the ‘Client ID’, which we’ll use in our application later. Also, on this screen you can give your mobile application access to Active Directory or add another application like Web API, which can be used by mobile application once authentication is complete.
   

Step 2: Authenticating the application with Azure AD

In your application, add a reference to Azure Active Directory Authentication Library (Azure ADAL) using the NuGet Package Manager in Visual Studio or Xamarin Studio. Make sure you select ‘Show pre-release packages’ to include this package, as it is still in preview.

Note: Azure ADAL 3.0 is currently a preview and there may be breaking changes before the final version is released. I have included references at the end of this post where you can find more information on Azure ADAL.

In your application, you will now need to add the following class level variables that are required for the authentication flow.

//Client ID from from step 1. point 6
public static string clientId = "25927d3c-.....-63f2304b90de";
public static string commonAuthority = "https://login.windows.net/common"
//Redirect URI from step 1. point 5<br />
public static Uri returnUri = new Uri("http://xam-demo-redirect");
//Graph URI if you've given permission to Azure Active Directory in step 1. point 6
const string graphResourceUri = "https://graph.windows.net";
public static string graphApiVersion = "2013-11-08";
//AuthenticationResult will hold the result after authentication completes
AuthenticationResult authResult = null;

One thing to note here is commonAuthority. When the authentication endpoint is ‘common’, your app becomes ‘multi-tenant’, which means any user can use login with his Active Directory credentials. After authentication, that user will work on the context of his own Active Directory – i.e. he will see details related to his Active Directory.

At this time, you can modify the default button.Click event from the default Android application (or create your own flow to start the authentication). This will start the authentication and upon completion assign the result in authResult

button.Click += async (sender, args) => {
  var authContext = new AuthenticationContext(commonAuthority);
  if (authContext.TokenCache.ReadItems().Count() == 0)
    authContext = new AuthenticationContext(authContext.TokenCache.ReadItems().First().Authority);
  authResult = await authContext.AcquireTokenAsync(graphResourceUri, clientId, returnUri, new AuthorizationParameters(this));
}

In the above code, the AuthenticationContext is responsible for the authentication with commonAuthority. It has an AcquireTokenAsync method, which take parameters as a resource which needs to be accessed, in this case graphResourceUri, client ID, return URI. The app will return to the returnUri when authentication completes. This code will remain the same for all platforms, however, the last parameter, AuthorizationParameters, will be different on different platforms and is responsible for governing the authentication flow.

In the case of Android or iOS, we pass ‘this’ parameter to AuthorizationParameters(this) to share the context, whereas in the case of Windows, it is passed without any parameter as new AuthorizationParameters().

Along with it, we also need to override the OnActivityResult method in Android to resume the application.

protected override void OnActivityResult(int requestCode, Result resultCode, Intent data)
{
  base.OnActivityResult(requestCode, resultCode, data);<br />
  AuthenticationAgentContinuationHelper.SetAuthenticationAgentContinuationEventArgs(requestCode, resultCode, data);<br />
}

For Windows Phone, modify the OnActivated method in the app.xaml.cs file with the below code:

protected override void OnActivated(IActivatedEventArgs args)
{
#if WINDOWS_PHONE_APP
  if (args is IWebAuthenticationBrokerContinuationEventArgs)
  {
     WebAuthenticationBrokerContinuationHelper.SetWebAuthenticationBrokerContinuationEventArgs(args as IWebAuthenticationBrokerContinuationEventArgs);
  }
#endif
  base.OnActivated(args);
}

Now if you run the application, you should see an authentication dialog. Upon successful authentication, it will ask your permissions to access the resources (in our case Graph API).

If authentication is successful and you’ve authorized the app to access the resources, you should get an AccessToken and RefreshToken combo in authResult. These tokens are required for further API calls and for authorization with Azure AD behind the scenes.

For example, the code below allows you to get a user list from Active Directory. You can replace the Web API URL with your Web API which is protected by Azure AD.

var client = new HttpClient();
var request = new HttpRequestMessage(HttpMethod.Get, "https://graph.windows.net/tendulkar.onmicrosoft.com/users?api-version=2013-04-05");
request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", authResult.AccessToken);
var response = await client.SendAsync(request);
var content = await response.Content.ReadAsStringAsync();

This way you can authenticate your mobile apps against Microsoft Azure Active Directory. ADAL makes it much easier with fewer lines of code, while keeping most of the code the same and thus making it shareable across platforms.

Learn More:

• Azure ADAL is in preview. So, there can and most likely will be changes before the final release. Follow Vittorio Bertocci’s blog for more details and changes to the library.
• The Azure Team has shared a complete example with Azure ADAL for each platform. Download it from here.

GameObject::AddComponent(string) has been removed in Unity 5.0.  The alternatives are two overloads of this API, one taking the component type as a generic type argument and another one taking a reference to the component type. Automatic API updating has been configured but not all cases can be handled automatically.

In our quest to improve Unity we realized that we should let GameObject::AddComponent(string) go; in our first attempt we were too “aggressive” and removed GetComponent(string) as well. However, after receiving some great feedback, we reevaluated this decision and reintroduced it.

Unfortunately we could not do the same with AddComponent(string) (it would reintroduce the very same dependencies we are aiming to break, i.e, from core to subsystems). If your project uses this method you have two possible alternatives (depending on the accessibility of the type as explained in the rules related to compilation order and how the type name is specified). We’ll further describe these options in the following paragraphs (examples are written in C# but the same concepts applies to UnityScript (js) / Boo).

Scenario 1: Name of the type being added is passed as a constant / string literal and the type is known at build time

This scenario is straightforward and easily identifiable: AddComponent() is called with a constant string and you are able to declare local variables (or parameters, or fields) of the type being added. In this case you can simply use the generic version of AddComponent(), as shown in the following example:

// each class declared in its own file
namespace N1
{
      class C1 : MonoBehaviour { }
}

class C2 : MonoBehaviour { }

class MyObj : MonoBehaviour
{
      public void Start()
      {
          AddComponent(“C1”); // only the class name, no namespace information....
          AddComponent(“C2”);
      }
}

should be changed to:

// C1 / C2 declared as before.

class MyObj : MonoBehaviour
{
      public void Start()
      {
          AddComponent< N1.C1>();
          AddComponent< C2>();
      }
}

when porting the project to Unity 5.0.

Note that classes declared inside namespaces (C1) will require the namespace to be specified (line 8). This is unlike the version of this API that used to take a string, it only expects the class name).

Scenario 2: Parameter  / field / local variables are passed as the argument to AddComponent.

This scenario is also easily identifiable by simply checking the call to AddComponent() (it will use a field / local variable / parameter as the argument). Unfortunately, in this case the alternative is to rely on Type.GetType(string) to retrieve a reference to the type at runtime and call AddComponent(type) – which comes with some drawbacks:

1. Scenarios involving  AOT / stripping
   The same constraints that apply to platforms apply here. For instance, the AOT compiler may not include a type in the final binary if no reference to that type exists in the code (i.e, only the type name, as a string, is used). Also, keep in mind that on IL2CPP backend, stripping is always enabled.

2. Requires the type’s assembly fully qualified name
   This is more an annoyance than an issue, nevertheless, assembly qualified names can be pretty big, intimidating and prone to syntax errors.

3. Requires an actual .Net type to exist
   Some Unity components only existed in native code (i.e, no .Net counterpart) (for instance, EllipsoidParticleEmitter). We added .Net representation for such components (from UnityEngine) but we may always have overlooked one or more types ;)

4. Performance overhead involved in type lookup and / or other tasks.
   Usually this should not be an issue unless Type.GetType(string) gets called in a tight loop, nevertheless, you should keep it in mind.

Automatic API Updating

Since we want to make project updates as easy as possible, we configured our API Updater to take this change into account. When calls to AddComponent(string) are found, the updater analyzes the value used as the argument and, if it succeeds in resolving the type (which excludes the cases described by scenario 2 as the type name is only known at runtime) it simply applies the mechanics described in scenario 1 replacing the call to AddComponent(string) with a call to:

AddComponent< T>() // for C#

AddComponent.< T>() // for UnityScript (js) 

and AddComponent[of T]() for boo.

(“T” being the type of the component being added)

While planning how to handle the scenario in which the updater is unable to resolve the type being passed as the argument (scenario 2 and also some sub cases of scenario 1 – classes declared in namespaces for instance), we’ve tried to achieve a balance between usefulness, reliability and ease of use. After our first evaluation we came up with the following options:

1.  Do not touch the script at all (not good);

2. Simply replace all invocations to AddComponent(string) with its generic version (or the one taking System.Type as its parameter) and assume / hope it works;

3. Replace such invocations with more elaborate, possibly slow, code that tries to resolve the type at runtime looking in multiple assemblies.

Option 1 got discarded really quick and option 2 did not look very user friendly / reliable or professional to us, so we’re left with option 3 which, to be fair, didn’t sound like a great solution either. In the end we settled on what we consider to be a good compromise:  calls to AddComponent(string) that fall into this category (type cannot be resolved at compile time because it is passed through non constants / non literals) are replaced by a call to APIUpdaterRuntimeServices::AddComponent(…) which, in the editor, is implemented as described in option 3 with extra logging to provide developers hints on how to replace the call with something that is production quality. Below you can see a screenshot of such a log:

Log when game enter in play mode

(note that the line / column displayed in the log may be slightly off due to other updates being applied; also it is worth mentioning that the explanation uses C# generic method syntax – so if your scripts are written in UnityScript/Boo make the appropriate changes).

In the above example, even though the updater was unable to resolve the type, when in play mode, i.e, when using the editor version of UnityEngine assembly, APIUpdaterRuntimeServices::AddComponent() found out that the component being added can in fact be resolved and suggested replacing that call with a call to the generic overload of GameObject::AddComponent().

Due to platform constraints (this method uses methods / types not supported on all platforms) and performance implications for players, this method is marked as obsolete and you’ll get an error if you try to build the game, meaning that you do need to take some action to make your code ready for production.

While we understand that this is not a perfect solution we do believe that this is a necessary step to untangle this dependency, and we feel that the Unity 5.0 launch is the perfect time to make this change.

Was this information useful? Do you have any compliments? comments? complaints? Drop me a message!

@adrianoverona

The latest version of Mono has released (actually, it happened a week ago, but it took me a while to get all sorts of exciting new features bug-checked and shipshape).

Stable packages

This release covers Mono 3.12, and MonoDevelop 5.7. These are built for all the same targets as last time, with a few caveats (MonoDevelop does not include F# or ASP.NET MVC 4 support). ARM packages will be added in a few weeks’ time, when I get the new ARM build farm working at Xamarin’s Boston office.

Ahead-of-time support

This probably seems silly since upstream Mono has included it for years, but Mono on Debian has never shipped with AOT’d mscorlib.dll or mcs.exe, for awkward package-management reasons. Mono 3.12 fixes this, and will AOT these assemblies – optimized for your computer – on installation. If you can suggest any other assemblies to add to the list, we now support a simple manifest structure so any assembly can be arbitrarily AOT’d on installation.

Goodbye Mozroots!

I am very pleased to announce that as of this release, Mono users on Linux no longer need to run “mozroots” to get SSL working. A new command, “cert-sync”, has been added to this release, which synchronizes the Mono SSL certificate store against your OS certificate store – and this tool has been integrated into the packaging system for all mono-project.com packages, so it is automatically used. Just make sure the ca-certificates-mono package is installed on Debian/Ubuntu (it’s always bundled on RPM-based) to take advantage! It should be installed on fresh installs by default. If you want to invoke the tool manually (e.g. you installed via make install, not packages) use

cert-sync /path/to/ca-bundle.crt

On Debian systems, that’s

cert-sync /etc/ssl/certs/ca-certificates.crt

and on Red Hat derivatives it’s

cert-sync /etc/pki/tls/certs/ca-bundle.crt

Your distribution might use a different path, if it’s not derived from one of those.

Windows installer back from the dead

Thanks to help from Alex Koeplinger, I’ve brought the Windows installer back from the dead. The last release on the website was for 3.2.3 (it’s actually not this version at all – it’s complicated…), so now the Windows installer has parity with the Linux and OSX versions. The Windows installer (should!) bundles everything the Mac version does – F#, PCL facades, IronWhatever, etc, along with Boehm and SGen builds of the Mono runtime done with Visual Studio 2013.

An EXPERIMENTAL OH MY GOD DON’T USE THIS IN PRODUCTION 64-bit installer is in the works, when I have the time to try and make a 64-build of Gtk#.

Welcome to the big bad world of advertising. As a game developer, advertising can be a little overwhelming. How do I make money? How do I acquire users? What do all of those weird acronyms even mean?

Let’s take a step back and look at look at both sides of the game advertising coin:

• Monetizing your game by displaying ads for other products within your game.

• Advertising your game in order to acquire users.

Monetization – Displaying ads inside your game

There are, of course, several strategies you can employ to make money from your game – by displaying ads, by using in-app purchases and so on. These strategies aren’t necessarily exclusive. Games that feature in-app purchases often display ads as a complementary revenue source. Games without in-app purchases can generate significant revenue if they have sufficient numbers of users.

If you decide to display ads within your game, you’ll become what’s known within the industry as a publisher making inventory (the facility to display ads within your game) available to advertisers.

Advertisers will look to target particular player demographics (players with specific characteristics, those living in a particular region of the world, for example). In order to connect you as a publisher with advertisers who find your players particularly attractive, you’ll need the services of an advertising network.

Advertising networks, such as Unity Ads (currently, probably the fastest-growing Game Ad network in the world) receive money from advertisers for providing them with inventory. Ad networks use algorithms to determine when it’s relevant to display a particular advert within a given game, both to match up advertisers’ demographic requirements with a particular game’s players and, more importantly, to optimize the chances of players clicking ads.

If you’re considering becoming a publisher and making advertising inventory available within your game, there are a number of strategies you can employ to ensure that your users don’t find those ads intrusive.

A particularly successful one, in our experience, is linking ad views to in-game rewards (coins and the like). More on how best to integrate ads into your game in a later post…

Advertising – Acquiring users through in-game ads

Every developer needs players for their game, but not every developer knows if spending time and money on advertising makes sense. If you’re considering advertising your game, the first thing you need to work out is how much each player is worth to you.

If your game makes a relatively large amount of money per player from in-game purchases or ads you display inside your game, using advertising to acquire new users may well make sense.

If the cost per install of advertising your game is less than the amount of revenue you make from each install the difference between the two is pure profit. In the jargon, this is expressed as follows:

ARPU – Average Revenue Per User

        Each user you bring in typically brings in X dollars in revenue

CPI – Cost Per Install

Acquiring a new user through advertising, will cost you Y dollars.

        ARPU – CPI = Profit

Once you really get into advertising, there’s a lot more to discuss: advertising creatives, optimization, targeting… we’ll go into all of that in future blog posts.

Unity Ads

Crossy Road developers Hipster Whale chose to monetize their game by publishing ads (amongst other things). With Unity Ads, they were able to generate over $1 Million in revenue in just a few weeks.

Getting started with Unity Ads is very simple – just import the free Unity Ads plugin from the Asset Store and you’re good to go!

Today, we are are happy to announce the release of our WatchKit Preview for Xamarin Studio, enabling you to build, run, and test your Apple Watch apps directly from Xamarin Studio.

WatchKit Templates

We’ve added new templates for Watch apps and Watch extensions inside Xamarin Studio. Start with a new or existing iOS app, add a Watch App to house your interface, and then add a Watch extension to power the interaction. Xamarin Studio does all of the heavy lifting for you.

Test in the Simulator

Get started testing your applications in the simulator so you can be ready when devices hit the market. Xamarin Studio has support for building, running, and debugging your Watch apps in app mode. You can also test your app in Glance and Notifications mode from the command line.

Get Started Today

You can download the bits for WatchKit Preview directly from the Xamarin Developer site. To get started with WatchKit, check out the WatchKit Preview guide.

Please note that this release is a Preview. It is not available on the Stable, Beta, or Alpha channels and is a separate install. We are working hard on adding even more features for WatchKit, including support for the Xamarin Designer for iOS and Visual Studio, in future releases.

Very Important: Since this release is missing our designer support, you must follow the steps outlined in the WatchKit Preview guide to build your UIs.

See everything that WatchKit support has to offer by running the WatchKit Catalog sample from our sample gallery.

As an early adopter of Unity Cloud Build, prolific developer Spry Fox has found work on its next game Alphabear moving forward at a tremendous pace. Spry Fox developer Andrew Fray explains just how the power of efficient builds helped the studio.

Like many teams today, Spry Fox isn’t based in a single location. It employs talent across several continents, because they value talent and creativity more than proximity.

But managing the build process and the multitude of iterations a game goes through during development is a huge challenge; something Spry Fox Developer Andrew Fray knows well.

Unity Cloud Build has handled the entire compilation and bundling process for Alphabear during development, automatically processing any changes the team pushed to their source control repository, and delivering the result as a new build sent instantly via email. In short, it meant changes to the art, audio and copy appeared in new builds in minutes, on-device, without the need to ask engineers to export a build manually.

“Having our builds in the cloud, and giving people the ability to fetch it from wherever they are, out and about, is amazing,” explains Fray.

“Being spread across different continents, I can’t just call everyone over to my desk to see a new build, or pass a device around the office. That’s just not possible. It can make it very hard to share builds with your team efficiently.”

Creating and sharing builds is at the core of game development:  in order to test and gather feedback from teammates, beta players, clients, publishers and partners, game developers need to have a streamlined and effective method for building new versions and delivering them to the appropriate people. Otherwise, the process is not just merely time-consuming, but destructive to timelines and creativity.

“With our game Triple Town for mobile I needed to get builds out to the team,” offers Fray. “I needed to show them new features and get feedback quickly. Exporting the game could take some time, and that would be time looking at my machine not able to get on with my work. Once a day that might not be so bad, but then I’d be limited to feedback once a day. Really, as you iterate on a game, you want that feedback coming in all the time; it’s what helps you make a better game.”

For Spry Fox’s forthcoming word puzzler Alphabear, the team turned to the power of Unity’s currently-in-beta Cloud Build platform. “I’m even able to push a change, and then head out to pick my daughter up from school. It’s only just down the road, but I can already be testing the latest build on my phone when I’m waiting for her at the gates.”

But for Fray, Unity Cloud Build isn’t just about maximizing the potential of the school run; it’s about efficiency, simplicity and speed.

“When we look back at previous projects we’ve worked on that are comparable to Alphabear, Cloud Build has increased the speed and ease with which we’ve made the game,” he says. “We’ve been able to iterate so much faster, get feedback so much quicker, and have our artists more involved with the process by letting them see their output live on device.”

In the case of Spry Fox, the benefits of Unity Cloud Build have had an exponential effect which Fray is convinced results in a better quality game all round.

“The artists aren’t having to constantly ask the programmers to make builds, so the programmers have more time. And the artists themselves can iterate faster and build more confidence in the work they’re producing. It really benefits everybody’s work beyond the build process.”

Speaking with Fray it is clear Unity Cloud Build has introduced faster iteration, simplified the build process, given team members more time to focus on their core roles, and let Spry Fox continue working in the same way they always have.

And so it is that Alphabear is progressing smoothly and quickly, and a soft launch is imminent.

Unity Cloud Build is currently available as a free beta for Unity Pro users, and will in time be available for users of the free version of Unity.

Earlier this month we announced that Xamarin.iOS 8.6, featuring the Unified API, is available in the stable channel. This release comes perfectly timed for Apple’s February 1st deadline for new iOS app submissions and June 1st deadline for all new and existing iOS app submissions or updates to include 64-bit support.

In this webinar recording, Xamarin Evangelist Mike James provides an overview on how to make sure your libraries and apps are 64-bit ready by Apple’s deadlines, including how to migrate apps to the Unified API. In addition to the Q&A at the end of the video, we have also included an extended Q&A, below, covering more of the many questions asked during the webinar.

Additional Resources

The sample used in the demo can be found here.

If you’d like to learn more about the Unified API and 64-bit, our documentation has everything you need to get started here. You can also read our blog posts on the Unified API here and here.

Q&A

General

Do we need 64-bit versions of portable libraries coming as NuGet packages to use in a ‘unified’ project?

Library creators will need to update to the new Unified API, and we’ve got some excellent documentation about this here.

Why does the compiler not decide to use int or nint for us? This does not seem to be very “.NET like”.

In a 32-bit world, NSInteger could very easily be mapped to the System.Int32 (short: int) and it worked very well. With NSInteger now being both 32-bit and 64-bit (depending on the underlying architecture of the platform), this approach no longer works.

We’ve gone through all of our iOS and Mac API’s and found every instance of the Objective-C API using NSInteger that originally was mapped to int and these now take an nint.

You can learn more about our decisions behind nint here.

What is a Type Registrar?

On startup, Xamarin.iOS will registered managed classes (which include the [Register] attribute) and methods (which include the [Export] attribute) with the Objective-C runtime. This allows managed classes to be created and managed methods to be called from Objective-C. This is how methods and properties are linked between the C# and Objective-C worlds.

You can learn more here.

How should we handle the new “n” types in shared code?

The new native types found in the Unified API should only be shared in iOS and Mac projects. When creating libraries for consumption outside of these platforms (PCL, Share libraries, etc.) you should be using Int for 32-bit values and Long for 64-bit values.

Learn more about the new type here.

So with non-64-bit devices, will we have to do something different or will it just work?

When you build your Unified API based app, it will by default build dual 32/64-bit binaries transparently.

You alluded to new garbage collection; please elaborate.

We now have a garbage collector called sgen, which is now the default (as opposed to Boehm) which was used for the Classic iOS apps. We’ve also shipped support for our new reference counting system, which helps solves a number of problems that caused apps to crash. Another benefit of the change means your app consumes less memory. (The new reference counting can also be enabled in the Classic API from the project settings)

Learn more here.

Xamarin.Forms

Should I migrate my UI shared project on Xamarin.Forms? Or just the iOS Project?

You will only need to update the iOS project rather than the shared project. You can find our documentation on Xamarin.Forms migration here.

What about migration of an existing Plugin for Xamarin.Forms? How do we keep compatibility with existing apps that might be using our control and also provide the 64-bit support?

You simply need to upgrade your plugins to 1.3.1 and add a unified Library. I have already updated mine on GitHub. You can also check out other examples here and here.

Discuss this blog post in the Xamarin Forums

A story about a million shader variants, optimizing using Instruments and looking at the data to optimize some more.

The Bug Report

The bug report I was looking into was along the lines of “when we put these shaders into our project, then building a game becomes much slower – even if shaders aren’t being used”.

Indeed it was. Quick look revealed that for ComplicatedReasons(tm) we load information about all shaders during the game build – that explains why the slowdown was happening even if shaders were not actually used.

This issue must be fixed! There’s probably no really good reason we must know about all the shaders for a game build. But to fix it, I’ll need to pair up with someone who knows anything about game data build pipeline, our data serialization and so on. So that will be someday in the future.

Meanwhile… another problem was that loading the “information for a shader” was slow in this project. Did I say slow? It was very slow.

That’s a good thing to look at. Shader data is not only loaded while building the game; it’s also loaded when the shader is needed for the first time (e.g. clicking on it in Unity’s project view); or when we actually have a material that uses it etc. All these operations were quite slow in this project.

Turns out this particular shader had massive internal variant count. In Unity, what looks like “a single shader” to the user often has many variants inside (to handle different lights, lightmaps, shadows, HDR and whatnot – typical ubershader setup). Usually shaders have from a few dozen to a few thousand variants. This shader had 1.9 million. And there were about ten shaders like that in the project.

The Setup

Let’s create several shaders with different variant counts for testing: 27 thousand, 111 thousand, 333 thousand and 1 million variants. I’ll call them 27k, 111k, 333k and 1M respectively. For reference, the new “Standard” shader in Unity 5.0 has about 33 thousand internal variants. I’ll do tests on MacBook Pro (2.3 GHz Core i7) using 64 bit Release build.

Things I’ll be measuring:

• Import time. How much time it takes to reimport the shader in Unity editor. Since Unity 4.5 this doesn’t do much of actual shader compilation; it just extracts information about shader snippets that need compiling, and the variants that are there, etc.
• Load time. How much time it takes to load shader asset in the Unity editor.
• Imported data size. How large is the imported shader data (serialized representation of actual shader asset; i.e. files that live in Library/metadata folder of a Unity project).

So the data is:

Shader   Import    Load    Size
   27k    420ms   120ms    6.4MB
  111k   2013ms   492ms   27.9MB
  333k   7779ms  1719ms   89.2MB
    1M  16192ms  4231ms  272.4MB

Enter Instruments

Last time we used xperf to do some profiling. We’re on a Mac this time, so let’s use Apple Instruments. Just like xperf, Instruments can show a lot of interesting data. We’re looking at the most simple one, “Time Profiler” (though profiling Zombies is very tempting!). You pick that instrument, attach to the executable, start recording, and get some results out.

You then select the time range you’re interested in, and expand the stack trace. Protip: Alt-Click (ok ok, Option-Click you Mac peoples) expands full tree.

So far the whole stack is just going deep into Cocoa stuff. “Hide System Libraries” is very helpful with that:

Another very useful feature is inverting the call tree, where the results are presented from the heaviest “self time” functions (we won’t be using that here though).

When hovering over an item, an arrow is shown on the right (see image above). Clicking on that does “focus on subtree”, i.e. ignores everything outside of that item, and time percentages are shown relative to the item. Here we’ve focused on ShaderCompilerPreprocess (which does majority of shader “importing” work).

Looks like we’re spending a lot of time appending to strings. That usually means strings did not have enough storage buffer reserved and are causing a lot of memory allocations. Code change:

This small change has cut down shader importing time by 20-40%! Very nice!

I did a couple other small tweaks from looking at this profiling data – none of them resulted in any signifinant benefit though.

Profiling shader load time also says that most of the time ends up being spent on loading editor related data that is arrays of arrays of strings and so on:

I could have picked functions from the profiler results, went though each of them and optimized, and perhaps would have achieved a solid 2-3x improvement over initial results. Very often that’s enough to be proud!

However…

Taking a step back

Or like Mike Acton would say, ”look at your data!” (check his CppCon2014 slides or video). Another saying is also applicable: ”think!”

Why do we have this problem to begin with?

For example, in 333k variant shader case, we end up sending 610560 lines of shader variant information between shader compiler process & editor, with macro strings in each of them. In total we’re sending 91 megabytes of data over RPC pipe during shader import.

One possible area for improvement: the data we send over and store in imported shader data is a small set of macro strings repeated over and over and over again. Instead of sending or storing the strings, we could just send the set of strings used by a shader once, assign numbers to them, and then send & store the full set as lists of numbers (or fixed size bitmasks). This should cut down on the amount of string operations we do (massively cut down on number of small allocations), size of data we send, and size of data we store.

Another possible approach: right now we have source data in shader that indicate which variants to generate. This data is very small: just a list of on/off features, and some built-in variant lists (“all variants to handle lighting in forward rendering”). We do the full combinatorial explosion of that in the shader compiler process, send the full set over to the editor, and the editor stores that in imported shader data.

But the way we do the “explosion of source data into full set” is always the same. We could just send the source data from shader compiler to the editor (a very small amount!), and furthermore, just store that in imported shader data. We can rebuild the full set when needed at any time.

Changing the data

So let’s try to do that. First let’s deal with RPC only, without changing serialized shader data. A few commits later…

This made shader importing over twice as fast!

Shader   Import
   27k    419ms ->  200ms
  111k   1702ms ->  791ms
  333k   5362ms -> 2530ms
    1M  16784ms -> 8280ms

Let’s do the other part too; where we change serialized shader variant data representation. Instead of storing full set of possible variants, we only store data needed to generate the full set:

Shader   Import              Load                 Size
   27k    200ms ->   285ms    103ms ->    396ms     6.4MB -> 55kB
  111k    791ms ->  1229ms    426ms ->   1832ms    27.9MB -> 55kB
  333k   2530ms ->  3893ms   1410ms ->   5892ms    89.2MB -> 56kB
    1M   8280ms -> 12416ms   4498ms ->  18949ms   272.4MB -> 57kB

Everything seems to work, and the serialized file size got massively decreased. But, both importing and loading got slower?! Clearly I did something stupid. Profile!

Right. So after importing or loading the shader (from now a small file on disk), we generate the full set of shader variant data. Which right now is resulting in a lot of string allocations, since it is generating arrays of arrays of strings or somesuch.

But we don’t really need the strings at this point; for example after loading the shader we only need the internal representation of “shader variant key” which is a fairly small bitmask. A couple of tweaks to fix that, and we’re at:

Shader  Import    Load
   27k    42ms     7ms
  111k    47ms    27ms
  333k    94ms    76ms
    1M   231ms   225ms

Look at that! Importing a 333k variant shader got 82 times faster; loading its metadata got 22 times faster, and the imported file size got over a thousand times smaller!

One final look at the profiler, just because:

Weird, time is spent in memory allocation but there shouldn’t be any at this point in that function; we aren’t creating any new strings there. Ahh, implicit std::string to UnityStr (our own string class with better memory reporting) conversion operators (long story…). Fix that, and we’ve got another 2x improvement:

Shader  Import    Load
   27k    42ms     5ms
  111k    44ms    18ms
  333k    53ms    46ms
    1M   130ms   128ms

The code could still be optimized further, but there ain’t no easy fixes left I think. And at this point I’ll have more important tasks to do…

What we’ve got

So in total, here’s what we have so far:

Shader   Import                Load                 Size
   27k    420ms-> 42ms (10x)    120ms->  5ms (24x)    6.4MB->55kB (119x)
  111k   2013ms-> 44ms (46x)    492ms-> 18ms (27x)   27.9MB->55kB (519x)
  333k   7779ms-> 53ms (147x)  1719ms-> 46ms (37x)   89.2MB->56kB (this is getting)
    1M  16192ms->130ms (125x)  4231ms->128ms (33x)  272.4MB->57kB (ridiculous!)

And a fairly small pull request to achieve all this (~400 lines of code changed, ~400 new added – out of which half were new unit tests I did to feel safer before I started changing things):

Overall I’ve probably spent something like 8 hours on this – hard to say exactly since I did some breaks and other things. Also I was writing down notes & making sceenshots for the blog too :) The fix/optimization is already in Unity 5.0 beta 20 by the way.

Conclusion

Apple’s Instruments is a nice profiling tool (and unlike xperf, the UI is not intimidating…).

However, Profiler Is Not A Replacement For Thinking! I could have just looked at the profiling results and tried to optimize “what’s at top of the profiler” one by one, and maybe achieved 2-3x better performance. But by thinking about the actual problem and why it happens, I got a way, way better result.

Happy thinking!

It’s that time of the year again! Global Game Jam is on next weekend! Unity Pro trial licenses are available to download right now, so you can prepare your toolset for the jam. We’re also running a number of giveaways and shipping Unity people to game jams sites across the world.

Unity 4 Pro trial licenses are valid for thirty days and it doesn’t matter whether you’ve used a trial version before or not. To get it, head over to our Global Game Jam site and login. To use Unity Cloud Build with your Unity Pro GGJ trial license, use GA-MEJA-MGAM-EJAM-GAME-JAMG as a license code.

You can also enter a raffle to win Unity Pro licenses at a number of individual game jam sites (in countries that allow sweepstakes). We’ll announce the lucky winners on January 27.

Just like last year, we’re also running Twitter sweepstakes for jammers using Unity. Just tweet about whatever you’re making with #ggj15 #madewithunity before midnight San Francisco time on Sunday and you can win a $200 voucher for the Asset Store.

I’m heading out to Plovdiv, Bulgaria, for the jam. More than 30 other Unity and Unity affiliated folk will meet you in person in Cleveland, Moscow, Vancouver CA, Taipei, Washington D.C., Manila, Atlanta, Loveland (CO), Seoul, Okinawa, London-Google Campus, London-SAE, Singapore, Memphis, Staffordshire, Tokyo-Hachioji, Tokyo-Koutou-ku , Malmo, Melbourne, Shanghai, Vilnius, Paris, Los Angeles, Mexico City, Porto Alegre, Portland, Toronto, Cambridge (MA), Nagano and San Francisco.

Arturo Nunez will spend the weekend on Google Hangout with jam sites in Mexico, Guatemala, Peru, Chile and Colombia. He’s looking to add more jammers in Latin America, so let him now in the comments if you’d like to join the Spanish speaking hangout.

Have you created a beautiful app with Xamarin? Here’s your chance to show the world what you’ve built!

In this contest, you will create a short video showing us the app you have created, how it works, and any other fun details about the development process while building your mobile application.

How to Enter:

1. Record a short video demoing your Xamarin app
2. Post your video to the Show Us Your App forum thread
3. Tweet your video with the hashtags #Xamarin #BuiltWithXamarin

Here is a sample from our own James Montemagno, demoing his Android app “Bike Now”:

Prize:

• Best App: $100 App Store / Google Play credit to help promote your app!
• Best Video: $100 App Store / Google Play credit to help promote your app!

All submissions must be made by Monday, February 2nd at 12pm EST. We will evaluate each video and choose the winner based on concept, video quality, and originality. A valid entry consists of a tweet and forum post with a demo video of your personal app. Contestants should follow @XamarinHQ to enable us to DM you for private follow-up. There is no purchase necessary to enter the Show Us Your App Video contest.

Join Xamarin at Microsoft TechDays 2015 in Paris, France from February 10-12. Key members from Team Xamarin will be available all three days to answer your questions, discuss your apps and projects, and catch you up on our incredible 2015 roadmap.

Mike James, Xamarin Developer Evangelist, will speak about cross-platform development with Xamarin and Xamarin.Forms on Wednesday, February 11th at 11:00am.

Visit us at Booth S67, or schedule a dedicated time to speak with one of our team members.

À bientôt!