Search Unity

Almost a year ago now, we started to talk about the future of scripting in Unity. The new IL2CPP scripting backend promised to bring a highly-performant, highly-portable virtual machine to Unity. In January, we shipped our first platform using IL2CPP, iOS 64-bit. The Unity 5 release brought another platform, WebGL. Thanks to the input from our tremendous community of users, we have shipped many patch release updates for IL2CPP, steadily improving its compiler and runtime.

We have no plans to stop improving IL2CPP, but we thought it might be a good idea to take a step back and tell you a little bit about how IL2CPP works from the inside out. Over the next few months, we’re planning to write about the following topics (and maybe others) in this IL2CPP Internals series of posts:

  1. The basics – toolchain and command line arguments (this post)
  2. A tour of generated code
  3. Debugging tips for generated code
  4. Method calls (normal methods, virtual methods, etc.)
  5. Generic sharing implementation
  6. P/invoke wrappers for types and methods
  7. Garbage collection integration
  8. Testing frameworks and usage

In order to make this series of posts possible, we’re going to discuss some details about the IL2CPP implementation that will surely change in the future. Hopefully we can still provide some useful and interesting information.

What is IL2CPP?

The technology that we refer to as IL2CPP has two distinct parts.

  • An ahead-of-time (AOT) compiler
  • A runtime library to support the virtual machine

The AOT compiler translates Intermediate Language (IL), the low-level output from .NET compilers, to C++ source code. The runtime library provides services and abstractions like a garbage collector, platform-independent access to threads and files, and implementations of internal calls (native code which modifies managed data structures directly).

The AOT compiler

The IL2CPP AOT compiler is named il2cpp.exe. On Windows you can find it in the Editor\Data\il2cpp directory. On OSX it is in the Contents/Frameworks/il2cpp/build directory in the Unity installation. The il2cpp.exe utility is a managed executable, written entirely in C#. We compile it with both .NET and Mono compilers during our development of IL2CPP.

The il2cpp.exe utility accepts managed assemblies compiled with the Mono compiler that ships with Unity and generates C++ code which we pass on to a platform-specific C++ compiler.

You can think about the IL2CPP toolchain like this:

il2cpp toolchain smaller

The runtime library

The other part of the IL2CPP technology is a runtime library to support the virtual machine. We have implemented this library using almost entirely C++ code (it has a little bit of platform-specific assembly code, but let’s keep that between the two of us). We call the runtime library libil2cpp, and it is shipped as a static library linked into the player executable. One of the key benefits of the IL2CPP technology is this simple and portable runtime library.

You can find some clues about how the libil2cpp code is organized by looking at the header files for libil2cpp we ship with Unity (you’ll find them in the  Editor\Data\PlaybackEngines\webglsupport\BuildTools\Libraries\libil2cpp\include directory on Windows, or the Contents/Frameworks/il2cpp/libil2cpp directory on OSX). For example, the interface between the C++ code generated by il2cpp.exe and the libil2cpp runtime is located in the codegen/il2cpp-codegen.h header file.

One key part of the runtime is the garbage collector. We’re shipping Unity 5 with libgc, the Boehm-Demers-Weiser garbage collector. However, libil2cpp has been designed to allow us to use other garbage collectors. For example, we are researching an integration of the Microsoft GC which was open-sourced as part of the CoreCLR. We’ll have more to say about this in our post about garbage collector integration later in the series.

How is il2cpp.exe executed?

Let’s take a look at an example. I’ll be using Unity 5.0.1 on Windows, and I’ll start with a new, empty project. So that we have at least one user script to convert, I’ll add this simple MonoBehaviour component to the Main Camera game object:


When I build for the WebGL platform, I can use Process Explorer to see the command line Unity used to run il2cpp.exe:

That command line is pretty long and horrible, so let’s unpack it. First, Unity is running this executable:

The next argument on the command line is the il2cpp.exe utility itself.

