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.
