Search Unity


Today we announce the public release of Unity 4.6.2, available for download as of right now. It is the first public release with iOS 64-bit support, using our new IL2CPP technology.

IL2CPP is an innovative scripting technology developed in-house by Unity. It delivers greatly improved performance for all scripting inside your projects, and is compatible with the current Mono-AOT solution used on iOS builds.

IL2CPP enables us to rapidly port our scripting solution to new platforms (like our WebGL support) and architectures, of which ARM64 (the architecture that underpins 64-bit on iOS devices) is one. With Unity 4.6.2 you’ll thus be able to make a Universal build that works on both 32-bit and 64-bit iOS devices.

Impressive performance improvements

During our alpha and beta cycles we’ve benefited from lots of really useful feedback from the Unity Community. And, users testing our iOS 64-bit and IL2CPP support frequently reported their scripts running much faster with the new scripting backend.

For example, Andrew Witte, who was running the RayTraceBenchmark on his 32-bit iOS device (benchmark performed on an iPad Mini, 1st gen), achieved the following:


Of course, what we care about most is your scenarios, but during our benchmarking we also saw significant performance improvements.

This is the simple total time of a JPEG Encoder written in UnityScript (this benchmark was performed on an iPad Air 2):


This is the Mandelbrot benchmark that is part of the Unity benchmark used for testing WebGL; it shows a significant performance increase on IL2CPP (this benchmark was performed on an iPad Air 2) :


Get started with iOS 64-bit support

In this new build, enabling the IL2CPP scripting backend and iOS 64-bit support on your project is just a couple of clicks away. In the Player Settings for iOS you’ll find two new dropdowns: “Scripting Backend” and “Architecture”.

ScriptingBackendSelection_800wide (1)

Switching the scripting backend to IL2CPP unlocks the 64-bit iOS support. By default it builds for “Universal” Architecture, which means your builds will include both the ARMv7 and ARM64 binary slices in your application.

If your existing project depends on native plugins, you might need to upgrade them to a version that supports 64-bit iOS and IL2CPP. We partnered with Unity plugin developer Prime31 to get all their plugins upgraded for use on iOS64. You can download them here.

Once this is done, export your project to Xcode. Note that because IL2CPP outputs scripts as C++ into your Xcode project, you’ll need to set the configuration to Release to utilize the full performance optimization of the Clang compiler on the IL2CPP generated code.

You can see how to set it up in the following two screenshots from Xcode 6:

Now you’re ready to run your application on a device. Use the Architecture “Universal” player setting, and the appropriate code will run automatically whether you’re using a 64-bit or 32-bit device. You can get a more detailed iOS 64 bit upgrade guide from the Unity manual.

Things to be aware of:

  • WebRequest/WebClient API is currently available but not functioning. Anything requiring asynchronous sockets through Delegate BeginInvoke/EndInvoke currently doesn’t function. We will address this in an upcoming patch release.

  • Delegate BeginInvoke/EndInvoke will not work though other delegate functions are working well. We will address this in an upcoming patch release.

  • RakNet networking has not yet been ported to IL2CPP, and causes issues if you or 3rd party assemblies reference it. We will address this in an upcoming patch release.

  • Stripping is always performed when on the IL2CPP backend. This might necessitate workarounds to prevent stripping of used types.

  • When stripping is set to micro-mscorlib, compilation might fail on missing types. We are planning to completely disable its selection for IL2CPP in a future build.

  • Xcode takes longer to build. The main reason being that there is a far greater amount of source code to compile.

  • Managed Debugger is not supported. We have it on our roadmap. In the meantime, beta users have had great success debugging their script code using the Xcode debugger.

  • Enabling the Xcode Internal profiler will result in compilation errors when using the IL2CPP scripting backend.

We are very aware that some of the items on the above list will cause shipping delays for some. Ever since Apple’s Oct 20 announcement that new iOS apps uploaded to the app store must have 64-bit support, we’ve been working around the clock, picking off bug-reports at an unprecedented rate while pushing out new builds weekly.

Everyone working on this deeply cares about getting every single issue resolved as quickly as humanly possible.

If you already have your iOS project on the App Store, we recommend that you keep shipping updates using the Mono backend on ARMv7. Apple states that you can continue to do this up until June 1. We further recommend that you commence internal testing of your project using the IL2CPP backend as soon as practically possible.

