Cross Platform Apps For Microsoft Developers
There is a demand which didn’t exist five years ago for business applications which run on tablets and phones.
If you are a developer in a Microsoft shop you would probably first consider developing your app for windows tablets / phones. But you need to consider what devices your customer has and will have over the next few years. Android and IOS fill 89% of the market so developing only for a windows device would limit the app to a tiny percentage of the market. You could pick one of the big two, but this would require learning a new language (Objective-C / Swift or Java) and understanding the design principles of that platform (Material / Flat).
There seems to be two viable options for developers in the Microsoft stack:
- Using C# and XAML with Xamarin Forms.
Write once run anywhere seems like an ideal solution, but there may be compromises. The decision needs to consider the following areas:
- The skillsets your developers already have (XAML or HTML).
- The ease and speed of development in each environment. What tools are available ?
- Resources for learning. e.g. Videos and the information supplied by the suppliers (wiki, web site).
- The community and third party activity behind each option.
- How active the code owners are (releasing new features, bug fixing).
- Each platform has its own design principles which create a standard experience for the users, a common approach may not be able to supply this native experience. If this matters less to your users than the functionality then this shouldn’t be a problem. Users of business apps probably already experience a multitude of design experiences: ‘Winforms’, ‘Web applications’, ‘WPF/Silverlight’ etc.
- Performance issues may prevent a non native approach. If the app requires a high frame-rate or has intense graphical requirements such as 3D then performance may be an issue.
- What devices are they using. Do they have a mixture running different operating systems or do you only need to support one.
If there is no clear choice then you could clarify the decision by doing a few sprints developing each solution, then see which the developers and users prefer.