Search 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

50 replies on “Apple iOS 64-bit support in Unity”

Hi there,

thanks to the Unity team for rushing on to deliver a working 4.6/5.0 version with iOS 64bit compatibility!! This is highly appreciated.

Still, does anyone know when exactly that “updates-in-32bit-are-still-ok-because-you-already-have-an-app-rule” (until 1st June I know) actually starts to count?
Does the previous 32bit app need to be actually available in the store, or would that rule already count, if the app was just sent for approval??
My question is: Can I send an unfinished 32bit app to Apple now, then NOT release it to the store (if it was approved at all) and push out an update (still 32bit) between 1st Feb and 1st June?


I tried to upload my binary about two days ago, anyway, it won’t except my archive. The error message says that 64bit is missing.

Can someone please confirm these dates? somewhere something went wrong, either apple has made a mistake and i need to contact them or i need to wait until the end of the month for unity upgrade (which has 64bit support).

This is a very frustrating situation for us because we planned on uploading our binary this week. Can someone please confirm the 64bit support for the end of January?

again i am going to mention that Xcode tells me that my archive during validation process needs 64bit.

Ok so, i’ve been a noob.

It was just a warning and i didn’t realise that i could actually submit.

I can confirm that my 32bit was accepted by apple and is now waiting for review.

i apologise for the misunderstanding.

Rock on!

“We think it’s reasonable to plan a beta for pre-order customers and subscribers for January 2015.”

Does the current pre-order Beta for Unity 5 have iOS 64 bit support?

Apple emailed me today to say that app –updates– must meet the same 64-bit requirement, starting June 1, 2014. The big question… will Unity be ready by then?

Dear Developer,

As we announced in October, beginning 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.

If you have any questions, visit the Apple Developer Forums.

Best regards,
Apple Developer Technical Support

Yes. Unity 5.0 with 64 bit iOS support is being tested now; and 4.6 with 64 bit iOS support is being worked on. There should be a blog post with status update in a few days.

[…] forget that as we announced here, we plan to ship a beta preview of our iOS ARM64-bit feature based on Unity 4.6.x in January […]

As Apple say the existing 32-bit apps will work fine. … Does that alter plans at all to support Windows mobile as Unity and Marmalade amongst others do?

[…] forget that as we announced here, we plan to ship a beta preview of our iOS ARM64-bit feature based on Unity 4.6.x in January […]

Wow, that’s happening a lot faster than I expected (Thank you Apple ;-) ). Biggest issue I see here is the back-port to 4.6 since it wasn’t exactly built with IL2CPP in mind. I for one am cautiously optimistic given the timelines that are being talked about. Things sound a little rushed, but understandably so (Curse you Apple :-|). This reminds me the post concerning the new Apple TOS back in 2010 where you showed us what mono behaviour written in c++ will look like :-) (please change that name – MonoBehaviour – I don’t like it).

Well, all the best then.
Thanks team.

Apple released the 64 bit iPhone 5s more than a year ago. If they hadn’t announced the February 2015-deadline, I bet the Unity team would still be sitting in their a**es.

IL2CPP was in development for a long time too, just the focus was more on getting it to work, rather than applying it for iOS 64bit.

Nice to get a status update on this one and praise the lord that 4.6 will be supported as well!

On the technical side, I’m a bit confused though. Statements:
– The solution to a 64-bit iOS solution is IL2CPP
– IL2CPP will be used from Unity 5 onward, not in 4.6
– 4.6 will also support 64-bit iOS and share plenty of code with the 5 version

So IL2CPP isn’t actually the solution for the 64-bit but makes it easier to maintain / integrate than it was in 4.6?
Would be interesting to get an insight in how difficult this kind of change is for Unity to support.

We are working on back-porting IL2CPP to 4.6 for iOS. This is a non-trivial amount of work as the 4.6 and 5.0 code bases have diverged quite a bit already, but we realize that a lot of people depend on this and we are making good progress, so we expect to have everything working in 4.6 by the same timeframe we will be ready to ship it for 5.0.

That’s somewhat out of scope / unrelated for this blogpost and I honestly don’t know the answer right now, but I’ll see if the Editor team can answer that here.

One thing I don’t get is why Apple is so eager to move to 64 bit on IOS. Even on the desktop people have been reluctant to move over because the only advantage is addressing more than 4 Gb memory. I don’t know of any IOS program / game which will hit this limitation in the distant future, let alone now.

Ironical, the Verge promises an answer to that question here, but fails to deliver:

There is more to the transition than the bigger address space, the ISA is different, plus it stops them from having to maintain a 32-bit Objective-C runtime, since OS X only uses a 64-bit one. That runtime also uses tagged pointers for automatic reference counting on 64-bit architectures, which would not be practical on 32-bit, as it would eat up way too much address space.


As much as I’m not what you’d call an Apple fan, early transition to 64 bit tech actually makes sense thanks to the (vastly) increased address space. Yes, transitioning from 32 might be inconvenient for some, but it’s a logical step.

Thanks for sharing your plans.

I’m looking forward to seeing the performance improvments coming with IL2CPP.

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.

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

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.

Next to Jonathan’s comments, I also wanted make sure to address your concerns regarding integration of MonoDevelop and other code editors (most importantly VS / UnityVS). We have a roadmap and are working, which will deliver way better integration of code editors in the future; this will be much tighter integrated and an overall better experience. Expect a blogpost from Lukasz / Lucas about this at a later point in time.

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 ?

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.

Please re-read our previous post on the future of scripting.

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.

“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?

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: “From 1st February 2015, newly-submitted apps and updates must be built against Apple’s iOS 8 SDK.”

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.

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.

Our statement is based on lengthy discussion with Apple people, rather than just interpretation of single quote.

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 (

“Although the article does not state specifically for app updates, an update to an existing app would still carry these same requirements.”

Today I reached Apple dev relations person once again and got following confirmation:

Hi Mantas,

Updates to existing apps are not affected by 1 Feb deadline.

The wording in the announcement reads ‘new iOS apps’:

Hey Mantas! So we have an unreleased game.. Any idea if it’s ok to launch it on a few territories (like a soft launch), before Feb 1, and then update it and launch it worldwide after Feb 1 (with 32bit only)?

Apple’s submission process is automated and has been for some time now. As a result it WILL automatically reject any and all submissions that do not support 64 bit after February 1st or whenever Apple switch on that particular check.

This submission process takes no account. I repeat NO account of if the submission is an update or a new app. It simply doesn’t know the difference. So saying that existing app submissions will not need to be 64bit is wrong. Already the app uploader will give a very stern warning to you if you upload an update that isn’t 64 bit, which should prove my point quite aptly.

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 ;)

Can you define: “games with scripting of medium complexity will be able to run.” What makes a game highly complex? Little help?

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.

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.

Comments are closed.