Xamarin iOS Autolayout Cheat Sheet

I get questions on this a lot by people new to iOS development or new to iOS development using Xamarin. I've made this cheatsheet to help with people learning how to use autolayout. Apple's iOS uses a layout system based on absolute positioning called autolayout. Unfortunately, the layout system feels bolted on top of an absolute positioning system (which in many ways it was) and feels a little awkward at times. This guide is for anyone new to the constraint system. Using autolayout in Xamarin iOS is very similar to what it was in XCode but there are some designer differences.

Background Concepts:

Size Classes: A constraint can be made for a particular size class. Size classes are Compact, Any and Regular. Compact are for narrow or short screens while regular is for everything else. Most constraints are likely to be made with any, which means the same constraint will be used for any sized screen. To ensure you are creating constraints with 'any' selected you can on the size class selection in the upper left hand corner of the storyboard designer.

You can also change the size classes to see how they will lay out differently in different sized screens (well compact, any and regular).

Number of Constraints: A control will normally have four constraints that define its X/Y position, width and height. If you have more than four and didn't do it for a very particular reason (such as another control using the position of this control to do its layout), it is probably a mistake.

Control states: You can click on a control in interface builder to to toggle it's state from resize mode to constraint editing mode.

Resize Mode:

Constraint Editing Mode:

Valid Control State Indication: A control with a blue background is considered to have a valid set of constraints. A control with no constraints at all is also considered valid (it will have a fixed X/Y position and a fixed height and width).

A control with incomplete constraints will have an orange background.

A control with conflicting constraints will have a red background. This normally means you did something wrong.

Constraint editing mode

Normally you will choose a set of horizontal constrains and a set of vertical constraints.

Common Horizontal Constraint Sets:
Start at a fixed amount of space from the left with a fixed width.

Start at a fixed amount of space from the right with a fixed width.

Start and end with a fixed amount of space to the left and the right (control stretches and shrinks as the width of the screen does).

Control a fixed amount of space to the left or right of the center (can even be exact center) with a fixed width.

Common Vertical Constraint Sets:
Start at a fixed amount of space from the top with a fixed height.

Start at a fixed amount of space from the bottom with a fixed height.

Start and end with a fixed amount of space to the top and the bottom (control stretches and shrinks as the height of the screen does).

Control a fixed amount of space to the top or bottom of the center (can even be exact center) with a fixed height.

Control Combinations: Constraints don't just have to constrain controls to the edges of the screen or the center, they can constrain controls against other controls. Take the following example, the button is constrained to the bottom of the view with a fixed height. The image view is constrained at the top of the view and the bottom by the top of the button. So the button will always be the same height and space to the bottom and the image view will shrink and grow in height as the form does, always leaving the same spacing to the button.

Hiding controls: Controls that are not visible still have their constraints in place. That is to say they will still occupy the same space on the view and any other controls that are constrained by they will still lay out as if the control were visible. This is very different behavior than other systems like Android XML where if a control is marked as gone, the other controls re-adjust as if it didn't exist. In order to make an iOS control gone and any other controls constrained against it readjust, you may have to make some constraints have a zero height and / or width (constraint property) and then reset the constraints height and width when it becomes visible again.

There is certainly more to be learned about constraints but for anyone trying to understand them, I hope it gets you started.

Xamarin Build Services - Nuget Restore with VSTS

Recently I wrote a post about about setting up a continuous delivery process using VSTS, Xamarin and MacInCloud. One of the things I mentioned was using the restore Nuget packages task in order to make sure the appropriate files were available to the build server. It seemed to work great in my test project. Then I was working with a real project using the same process and introduced MvvMCross into the mix; suddenly I encountered an error on the build server similar to "'MvvmCross.Core' already has a dependency defined for 'MvvmCross.Platform'." Here is a Stackoverflow discussion on this:

http://stackoverflow.com/questions/37838587/mvvmcross-wont-restore-when-running-nuget-restore-error-mvvmcross-core-alrea

