Search Unity

The end of 2014 is coming, and so we thought that it would be good to let our users know about the progress we are making in adding iOS 64-bit support as well as providing an update on our strategy for Web deployment.

On iOS 64-bit apps

Almost one month ago, we announced upcoming support for iOS 64-bit apps in Unity 5. Recently, Apple made another announcement related to 64-bit apps on iOS:

As we announced in October, beginning on February 1, 2015 new iOS apps submitted to the App Store must include 64-bit support and be built with the iOS 8 SDK. Beginning June 1, 2015 app updates will also need to follow the same requirements. To enable 64-bit in your project, we recommend using the default Xcode build setting of “Standard architectures” to build a single binary with both 32-bit and 64-bit code.

So what does it mean for you and how are we going to address this? Please continue reading to find all the answers.

Upgrade your projects now

We are going to support iOS 64-bit via IL2CPP in Unity 4.6.x and Unity 5. If you are planning to publish a new project or issue an update to an existing project on the Apple iOS App Store, then your project must be upgraded either to Unity 4.6.x or Unity 5.0. Upgrade your project to Unity 4.6.1 now if it is already shipped using Unity 4.x/3.x and you need to release an update or if it is in late production stage. This will let you quickly upgrade your game to a 64-bit iOS app after the Unity 4.6.x with iOS 64-bit support is released.

However, if you own a Unity 5.x Pro license and your game is in the early stages of development, or you plan to use some advanced Unity 5 features, select the Unity 5 upgrade path. Customers who already work on Unity 5 based projects can continue doing so without much concern: iOS 64-bit support and Metal rendering are going to be actively supported and improved upon in Unity 5.x.

iOS 64-bit for Unity 5 progress

We have made a Unity 5 based alpha build and have started shipping it to our closed alpha testing group and dedicated focus group to get some initial feedback. We have made good progress and have multiple game projects running as 64-bit apps on iOS 8. We also partnered with Prime31 plugin developers to upgrade the most popular plugins for IL2CPP and 64-bit. After the New Year, we plan to merge those changes to our main Unity 5 beta branch and release it as a part of Unity 5 beta builds. This way all of our Unity 5 pre-order customers and subscribers will get access to this new functionality in the first half of January 2015.

iOS 64-bit for Unity 4.6.x progress

Due to the popularity of Unity 4.x with thousands of game projects in the final stages of production, we decided to add iOS 64-bit support to Unity 4.6.x.

Just today we shipped the first iOS 64-bit enabled beta build based on Unity 4.6.1 to our closed beta testing list. We expect to ship an official “dot-dot” update of Unity 4.6 with iOS 64-bit support enabled by the end of January, 2015.

Metal rendering for Unity 4.6.x

Initially we were planning to have iOS Metal rendering only on Unity 5, but after listening to your concerns and feedback we understand that it is absolutely crucial to have it in Unity 4.x. We have already started the backport of Metal rendering support to Unity 4.6.x and have a build for the closed alpha testing group in preparation. We plan to release 4.6.x beta builds of Metal rendering in January, 2015 and expect to ship the official version of Unity independently of iOS 64-bit support.

What’s under the hood?

Most of you know that we’ve been developing our own runtime solution, IL2CPP, for a long time. It allows us to give you great scripting performance (see our blog about performance on WebGL here) and will also enable us to be more flexible and efficient in supporting various platforms including iOS 64-bit. For a complete rundown of the technology, please see our previous blog post “The Future of Scripting in Unity.”

In Unity 4.6.x and Unity 5 we will support two scripting backends: Mono and IL2CPP. There is a new Scripting Backend selector in iOS platform Player settings:


The Scripting Backend can be either Mono or IL2CPP. If Mono is chosen then the 32-bit ARM v7 architecture app is built. Until June 1, 2015 the Mono scripting backend can be used to publish 32-bit updates to existing apps on the iOS App Store or for internal testing. If the IL2CPP scripting backend is chosen, then the Architecture selector will allow you to build 32-bit, 64-bit or Universal – the prefered option if you’re targeting both high-end and low-end devices.

Our goal is to have the exact same scripting experience via IL2CPP on iOS as via Mono, such that after clicking once in the Player settings and choosing IL2CPP as your scripting backend you notice no change. However there are some differences:

  • Longer build times because there are additional steps to converting IL bytecode to C++ and compiling that to build Unity engine libraries.

  • Larger iOS binary sizes because we need to store 32-bit and 64-bit iOS binary code in a Universal app, so that games can run on both older 32-bit devices and new 64-bit ones.

  • IL2CPP always has code-stripping enabled, to reduce code size; this might mean that types that are not in the compilation, might need to be manually added.

Short term there might be defects in IL2CPP because it is newly released, however we’ll fix whatever you find on a weekly basis via our patch releases.

On Unity Web game development

In Unity 5 we will introduce an exciting new platform – WebGL  – and have already seen a nice game shipped on it several months ago. We believe that WebGL can change the face of Web gaming: game developers will get access to billions of gamers without needing to install an additional external plugin. However current browser vendors offer varying levels of WebGL support in their browsers, so 2015 game developers may want to employ hybrid tactics in order to be the most successful. Recently the Chrome team announced the update of NPAPI sunset plans, quoted below:

