Search Unity

Технологии и аппаратное обеспечение сегодня развиваются очень быстро! Многие из вас уже видели заявление Apple для разработчиков от 20 октября.

С 1 февраля 2015 года новые iOS-приложения, загружаемые в App Store, должны включать 64-битную поддержку, и будут собираться с iOS 8 SDK, включенной в Xcode 6 или более поздней версией. Чтобы обеспечить 64-бит в вашем проекте, мы рекомендуем использовать установку сборки по умолчанию Xcode “Standard architectures”, чтобы собрать один файл и с 32-битным, и 64-битным кодом. 

Итак, что же это значит для вас, разработчиков мобильных приложений? Начиная с февраля, выпускаемые вами игры (и другие приложения) должны будут использовать iOS 8 SDK и новые 64-разрядные ARM чипы в новых iOS устройствах.

Есть и хорошая новость —  мы уже поддерживаем iOS 8 и несколько месяцев трудимся над в созданием решения для 64-битной iOS. Это решение – IL2CPP.

Что такое IL2CPP?

Большинство из вас знают, что мы уже долгое время разрабатываем собственное runtime-решение, IL2CPP. Оно предоставляет больше гибкости как разработчикам, так и Unity. Мы ожидаем серьезное повышение производительности, которая так важна конечным пользователям. Вообщем, оно нам нравится.

IL2CPP возникла, когда мы думали над WebGL, исследуя новые способы сделать постоянную поддержку для различных платформ более эффективной. Runtime сочетает в себе компилятор с виртуальной машиной для преобразования сборки в C ++, используя при этом стандартные для платформы C++ компиляторы для создания бинарных файлов. В результате, игры и приложения работают с нативной скоростью. Это позволяет нам использовать новые основные особенности на всех поддерживаемых платформах, и, в то же время, с гораздо  более эффективным графиком обновлений. Чтобы познакомиться с технологией, пожалуйста, смотрите наш предыдущий пост в блоге «Будущее скриптинга в Unity».

Мы уже получили потрясающие результаты с WebGL, и ждём большое повышение производительности на всех поддерживаемых Unity платформах, в том числе – на iOS, и это уже разработке.

Когда я смогу её «пощупать»?

IL2CPP уже используется для WebGL, и, если вы видели какое-либо демо Unity по WebGL, вы видели его в действии. За WebGL идёт iOS. Через несколько недель первая Unity 5 альфа-сборка iOS ARM64 preview с использованием IL2CPP планируется к началу закрытого тестирования в альфа-группе. Вскоре после этого она будет доступна для наших закрытых групп бета-тестирования.

После этапа интенсивного и целенаправленного тестирования, мы выпустим бета-превью для бета-группы по предзаказу. Сроки выхода полностью зависят от первоначального этапа тестирования. Мы считаем, что разумно планировать выход беты для сделавших предзаказ и для подписчиков, на январь 2015.

Официальный релиз функции iOS ARM 64-бит в Unity 5 зависит от даты выхода Unity 5, поэтому мы не можем говорить о конкретной дате. Ожидается, что превью сможет запускать игры со скриптами средней сложности.

[UPDATE]  Термин “средней сложности” был слишком неоднозначен. Уточним: мы уверены, что большинство проектов для iOS будет работать с небольшими изменениями или практически без изменений. Есть вероятность того, что некоторые редко используемые функции в настоящее время недоработаны или содержат ошибки. Эти проблемы будут решены в кратчайшие сроки. Сейчас мы тестируем ряд iOS-игр, и будем держать вас в курсе того, как мы движемся к февральскому сроку.

А что насчет 4.6? 

Мы уже начали работу по поддержке этой версии. Unity 4.6 находится в цикле Release Candidatе, и выйдет очень скоро. Сейчас планируется выпустить бета-превью функции iOS ARM64-бит, основанной на Unity 4.6.x, до февраля. Мы очень хорошо понимаем людей, имеющих почти законченные игры на Unity 4.x, и мы прилагаем все усилия, чтобы выпустить стабильное решение для Unity 4.6. Из-за переиспользования большого количества кода, превью iOS ARM64-бит в Unity 4.6.x ожидается на одном уровне с реализацией в Unity 5: вы сможете запускать игры со скриптами средней сложности.

А что насчет версий до 4.6? 

Мы не будем добавлять поддержку 64-битной iOS для версий до Unity 4.6. Использование этой технологии в более старых версиях Unity усложняется большими различиями в коде. Для того, чтобы максимально ускорить выход поддержки 64-битной iOS, мы решили сосредоточиться только на последней версии Unity из серии 4.x — Unity 4.6. Если у вас есть неизданные игры, которые находятся в стадии разработки в старой версии Unity 4.x, вам нужно будет обновить Unity до версии 4.6.x или до версии 5, чтобы опубликовать его на  iOS App Store. Обращаем ваше внимание на то, что вы можете обновить уже выпущенные 32-битные приложения в iOS App Store с любой версией Unity 4.x или Unity 5. Там нет никаких требований по поддержке 64-бит для игр и приложений, опубликованных в iOS App Store до февраля 2015 года.

Смогу ли я отправить свою игру во-время?

Ваш успех  — это единственная причина нашего существования, поэтому мы делаем всё, чтобы успеть всё сделать во-время. Вам мы тоже рекомендуем начать тестирование как можно раньше, получить Public Preview в январе, и начать апгрейд.

Если вы работаете над чем-то очень сложным, то вам, вероятно, потребуется больше времени, чтобы закончить работу, но вы должны делать это быстро, если ориентируетесь на апрель.

Мы очень, очень рады тому, что уже сделано в IL2CPP и как он развивается!

Он не только повысит производительность в играх, но ускорит разработку новых фичей, которыми мы поделимся с нашим сообществом.

Вопросы и ответы

Что это значит для моих приложений, которые уже вышли?

В ближайшем будущем – ничего. Apple не будет удалять приложения, которые не поддерживают 64-бит, если они были загружены и доступны для продажи до 1 февраля 2015.

 Что делать, если мне нужно обновить свои приложения после истечения срока?

Сейчас Apple говорит, что существующим играм и приложениям не понадобится поддержка iOS 8 и 64-битной архитектуры на 1 февраля 2015 года. Но важно отметить, что, хотя Apple подтверждает это, есть вероятность того, что в какой-то момент все приложения должны будут поддерживать iOS 8 и 64-бит.

Что делать, если я планирую выход после 1 февраля?

Тогда вы должны будете выполнить требования Apple. Новые приложения должны поддерживать iOS 8 и 64-разрядную архитектуру, чтобы обеспечить максимальную поддержку новых iOS устройств. Для получения помощи от службы поддержки разработчиков Apple, посетите https://developer.apple.com/contact/.

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?

Cheers,
Daniel

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:
http://www.theverge.com/2013/9/12/4722470/iphone-5s-64-bit-processor-is-a-bigger-deal-than-you-think

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.

This.

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.

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

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

«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: http://goo.gl/ITl7eI «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.

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

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’: https://developer.apple.com/news/?id=10202014a

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

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.