The Problem:
This error is caused by the version of Nuget that is currently deployed with the Xamarin Studio on the Mac has problems with certain Nuget restore operations. After conferring with the support group from MacInCloud they stated a solution similar to what I am detailing here might work, it did.

The Solution:
Do not use the Nuget restore task in VSTS, instead deploy the latest version of Nuget in your source control and include a shell script to restore the packages using a newer version of Nuget.

Steps:
1) Download the latest version of Nuget.exe and add it to your source control repository. You can download it from the following site. You should get the latest 3.X version.

https://docs.nuget.org/consume/installing-nuget

Take the downloaded nuget.exe and place it in a directory in your repository. I placed mine under a folder called Nuget off the repository root.

2) Create a shell script file. It is just a text file with a .sh extension. I called mine nugetrestore.sh. In the file is a single line:

mono nuget/nuget.exe restore $1

I saved this file to the root of the repository.

3) Add a new shell script task to the build script in VSTS. The Script Path points to the location of the nugetrestore.sh file in the repository and the Arguments setting should point to the solution file that Nuget packages need to be restored for.

With this alternative method of restoring Nuget packages on a Mac build server, more complex restores work without the errors that are encountered using the default Nuget restore task.

Setting Up Builds With Xamarin Using MacInCloud and VSTS

For many of us doing mobile work the ability to create great continuous integration and continuous delivery solutions has been hampered by the lack of enterprise support for Macs and generally the lack of available build agents that work with iOS and even Android projects. Recently MacInCloud released a Visual Studio Team Services (VSTS) build agent that can work with native, Xamarin and Cordova development for iOS and Android. For Magenic this is exactly what we need so I have been working through creating a repeatable process that we can use project after project to stand up this sort of build service.

To start with I want to talk about the kinds of build services we can set up:

Continuous Integration (CI) - A build designed for when developers check in code. Usually ensures that the code being checked in compiles and that all unit tests pass.

Continuous Delivery (CD) - Happens when code is promoted to an environment, such as QA, built and deployed out to the app deployment service to be used for testing. Code promotion usually happens as code is merged into a branch for that purpose, such as a QA branch.

There is also a concept of Continuous Deployment, that is in many ways similar to Continuous Delivery expect the build is pushed to the production environment. For this blog post I will focus on continuous delivery for Xamarin when code is moved to a QA branch from a Development branch. I hope to follow it up by posts for CI and also for Native technologies and Cordova using VSTS and MacInCloud.

The technologies covered by this post:
Visual Studio Team Services (VSTS)
Xamarin Android
Xamarin iOS
MacInCloud VSTS Agent
HockeyApp

What do I want to accomplish when doing my CD Build:
Kick off when moving code into the QA branch
Register my Xamarin Account
Get all required dependencies
Change version number of Android and iOS code
Build iOS and Android code
Sign Android and iOS code
Generate required documentation (will cover in a later post)
Deploy out to HockeyApp

I won't go into how to connect the VSTS MacInCloud agent to VSTS. A good post that explains this can be found here: Getting Started with the MacinCloud VSTS Build Agent Plan. I also won't go into branching strategies, I assuming multiple branches with at least Development, QA and Release branches. I use git style repositories but the TFS style repositories will work as well.

What I assume is already done:
VSTS repository created
Branching implemented
MacInCloud VSTS agent purchased
MacInCloud agent created and connected to VSTS
iOS certificates and provisioning profiles uploaded to MacInCloud agent

Note: If you ever want to change the pool name that the agent is connected to, it will submit a request in the MacInCloud portal but it doesn't seem that the request is processed immediately. It may take a few hours for it to occur during which time you cannot build with the agent. Be cognizant of this when changing the pool name after the initial agent setup (which seems to happen nearly immediately).

Note: It may happen that the agent gets locked up or otherwise seems to stop responding. Unfortunately, at this time there is no way to manually reset the agent. You will need to create a support ticket with MacInCloud. Luckily they are very responsive and always got back to me later in the day.