We’re continuing our weekly builds and you can check out our patch releases regulary on Please feel free to reach out to us on this forum thread. We answer queries daily.

Update; we had mirrored some of the benchmarks (Xamarin.iOS LLVM/No-LLVM) in the RayTraceBenchmark that are pointed out to be incorrect, as they are made in debug mode. We’ve thus chosen to update the bar-chart, leaving only the comparison with Mono 2.6 with IL2CPP (which are both tested in Unity).

Update2: after verifying the RayTraceBenchmark we labeled as Mono 3.2 ran in Release mode and testing on a range of devices, we have reverted the post to reflect the original numbers.

87 replies on “Unity 4.6.2 iOS 64-bit support”

We just finished getting our project to build under IL2CPP. Assuming you don’t have to do anything besides going into Xcode and putting release to “standard architecture arm7,arm64” adding il2cpp added 90 megs to our build size making it impossible to stay under the 100 meg limit when our entire app fit below that limit art, sound, music etc before. How can there really be 90 megs of code compared to ~30 before….

Same here. Minimal project, 10megs of textures and 5 megs of libraries and files. Actual executable size using IL2CPP on iOS is 50 megs. Android/Mono build is 10-20megs. Final app store build is 91 megs. Build time also hugely increased – can see tons of .cpp files being processed. That’s less of a concern but theres clearly a LOT more stuff going into the IL2CPP executable making it almost impossible to stay under the 100meg cellular download limit with even a bare minimum project…

When I build a project from Unity 4.6.3p3 to Xcode. Xcode is displaying 300+ warnings. Mostly “Value conversion issues” I selected L2CPP and universal. Not errors, just warnings, but I’m not sure if that many warnings will effect my submissions to Apple.

[…] Additional improvements and bugfixes are also included. The entire list of changes can be seen in the What’s new list on the Unity website. Additional infomation about iOS 64-bit support can be found on the Unity blog. […]

Please implement .net code for System.Globalization.CultureInfo class.
for example : something like lack of createspecificculture function code.
as of mono 2.x. it works well, but Il2cpp missing alot of .net code. please fix thanks.

So, Only IL2CPP supports 64-bit ios? What bout Mono (2.x)?
I built my project in both ways, and my app with IL2CPP Scripting Backend is about twice bigger than mono (2.x).
Is there no way to build with Mono (2.x) supporting 64-bit ios?

How to reduce the size of my universal build .Previous version of app size with unity 4.5 is 42.8mb .same app with IL2CPP is 87.3 mb .

Amazing job done by Unity Team!

“Stripping is always performed when on the IL2CPP backend” – Does this mean there is no difference between making a build with Stripping Level “Disabled” and Stripping Level “Strip Byte Code” on il2Cpp? Since stripping is always being performed with il2Cpp, the option Stripping Level is irrelevant?

Unity, how come when I try building an iOS IL2CPP build with trial Pro version of Unity 4.6.2 with “Strip Bytecode” ENABLED and opening the resulting built IPA-package I find… MANAGED directory with perfectly preserved and decompilable sets of managed libraries and Assembly-CSharp.dll files and within it – a “not-stripped” subdir with… The same files just bit different sizes!

What’s going on?

Not only this means Assemblies don’t get stripped when they should be, they get included TWICE which blows up the size of the resulting app almost twice compared to Mono AOT build!

For the record: tried making an app with mono 2.x build and Assembly byte code got stripped exactly in accordance with Player build settings.

Really… Why oh why do you include (two!) sets of IL-code with a native app?

Found out that 4.6.2p1 released Feb 5-th fixed this and dll’s aren’t event included with the build. Cool.

I am also experiencing mid-level crashes for the IL2CPP build. For some reason it always happens at the same place of a level and I have absolutely no idea why. I don’t use reflection, no native DLLs or whatever. It just crashes BUT only on my iPad mini 3 which runs 64-bit version of the app. I’ve verified it by building a 64-bit app just to make sure. 32-bit IL2CPP app runs fine on the iPod touch 5G.
Mono build doesn’t crash btw, but it’s 32-bit of course.

