can this will support ios or android mobile platform?

[srxqds]

can this will support ios or android mobile platform in plan?

[jkotas]

Not in our plan for foreseeable future. We will be happy to accept changes to add the support if somebody is interested in contributing them.

BTW: Have you checked Mono (https://github.com/mono/mono) ? It is .NET runtime that supports ios and android today.

[wis]

I chose to comment here instead of opening another issue, you can correct the title and the comment.
@jkotas I've been watching the progress for more than a year, slow, constant (daily) and steady progress, I understand why it's taking so long, this is no small feat you guys are doing, and I love how engineers from Samsung are contributing.

• will Xamarin leverage CoreRT in the future?
• Yes ...

"the runtimes are converging", Miguel de Icaza said in his answer to my question at Connect(); 2016 in a live Q&A session.

published benchmarks on the web, show Xamarin's performance worse than apps built with their respective platform's techs, Swift or Java/Kotlin, and better than competing techs, but not as much better than I expected, on android I expected JITing Mono and Xamarin to be much faster than V8 and [a direct competitor]'s runtime.

according to this answer on SO, Xamarin has binding between native and managed il jit runtime for 3 different types of objects,
I suspect that's what's constraining performance causing that noticeable perf gap, if apps are AOT compiled with CoreRT, you can have no binding, and have on par perf or possibly better performance, because native apps are faster than apps with JIT compiling runtimes or VMs (JVM / JS/other VMs).

is that correct?, will AOT compiled apps have have on par or even better perf that first-class citizen techs?

other published benchmarks on the web also show the competition (which are also attractive to me, because of my as good web skills), suffering from marshaling constraining perf, Native can make Xamarin stand out again very clearly from the competition.

is there a (publicly shareable) date/goal for ARM support, and following that IOS and Android support, and then following that Xamarin changing from Mono to CoreRT? if not, can you give an estimate? (q4 2018?).

[jkotas]

@wesamco Thanks for your interest in CoreRT! These good questions.

will Xamarin leverage CoreRT in the future?

Xamarin/Mono is leveraging parts of CoreRT today – check https://github.com/mono/mono/tree/master/external .
Our strategy has been to converge and share individual components at a time. We have started with the easier ones first, such as class libraries. It gets us, and our customers, the most immediate benefit.

A better question to ask would be whether there are plans for Xamarin/Mono to leverage specific component, and what kind of improvement you would expect out of it.

Xamarin has binding between native and managed
constraining performance causing that noticeable perf gap

The platform API bindings are independent on the runtime itself. They marshal arguments between .NET and the other programming environment, and the marshalling is where their performance overhead comes from as you have noted. The marshalling overhead does not go away with AOT or CoreRT. For example, the .NET string is different from Objective-C string, and thus it always needs to be marshaled.

is there a (publicly shareable) date/goal for ARM support

The ARM port is led by Samsung engineers for their Tizen platform. I have not seen any dates announced by them yet related to CoreRT.

[alpencolt]

Tizen uses armel (arm softfp) calling conventions, so it's not 100% ARM, difference is how to pass floating point arguments. But when Tizen support will be enabled it will needs little work to support ARM hard fp.

There is no official dates for release.

[fanoI]

The platform API bindings are independent on the runtime itself. They marshal arguments between .NET and the other programming environment, and the marshalling is where their performance overhead comes from as you have noted. The marshalling overhead does not go away with AOT or CoreRT. For example, the .NET string is different from Objective-C string, and thus it always needs to be marshaled.

But CoreRT will have a slightly advantage as it could load a native library in its memory space directly without need of P/Invoke right? And it will be possible to do the other way around (to link in a native application written in C - for example - a library AOT compiled by CoreRT).

[jkotas]

CoreRT does this already for the .dlls that are guaranteed to be always present. The performance advantage out of doing this is very small. I doubt you would be able to measure it.