Note: For Xamarin, a MacInCloud VSTS build agent can pretty much do all the build types you can do in Xamarin Studio on a Mac. However, that is not all types of .Net applications. For example, if you want to compile a UWP project as part of a Xamarin Forms solution, that part of the build would have to occur on a Windows build agent.

Setting up the build steps

Kick off when moving code into the QA branch

A last note on build steps. I called my branch to cause the CD build to run QA. Also I used the Ad-Hoc build definition to setup all the project settings for QA builds. In my VSTS project I created a new build configuration called "QA Build". I named my MacInCloud VSTS agent queue: Xamarin. My VSTS configuration for Repository, Triggers and General tabs to kick off the build looks like this:

Register my Xamarin Account

On the Build Tab we can start adding steps. There is one task that we care about to start, Activate Xamarin License. We need to add it to the build process four times. Twice at the beginning to activate the licenses for iOS and Android and twice at the end to deactivate them.

Note: Xamarin is now free and for many builds these steps may not be necessary. For some build options, such as embedding assemblies in native code for Android, an Enterprise Xamarin subscription or MSDN Enterprise license are still required. As the formal licensing switches from the Xamarin licensing scheme to the MSDN subscription scheme, these steps will likely slightly change.

Get all required dependencies

There are two tasks that can help here, Nuget Installer and Xamarin Component Restore. Put in tasks for one or both of these depending on where your packages come from. Currently, I'm using just Nuget packages and left the default to restore for all solutions in the branch.

Change version number of Android and iOS code 

Each and every build put into HockeyApp needs a unique build number that is ever increasing for it to understand what is the latest build. It does not use the upload or compile date as the primary mechanism for this, instead it uses the build number. A newer build will be thought to be older by HockeyApp if it has a lower build number than another in HockeyApp even if the version name looks higher.

Both Android and iOS has two build identifiers, one a human readable version name such as 1.3.2 or 1.3.3 and one an ever increasing sequence of numbers that is used to tell which is newer. In Android in the AndroidManifest the VersionName is the human readable name and the VersionCode is the ever increasing number to tell what is newer. For iOS the equivalent settings can be found in the info.plist under CFBundleVersion is the ever increasing number and CFBundleShortVersionString is the human readable name.

To handle this in VSTS I use a task called Version Assemblies that is part of Colin's ALM Corner Build and Release Tools. This is not a standard VSTS task so you will have to go out to the Marketplace (click Add Build Step then select "Don't see what you need? Check out our Marketplace." The Version Assemblies task allows you to search a file in search control for a RegEx match and replace it with part of the VSTS project's Build number.

Setup VSTS variables

To specify the build name I created a VSTS variable. This is done on the Variables Tab of VSTS setup. In this case I want the version name to be 1.3.0. When I change the version name, I will go here and change it. There are other ways to do this, but this is based on the use of the Version Assemblies Task. 

Then I setup the build number format on the general tab. This will use the current date, the value in the VersionNumber variable and the BuildID. 

$(date:yyyyMMdd)_$(VersionNumber).$(BuildID)

Note: Some samples I have seen, including the one for the task, show using the TFS revision number for this and using that for the build number. I highly recommend against this. The revision number resets on a daily basis or when anything else changes in the build number. This won't lead to an ever increasing number we can use for Android and iOS to tell what the latest is.

Setup iOS placeholder versions

Due to the structure of the iOS info.plist file it won't be easy for our task to find the right keys to replace. So we are going to use some numbers that will work fine for development, but ones that our build service will be able to find and replace. In the info.plist file I set the values as follows:

<key>CFBundleShortVersionString</key>

<string>1.0.0.0</string>

<key>CFBundleVersion</key>

<string>1.0.0.0.0</string>

Add Version Number tasks for iOS

Add two Version Assemblies tasks, one for the CFBundleShortVersionString, and one for the CFBundleVersion. Since a regex that finds and replaces 1.0.0.0 for the CFBundleShortVersionString will also find the first part of the CFBundleVersion, I recommend replacing the CFBundle version first in the build order. Here is how I set those up. With the the CFBundleShortVersionString will end up with the value in our VersionNumber variable (like 1.3.1) and the CFBundleVersion will end up with the unique and ever increasing BuildID.