Also after 4.6.2 I noticed that for some reason game runs on my iPhone 5 in aspect ratio of an iPad! I mean there are black bars on both sides! Why? It was running perfectly full-screen before the 4.6.2 update. This happens on both Mono and IL2CPP builds. This is a show stopper for me, since I can’t even update games in the AppStore any more, they are running 4:3 when they should be 16:9 on widescreen iOS devices.

Unity team, please fix this!


I’m developing a game for iOS which uses “UnityEngine.Network APIs”, i’m about to publish it but i can’t even compile because Xcode throws link errors for references to Network methods, is there any solution or alternative to this problem?, when do you think you’re going to release a patch?.

Thanks for the help ;)

The patch has solved the link errors but i have another problem, i’m using “System.Net.Sockets” c# libraries but it seems that don’t work, are these libraries incompatible with IL2CPP?.

Thanks for the help ;)

Ok, i’ve noticed that UDP BeginSend and BeginReceive don’t work, i’ve changed my code to use sync blocks and now it works. But now another problem comes to me, i don’t know exactly how but RPC functions aren’t recognized, i get this error: Internal RPC error. Invalid RPC index, function not registered.

Thanks for the help,


I built my game and downloaded latest Unity 4.6.2 and activated IL2CPP + Universal settings.
– Then I built in Xcode with Release scheme as mentioned above.
– The build showed several warnings but the it succeeded.
– Now, when I play the game on my iPhone5, it starts and the opening menu is working but when I play the game, the screen goes black and the game quits.

Does anyone know why this might be happening. The whole game was running smooth prior to 64bit implementation as mentioned above.


I should mention that on hitting START, the game does play but screen goes black and it quits after 2 seconds.

Any help is appreciated because I am not sure how to solve this and my game is being delayed due to 64Bit now.


[…] сообщили в своем блоге о релизе версии движка Unity 4.6.2 c поддержкой 64-битной […]

Here i m getting an issue when i run my project IL2CPP configuration.

i am using prime 31 plugins for admob,social networking,storekit and when run for IOS64 bit in xcode code got the following to solve this issue.” When i asked prime 31 guys they replied saying ::::::::: it’s not a prime31 issue, it’s unity. they’re using the same zip libraries and not creating a separate folder/namespace so duplicates symbols will be created. they’re aware of the need for an urgent fix.

duplicate symbol adler32 in:
duplicate symbol crc32 in:
duplicate symbol deflateInit2 in:
duplicate symbol _deflateReset in:
duplicate symbol deflateEnd in:
duplicate symbol deflate in:
duplicate symbol inflatefast in:
duplicate symbol _inflateReset in:
duplicate symbol inflateInit2 in:
duplicate symbol _inflateInit in:
duplicate symbol _inflate in:
duplicate symbol inflateEnd in:
duplicate symbol inflatetable in:
duplicate symbol __tr_init in:
duplicate symbol __tr_stored_block in:
duplicate symbol __tr_align in:
duplicate symbol __tr_flush_block in:
duplicate symbol __length_code in:
duplicate symbol __dist_code in:
duplicate symbol _z_errmsg in:
duplicate symbol _zcalloc in:
duplicate symbol _zcfree in:
ld: 48 duplicate symbols for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Got the exactly same issue here. I’m using prime 31 plugins and heyzap (Chartboost, admob, atc) and I got 48 duplicate symbols for arch. arm64. Did you solve that? If yes, how?

Well, removing the -all_load flag in linking something (can’t remember now) in the build setting did the trick. No bugs until now. I could use prime plugins, connect to facebook… try this!

“You need 64 bit capable device to test on. These are all iOS devices with A7 or later chip (currently these are: iPhone 5S, iPad Air, iPad Mini Retina, iPhone 6, iPhone 6 Plus, iPad Mini 3, iPad Air 2).”

Does this mean the final product wont be able to run on anything less than a 5S, or does this only apply to dev testing?

If you build 64-bit only, then that’s correct, it won’t be able to run on devices older than a 5S.

However, it’s still possible to build 32-bit apps that run on older devices, as well as building universal apps that contain both 32-bit and 64-bit binaries and run on everything (though these are larger, of course).

Xcode takes longer to build. The main reason being that there is a far greater amount of source code to compile.

