Skip to main content

Mobile Development Platform Performance Comparison

When choosing a development platform for building Mobile applications, performance is always one of the discussion points pro- or contra a specific technology. A lot of people claim that technology X is faster than technology Y without real numbers to proof their point. I did some tests myself and had mixed experiences using Cordova, Xamarin and Native Mobile development.
Last week I noticed this blog post by Kevin Ford: http://magenic.com/Blog/PostId/67/mobile-development-platform-performance. Kevin took the time to create a formal comparison between
  • Native (Objective-C 64 bit and Java)
  • Cordova (Multi-Device Hybrid Apps) using Intel's App Framework for the UI
  • Classic Xamarin (64 bit unified beta for iOS)
  • Xamarin.Forms (64 bit unified beta for iOS with beta version of Xamarin.Forms, note latest version of the unified API in the beta/alpha channels could not be used as it is not supported by Xamarin.Forms)
Go check out the full post for all the details, but some things that are worth to mention:
  • Xamarin is really fast, sometimes even faster than the native platform(e.g. Objective-C)
  • Xamarin.Forms has little overhead and gives almost the same numbers as for the classic Xamarin libraries
  • Cordova is a lot slower for CPU bound work but can keep up for service calls and serialization
Great post!

Remark: A colleague mentioned another performance comparison with similar conclusions; https://msdn.microsoft.com/en-us/library/system.string.isinterned(v=vs.110).aspx

Popular posts from this blog

Kubernetes–Limit your environmental impact

Reducing the carbon footprint and CO2 emission of our (cloud) workloads, is a responsibility of all of us. If you are running a Kubernetes cluster, have a look at Kube-Green . kube-green is a simple Kubernetes operator that automatically shuts down (some of) your pods when you don't need them. A single pod produces about 11 Kg CO2eq per year( here the calculation). Reason enough to give it a try! Installing kube-green in your cluster The easiest way to install the operator in your cluster is through kubectl. We first need to install a cert-manager: kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.5/cert-manager.yaml Remark: Wait a minute before you continue as it can take some time before the cert-manager is up & running inside your cluster. Now we can install the kube-green operator: kubectl apply -f https://github.com/kube-green/kube-green/releases/latest/download/kube-green.yaml Now in the namespace where we want t...

Azure DevOps/ GitHub emoji

I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.

.NET 9 - Goodbye sln!

Although the csproj file evolved and simplified a lot over time, the Visual Studio solution file (.sln) remained an ugly file format full of magic GUIDs. With the latest .NET 9 SDK(9.0.200), we finally got an alternative; a new XML-based solution file(.slnx) got introduced in preview. So say goodbye to this ugly sln file: And meet his better looking slnx brother instead: To use this feature we first have to enable it: Go to Tools -> Options -> Environment -> Preview Features Check the checkbox next to Use Solution File Persistence Model Now we can migrate an existing sln file to slnx using the following command: dotnet sln migrate AICalculator.sln .slnx file D:\Projects\Test\AICalculator\AICalculator.slnx generated. Or create a new Visual Studio solution using the slnx format: dotnet new sln --format slnx The template "Solution File" was created successfully. The new format is not yet recognized by VSCode but it does work in Jetbr...