(You will need to open the advanced area)
Build Regex Pattern:  (?:\d\d\d\d\d\d\d\d_)(\d+.\d+.\d+.)(\d+)
Build Regex Group Index: 2
Regex Replace Pattern: (\d+.\d+.\d+.\d+.\d+)



Build Regex Pattern:  (?:\d\d\d\d\d\d\d\d_)(\d+.\d+.\d+)(.\d+)
Build Regex Group Index: 1
Regex Replace Pattern: (\d+.\d+.\d+.\d+)

Setup Android placeholder versions

In the Android Application.Manifest ensure the versionName is two numbers separated by a period such as 1.2 and that the versionNumber is a number without a period like 4.

Add Version Number Tasks for Android

Build Regex Pattern:  (?:\d\d\d\d\d\d\d\d_)(\d+.\d+.\d+)(.\d+)
Build Regex Group Index: 1
Regex Replace Pattern: versionName="\d+.\d
Prefix for Replacements: versionName="


Build Regex Pattern:  (?:\d\d\d\d\d\d\d\d_)(\d+.\d+.\d+.)(\d+)
Build Regex Group Index: 2
Regex Replace Pattern: versionCode="\d+
Prefix for Replacements: versionCode="

Build iOS and Android code

Build iOS Code

I build the iOS code first by using the Xamarin.iOS build step. I add it in and point to a solution that contains all the iOS projects and any shared PCLs. The configuration I use the $(BuildConfiguration) variable which I set to Ad-Hoc. This will build the targeted solution in the Ad-Hoc build configuration with all appropriate build settings.

Note: I leave the Signing and Provisioning profile section blank. Instead I have defined the proper certificate and profile in the Ad-Hoc configuration project properties for the iOS projects. These correspond to the signing and provisioning profiles that I have already uploaded to my VSTS build agent in MacInCloud.

Note: I encountered an error "user interaction is not allowed" which had to do with the keychain for the certificates I uploaded being locked. I'm not sure how this happened and there is likely nothing you can do to fix it yourself. I submitted a ticket and the MacInCloud support team was able to quickly change something on their end to resolve the issue.

Note: I could have also included the Android projects in the solution and they would have built. However, I wanted direct control over their building and signing so I created a solution used only for the builds that only contains the shared PCLs and iOS projects so I wouldn't build the Android projects twice. It also gives me higher level quick visibility if it was the iOS and Android part of the build that failed. 

Build Android Code

Here I used the Xamarin.Android task. Instead of pointing to a solution, it points to a particular project. I also added and additional argument, /t:SignAndroidPackage that forces it to build an .APK. 

Note: I didn't include anything in the project file about sighing the APK because that would require me to keep my signing information in the project file itself. Instead I used a separate Android Signing build task and kept the certificate's authentication information in variables in the VSTS build definition.

Note: At first I received an error, "The Android SDK Directory could not be found. Please set via /p:AndroidSdkDirectory." This had to do with the ANDROID_HOME environment variable not being set correctly in the agent. If you put in a ticket, the MacInCloud support team can fix this for you.

Sign Android and iOS code

There is nothing to do here for iOS, as the code signing occurred as part of the iOS build process. For Android I added an Android Signing task to the build steps. I also added the appropriate keystore file into source control so I could reference it as part of the build.

Setup Keystore Variables

Granted, these are not very good passwords, but they will do for this test. Create these three variables in your build definition with the proper credentials for your keystore.

Add Android Signing Task

Use the following configuration for the Android Signing. The keystore should be located within your source code checked into the branch that is building.

Note: The first time I tried this I received an error, "Path must be a string…”. After searching and finding it wasn't a setting on the task, I found this was caused by the JAVA_HOME environment variable not being setup on the VSTS build agent. I submitted a ticket and they got the JDK properly setup with this variable defined and everything started working.

Deploy out to HockeyApp