In April 2015 NPAPI support will be disabled by default in Chrome and we will unpublish extensions requiring NPAPI plugins from the Chrome Web Store. Although plugin vendors are working hard to move to alternate technologies, a small number of users still rely on plugins that haven’t completed the transition yet. We will provide an override for advanced users (via chrome://flags/#enable-npapi) and enterprises (via Enterprise Policy) to temporarily re-enable NPAPI while they wait for mission-critical plugins to make the transition.

In September 2015 we will remove the override and NPAPI support will be permanently removed from Chrome. Installed extensions that require NPAPI plugins will no longer be able to load those plugins.

The good news is that the teams behind the Microsoft IE, Mozilla Firefox and Apple Safari browsers have not announced any plans to deprecate plugin support.

We are committed to supporting the Unity Webplayer in Unity 5 at least through 2015 and as long as it is useful for our developers.

So, what should you do to ensure you continue to reach the largest number of users? For the time being the best way to reach the largest gamer audience is to ship your game using the Unity 5 Webplayer and Unity 5 WebGL at the same time. Currently WebGL games are more limited in terms of functionality and performance, so if you are starting a new project it is recommended that you have Unity 5 WebGL as the default target and port your game to the Unity 5 Webplayer later, adding some additional functionality to leverage more capabilities of the Unity Webplayer. This way, gamers will be able to play a WebGL game on Mozilla Firefox, Google Chrome, Apple Safari 8.x or play it as a Unity Web player game on Microsoft Internet Explorer or Apple Safari 7.x.

41 replies on “R&D Christmas update”

it seems that C# socket is not supported in IL2CPP in Unity 4.6.x? how to fix this problem?

[…] Source link 作者:VILMANTAS BALASEVICIUS 原文連結 […]

“IL2CPP always has code-stripping enabled”

I have to keep stripping disabled because I keep getting compilation errors when I enable it, does that mean that my app won’t work with IL2CPP unless I fix all my problems? what stripping level does it use?

This also brings up a question, now that stripping is enabled by default and mandatory for 64bit apps on iOS, is the feature part of Unity free or how will that work for people without a pro license?

I noticed the ultimate fate of the webplayer plug-in is left ambiguous. I do hope that it will continue to be supported unless the webgl surpasses it in performance. Web development is the thing i wish to focus on the most.

Great to hear, it has been a difficult end of year for dev’s providing support for IOS 8 already and possibly till after this first quarter will remain tricky, on a few projects have been using Vuforia and with deadlines past and future ones looming I really appreciate all the help I can get with the required migrations to 64-bit decided by the powers that be. I hope this means when android finally has 64 bit specifications, the switch over will be far less turbulent but who knows. Thanks again and keep up the great work.

Does this mean we’re getting iOS IL2CPP in Unity 5.0.0 already? cool! but is seems a final won’t be out until 2Q 2015.
Can you tell us what more platforms could possibly use IL2CPP..

Currently iOS is the primary focus and WebGL only works on top of this technology.
Other platforms will follow later.

Great news,
It also sounds like we hav to brace ourselves for a chaotic 1st quater bugs on both the webGL and Ios side of things. Perhaps if y

Can you clarify that statement a bit? 64-bit precision for a particular set of APIs?

This feature request (some support for solving floating point precision problems) has absolutely nothing to do with 64 bit CPU architectures…

I hope so, but it is clear that Unity will not give us C++ compile option, nor 64 bit floating point precision, that is a shame but let they continue to publish the wonderfull 64 bit iOS support…

What you’re after is double precision floating point numbers, which is something I asked about at Unite Australia and they said it is being looked into because it is a problem for larger games and things like flightsims and GIS applications.

” We also partnered with Prime31 plugin developers to upgrade the most popular plugins for IL2CPP and 64-bit”

Does this mean that every plugin won’t have just to be recompiled with 64bit support but also modified to support IL2CPP?
Or it is just to ensure that there are no issue on IL2CPP side of code?

No, all plugins will not need to be modified to support IL2CPP. Some will need to be modified, no doubt, but most won’t. We’re aiming to match the behavior of Mono as much as possible. This work was done to ensure that we did not have problems on the IL2CPP side. Specifically, we wanted to confirm that p/invoke and marshaling worked well in IL2CPP, among other things.

IL2CPP always has code-stripping enabled, to reduce code size; this might mean that types that are not in the compilation, might need to be manually added.

What does this mean? Can you give an example? How do you add types manually?


Stripping is an option with iOS/Mono builds in Unity, but it will always occur with IL2CPP. Types can be manually added by using an XML file. You can find more details in the Unity docs here.

Yes, IL2CPP supports .NET threads now. Note that threads are not supported with WebGL, since browsers don’t support threads in JS yet. However, .NET threads do work via IL2CPP on iOS.

How does the C#/Mono upgrade fit into this?

“Until June 1, 2015 the Mono scripting backend can be used to publish 32-bit updates to existing apps on the iOS App Store”

Does this mean we shouldn’t expect to see the Mono upgrade until after June 1, 2015?

I don’t have an exact date for you, but a .Net/Mono upgrade will not happen until IL2CPP matures and has been deployed to all the platforms that require it.

Limited Unity 5 Pro WebGL update for Unity 4 Pro license owners would be nice solution. I need only export my projects to WebGL, I don’t need any Unity 5 Pro new functionality ;/

Well, as Unity 5 Free “should” have WebGL export I don’t see the need to backport it to 4.6.x – just use the free version as you say you don’t require the Pro features anyway…


In the comment above I have assumed that Unity 5 Free will have WebGL export – would I be right in that assumption? The only people losing out would be 4.6.x Pro users not willing to upgrade… Is that correct?

Comments are closed.