Oh. My. Dear. Lord. You weren’t kidding… Just tested it out today: compiling my game as x32/x64 universal app takes 25-30 times longer than when using mono AOT!

I’m still stunned. All I can say is – please, oh please, don’t remove mono 2.x aot option from Player settings for iOS in the nearest future (better yet – just let it be there as long as possible). Otherwise testing on the device will become pure torture!

compile times are not that much longer compared to dSYM linker step with mono / which were horrible btw /
might be even better actually
it’s really not an issue for me

with mono you couldn’t submit new iOS binary after Feb 1st since it has no 64-bit support

When it comes to production, compile times can be whatever (and we really have no choice here, x64 is available only with IL2CPP). It’s fine, one can wait when building a release build.

But compiling with mono AOT in my case takes less than a minute, whereas with IL2CPP build times skyrocket to about 15-20 minutes! That’s simply unacceptable for iterative testing as you can imagine. I’m happy to see mono 2.x being available for use and working as id tit before, but for how long will it be there?..

It’s understandable, seeing how mono iOS build generates (in my case) a 320 Mb Xcode project directory, while IL2CPP fills it up to 950 MEGS! Wow, that’s impressive. It’s as if Unity team took mono VM, reverse engineered it and now provide it with a project as a bunch of .CPP files to be compiled each single time. At least that’s what it looks like.

we have work coming in upcoming 4.6.2 patch releases to make sure we emit less .cpp code (so your buildtimes go down), as well as work on better support for incremental builds, to make all builds after the 1st one go faster. The next patch release build fixes the zlib problem. You could fix the zlib problem in the meantime by finding which library you use that also includes zlib, and removing it from there. We hope to land the patch release with the zlib fix end of next week.

I’ve currently hit a wall with a issue regarding duplicate symbols (zlib).

Not sure how i can resolve this on my own (i believe some 3rd party stuff we use include zlib in them).

Just installed 4.6.2, playing around with IL2CPP, is it just me or there’s absolutely 0 (NOTHING) in the documentation about that ?

Will using the new compilation back-end, now on IOS, later on other platforms will have a negative impact on compile time while developing or will this affect only a full player build?

I’ve just updated to 4.6.2 (Due to Apple’s deadline) and now my project has 66 apple mach-o linker errors when I set it to IL2CPP.

It was working fine in 4.6.1.

Which linker errors? It sounds like you might have a native plugin, that has not been compiled for arm64 yet. you could try only building for armv7. If you file a bug with your linker errors we can help figure out what is going on

Could you put Unity benchmark to the AssetStore, that we could create benchmark applications and test them on our devices?

How is linq support with this build of IL2CPP vs. mono AOT? Better/similar/worse? Are there lots of expanded lines in my future? :)

I think we are roughly on par with mono-aot shipped in Unity. We have a big improvement to very deep generics landing somewhere in the next two weeks that we think will make the coverage much better than what we had.

[…] is adding support to a new and faster scripting backend called IL2CPP. In fact it’s already available from Unity 4.6.2. Previously it only supported a custom […]

We’ve provided Miguel and the mono team the benchmarks we use, and they’ve already identified a few things they can fix to get better performance on these benchmarks. While we are obviously happy that the performance of il2cpp is shaping up like we hoped, we really want mono to be as fast as it possibly can as well. The Unity editor will be using Mono for a long time to come, and having it perform well on code typically used in games is a very good thing. Mono is a great match for Unity editor, and does a lot of things we need, that IL2CPP will never do, because we designed IL2CPP to never have to do those things. (think JIT compilation when you make an edit to your script and hit play, ability to reload code at all)

Because they have .NET 4.5 they can force inline code in some areas. I’ve done this and yes you can get a little better performance but there is really nothing you can do to match IL2CPP in Mono right now.

Nice! Keep it up guys!
I have a question regarding the difference between 32bit and 64bit performance. Does it have anything to do with differences in hardware (cache lines?) or just a difference in il2cpp implementation for these architectures.

the difference between il2cpp 32bit and il2cpp 64bit is all to the hardware’s (and c++ compilers) credit.

Our goal is to support IL2CPP on all platforms in the future. We are simply starting on iOS because we need to solve the 64 bit support on iOS. Once we have that in a really good shape we will start adding more platforms.