Luckily there is already a task for deploying to HockeyApp in VSTS.  We need to add two of these tasks to our build definition, one for Android and one for iOS. On the first one you add you will need to setup the connection between HockeyApp and VSTS. To do this press the manage link on the HockeyApp connection section of the task. This will bring up an area where you can create a new connection. It will ask for an API Token.

The API Token can be found in HockeyApp under Account Settings \ API Tokens. I created one with Full Access though only Upload and Release is probably sufficient. Copy the created API token back into the VSTS HockeyApp connection.

Setup Apps in HockeyApp

You will need to setup two apps in HockeyApp, one for Android and one for iOS. I manually created them and set the Bundle Identifier (iOS) and package name (Android). Each one of these HockeyApp applications gave me an App Id that I could then copy back into the HockeyApp deployment task in the VSTS build.

Finalize Deployment Settings

For both the Android and iOS HockeyApp deployment tasks I added information on what binaries to deploy. I could also set release notes (later post), debug symbols and restrictions on who can download.

Android

iOS

Final Thoughts

This took a fair amount of trial and error to get it right. I'm hoping that this can be used by others as it is moving toward codification as part of Magenic's new recommended CD process. I'm sure there is some cleanup to be done and I wanted to get this down while it was fresh in my mind. Let me know if you have any issues with it. Here is a view of the full list of build steps:



What the builds look like in HockeyApp for Android:


For my simple solution the entire continuous delivery process takes less than 3.5 minutes.

Are you Ready to Bring in a Partner to Help Create a Mobile App?

This is a question that organizations should ask themselves when engaging a partner to help with their mobile initiative. As a consulting company Magenic does our best to help the clients understand if they are ready to start the app creation process but we will never fully know until we engage with them. In cases where we engage and find the client isn’t ready, we try to steer them into a soft landing through continued communication of project difficulties which may cause a re-evaluation of the current path. However, it is always better if the client is ready before we engage. A false start can be a source of significant lost time, capital and frustration for all parties.

This leads to the important question, how do you know you are ready? At Magenic, we generally look at the following areas.

Do you understand if you have a project or a product?

Understanding this is key to knowing how the app will be built and setting expectations around the long term financial investment. Projects tend to involve a set amount of scope and have fixed delivery timelines, with a clear start and end date Many B2E applications that are not in a “bring your own device” environment may potentially be viewed as projects. A key expectation for a project type app is that it will be built once and only have minor maintenance over time. A project may also be suitable for either a waterfall approach or agile.

A product, on the under hand, describes an app that will continually change and evolve as time goes on. Most apps that are externally facing should be considered as products. The mobile environment and user expectations and competitive market are continually changing and your app will have to evolve with it as devices, capabilities and desire for features change over time. A key feature of a product is the expectation that there will be a team continually working on improving and evolving the app through its entire lifetime. Products are well suited for an agile methodology and usually falter in Waterfall environments. For more information, see Mobile Project vs. Mobile Product.

Do you understand the vision for your product and is it shared organizationally?

This may seem like an unusual problem problem but it is not. Many organizations have groups with different or incomplete vision and understanding for what the product should do. Sometimes we given guidance “to  make it work like System X”, but no one is able to articulate exactly what system X does or how it does it, because the people who knew are no longer available.  The technologies behind System X may also be considered legacy and reproducing features identically in a new technology may not be feasible. This leads to incomplete requirements and dissatisfaction as it is inevitably realized that something is missing, or that it will cost even more to create. If you are not able to articulate what your product needs are, your partners won’t know them either. Problems manifest themselves in different ways in this situation but the end result is the same: unclear requirements with no way to prioritize the backlog or successfully complete the product.  In many cases, you may have a release which does not align with stakeholder expectations or deliver expected features,

We help our clients reconcile their emerging points of view, and reach consensus on the business needs.  We help  define key application features and it’s into their overall business strategy.  We also help our client understand critical strategies to leverage mobile transformation into a strategic advantage. However, in some cases, we still find it difficult to broker internal reconciliation and shared understanding due to cultural realities. Partners like Magenic can help facilitate the process of defining strategy and how they app supports it but it is clear that understanding and agreement has to come internally. Partners are not going to be able to change, or in many cases overcome, a client’s internal culture or ability to come to consensus.