The remaining command line arguments are passed to il2cpp.exe, not mono.exe. Let’s look at them. First, Unity passes five flags to il2cpp.exe:

  • –copy-level=None
    • Specify that il2cpp.exe should not perform an special file copies of the generated C++ code.
  • –enable-generic-sharing
    • This is a code and binary size reduction feature. IL2CPP will share the implementation of generic methods when it can.
  • –enable-unity-event-support
    • Special support to ensure that code for Unity events, which are accessed via reflection, is correctly generated.
  • –output-format=Compact
    • Generate C++ code in a format that requires fewer characters for type and method names. This code is difficult to debug, since the names in the IL code are not preserved, but it often compiles faster, since there is less code for the C++ compiler to parse.
  • –extra-types.file=”C:\Program Files\Unity\Editor\Data\il2cpp\il2cpp_default_extra_types.txt”
    • Use the default (and empty) extra types file. This file can be added in a Unity project to let il2cpp.exe know which generic or array types will be created at runtime, but are not present in the IL code.

It is important to note that these command line arguments can and will be changed in later releases. We’re not at a point yet where we have a stable and supported set of command line arguments for il2cpp.exe.

Finally, we have a list of two files and one directory on the command line:

  • “C:\Users\Josh Peterson\Documents\IL2CPP Blog Example\Temp\StagingArea\Data\Managed\Assembly-CSharp.dll”
  • “C:\Users\Josh Peterson\Documents\IL2CPP Blog Example\Temp\StagingArea\Data\Managed\UnityEngine.UI.dll”
  • “C:\Users\Josh Peterson\Documents\IL2CPP Blog Example\Temp\StagingArea\Data\il2cppOutput”

The il2cpp.exe utility accepts a list of all of the IL assemblies it should convert. In this case they are the assembly containing my simple MonoBehaviour, Assembly-CSharp.dll, and the GUI assembly, UnityEngine.UI.dll. Note that there are a few conspicuously missing assembles here. Clearly, my script references UnityEngine.dll, and that references at least mscorlib.dll, and maybe other assemblies. Where are they? Actually, il2cpp.exe resolves those assemblies internally. They can be mentioned on the command line, but they are not necessary. Unity only needs to mention the root assemblies (those which are not referenced by any other assembly) explicitly.

The last argument on the il2cpp.exe command line is the directory where the output C++ files should be created. If you are curious, have a look at the generated files in that directory, they will be the subject of the next post in this series. Before you do though, you might want to choose the “Development Player” option in the WebGL build settings. That will remove the –output-format=Compact command line argument and give you better type and method names in the generated C++ code.

Try changing various options in the WebGL or iOS Player Settings. You should be able to see different command line options passed to il2cpp.exe to enable different code generation steps. For example, changing the “Enable Exceptions” setting in the WebGL Player Settings to a value of “Full” adds the –emit-null-checks, –enable-stacktrace, and  –enable-array-bounds-check arguments to the il2cpp.exe command line.

What does IL2CPP not do?

I’d like to point out one of the challenges that we did not take on with IL2CPP, and we could not be happier that we ignored it. We did not attempt to re-write the C# standard library with IL2CPP. When you build a Unity project which uses the IL2CPP scripting backend, all of the C# standard library code in mscorlib.dll, System.dll, etc. is the exact same code used for the Mono scripting backend.

We rely on C# standard library code that is already well-known by users and well-tested in Unity projects. So when we investigate a bug related to IL2CPP, we can be fairly confident that the bug is in either the AOT compiler or the runtime library, and nowhere else.

How we develop, test, and ship IL2CPP

Since the initial public release of IL2CPP at version 4.6.1p5 in January, we’ve shipped 6 full releases and 7 patch releases (across versions 4.6 and 5.0 of Unity). We have corrected more than 100 bugs mentioned in the release notes.

In order to make this continuous improvement happen, we develop against only one version of the IL2CPP code internally, which sits on the bleeding edge of the trunk branch in Unity used to ship alpha and beta releases. Just before each release, we port the IL2CPP changes to the specific release branch, run our tests, and verify all of the bugs we fixed are corrected in that version. Our QA and Sustained Engineering teams have done incredible work to make delivery at this rate possible. This means that our users are never more than about one week away from the latest fixes for IL2CPP bugs.

