Alessandro Farace
Alessandro Farace

Reputation: 322

C# Native IOS with .NET

I was looking to start learning Xamarin and IOS development. A book I found had in its description

for building native Android, iOS, and Windows Phone apps using C# and .NET.

This put my off completely. I thought native is synonymous with unmanaged code, but then how can it be using .NET?

No doubt, my understanding of these terms are flawed, so when clarifying, can you try to be as simple as possible as to take into consideration a lack of knowledge.

Upvotes: 2

Views: 1114

Answers (2)

Aaron Carter
Aaron Carter

Reputation: 62

C# and other .NET languages are, as others have explained, always compiled to native CPU instructions at some point in time. The "traditional" way was through "JIT" ("Just In Time") compilation, where the runtime compiles the intermediate assembly language (or "IL", also often called "MSIL", "bytecode", "IL asm", etc) into native binary. This has a slight delay the very first time a piece of code runs, because the JIT compiler obviously has to run over the IL code and emit native instructions, but the delay is very, very tiny and on subsequent calls or entry to that block of code it's already compiled and in native binary form, so from there on it just runs instantly. Most of the time that little JIT overhead is unnoticeable to a human being and you can only notice it with an very accurate timer. And it's a very small price to pay for the benefits you actually get from the JIT compiler. Some of those benefits are that one assembly can run on all different platforms, the JIT compiler has the opportunity to emit native code highly optimized to that very specific hardware and OS, only the code you're actualling using needs to get compiled which saves memory and creates an overall smaller memory footprint for the application, new code can even be emitted at runtime fairly easily with reflection APIs and that same code will work across your different target platforms and code that's no longer needed can be disposed of and free up memory and resources. So JIT is not bad at all, and it's actually very optimized and does you a lot of favors.

However, you can't use JIT in every scenario. Sometimes you have to have code that has no delay or overhead on a "cold start" (being called for the first time) like some important, performance-critical code. And sometimes you have restrictions or other reasons you must supply a native executable image, such as in the case of iOS-based systems (arguably an arbitrary "requirement" Apple imposed to try to have more control over 3rd party developers). Whatever the case, in these situations we do full "Ahead of Time" or "AoT" compilation, which is similar to how C/C++ code compiles. However, it still has .NET metadata, runtime references and all the good .NET stuff, it's just all fully compiled to native binary instructions and ready to run on target platform's CPU. In this form it's not all that different from compiling code in unmanaged languages, but you still have managed .NET benefits like garbage collection, rich metadata, very low risk of memory management errors and instability due to memory-related errors, etc.

So .NET applications and libraries built for Android or iOS literally are "native" in the sense their format and compatibility with the hardware and system, even if they're built with a different language and set of tools than the first-party system developers used and distributed to 3rd party developers. So you are able to use a language like C# instead of Java/Kotlin or Objective-C/Swift, all that ultimately matters is generating binary that works with the CPU and hardware and packaging it in the way that the OS requires it.

Upvotes: 0

Ivan I
Ivan I

Reputation: 9990

At the end of the day, the application has to run using the native code. .NET brings its APIs and garbage collection on the top of the native APIs and acts as a middle layer between the application and native APIs.

But in doing so it may do it in a way that it supports only its own subset of APIs (with the ability to P-invoke non-supported APIs), or that it also supports all native APIs. Xamarin supports all native APIs out of the box. That is why it is called 'native'.

The second thing is that application code can be converted to native on the fly or it might be precompiled. Microsoft also calls this precompiled code as .NET native in UWP (https://blogs.windows.com/buildingapps/2015/08/20/net-native-what-it-means-for-universal-windows-platform-uwp-developers/#eZpcAqAsHbO5CMeU.97), and it can be compared to what Xamarin does.

Upvotes: 1

Related Questions