I can only repeat MADS wish for an update of the link.xml documentation. Can’t remember how many hours I wasted on that, just to figure out how it’s done and if anyone knows anything about it.
Please give some examples (or let the community do it) for class type, namespace, complete assembly in the doc, so everybody knows how it’s working.

AdColony doesn’t work anymore :( I sended them a mail for that but no answer, do you have better contacts with them?

Hey Romain, if you can file a bug with your project that doesn’t work (the more stripped down the better), we’ll take a look what’s going on

After all it seems related to our project, I tried the sample project and it works fine with IL2CPP.
We didn’t made any modifications to ADColony, I don’t understand why it’s not compiling…
Do you think it can be related to any other plugin but stopping on something related to AdColony?

What are your version numbers for the AdColony Unity Plugin and iOS SDK? Which version of Xcode are you using to build your project? What version of iOS are you running your build on, and on which device model? Have you made any other changes to your PlayerSettings for iOS (other than Scripting Backend set to IL2CPP, Architecture set to Universal, target iOS version 5.0)?

With the forced code stripping I think it’s now time to write better documentation for how to construct the link.xml file.

It’s all well and good showing a simple example but this doesn’t list everything. For example I recently found out that the keyword ‘namespace’ can be used. What else is missing from the example?

Our documentation of the link.xml format can definitely use some work. While we go and improve that, here is the sourcecode that we use to parse the .xml file, which can be used in the meantime to figure out what you can and cannot do:

Note: In 4.6.2 we’ve made it so that link.xml files no longer need to be at the root of the assetsfolder, but they can live anywhere, which makes it so much easier for different plugin authors to not step on eachothers toes.

Well done lads this should make it possible for bigger numbers and distances onetime. looking forward to playing with this

hi all, if I have an app pretty much half built with no fancy coding in it ( I.e. I understood none of the above post ) will it effect me in any way? Will this mean I can’t upload my old project to the App Store, so confused

From the blog post:

If you already have your iOS project on the App Store, we recommend that you keep shipping updates using the Mono backend on ARMv7. Apple states that you can continue to do this up until June 1.

So if you have already shipped with the Mono backend, you can continue to do so until June 1. If not, you will want to start trying the IL2CPP backend soon. If you find bugs or problems, please report them!

Hey guys,

Congratulations on the release of IL2CPP and your support for iOS 64.

That said, the benchmark reports that you are using for the RayTracer is incorrect (the only one I could find the source for and the source for the numbers).

The data comes from here:

First of, the labels are wrong. You are claiming that this is Mono 3.2, while the numbers and tests clearly show that this was Xamarin iOS

Second, the benchmarks were ran in Mono’s “Debug Mode”, which generates vastly different code than the code that is used for a release build.

If the same test is deployed in “Release” mode, the number goes from 8.458 to 5.212 seconds. Which is marginally faster than IL2CPP (I do not have Unity, so I can not reproduce the same results).

The reason why Mono generates different code on iOS for debug mode is that we do not have access to Apple’s native debugging capabilities. So mono implements debugging on iOS by injecting a check for whether the debugger would like to stop at a particular line at every line.

This means that:
a = 1;
b = 2;
c = 3;

Is compiled as:
a = 1;
if (debugger_wants_to_stop) stop ();
b = 2;
if (debugger_wants_to_stop) stop ();
c = 3
if (debugger_wants_to_stop) stop ();

Considering that IL2CPP does not support debugging at this point, this is comparing apples and oranges. Please fix that graph, and update the blog post to reflect that.

Miguel, apologies for any misrepresentation of the stats there. We had taken the stats represented on the RayTraceBenchmark verbatim, not realizing this was a debug build. Comparison against those stats is taken out and we added an update to reflect the change.

This is not true, those benchmarks were ran in “Release” without the debugger attached.
I just “now” did another build with the latest Xamarin.iOS version and LLVM and get the same results in “Release” for iPad Mini.

This is how builds were made:
1) Set build to Release.
2) Make sure in “Project->iOS Build->Advanced” settings are set correctly to LLVM, SGEN ect.
3) Build project.
4) Click file menu “Run->Upload to device”
5) Open app on device and run benchmark.

If there is another step required to get full optimization please advise as to what that is, otherwise the results are valid.