Have you defined Key Performance Indicators and know how they will be measured?

Like the definition of “done”, the definition of success can be similarly murky. Successful mobile initiatives have defined key performance indicators to track and measure success and have defined the metrics needed to evaluate success.  Without fully understanding how success will be measured, it becomes challenging to prioritize features or adjust the product after initial release to further business goals. The lack of a good definition of success can be an insidious problem because the symptoms associated with it are not always readily apparent. It usually manifests itself in difficulty creating requirements or general dissatisfaction over the perceived value of the product being created.

Do you have a product owner who is empowered to make decisions?

Someone needs to own the business requirements and be empowered to make decisions, at least on a tactical basis. No matter how well planned out a feature is, questions will come up as changes are being made to the application. Additionally, disagreements over direction will arise that need timely resolution. Questions that can’t be answered quickly will lead to a disruption in the development process. This can be particularly hard for organizations used to making decisions by committee or when other organizational stakeholders are allowed to enforce changes or alter decisions made by the backlog owner.  . When there is no clear product owner or the product owner is unable to decide or enforce decisions, at least on a short term basis, then the app development process will almost certainly start to falter as the delivery team becomes idled waiting for decisions to be made or re-working changes to decisions that have already been implemented.

Are you willing to commit to the project lifecycle and understand what it is?

Most mobile projects are better suited for using an Agile methodology, which goes beyond a solid a technical delivery team; it requires a team that includes representatives of the business that have the time and capacity to be involved in the requirements and delivery process, who can commit to the meetings/ceremonies and are willing to abide by other agile rules.  A cardinal rule here is to respect the Sprint commit once it has been made, and not change Sprint deliverables midstream.  If some of these terms seem foreign to a Client, then the Client is not ready to start an agile process. Good partners will be able to help you understand the process but they can’t force you to commit to it. That will need to happen internally and requires full support from all stakeholders.

Can your internal technical team deliver their pieces on time?

Many mobile projects integrate with internal systems that are already in place. Access to these systems can be critical to fulfilling the business requirements of the product. While in many cases integrations can be delayed and worked around for a short period of time, they usually represent a significant source of technical risk and should be addressed as early as possible. Delays in critical integrations will eventually cause project failure as the delivery team becomes delayed and costs mount to an unacceptable level without project completion.

Do you understand that the world of mobility is continually changing?

A source of product dissatisfaction can be around a misunderstanding that a product is never done and that changes to the underlying platforms can interfere with the fulfillment of business objectives. Apps, particularly ones visible to the public, your customers or business partners, need to change and evolve as the platforms change or there is a significant risk of application invalidity. The constant updating of the app to handle platform, expectation and device changes  must be anticipated and accepted.

Can you control scope and expectations internally?

Everyone wants the magic app that will do everything, solve all problems and catapult a client into the Number 1rank in the industry; sometimes, this is expected immediately and without a huge spend.  Apps can take a lot of time to build correctly; in the mobile world, applications are normally created through a long cycle of trial and error. This means that it is critical to control scope to create a minimum viable product (Does an MVP Release Make Sense for your Mobile Initiative?) and set internal expectations that not all features will need to get into the app’s first release. The app will continue to evolve and grow as you organizationally gain more insights into actual usage of the application and validate desired additional features before implementation.  It should be expected that this is “normal” and a significant source of dissatisfaction and eventual project failure is caused either by a “big bang” approach to development and/or a failure to recognize and commit to the level on ongoing investment required.

If all else fails, know when to stop

Sometimes these problems will manifest despite our best efforts or intentions. Project rarely fail due to technical reasons. There are generally 3 main themes behind every project failure: inability to define requirements;  dependencies not being met in a timely matter; and  improper expectations setting. A sign of a great collaborative relationships is when extreme problems are recognized and the group is willing to stop and pause the process so course corrections can be made.