Our user community has proven invaluable by submitting many high quality bug reports. We appreciate all the feedback from our users to help continually improve IL2CPP, and we look forward to more of it.

The development team working on IL2CPP has a strong test-first mentality. We often employee Test Driven Design practices, and seldom merge a pull request without good tests. This strategy works well for a technology like IL2CPP, where we have clear inputs and outputs. It means that the vast majority of the bugs we see are not unexpected behavior, but rather unexpected cases (e.g. it is possible to use an 64-bit IntPtr as a 32-bit array index, causing clang to fail with a C++ compiler error, and real code actually does this!). That difference allows us to fix bugs quickly with a high degree of confidence.

With the help of our community, we’re working hard to make IL2CPP as stable and fast as possible. By the way, if any of this excites you, we’re hiring (just sayin’).

More to come

I fear that I’ve spent too much time here teasing future blog posts. We have a lot to say, and it simply won’t all fit in one post. Next time, we’ll dig into the code generated by il2cpp.exe to see how your project actually looks to the C++ compiler.

66 replies on “An introduction to IL2CPP internals”

[…] is the sixth post in the IL2CPP Internals series. In this post, we will explore how il2cpp.exe generates wrapper methods and types use for […]

[…] is the fifth post in the IL2CPP Internals series. In the last post, we looked at how methods are called in the C++ code generated for the […]

Well…moving to IL2CPP is not a great success for me…

mscorlib_System_Predicate -> unknown class when building on xCode.

Any idea what could be causing this problem?

[…] is the fourth blog post in the IL2CPP Internals series. In this post, we will look at how il2cpp.exe generates C++ code for method calls in managed […]

when i change to the IL2CPP , and i build the arm7 and arm64 arch , the build size is add 50M…what’s happen?? how can i debug this? can anyone help me ??

Hi, can you please help me understand how IL2CPP affect use of generics? I’m still getting lost to understand it. Based on what I read is that generics and reflection works in C# thanks to JIT compiler on vanila .NET platform. Now IL2CPP will use AOT which means the use of generics should be affected. Will there be some article about how to use generics and reflection properly in order to be used with IL2CPP. This looks strange to me (I’m probably not getting this right), but doesn’t support of AOT cut off some C# language features?

Second thing, you mentioned that Unity 5 is shipped with Boehm-Demers-Weiser garbage collector. Is this garbage collector used as main garbage collector and this is complete replacement for old Mono GC? If so, is this finally multigenerational GC? Is there any materials explaining how this GC works (I’ve found only github links to source code) and how to properly write C# code for this GC in order of getting better performance?

Thanks for your reply :)

[…] is the third blog post in the IL2CPP Internals series. In this post, we will explore some tips which make debugging C++ code generated by IL2CPP a […]

[…] 文章的源地址: […]

[…] 鏂囩珷鐨勬簮鍦板潃锛 […]

[…] is the second blog post in the IL2CPP Internals series. In this post, we will investigate the C++ code generated by il2cpp.exe. Along the way, we […]

Thanks for the Good Post.

I understood that il2cpp.exe perform roles AOT compiler and runtime Library to support VM and also one role of runtime is the garbage collector.
but I don’t know where IL2CPP VM is and what its role is.

Could you tell me about that?

Sure, the il2cpp.exe is really just the AOT compiler. It converts .NET IL code to C++ code. IL2CPP doesn’t really provide a full VM, at least for the strict definition of a VM. We are really still using the .NET VM, implemented by Mono.

Instead, IL2CPP provides a static library named libil2cpp (on some platforms like iOS, libil2cpp is linked into another static library with other code). The libil2cpp library provides support functions for the .NET VM, like internal calls. Internal calls are native methods called by the C# managed code in mscorlib.dll and other standard library assemblies. It also provides garbage collector support, and access to platform specific resources via a common API.

I hope this helps to clear things up a bit.

what’s about IL2CPP support for Android and Windows Phone, is it coming any time soon?

We’re working on some other platform ports of IL2CPP now. I can’t yet say which ones or when they will be ready though. We’ll announce them as soon as we can!

Can you tell us about the advantages of Mono over CoreCLR. I’m just curious , honestly speaking I’m not involved with any WebGL or iOS project at the moment so am not affected by problems of early days of IL2CPP before getting mature.

