Search Unity

We’ve been hard at work improving the updated scripting runtime since our last update. Unity 2018.2 ships with dozens of bug fixes related to the scripting runtime, thanks to all of the great feedback we have received since the .NET 4.x Equivalent scripting runtime became officially supported in Unity 2018.1. We’ve also added a number of features, available only with the .NET 4.x Equivalent scripting runtime, which make switching your project even easier.

Managed code debugging with IL2CPP

Unity 2018.2 brings managed code debugging to the IL2CPP scripting backend, with all of the same features as the Mono scripting backend. Just enable the Script Debugging option in the Build Settings for your IL2CPP builds, deploy the Unity player, and debug with great tools like Visual Studio (and all other debuggers which work with Unity).

The debugger attaches to the Unity player running on the device for IL2CPP just as it does for Mono. So remote debugging of a player running IL2CPP is available.

Debugging works with all IL2CPP platforms (Xbox One support will be available in 2018.2.2f1).

Modern SSL/TLS support in .NET

The .NET 4.x Equivalent scripting runtime brings full TLS 1.2 support to all of the .NET class library APIs, on all Unity platforms with Mono and IL2CPP. Unity will now work properly with the operating system to access the local certificate store and make secure socket and HTTPS connections work as you would expect.

Optimizing build size

The API Compatibility Levels available with the .NET 4.x Equivalent scripting runtime bring lots of great .NET APIs Unity developers have wanted for some time. They also bring more code from the .NET class libraries, which can increase the build size. We’ve focused the 2018.2 and (upcoming) 2018.3 releases of Unity on making the build size as small as possible for the .NET 4.x Equivalent scripting runtime.

Our internal tests indicate that Unity 2018.2 ships with a build size increase of less than 2% for a number of real-world projects that switched from the old scripting runtime to the new scripting runtime. In 2018.3 we’ll be delivering more improvements, including new features to allow even more aggressive managed bytecode stripping options, so stay tuned.

The future of .NET is bright

These are a few of the improvements we’ve been able to make with the .NET 4.x Equivalent scripting runtime to make the lives of Unity developers just a little bit easier. The 2018.3 release of Unity will bring even more improvements, as we continue our mission to democratize game development.

Unity 2018.3 will make the .NET 4.x Equivalent scripting runtime the default option for new Unity projects and will deprecate the .NET 3.5 Equivalent scripting runtime. Look for the .NET 3.5 Equivalent scripting runtime to be removed from Unity in the 2019 release series.

If you haven’t tried your project with the new, .NET 4.x Equivalent scripting runtime, the new features in Unity 2018.2 are a great reason to switch.

33 replies on “Scripting Runtime Improvements in Unity 2018.2”

Tough crowd. I really like the scripting improvements.

Before: no scripting improvements
After: people complain because Unity made scripting improvements

Thanks guys, I appreciate the improvements!

Please add new features & optimization tools for application developing with unity instead of Android Studio, because android studio is sucks

Still no new GC. Will you guys really improve the GC? Unity has no garbage collector, just has a garbage. I think you guys miss the point. We cannot use your **Improvements** features because of GC. You guys should release us from Memory-pool-hell or Spike-hell rather than ‘democratize’ something.

Why the hell do infinite loops still crash Unity? WTF? Fix that and I’d finally have a good reason to update.

Unity is not crashing. It just hangs. Which is what infinite loops tend to do. Fix your code.

Some things not implemented in NET 4.x/Net Standard 2.0, but works with NET 3.5 equivalent. (Case 1040632)

I switched to 2018.2 hyped about new features but it sucks it has two major bugs
1.Android app now does not have 2.1 wide screen support don’t know why
2.astc texture compression failed editor crashed and no solution found by unity support.exe thus editor never opens until you manaully delete the file you tried to compress

I tried to implement entities (only hybrid system, the one with OnUpdate), it works great, but my build size increased from 30 mb to 34 after switching to 4.x

What’s the last version of Unity that supports .JS? I have some long-term projects in need of changes, and sticking with the existing .JS would be a help!

RE: Optimizing build size

What is the minimum Android apk build size you managed to produce?
Is it possible to achieve sub-10M for Google Play Instant using .NET 4.6?


For Google Play Instant you should start with the following instructions:
– Download and install the Google Play Instant plug-in from github ( , which will make it easier for you to reach the APK size limit, among other things.

And sign up for the Google Play Instant Unity beta (here: to access the latest updates and guidance on how publish your Google Play Instant Game

Additionally we encourage you to review the Google Play Instant getting started guide (

We are working with Google to accommodate the size limit. In most cases, you have to rely on Asset Bundles to download extra content once the Instant version of your game is downloaded.

Thanks Joshh and JC,
Here are a few data points for 2018.2.0f2:

1. a completely empty build on 2018.2.0f2 is at 7MB after cutting _everything_ out:
– pacman completely empty (no packages, no builtin) meaning not even audio supported (no physics, no UI, no animation, …)
– IL2CPP (with code stripping)
– Google Play Instant Unity beta recommended settings (OpenGLES2, ARMv7, micro mscorlib …)
– Default compression method
– ProGuard minification
These 3 extra megs would be a breeze, however as soon as you add something useful (ex: add TextMeshPro, which needs IMGUI and Physics) you are over the 10M budget.

2. a default empty project with 2018.2.0f2 (only Ads, Analytics and IAP removed in pacman, all Built In packages kept) is above 11MB

For others trying to optimize their build size, this conversation might help:

Would you guys have other tricks and recommendations to further reduce the build size?

I did try again an empty project (3D Template) with 2810.2f2, just removing the Ads, IAP & TextMesh packages – tested on Windows.
Building APKs with Scripting Runtime Version .NET 3.5 vs 4.x is about the same size ~7Mb – even slightly smaller with .NET 4.x
(Settings: OpenGLES2, IL2CPP, API Level .NET Standard 2.0)
Please make sure you are using the .NET Standard 2.0 API Compatibility Level, as it provides a much smaller API from the class libraries, and therefore smaller code, if .NET 4.x selected for this option, then the APK goes to ~10Mb)

Finally, shooting for the 10Mb limit for your Google Play Instant is the goal, but first try to go as low as you can and test/submit int the Play Store sandbox to validate the flow.

Comments are closed.