Problems will always occur, but not all problems can be solved merely through by force of will. Knowing the difference and having the courage to call a “stop” can be the difference between long term success or burning through budget, until the project is eventually considered a failure. Good consulting partners will give you ample warning that a stop may be required. An early alert to this eventuality will be in consistent progress warnings on status reports and conversations consistently pointing out missed dependencies and commitments.

Creating a good mobile application is an expensive process and not one you can just throw over the fence and have a partner throw the result back at you. It is an iterative and collaborative process where everyone works as a team to identify and create value, are willing to commit to a shared process and where responsibility for success is likewise shared. Many of our clients cannot afford major misses on mobile initiatives. The questions listed above should be discussed internally and a readiness evaluation should be conducted before making a significant financial investment and engaging a partner. 

MS Buys Xamarin - Analysis # 248

As you probably heard Microsoft announced that they are acquiring Xamarin. I see there are a ton of these posts asking the fundamental question, what does this mean? For myself I'm thinking through a bunch of issues.

Will the pricing model for licensing change?
I would guess almost certainly. Microsoft generally handles licensing for development tools through Visual Studio editions and MSDN licensing. Already the "free" version of the Xamarin platform is available as part of the VS install. I expect this will now become the full version that is baked into Visual Studio. What level of Visual Studio will be required for Xamarin? I'm actually not sure. However I expect MS will want most developers to be able to use the Xamairn tools so they will likely set the bar pretty low.

What about Xamarin Studio?
If  you love Xamarin Studio, I'm not hopeful, at least in the long run. Microsoft already has Visual Studio and Visual Studio Code. I would expect them to double down on these IDEs and in that world Xamarin Studio largely becomes redundant. In the short term I expect it will be around for a bit.  What this means is that development will done on a PC with a remote build server unless and if Microsoft builds the Xamarin technology into Visual Studio Code to run on OSX. This may or may not happen, it is always possible that if it is part of the roadmap that Xamarin Studio will be kept around until then. But at some point I guess that it will almost certainly be retired.

What about Mono?
Mono is open source, will remain so, and so isn't overly impacted by this. The new MS loves open source anyway.

Xamarin University?
Microsoft does not have a training program or certification program as in depth and extensive as Xamarin University and its associated certification. I'm not sure this is an area where Microsoft will invest in changing how they do things. The Xamarin University program will likely be rolled into Microsoft's current certification scheme.

How about Xamarin's Partner Program?
Microsoft, I hate to say this but Xamarin's partner program has your's beat, hands down. I am not hopeful that Microsoft will change its partner program to meet Xamarin's but I do at least have some small hope that they will examine it closely for things that really work there. That may just be wishful thinking on my part.

What is the future of Xamarin Forms?
I expect it to be pulled in more closely to the UWP structure so it can be used without extensively altering UWP development. For example the XAML may change to meet the UWP structure. Having said that the match will not be exact. Part of the reason why the UWP structure works is because MS is in control of the UI components and sits on top of a unified OS. This is not true for iOS and Android. I expect some changes here, but the concepts won't (and likely can't) be completely abandoned. Jason Smith's work is still relevant.

How about their relationship with Apple?
There will be some degradation in the relationship because MS will be seen as less of a neutral party than Xamarin is.  Having said that, the relationship between Apple and Microsoft has fundamentally changed and improved over the past year or two. This will likely continue.

Can we still expect day one support for API changes?
As I understand how Xamarin wraps the iOS APIs it is largely automated so in cases where there will be no fundamental underlying change in the ability to get day one support for most XCode version and API changes. However, more fundamental changes like moving from 32-to-64 bit or the Apple Watch structure may require a closer relationship. I suspect Microsoft will try and continue to partner with Apple across a wide variety of initiatives and keep improving the relationship. Let's be honest here, Apple and Android have the phone space and Microsoft isn't a viable competitor here. Tablets are a different story but one where the advantages of cooperation for both firms, given the current conditions, outweigh the desire to freeze each other out.