It seems CoreCLR should be the wise choice. Mono people will integrate more and more with it but will have their own version because of Xamarin and their mobile platforms and … Is there an advantage in following them instead of the faster more productive Microsoft team? Are you using some tech in Mon which is not available in CoreCLR which is not and will not be available on CoreCLR soon? Or it’s just a hard engineering problem to solve to switch?

We’re using Mono for a number of reasons. Among them, Mono has been ported to many more platforms than CoreCLR (platforms where we need it), the cost of switching to CoreCLR does have a very high engineering cost (we can spend that time adding features or fixing existing bugs), and we’ve had good success with Mono in the past.

We are very excited about where the .NET community is going though, and we’re looking forward to a bright future in the community, based on the move toward open source.

Do you have any plan with SSE or NEON in IL2CPP ?
Such as writing some special codes in C#, then IL2CPP will know these codes are using SSE or NEON.

This is something we have considered. We don’t have any firm plans yet, but it is certainly a great opportunity to leverage our creation of a code generation tool to provide users with more power.

I don’t understand this sentence: ” We did not attempt to re-write the C# standard library with IL2CPP.”
What do you mean? That the standard assemblies are il2cpp’d like any other assembly? If so, does that happen every time or do you have some kind of preprocess cache? (I guess with stripping you’d still want to postprocess them every time anyway.)
What was the alternative? re-write the standard libs in C++ from scratch?

This means that we use the same mscorlib.dll, System.dll, etc. assemblies for both the Mono and the IL2CPP scripting backends. If one of these assemblies is used, it is converted from IL to C++ via il2cpp.exe during each build.

This conversion of the standard library code does increase both the conversion time in il2cpp.exe and the compile time for the native compiler. However, as you correctly point out, we need to convert each time the project is built because stripping can change the contents of these assemblies. We’re looking at ways to enable incremental builds and avoid converting these assemblies each time, but we’re not ready to release anything yet.

The alternatives would be to re-write the standard libraries in each C# (and convert them) or write them in C++ with a thin C# wrapper. Neither option made much sense, as the approach we took allows us to leverage plenty of well-written, existing code.

In one of the previous blog posts about IL2CPP I’ve read that eventually, Unity will switch from .NET 2.0 to a more recent version. Considering that the most recent version is 4.5.2, it seems only appropriate. Is this still on the roadmap?

(Note: of course, what Unity really uses is Mono, but I don’t know which version of Mono corresponds to which version of .NET, and Unity states “Full .NET 2.0” in the editor, so I decided to stick with that)

Yes, an upgrade to the latest version of Mono is on the roadmap. We don’t have dates or releases to talk about yet, but it is coming.

Does it follow then that the Unity version of MonoDevelop will also get an upgrade?

Yes, we’re also working on improvements to our interaction with MonoDevelop and hopefully an upgrade. Again, I can’t give any specific dates yet though.

I believe the main reason for this tech to appear were iOS and WebGL platforms, and I don’t see any reasons it should be used on PC/Mac.

You are correct that the original platforms for IL2CPP are WebGL and iOS. However, has been implemented to be more generally available. It might make sense on PC or Mac for certain cases, as it can provide better performance, for example. Not that IL2CPP is AOT-only, and does not provide a JIT. So existing projects which use features like System.Reflection.Emit (which is available on PC and Mac) won’t work with IL2CPP.

In any case, we don’t have the PC or Mac platforms ready with IL2CPP now, although we are considering them for the future.

It amuses me that .js scripts being built to webgl now follow the following transform:

Javascript -> IL -> C++ -> LLVM bitcode -> Javascript

Yes, this is a bit odd :) Remember though that “JavaScript” used in Unity really isn’t JavaScript. It’s UnityScript, which looks a lot like JavaScript, but compiles down to IL and runs on the Mono VM.

Thanks for the insights. I see this is a interesting exercise from engineering point of view, and these’s the kind of hardcore work I loved to do at nights.

From a business point of view however and for web publishing, this is still no a solution for any serious project and it seems far from ready, so I’m, with great interest (there’s money on the air!), looking after a breakthrough and usable achievement in the future.