Hello Andrew,

I just checked out your sample, chose the device, and used “Release” vs “Debug” from the top menu, and I get those two different results.

Your project is a 32-bit project, so even on iPhone 6, it will generate code for ARMv7 (32-bit) and not 64 and wont take advantage of the 64-bit instructions on iPhone 6 (where we do perform even better!)

Here are a couple of videos showing my settings and the results.

My original findings on iPhone 6:

Updated with iPad Mini:

There are only two things that I can think of that can affect the different results.

#1 You are using Xamarin.iOS 7.0.2 which is 14 months old, we have done a lot of work in that area
#2 You are using iOS 7, and I am using iOS 8
#3 I am using a more up-to-date version of the iOS SDK.

This is my version information:

=== Xamarin Studio ===

Version 5.7 (build 661)
Installation UUID: f69988af-eb84-438f-88c9-4c5d6beb26a9
Mono 3.12.0 ((detached/a813491)
GTK+ 2.24.23 (Raleigh theme)

Package version: 312000068

=== Apple Developer Tools ===

Xcode 6.1.1 (6611)
Build 6A2008a

=== Xamarin.iOS ===

Version: (Business Edition)
Hash: dfb682f
Build date: 2015-01-08 13:39:32-0500

=== Xamarin.Android ===

Version: (Business Edition)
Android SDK: /Users/miguel/Library/Developer/Xamarin/android-sdk-mac_x86
Supported Android versions:
2.1 (API level 7)
2.2 (API level 8)
2.3 (API level 10)
3.1 (API level 12)
4.0 (API level 14)
4.0.3 (API level 15)
4.4 (API level 19)
Java SDK: /usr
java version “1.8.0_20”
Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode)

=== Xamarin.Mac ===

Version: (Business Edition)

=== Build Information ===

Release ID: 507000661
Git revision: b70bab61da996da29045ea8ee8aed1a6faedbe78
Build date: 2015-01-05 16:31:31-05
Xamarin addins: 82f6c71490562d6cd125a09287f441902fdac3d7

=== Operating System ===

Mac OS X 10.10.1
Darwin MacBook-Pro.local 14.0.0 Darwin Kernel Version 14.0.0
Fri Sep 19 00:26:44 PDT 2014
root:xnu-2782.1.97~2/RELEASE_X86_64 x86_64

NOTE: Tests are done on iPad Mini 1st gen. The non-retina version in case you are testing on a newer faster device.

cool spot. really cool

cant wait to try it out and see the differences. it will be nice once all platforms are in the same ball park, but a good start

[…] Issues still remain however and Unity has admitted that some of these may cause delays for some developers. For example, enabling the Xcode Internal profiler will result in compilation errors when using the IL2CPP scripting backend, while RakNet networking has not yet been ported to IL2CPP. […]

Really impressive. Cant wait to see IL2CPP in the other platforms, specially windows. Time to squeeze more out of the scripts!

I second that motion! PC is what will really start kicking ass with IL2CPP. Imagine the awesomeness… keep up the awesome Unity!

We’ll make it come to windows as well. We actually do a lot of il2cpp development on windows. The reason we haven’t shipped it yet is a) we just want to focus on making iOS 64bit as good as we can, b) windows does not by default come with a c++ compiler installed. So we need to either make it easy for you to install visualstudio, or have unity ship with a c++ compiler out of the box.

Please don’t force a static version of C++ that will age over time. Links to VS Community or Express editions will suffice, and let those products manage the periodic updates to compilers on Windows. Honestly, with VS Community and the VS Tools for Unity extension, I never have to see the inside of MonoDevelop again.

From the other direction, it would be pretty darn cool to start from scratch in a VS solution (VB or C#) template that contained the Unity project set as default and editor hooks to open certain files with appropriate Unity editor UI’s within VS, and ultimately build a 64-bit IL2CPP output. We’d have a custom Tool Window for the Inspector and Assets, and a vastly expanded Toolbox for components, Edit and Continue, full Intellisense, auto-complete, code snippets….

Oh, come on….I can dream, can’t I?!?

What about development on MAC, there isn’t VS, but is Xcode. Unity on Windows will use VS and on MAC Xcode?

Comments are closed.