How about product stability?
This is one the huge pluses that I see. Xamarin was a smaller company that was very ambitious in the breadth of their offerings and what they are trying to do. The stability of the products from release to release is, well, not always where it should be. I've stated this before, Xamarin has a lot to learn in really getting a fully stable product to market and they are solving an extremely complex problem. I suspect that the Microsoft control over process and quality assurance will only have a long term positive impact on the product. Having said that, it may take a while to play out.

What about the Android Player?
Microsoft has their own player that sits on top of Hyper-V, Microsoft's virtualization technology. The real advantage of the Xamarin Android Player is that it works with Oracle's Virtualbox and can run on a Mac. With recent improvements in Google's version of the Android player I'm not sure if they will need to keep the increasingly redundant Xamarin Android player. One of them will likely go and it probably won't be the one that runs on Hyper-V.

For that matter Xamarin Insights?
Microsoft has their own Insight's product. I expect the Xamarin version to be rolled into the Microsoft one, using the Microsoft back end and pricing schemes.

Test Cloud?
This type of cloud service is right up Microsoft's alley. Perhaps rebranded as part of Azure, I think good things will happen here if you use this product. Also this will likely continue to use more standard testing formats.

Profiler?
This tool is very specific to the mobile platforms and Microsoft will likely (hopefully) complete it.

The upshot of all this? I believe it will be a net positive impact. There are two major benefits I see; first since Microsoft gets its revenue in other ways the licensing scheme will change making the Xamarin platform a bigger player because it will lower the bar to learning the platform. The second has to do with the size of Microsoft and maturity of their development processes, the products will only get stronger and more stable.

I look forward to seeing how this plays out.

Best in Class Consultants or Learning on Your Dime

If the consulting company you are looking at says "yes, we do that" to whatever technology you throw at them, they are probably learning on your dime. If you work for such a consulting company, you probably have a lot of sleepless nights and unhappy customers. A common truism is that no one can be an expert in everything and that extends to organizations as well. Highly sales focused organizations, in particular, can fall prey to this if the pressure to keep selling overwhelms the desire for quality delivery.

When I became the mobile practice lead early last year one of the first things my boss shared with me is that he wanted us to become a best in class provider for mobile services. In order to achieve that goal we had to decide what it is we actually do, and by extension what we don't do as well. Different companies may come to different conclusions but for our mobile practice we looked at our internal competencies, the spectrum of client needs and settled on native iOS/Android, Xamarin and Cordova, with responsive web applications being covered by other groups in the company. If a client needs Appcelerator of Kony development expertise we let them know that we may not be the best partner. This is in their best interest and in ours.

By deciding what we actually did in the mobile space we solved many problems. We now knew where to focus our training efforts and in so doing alleviated many delivery issues associated with resources that learn on the job. The impact of this keeps spreading. By reducing delivery issues our thought leadership becomes free to put more formalization around our technical delivery and ALM process, adding to our existing overall delivery process and in turn further reducing delivery issues associated with these processes. This again frees up management to work on other issues, including growing and scaling the business.

This idea isn't anything new. People can't be experts in everything and if they perpetually stay at the start of the learning curve of an overly wide variety of disciplines they will constantly be making the mistakes associated with that part of the curve; with management dealing with the fallout. As good consultants we don't do our clients any favors when we just blindly reply, "Yes, we do that" when we know it is far outside our our capabilities.

That's not to say you shouldn't move into new skill sets and product offerings as a person or as an organization. Indeed you likely need to do that to continue to thrive. But every new skill learned or product offered comes with a learning curve and a cost in terms of focus that is redirected into learning that skill set or creating that new product. With that in mind it should be a deliberate process, one where you understand and are prepared for the cost and with that understanding knowing that there is limited capability to do it all, know it all and learn it all at once.

To be best in class you need to limit the scope of that class to something that can be viably achieved and understand exactly what it is are best in class at. If you are on the other side and looking to hire a consulting company with best in class talent, just remember if they keep saying,"Yes we do that" to an overly wide variety of things, they probably are not best in class at anything and likely you will be paying them to learn.