As others have stated if this technology can’t produce reduced sizes builds in a sensible time of our code similar to what a WebPlayer build means today (ok, not counting the Unity core runtime itself), then it can be shelved as a nice experiment or treat as an alpha.

For me, web and Javascript mean near-instant usage during the lifecycle:

– I don’t want to wait for +10 minutes each time I change a single line of code to test that on the web. Incremental builds?

– I don’t want to see other pure WebGL or javascript applications start running in 2-3 seconds in modern devices, while having mine to wait for several minutes to load.

So, honestly I think that before continuing the arguments around the number of fixes worked out, we need to know what are your assumed expectations for this technology (for this year), as IL2CPP + WebGL are being touted by you as a replacement for WebPlayer:

I look forward to your next posts to learn more about:

– What are the comparison performance magnitudes between WebPlayer and WebGL for same project? In size and build times (x2, x3, x5?).

– What are the minimum sizes for a WebGL build compared with WebPlayer?

– What kind of asset or code additions impact the most the build size of a WebGL project?

– A known list of limitations or issues for WebGL builds (WWW? no substances? audio loops?).

– Cloud builds for WebGL, when?

– Any talks with Facebook for canvas applications on WebGL?

Thanks very much.

Most of your questions are not related to IL2CPP at all but rather on the WebGL itself and it’s limitations. I would not expect answers to platfrom specific issues but maybe for the common ones that are shared on all (like build time and size).

You’re right, but correct me please if I’m wrong… what’s the point of IL2CPP from user point of view? Performance? I’m not worried about that right now, you know, could be, but we have a major show-stopper on the web, and the alternative seems to be WebGL. And… WebGL requires compiling with IL2CPP right?

So I really don’t want to focus on a specific piece of the stack required behind a WebGL production, but on the overall experience. As a developer I care about platform specifics! If there’re limitations to WebGL itself, then we need to know as well! It could be misleading to think that as soon as IL2CPP is mature, then we’ll be able to work productively for the web!

From the perspective of a Unity user, IL2CPP provides at least three benefits:

1. Near native code performance for script code.
2. Easier porting to new platforms, so Unity users should get new platform support sooner.
3. Support for modern C#/Mono versions coming in the future.

You are correct in saying that IL2CPP is required for WebGL. And WebGL does have some platform limitations outside the scope of IL2CPP (e.g. no support for threads).

We’ve already seen some nice improvements in WebGL technology, and I expect those to continue, so I think the future for web publishing is bright, but we still have work to do.

Well still it seems you are more after a blog post about WebGL itself and not IL2CPP with your questions. I assume such blog post will come sometime in future from guys in that team (Ralph, Jonas(?)) and maybe when WebGL might be moving out from preview state. In the mean time most of questions have been answered in the manual or in the WebGL forum section by devs.

As mentioned in the blog post linked form this one about the future of web publishing, we do see WebGL as a key technology move forward. The question raised here are good ones. This blog post series is focused a bit lower in the technology stack, so I was not planning to address them. I’ll talk with our WebGL team to see if we can address these questions though.

As stated before, your questions are mostly specific to the WebGL platform, and not il2cpp, what this blog post is about. I plan to write a blog post on the status and plans for WebGL within the next month or so, stay tuned for that. But I’ll try to answer your questions quickly:

– What are the comparison performance magnitudes between WebPlayer and WebGL for same project? In size and build times (x2, x3, x5?).

This depends on a lot of factors (browser used, subsystems used).
See here for a more in-depth analysis:

– What are the minimum sizes for a WebGL build compared with WebPlayer?

Currently, minimal projects in Unity WebGL weigh in at about 3 MB total download size. I hope to get that down to below 2 in the future. For the web player, a minimal project is just a few KB, but bear in mind that that does not include the engine code itself, which adds a 10 MB download to the web player every time it needs a new engine version.

– What kind of asset or code additions impact the most the build size of a WebGL project?

It’s hard to give a general answer to this. But any subsystem touched in Unity will add to the build size. PhysX, for instance is a big one – if you don’t use any Colliders/Rigidbodies/Raycasts/etc, your build will shrink significantly. Third party .NET dlls also frequently add a lot to your build sizes.

