Apple iOS 64-bit support in Unity
Technology and hardware moves fast these days! Many of you will have seen by now the announcement that Apple made to developers on October 20.
Starting February 1, 2015, new iOS apps uploaded to the App Store must include 64-bit support and be built with the iOS 8 SDK, included in Xcode 6 or later. 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 this mean for you mobile developers? Starting in February, your newly released games (and other apps) will need to take advantage of iOS 8 SDK and the new 64-bit ARM chips in newer iOS devices.
The good news is that we already support iOS 8 and have been hard at work on our 64-bit iOS solution for some months. The solution is IL2CPP.
What is IL2CPP?
Most of you will know that we’ve been developing our own runtime solution, IL2CPP, for quite a while now. It allows a range of flexibility for developers and internally here at Unity. We’re expecting big increases in performance experienced by end users as well. In short, we’re very excited about it.
IL2CPP came about when we were investigating how to approach WebGL while we were also researching new ways to make continued support for various platforms more efficient. The runtime combines an ahead of time compiler with a virtual machine to convert assemblies to C++ while leveraging standard platform C++ compilers to produce native binaries. The result are games and apps that run at native speeds. It allows us to push new core features to all of our supported platforms at the same time for a much more efficient schedule of updates. For a complete rundown of the technology, please see our previous blog post “The Future of Scripting in Unity”.
We’ve already seen tremendous results in WebGL and are expecting big increases in performance across all of Unity’s supported platforms, including iOS, which is already in development.
When can I get my hands on the tech?
IL2CPP is already being used for WebGL and if you’ve seen any of the Unity-authored WebGL demos, you’ve seen it in action. Hot on WebGL’s heels is iOS. In the next few weeks, first Unity 5 based alpha builds of the iOS ARM64 preview using IL2CPP are going to be released to closed alpha testing group. Shortly after, it will be made available to our closed beta groups.
Once we’ve had a round of intense and focused testing, we’ll roll the beta preview out to the pre-order beta group. The timeline for that completely depends on how that initial round of testing goes. We think it’s reasonable to plan a beta for pre-order customers and subscribers for January 2015.
The official release of iOS ARM 64-bit feature preview in Unity 5 series depends on the Unity 5 launch schedule, so we can’t say much about a specific timeline.The preview can be expected to run games with scripting of medium complexity.
[UPDATE] The term “medium complexity” was a bit too ambiguous. To clarify, we are confident that the majority of iOS projects will work with little or no modifications. There is a chance that some infrequently used functionality is currently incomplete or contains bugs. These issues will be addressed and resolved quickly. We are currently testing a range of iOS games and will keep you updated on progress leading up to the February deadline.
What about 4.6?
We have begun work on supporting that version as well. Unity 4.6 recently entered Release Candidate cycle, so it is going to be out really soon now. The plan right now is to ship beta preview of iOS ARM64-bit feature based on Unity 4.6.x before the February deadline. We’re very aware of people having nearly completed games on Unity 4.x and we’re working hard to deliver a solid solution for Unity 4.6. Due to heavy code reuse, the preview of iOS ARM64-bit in Unity 4.6.x is expected to be on par with Unity 5 implementation: games with scripting of medium complexity will be able to run.
What about earlier than 4.6?
We will not add iOS 64-bit support for versions of Unity prior to Unity 4.6. Bringing this technology to older versions of Unity is getting exponentially more difficult due to large differences in codebase. In order to ship iOS 64-bit apps support as soon as possible we chose to focus only on latest Unity 4.x version – 4.6. If you have unreleased games currently in production that are still being developed in an older Unity 4.x version, you will need to upgrade either to Unity 4.6.x or Unity 5 in order to publish it on the iOS App Store. Please note you can update 32 bit apps already released on the iOS App Store with any Unity 4.x or Unity 5 version. There is no requirement of 64-bit for games and apps already published on iOS App Store before the February deadline.
Will I be able to ship my game on time?
Your success is our entire reason for being, so we’re pushing hard to get everything ready on time. The best approach to be ready is to start testing early, so we encourage you to get a public preview in January and start upgrading.
If you’re working on something very complex, it will likely take a little while longer to have everything in place but you should be good to go if you’re targeting April.
We’re really, really happy with where IL2CPP is already and where it’s going!
It’s going to make a big difference not only to performance in games, but also in how quickly we can develop and share new features to all of you in the community.
Summary Q&A
What does this mean for my existing apps?
Nothing in the short term. Apple will not be removing any apps that don’t comply with 64-bit that have been uploaded and made available for sale before February 1, 2015.
What if I need to update my apps after the deadline?
The current word from Apple is that existing games and apps will not need to include support for iOS 8 and 64-bit architecture at the February 1, 2015 deadline. It’s important to note that while Apple has confirmed this, there is still the possibility that all apps need to support iOS 8 and 64-bit at a separate date down the line.
What if I’m planning to release after Feb 1?
Then you’ll need to comply with Apple’s demands. New apps will need to support iOS 8 and 64-bit architecture to ensure they’re making the most out of new iOS devices. For assistance from Apple developer support, visit https://developer.apple.com/contact/.
iOS dev
November 21, 2014 at 1:28 am /
I’m sure you can appreciate that your iOS users are left feeling frustrated at the moment between Apple’s change of terms and a bit of an unknown Unity roadmap. There’s plenty of discussion going on in other places about this and it’s difficult to piece together the information Unity have released to know exactly what’s going on.
For all of the updates and new stuff coming, it still feels like Unity has dropped the ball a bit. We’re stuck with old C#, old .Net, old and not very nice MonoDevelop, and some old bugs that never seem to get attention. Not much of the information Unity is releasing is putting developers’ minds at ease with regards to language features, framework support, and development environments. Bradley’s comments are right – changes and new features in Xamarin/Mono, Microsoft opening up .Net and releasing new compilers and updating their tools like Visual Studio are all great, but not really knowing much about how Unity are planning to support these things is not. Saying that parts of the language or framework is hard to make work with your new compiler toolchain and may or may not be supported is hard to hear. It would be awesome to hear relax, C# 5/6, .Net 4.5, 64bit, snappy GC, and tight integration with a new Xamarin/Visual Studio are all on the way, but Unity responses are things like ‘.Net profile upgrade when IL2CPP is in place’, ‘we can make use of [Microsoft opening up compiler/GC] where it makes sense’, ‘long term goal is to support at least the same functionality as Unity on iOS with mono today’, or ‘read our other blog posts’.
Can you say anything more at all about Unity supporting more of these modern features? I realise it’s all very hard stuff and that you might not even know yourselves at the moment but that’s part of the problem at the user end, especially given the way companies like Apple change the playing field on everyone and you’re put under pressure to release more information.
Jonathan Chambers
November 21, 2014 at 1:57 am /
I can understand your frustration on some topics, but understand it’s hard for us to make promises with so many unknowns. The long term plan is for Unity to be part of the modern .Net ecosystem. That includes most of the things you mentioned (latest versions of C#, .Net Core). We’ve explained in the past how IL2CPP helps us get there.
We plan on making use of the pieces of .Net that Microsoft is open sourcing. The .Net Core (which does not exist yet) is very exciting. An open source JIT/GC/Runtime from MS looks like it will be available next year some time http://blogs.msdn.com/b/dotnet/archive/2014/11/20/one-week-of-open-source.aspx However, I don’t know when it will be ported and stable on multiple platforms.
In summary, a lot of awesome things are happening in the .Net ecosystem. We want to take full advantage of every bit that we can. IL2CPP is a concrete and definitive piece of technology we need for that to happen. It is a component of our evolving vision for .Net within Unity, and is not exclusionary of any other efforts or technology.
iOS dev
November 21, 2014 at 3:43 am /
Thanks for your reply, Jonathan. Being caught in 64bit limbo on iOS isn’t going to be fun, but I can appreciate it’s a consequence of a lot of complex stuff as the Unity platform moves towards its future tech. I hope everything falls into place nicely and we get all the shiny dev toys to play with soon.
Lior Tal
November 21, 2014 at 12:40 am /
I am wondering why IL2CPP is the solution to this particular issue?
From my understanding, the AOT compiler today generates native code from user scripts so (1) this would need to change to emit 64-bit code and (2) to support ARM 64-bit, you would have to create a 64-bit iOS player.
I understand that IL2CPP can solve the first one, but how does it address the 2nd one ? or is that not the big issue at hand ?
Mantas Puida
November 21, 2014 at 12:57 am /
(1) we already covered in our previous blog post on Unity scripting future (http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-in-unity/).
(2) is lesser issue as compared to (1), because Unity runtime has been already ported to number of 64 bit platforms. iOS 64 bit player is running fine.
Bradley
November 21, 2014 at 12:13 am /
With the recent announcements from Microsoft regarding .net going open-source, I’m wondering if IL2CPP is going to fracture Unity from the mainline of c# .net and mono even further. I use a ton of Reflection in my code and I want that code to remain as multi-platform as possible. It sounds like IL2CPP is going to cut me out due to heavy use of reflection and generics, at a time when c# and the rest of .net is actually going to become LESS fractured for everything else. I realize there’s a very short-term deadline coming in the form of Apple’s arbitrary EOL date for 32bit. But you-all have me a little worried about the long-term. I think you really need to address your relationship to mono and the .net platform in the long term. It looks like you are headed down a path where more and more c# source-code must be configured for Unity or for .net exclusive to one-another. And that’s really bad if it’s where we are headed. Please refine and explain the apparent overall direction. It’s murky at best. And many of us have a lot of tech (intellectual property) to build and maintain based on your overall direction. It’s important.
Jonathan Chambers
November 21, 2014 at 12:28 am /
Please re-read our previous post on the future of scripting. http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-in-unity/
The open sourcing of .Net is a great step for Unity to reintegrate into the .Net ecosystem. .Net Core (the open source .Net version announced) is a smaller API that is designed to be portable across platforms. An open source version of the JIT/GC/Runtime has been announced by Microsoft, and we can make use of that where it makes sense.
IL2CPP still makes sense a very portable, performant, and customizable AOT (ahead of time) runtime.
Breyer
November 20, 2014 at 11:44 pm /
“The plan right now is to ship beta preview of iOS ARM64-bit feature based on Unity 4.6.x before the February deadline.” sounds like challenge accepted! ;P BTW this mean that after release IL2CPP for iOS 64bit there will no obstacle to update ancient Mono implementation? Or you have to release IL2CPP for console and then update Mono?
Jonathan Chambers
November 21, 2014 at 12:07 am /
This was addressed in previous IL2CPP related blog posts about the future of scripting in Unity.
http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-in-unity/
The plan is that a number of platforms will be migrated to IL2CPP. Concurrently work is being done for a .Net profile upgrade, and can be rolled out when IL2CPP is in place.
Walt
November 20, 2014 at 11:20 pm /
What is the source claiming that updates to existing apps don’t need to be 64-bit compatible? Everything else I’ve found online claims the opposite, such as this article on 9to5mac: http://goo.gl/ITl7eI “From 1st February 2015, newly-submitted apps and updates must be built against Apple’s iOS 8 SDK.”
Mantas Puida
November 20, 2014 at 11:31 pm /
We reached Apple for this and they confirmed it couple of times. Though in more distant future this requirement might be applied for existing app updates too.
Alex
November 21, 2014 at 12:12 am /
It sounds like one of you is misreading the quote from Apple. It sounds like Apple is saying if you have a 32 bit app up on the store on Feb 15th that’s fine you don’t have to do anything it will remain for sale. But if you update that app after Feb 15th that update will have to include 64 bit support.
Mantas Puida
November 21, 2014 at 1:08 am /
Our statement is based on lengthy discussion with Apple people, rather than just interpretation of single quote.
Stuart Leslie
November 21, 2014 at 1:24 am /
Are you able to explain why Apple is telling other developers the opposite then? That updates to existing apps will also need to be 64 bit.
One user posted their reply from Apple on the developer forums (https://devforums.apple.com/message/1062587)
“Although the article does not state specifically for app updates, an update to an existing app would still carry these same requirements.”
A*
November 20, 2014 at 11:09 pm /
Unity Team, This is Highly Appreciated…
I was worried when I read the blog post title, but when I read that 4.6 will be supported for 64-bit, ( as well as, already supporting iPhone 6 and 6+) I was relieved.
By the way, 4.6 flipped horizontally is 6.4 ~~ 64 bit ;)
iBrent
November 20, 2014 at 10:34 pm /
Can you define: “games with scripting of medium complexity will be able to run.” What makes a game highly complex? Little help?
Mantas Puida
November 20, 2014 at 11:13 pm /
There are few things, which make ahead of time (AOT) compilation and implementation of .NET runtime more complicated: mixing .NET value types with generics, use of Reflection API and some more rarely used .NET APIs.
Jonathan Chambers
November 20, 2014 at 11:56 pm /
The long term goal is to support at least the same functionality as Unity on iOS with mono today. Near term you may still encounter bugs or incomplete functionality, but we are rapidly working to improve.