Web, native or cross-platform?

So you’ve come up with a concept for an app or you have a service which in your mind would benefit greatly to be “appified “and given to the end user, but what tech do you choose to use? A web page? Hybrid web app? Native apps? Or do you go cross-platform?

At Shortcut we’re blessed with lots of highly skilled native developers for both iOS and Android, and we believe that native is the way to bring forth the best experience for the end user. There’s really no arguing it considering the platforms are designed this way.

Since the launch of iOS and the app store we’ve had a steady increase of alternative solutions that allow you to create apps that work on multiple platforms. The motivation behind these solutions is to leverage the knowledge you already have. It might be a particular language or a whole ecosystem that would be foolish to leave behind to go and learn Swift and Kotlin (or would it?). One other motivation is to be able to share code, assets and other resources, because why do the same work two to three times over?

Having worked with web, hybrid, native and cross-platform apps I can recommend these four ways of achieving your goal:

  • Web page
  • Native app using Objective-C/Swift for iOS, Java/Kotlin for Android and C# for Windows 10
  • React Native (Javascript)
  • Xamarin (C#/F#/VB.NET)

If you’re a web developer reading this you might ask me why I left out hybrid apps (or progressive web apps). Hybrid apps offer the user experience of a web page but is presented like an app. Very confusing. It can work, but experience has shown me and others (look up Facebook) that it’s not really to be recommended. However, that’s why I’ve included React Native.

Before we proceed lets get a little bit more familiar with React Native and Xamarin which represents the cross-platform choices I’m comfortable recommending:

React Native is a framework that allows you as a developer to leverage your experience and knowledge of Javascript and React for building native mobile apps. React Native is available for iOS and Android with Windows 10 support being currently developed. You define your UI the same way as you normally would when creating a web-page with React. The difference being there’s no browser or HTML involved. You use components such as Image, View, Text, ListView etc which are native UI elements that are represented as React components. It’s quite neat. It also aims to provide a common set of components to easily create apps that span multiple platforms such as iOS, Android and Windows.

Xamarin is a platform for creating native apps using C#, F# or Visual Basic .NET and leverages the power of the .NET framework. Xamarin gives you access to the whole API surface of iOS and Android and applies some .NET bits to it where possible. If you have experience with iOS and Android you will be quite familiar using Xamarin, because it’s the same components, classes, storyboards and XML layouts that you’re used to. Xamarin also provides a UI abstraction layer with their Xamarin.Forms framework you can use for writing layouts once in C# or XAML that works on iOS, Android and Windows. It works the same way as React Native where you have common components such as Buttons, Images that translates to UIButton for iOS and Button for Android and Windows behind the scenes.

“Okay Henning, enough talk, I’m on a tight schedule, just give me the answer so I can tell my managers what we’re gonna use for our app and be done with it”

I wish it were that simple. The trick to choosing the right one is challenging your idea, churn the user experience and don’t fixate on any one solution early on in the process. I highly recommend bringing in designers and developers that have experience with developing mobile apps. Especially if you’re thinking of hiring an app agency. The team will work with you on the idea and advise you on what will be the most beneficial for what you are trying to achieve.

When working through the app there are a couple of things to consider and determine early on which will help you decide:

What is the goal of the app? What’s the main feature going to be and who is it for? Under what conditions will the users be using this app? In some cases some ideas are better portrayed as a web page than an app. Challenging the idea early on will help you better determine this.

Do you want a full app or a prototype? When being agile (LEAN) it is highly recommended to test your concept early on with real users. Is the prototype going to be on iOS, Android and/or Windows? Cross-platform tools like React Native and Xamarin.Forms can get you quickly up and running with working prototypes reducing the workload needed to develop and maintain multiple platforms.

Who’s going to be doing the actual development? What are the strengths of the team? Don’t be clouded by your IT department or higher ups. It might sound nice that you want a web solution (or some other specific solution) since you can maintain it yourself when the app is done. Don’t fool yourself. If you’re serious about the app it will never be “done” and it is highly likely you won’t have the resources to push on through yourself.

The most important thing when choosing a framework is to not let your decision impact the user experience. You’ll most certainly want the users to have a great experience. It will be beneficial to you and your company.

I’d love to talk more about this with you so please do feel free to comment, contact me on my e-mail or tweet me @henningmosand.

If you’re serious about developing great user experiences then take a look at www.shortcut.no — we’ll be happy to talk and work with you.

Having trouble installing some NuGet packages on Xamarin projects in Visual Studio 2015?

In software development there is always, and I mean always, something that will turn that sincere joy of coding into a living nightmare and when you’re starting a new project you can be sure that it has something to do with package management, dependencies and versioning of those dependencies. It might be those Cocoapods, those Maven artifacts or in this case: NuGet packages.

This weekend I was coding on a project using the real-time framework SignalR and so I wanted to use the client libraries that existed for .NET. The SignalR Client package works on most if not all the platforms, but it has a couple of dependencies that might fail to install.

It seems that if you try to install the package Microsoft.Net.Http on a Xamarin iOS or Android project you can get these kinds of messages popping up:

Could not install package ‘Microsoft.Bcl.Build 1.0.14’. You are trying to install this package into a project that targets ‘Xamarin.iOS,Version=v1.0’, but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.

Could not find System.Net.Http.Extensions referenced by assembly Microsoft.AspNet.SignalR.Client, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35.


The Microsoft.Net.Http package has dependencies on the Microsoft.Bcl and Microsoft.Bcl.Build packages, and the culprit will be the Microsoft.Bcl.Build package.

After a while of swearing at the NuGet package manager and wishing I’d take other choices in my life I tried installing the dependencies manually.

It worked.

Turns out Microsoft.Bcl.Build has a newer package than 1.0.14 that supports the latest and greatest bits from Xamarin, and for some reason the Microsoft.Net.Http package does not know about it or hasn’t been updated to reference the newest one.

If you’re having similar problems then try to install the dependencies manually because you never know, it might just work..