– A known list of limitations or issues for WebGL builds (WWW? no substances? audio loops?).

See the list here:
FYI, Audio Loops will work in WebGL in 5.1.

– Cloud builds for WebGL, when?

Can’t tell, not on the cloud build team.

– Any talks with Facebook for canvas applications on WebGL?


To Jonas and Joshua, thank you very much for your answers. I have read some comments on WebGL platform forum and I’m really excited to test those improvements!

Thank you Jonas!

It’s really nice to see you’re in talks with Facebook. I’m excited to see what you both can provide together, in terms of Facebook Canvas but with WebGL.

In addition to Facebook API, I hope they also update their Parse API to support WebGL because it really works very well with current Unity WebPlayer platform.

Emscripten is an amazing tool. Im looking forward to see more of unity on the web. Alon Zakai seems to be on board. I saw him tweet the Unity Teleporter demo on WebGL not too long ago.

With all the time and money spend in IL2CPP and the only little results you obtained so far, how confident are you about the future of IL2CPP. I mean how much time more do you need before realizing that this was an overly ambitious project that has only delivered broken promises. Every body want a better mono, when are you going to try to do what people really need…

I wouldn’t say they haven’t gotten results. What they’ve done so far is impressive and working for a lot of people. They couldn’t get acceptable terms for licensing updated mono for mobile. So either they’d have to use different mono versions for desktop vs mobile (a bad idea) or move to something else. By moving mobile over, that frees them up to update mono on desktop systems to a more recent version, or possibly even move over to Microsoft’s .NET now that it’s opened up. And eventually we could see an option to build via IL2CPP for desktop platforms as well, if there’s performance gains to be seen there and you don’t need support for the unsupported runtime stuff.

I for one am happy that you guys went this direction, keep up the good work. Looking forward to seeing the performance increases made possible by this (either directly or indirectly by enabling us to use more recent runtimes).

Thanks for your concern here, I think that this an important question. If it is true (as we have been saying), that IL2CPP is a big part of the future of scripting in Unity (and it is), then we need to be confident that it will be solid.

I wouldn’t say that we have been overly ambitious or broken promises. Certainly, IL2CPP is not quite where we want it to be yet, but it is getting there – fast. Many customer are shipping significant games using IL2CPP technology now, and we’re seeing more every day.

