In the years since it was first released, Xamarin has certainly come a long way towards fulfilling the promise of true cross-platform development. This post will explore some practical considerations that are important to a team beginning to use Xamarin. Making some informed decisions up front will minimize the chance that you may need to backtrack further into your project and provide for a faster and smoother completion.
Decide and plan for all the platforms you will eventually want to support
There is no question that Xamarin provides for cross-platform development in ways that are considerably more developer friendly than past options but it’s also important to remember, excepting the most trivial of applications, there is still going to be some level of platform specific coding. One of the most important features of Xamarin is that it provides a framework for implementing platform specific code in a clean and organized manner and that is precisely because it remains an important factor in the overall development process.
A common scenario might be for a development team to decide to implement iOS first and then later return to implement Android. If the team was entirely focused on how to get things done for iOS without at least considering how it would be done in Android, they could easily paint themselves into a corner that is troublesome down the road.
An example of this kind of problem would be what third-party components & packages the team uses. Sometimes the developers of components do not include support for all the platforms that Xamarin targets. While such packages almost always include support for both iOS and Android, they frequently do not support Microsoft targets. Therefore, if your plans include deploying to Surface tablets or Windows Phones, you will want to make sure any packages you select support those targets as well.
Decide on your development hardware and IDE
Your decision on what development hardware your team will use is very contingent on what platforms you eventually want to target.
If you are targeting an Apple platform for your app, then in some form or another you will need access to a Mac for building and deploying (though not coding as I will explain later). If you are targeting any of the Microsoft platforms, then in a similar manner you will need access to a Windows machine even for coding. Fortunately, Android targets are supported on either type of machine.
It is entirely feasible for a team to have different development machines and have those with Mac computers perform all the building and debugging for Apple targets and those with Windows computers do so for Microsoft platforms.
As of May 2017, there are two tools that support Xamarin development: Visual Studio for Windows and Visual Studio for Mac. Xamarin previously also published their own Xamarin Studio but it was deprecated in May 2017 in favor of Visual Studio for Mac.
Visual Studio for Windows includes the ability to write code for all the platforms that Xamarin supports, even Apple platforms. However, when it comes time to build and deploy Apple platform code, it must connect to a Mac machine that has also been setup with the same set of tools required for development on the Mac itself.
Visual Studio for Mac allows for coding, building and deployment on all Apple and Android platforms. If you load a solution that includes Windows targets then those projects will simply not load and will appear as disabled in Visual Studio.
In practice, these facts mean that if your team is only planning to implement for iOS and Android, the setup that offers the fewest “moving parts” is using Mac machines for all your development work and hence Visual Studio for Mac would be your choice. If you do need to support Microsoft targets it is entirely feasible for a developer to do a majority of his work on a Windows machine and rely on the remote connectivity Visual Studio for Windows supports for the building, deploying and debugging of your app on Apple platforms.
Decide if Xamarin.Forms is appropriate for your project
The early versions of Xamarin supported cross-platform development by sharing code but each platform target project had its own user interface implementation. This meant that the cross-platform features were essentially confined to non-visible aspects of the application, for example your operations on your database and your business logic.
Xamarin.Forms is an official Nuget package that supports shared user interface definition, code and implementation. Using Xamarin.Forms greatly reduces the amount of platform specific implementation that your team will have to create. The trade-off for that reduction is that the resulting app will be slightly slower and that your ability to customize your user interface in platform specific ways becomes more complex.
This decision is one that is not quite black and white as the ones on what platforms to support and what development hardware/IDE to use. If the majority of your user interface is to be standard UI elements like buttons, text fields and so on then Xamarin.Forms is likely a good choice for you and will save your team considerable effort. A prime example of the type of app well suited for Xamarin.Forms would be your typical line of business app that is used for data entry/viewing.
On the other hand, if your app needs a lot of user interface that is styled in platform specific ways (for example, you want your app to look like a “typical” iOS app on Apple platforms and a “typical” Android app on Android platforms) or if a large portion of your app is accessing device specific features like GPS and multimedia, then it is likely that utilizing the older technique is better suited for your project. Apps that offer immersive user interfaces like games will also likely be candidates for this method.
Ultimately there are benefits and trade-offs with either approach. It really becomes a matter of determining how much your specific project will be aided or hampered by each method and selecting the one that gives you the most benefit and the fewest drawbacks. This is where having decided about how much your app requires platform or device specific code will be a great help.
Determine what aspects of your project will require platform specific development
Getting a firm grip on how much of your project will require platform specific code will greatly influence other startup decisions you’ll need to make. In general, you will be looking for any project requirements that will need platform and/or device specific functionality.
Examples of platform specific functionality include features that require accommodation for specific screen sizes, when platforms use different navigation modes (e.g., the hardware back button on Android phones), some earlier versions of Android don’t support certain touch gestures, and the use of push notifications which requires specific APIs for each platform.
Examples of device specific functionality includes features like the camera, GPS/maps, social media integration points and NFC. Even on the same platform different devices can have greatly varying capabilities and accessing them requires the use of native APIs.
Once you’ve determined what platform and device specific functionality your app will require it is then advisable to form a general plan for how each will be dealt with. The two general approaches to implementing platform/device specific code are platform abstraction and then simply divergent implementation.
In broad terms, platform abstraction would mean defining a shared façade that wraps around the platform specific code while divergent implementation means quite simply implementing it separately in each of your platform specific projects.
Any development project benefits from careful planning before leaping into the code but Xamarin mobile development is one environment where there are a lot of critical decisions to be made before even a single line of code is written.
Making early decisions about what target platforms you will support, your development environment, whether Xamarin Forms is appropriate for your needs and what parts of your app will require platform specific development will make it far less likely that you’ll need to backtrack later in your project. Having clear answers ready for those high-level questions will set the stage for a successful project that is on time and on budget.
The JBS Quick Launch Lab
Free Qualified Assessment
Quantify what it will take to implement your next big idea!
Our assessment session will deliver tangible timelines, costs, high-level requirements, and recommend architectures that will work best. Let JBS prove to you and your team why over 24 years of experience matters.