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.
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.
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.
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.
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.
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.
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.