The key things that gives me confidence in IL2CPP is our iteration rate. We’ve made some technology decisions with IL2CPP (e.g. writing the code conversion in C#, keeping the runtime library simple and cross-platform, re-using the existing class libraries) which have allowed us to move quickly. By continually improving IL2CPP, we’re moving fast toward the place where we want to be.

Thanks, i’ve pretty much understood the compilation process even before reading this post (but it was nice to get to know a few of those command line args).

With regards to debugging – is it even possible to debug the game once it was transformed to c++ ? having looked at it a few times, it does not resemble the original code in any way.

Yes, it is possible to debug the generated code (for example, on iOS using Xcode). Although it is not always easy. Since the C++ code is generated from IL, not C#, you’re really debugging something like IL code. So you need to make the mental jump from C# to IL, then debug IL code. I’ve been surprised more than once about how the C# code looks in IL!

The next post in this series attempts to demystify that a bit, looking at the layout of generated code and a few common cases. The third post attempts to use that information about the generated code to help debugging it in Xcode.

Will this solve any of the cross platform issues ? For instance : No events within dlls on iOS, limited generics on iOS (trampolines), no threading on WebGL. Moreover, will this add support for newer dotnet features such as TPL and async operators.

Some yes, and some no.

> No events within dlls on iOS – no IL2CPP doesn’t change anything here.

> Limited generics on iOS (trampolines) – Yes, IL2CPP doesn’t use trampolines, so has no such restriction

> No threading on WebGL – no , IL2CPP does not help here. Once browsers support threads in WebGL, then we can implement them in IL2CPP.

> Will this add support for newer dotnet features such as TPL and async operators – Immediately, no. But as outlined in the post about the future of scripting in Unity, Il2CPP is the path to getting the newer C# features in Unity. We’re not there yet, but we plan to get there.

Just a quick question. Now that U5 is up and out, do you have a deadline for U4 project developers? My project is U4 and due to serious shader and API changes in U5 it would take me up to 2 months to migrate, which will destroy deadlines. Meanwhile as I’m getting closer to release, I’m getting more and more nervous since I’m planning to ship fixes and updates and it would be painful to find out when Unity team suddenly (well, hopefully not!) decides to drop U4 support a couple weeks after the release of my U4 project.

How long do we, Unity 4 project developers have really? I don’t need a specific EOL date, just an approximation, please.

I’m not sure if or when support for U4 will end (the decision is not mine). I expect that it will be clearly communicated though, and well in advance. I can say that as long as U4 is supported, we will continue to port the latest IL2CPP code to U4.

We plan to continue releasing 4.6 patch releases at least until the end of 2015, though they’ll get less frequent than the current weekly schedule, and the fixes will be increasingly limited to only the most critical issues.

When you showed us that code snippet above. I thought you’d step through the various outputs (ie C#->IL->C++). I mean it’s cool that you took your time to outline the steps involved. But that snippet isn’t very useful to the understanding of this post unless we’re able to follow it’s journey from C# to C++. My thoughts.

We’ll see that a bit in the next blog post, exploring the generated code. There we’ll see how the C# code looks in C++ (although not in IL). That post should be up next week.

“Are there plans to move to .NET Core instead of Mono?” – I really don’t understand why they don’t focus their time on that. IL2CPP has been a complete disaster for me and my team. We have missed iOS launches and deadlines for ~3-4 months now.

-It takes literally takes more than 10 minutes to compile.

-The build size is massive….EVEN FOR A PRACTICALLY EMPTY PROJECT.

-There are still bugs…Still. Yes the dev team is doing a great job at fixing them. But at this rate we are going to see this kind of crap every time apple updates their iOS. Plus I can’t imagine actually being able to support later versions of .net.

Two better approaches would be to:

1: Use mono 64 bit now that it has been released for iOS.
2: Use the real .net – as of last week Microsoft just released .net on all platforms. (including mac and linux)

Our top development priority is now executable size. We’ve delivered some improvements in recent releases, and we have more coming, so stay tuned. We’re also aware that build times are far too long. We’re working on that as well. So you’ve hit on a couple of the biggest problems with IL2CPP now, but we are working to fix them.

Looking further ahead, we don’t anticipate any serious problems with new iOS versions. Since IL2CPP is generating cross-platform C++ code, we have confidence that we can quickly deal with changes in the future.

With that said, I feel for the delays you’ve had with our team – they clearly not acceptable. If you have any outstanding bugs that we should check on, let me know and I’ll have a look at their current status. Thanks.

When do you plan to port il2cpp to Windows, Mac and Linux? Also what about the latest C# standard?

We have some more IL2CPP platforms in development now, but that is the best I can tell you, unfortunately. We’ll have releases and dates available as soon as we are ready for new platforms.

We’re in the same boat for the C# upgrade. It is something that we want to do, but we’re not ready to point to a specific date or release yet.

No, we have no plans now to switch away from Mono. We are still on track to upgrade to a newer version of Mono, as outlined in the earlier blog post about the future of scripting in Unity (although we don’t have specific releases or dates ready to discuss).

With that said, we’re very excited about where the .NET community is going, especially with respect to open source code.

I don’t really understand why we should be stuck in the stone age that is Mono as .Net Core should generate the same bytecode. Hopefully when the new .Net Core open source community matures it’ll blow xamarin right the hell out of business.

When you showed us that code snippet above. I thought you’d step through the various outputs (ie C#->IL->C++). I mean it’s cool that you took your time to outline the steps involved. But that snippet isn’t very useful to the understanding of this post unless we’re able to follow it’s journey from C# to C++. My thoughts.

Do you know if there are any plans to switch the compiler to Roslyn for generating the IL? It can compile for .net 3.5 and would mean we could make use of all the C# 6 language features that .net 3.5 support.

Comments are closed.