Can I help you to add Appcelerator Titanium?

I've tested your Swift version on iPhone6 (and iPhone 4s), but get different results than you. My result on
iPhone 6 on 8.3 was 1.571 sec. When running on the IOS Simulator I get similar results: .201 sec.

Any idea why there is such a big difference?

Should this break be removed?
https://github.com/harrycheung/Mobile-App-Performance/blob/master/JavaScript/session_manager.js#L73

It would be great if you clarify if the beautiful graphs here:

https://medium.com/@harrycheung/mobile-app-performance-redux-e512be94f976#.1v6ezq7su

are based on 1,000 or 10,000 iterations runs. Maybe I missed it somewhere, but it's not 100% obvious to me since the source code for the different implementations support both variants.

Hi! I noticed your note about adding support for React Native when it's released. I wonder if you'd be interested in including NativeScript the up and coming (and stable) JS runtime for iOS and android. It is supposed to be pretty performant and anecdotally it feels hugely better than Cordova and a bit better than Xamarin, but I'd love to see this numerically.

If it's of interest, I'd be happy to prepare a PR, if you can give me some guidance on what the app must do and how the tests are executed?

I noticed that Point.swift used struct instead of class, while Point.cs uses class when it can use struct. It appears that when applying that optimization to Swift, the same optimization was missed for the C# version. I think that if Swift is able to gain the performance benefits that come from using value types, then C#/Xamarin should as well.

The change should be fairly simple, probably just changing the type declaration to use struct instead of class:

public struct Point 
{
    ....
}

Hi nice metrics, though it would be useful if Xamarin Classic and Forms could both be seen side by side?

I'm actually just interested in your helper method. In your article you said that UTC now is very expensive / slow. what makes your helper method faster? I'm intrigued.

Double values should be parsed using double.Parse(value, CultureInfo.InvariantCulture) instead. Otherwise it can fail on cultures with different decimal separator. It should speed up the code a bit as well.