Unity has really dropped the ball with I2CPP and 64bit support

Am I alone in thinking Unity has really dropped the ball here? It's now nearly a month that I've had my latest game ready to submit to Apple but Can't because it still doesn't work with the IL2CPP build. It actually now builds ok and runs on the device but now I've discovered yet another thing that works on Mono but not IL2CPP. Last time it was encryption, now it's WWW not working properly.

I know the guys are working hard to get this all working but my gripe is why wait until after the Apple deadline to still be thrashing at it. In very real terms I've now lost a month of income from a new game that I can't release.

Also I don't think the defence that Apple set the date is a defence as we have been arguing for a 64 bit version of Unity for the last couple of years.

So here I sit, creating another repo project to submit to get something as obvious as WWW fixed as soon as possible. I think the amount of pain we have gone through this last month is worth free copies of Unity5 Pro! If only for payment for all the bug testing we are doing for Unity.

Edit: in the hours since making project to reproduce the problem, I've discovered it's not a problem with WWW but MD5 hashing and the Cryptogrophy stuff. Bug Reported.

 

Couple of years? I've been saying 64-bit is the now, not the future, for a decade

They say the are quickly swatting IL2CPP bugs, and I believe them (because of the speed of bug fixing in general, and the speed they find some seemingly hard ones). But IL2CPP has an awful lot of issues, and they don't have infinite monkeys on the job.

I haven't got anything ready for iOS publishing yet "fortunately", but I feel the frustration of everyone trying to release games right now. Things like that (and cost!) keep this semi-hobbyist from buying mobile Pro.

 

In the meanwhile, have you checked for some handwritten MD5 c# algorithms?

 

Unity is a complex beast and no, they didn't wait until after the apple deadline. They've been working on it constantly since 2014. Unity is a beast though, and bugs do crop up.

Also, there is nothing constructive about this thread. It's just having a moan, even though the fixes are coming out weekly. I don't see the point since it will not change how quickly the bug fixes arrive, or change anything. Or create world peace.

 

64-bit iOS is a lot newer, and something different to a 64-bit editor. I don't think Unity were waiting for a month after the deadline.

 

The iOS 64 bit and metal stuff has been many months in development with all hands on deck to try and get it finished in time for Apple's fairly sudden deadline. It's been worked on in Alpha and Beta groups, and is a top priority for Unity.

To make older users happy, Unity have had to backport this from 5 to 4 at the same time, so people don't feel short-changed and are happy with 4. This is pretty hard work I'd say, keeping it going for two different versions of Unity code base.

MD5 hashing and the Cryptogrophy stuff is pretty rare for games, and a total niche case too I suspect so no wonder it's slipped through. Still, the OP posted a bug report today (I assume) so they'll have something to work with...

Shame it wasn't reported sooner.

 

It was reported sooner, I saw references to it quite some time ago and just today it was announced that a fix is forthcoming:
http://forum.unity3d.com/threads/4-6-ios-64-bit-beta.290551/page-16#post-1976533

I monitor the iOS / IL2CPP related threads pretty heavily to watch for anyone having issues with my asset as I know there are some things not yet implemented in IL2CPP which cause it to break in some circumstances (affects both iOS 64-bit and WebGL).

That being said, I don't necessarily agree that MD5 / Cryptography are edge cases. If they really are rarely used then folks might want to rethink strategy. Hashing especially is a good starting point for signing and verification of data between a remote server and your app to try to protect against injection of bad data (such as someone trying to trick their copy of the game into thinking they purchased IAP that they really didn't). Evidently people aren't employing these strategies much.

Edit: Though I should note that MD5 is more widely used for verifying data integrity and when it comes to signing / verification, the various SHA-X algorithms (such as SHA-256) are generally used.

 

I don't think they are employing these strategies much

 

Or strategies at all

If anybody wants to start a thread on shoddy security, please do. I think a lot of people would love the opportunity to vent!

Yeah, I still think MD5+file size+date should be sufficient to tell if the file you have locally is different from one a server offers you. The only worry is a MITM style attack, which should be avoidable through other means.

SHA variants (I think the current is KECCAK or something like that, up to at least 512 bits) are part of a decent password hashing scheme, but depending on speed it could replace MD5 for files. It might be the case that file I/O is still the bottleneck. I haven't run tests on the latest algorithms, but if IL2CPP can't produce reliable code there isn't much point :/

 

Right, just depends on what implementation you are using. In .NET using RSA (RSACryptoServiceProvider) to Sign / Verify for instance uses SHA256 by default, though you can use SHA512 (not available on all platforms), or MD5 or whatever. However, the problem I have with their implementation is it is a magic string approach (you pass the string name of the algorithm into the sign / verify methods). I actually write an RSA Encryption library for Silverlight and Windows Phone 7 when Microsoft weren't providing it. It was compatible with Microsoft's implementation, and usage was nearly identical with the exception of signing and verification which allowed you to create a hash provider and supply that instance to the sign / verify methods which eliminated the magic string requirement.

 

Nothing constructive and just having a moan?! I'm sure you would feel different if it were you sitting on a game you can't publish for 3 weeks. As for cryptography being an edge case, are you trying to tell me all you professional developers don't use any kind of security between your games and any back side servers? I use it for all comms to my servers. Even though MD5 isn't great, it's sure better than nothing, and fast for the job i need it to do.

 

Here is one more people who got a shipping crisis with IL2CPP.
I totally agreed with arkon.

 

A 64-bit editor has nothing whatsoever to do with 64-bit code for iOS. Unity has been able to publish 64-bit builds for years, but they needed a new technology (IL2CPP) to be able to publish 64-bit code for iOS. It's self-evident that a new technology wouldn't be as mature. (Though, for the record, I submitted a game published with IL2CPP without any problems.)

They didn't do that at all; this was in progress before Apple sprung the deadline, and they pushed pretty hard to get it done. Encountering bugs is going to be frustrating, yes, but making stuff up like this isn't helping anyone.

--Eric

 

Making stuff up like what? I own Pro, and pro IOS and have been unable to publish a game to IOS for the last 24 days now. You say Unity has been able to publish 64bit builds for years, so how exactly do I do that without switching on IL2CPP? Because its all working fine on Mono builds. So a Mono 64 bit build would be great. Am I missing some easy way to publish without using IL2CPP?

 

While I sympathise (we've been hamstrung ourselves and had to wait between 4.6.1 and 4.6.3 to be able to update), I think you're looking at a forest fire when there's just a few smouldering bushes.

Building to 64bit desktop isn't new, but it's a different story building to 64bit mobile - there were no 64bit mobiles until the 5S in late 2013, and it was 6 months later UT first mentioned IL2CPP ... which was for Unity 5, not Unity 4. It required a complete re-design of the compiler so they can support *all* platforms without having hacks for each, which would only get harder to support over time (and consequently we'd be moaning all the more).

Apple's announcement forced them to shoe-horn IL2CPP into Unity 4.x, which is where we are today. Sure it's got bugs, but the fact it exists at all is pretty remarkable, and the issues are getting more marginal with every patch release.

We're working on a 3rd party job at the moment which is nearly finished, and our final payment is dependent on submission. So yes, same boat, but dispiriting the guys trying to fix and improve things isn't going to make them more efficient at it. Props to em for getting this far so quickly.

 

It'd be great if you had time to expand on this. I feel I have lots to learn on this subject.

 

The stuff that you wrote that I quoted. It serves no purpose to do that; it's better if you express frustration in a more productive way. Please keep to the facts.

64 bit builds for the desktop. 64-bit builds have nothing to do with a 64-bit editor; you're confusing two separate things. You can't build for 64-bit iOS without IL2CPP.

That's not going to happen. IL2CPP is the way forward, for all platforms eventually.

--Eric

 

Unity should have supported iOS 64bit with Mono first.
If so, all 32bit unity games could be converted 64bit SMOOTHLY.

After that, unity can support IL2CPP selectively
for the people who want more performance.

This is definitely wrong decision of unity.

 

I agree, this route they choose wasn't at all smooth.

 

Even if it sounds like a simple thing, it is actually very complicated, especially because Unity doesn't own a license for newer Mono versions that support 64bit as far as I know. One of the main reasons why we don't have a newer Mono version in Unity is because of the licensing. It would have been a very expensive temporary solution, that would have required quite some engineering time for Unity most likely and as such would also have been something new with its own bugs.

I understand the frustration. But I am not sure whether Mono 64bit would have been a better solution.

 

That's the bit that makes me nervous. AOT on all platforms :/

 

That's exactly the part that makes me happy, because the coders are forced to avoid the magical reflection based solutions that are often just workarounds for bad code design. I can only think of a handful of use cases where reflection is really needed, or more precisely the parts of reflection that can't be used with AOT. One of them is certainly (de)serialization. Dustin, I completely understand what you mean!

 

True, I was being more facetious than anything. AOT has some limitations. We will probably never see things like dynamic and it can cause some headaches with generic interfaces, etc but the benefits far outweigh the drawbacks and even reflection (mostly) works fine as long as the runtime knows how to construct the objects you're reflecting which mostly just requires the compiler to have seen the constructors.

 

It's nightmare. How many time have you build with IL2CPP??
It spends 4x~10x more times than mono.
It breaks workflow.
It breaks code-build-test loops.

There are many tasks that should be tested in the mobile device.
ex) plugin. gyro-based game.

 

It's new.
It is being improved.

 

Unfortunately though it will always be slower as its a two step process... Compiling the code to IL and then the IL to CPP.

In fairness it was more likely the Eula and support agreement for pro licensees that required the backport for 4.x.

That being said, I saw a comment about infinite monkeys and one in another thread saying Unity are concentrating on 5.x. I can tell you that 4.6 has been getting more fixes by quite a few, especially around il2cpp and faster than 5.x. It definitely is a priority.

Also as someone who has experience working on both large and small teams, throwing more developers at any given task does not always help. 4x developers does not equal a 4x reduction in development time, so while it is unfortunate that they weren't able to get IL2CPP into a super stable state prior to the deadline, I'm sure Unity are allocating their resources in the most efficient manner and pushing the feature as fast as they can.

 

That's out of questions and will certainly stay, even though there might be improvements to the way it is made at the moment. I don't know whether Unity has some kind of incremental compilation or compilation in a background thread on the radar, but there is definitely a lot of potential in many areas still. The really difficult aspect for me personally is that it still feels dangerous to switch to il2cpp and I fear something might not work as it should. At the moment I create more builds than usual, just to be sure il2cpp works properly. Once it is more mature, that feeling won't be there anymore and the increased build time won't hurt me as much anymore. As I said, it is new, it is being improved.

 

I hope they consider Clang/LLVM for part of the process eventually, but it's probably a huge task to get it ported to that. Both Clang and the general Mono compile time improvements were like a computer upgrade for me, so losing that makes IL2CPP a little less attractive. It's a good thing they aren't unleashing it on every architecture yet, and keep working on improvements. Even though it's a two-step process it could still be lightning fast with some optimisation

 

It's longer, for sure, though not nearly 10X longer, at least in my case. But it didn't bother me that much, because even before IL2CPP I always used UnityRemote for most of the development, so I never needed to make lots of builds. I do know they're actively working on speeding things up. The main complaint I had is that the binary is quite a bit larger (even accounting for universal builds), but they're working on that too.

That wasn't an option, because of the licensing.

That's wrong, since IL2CPP is an entirely different process. Having 64-bit with Mono would have done nothing to smooth the transition. Any issues are with IL2CPP, not 64-bit per se; IL2CPP produces 32-bit code as well.

--Eric

 

I've just benchmarked my project, and it's 4.85x slower on the unity build and then 4x slower on the Xcode side.
my build time has one from 52 Seconds to 238 seconds, so all up 4.5x slower.

I know this isn't too much of a bother during the main bulk of development time, but it's been very frustrating for the last 3 weeks, having to constantly edit / build / deploy to try experiments to get around all the things that didn't work.
There are still a few things that aren't right with the editor also, but I haven't the time to keep sending in repo projects to get them fixed. Current biggies are the editor game window nearly halving frame rate if you have 3 inspector windows open, and the NGUI plugin doing something strange with sprites missing until you run the game.

I know the Unity team on this are working hard to fix this all, but it's no consolation when I've now lost a months of income, plus lost a month on the next project.

 

That's definitely wrong. You are out of focus.
I know that IL2CPP is not just 64bit.
But there is NO OPTION for iOS 64bit publishing without IL2CPP.
Also, iOS 32bit only submit is rejected.
Can you realized the situation now? IL2CPP breaks whole iOS publishing.

The problem like increased build time is subsidiary
Unity should realized their own position.
Unity becames the platform and platform should be stable.

It looks like many persons are just hobbist in this thread.
They just want to say "IL2CPP is great technology. It bring us to shining future. Praise IL2CPP"
IL2CPP shows that Unity has great platform risk.
This can't be accepted in professional area,

 

No, what I wrote is correct.

I never said there was.

Only for new apps (until June).

It works for me and other people.

It's as stable as they can make it. If you found any bugs, submit them with a repro project.

You're incorrect. IL2CPP is still a work in progress since it's quite new, but it is the future. http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-in-unity/ What exactly do you expect them to do that they're not already doing?

--Eric

 

So you're just blowing off steam, which doesn't actually help anyone, but OK. It wasn't a wrong decision, by the way, and even if it was, throwing a tantrum doesn't motivate anyone. Read this link: http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-in-unity/

--Eric

 

Yes it definitely sucks when there are show-stopping bugs. Unity has had a few times in the past where things got dangerous like the 3.3.1 TOS Apple moment before (the flash moment), Unity was ready to go C++ then. Because it is their business, Unity will do what is necessary and they are fixing things rapidly.

Having the engine export out to any format of C++ via IL2CPP (one day I'd still like to write game scripts in C++) or other is the preferable move forward though to help prevent licensing issues like with Mono and possible platform terms like disallowing Flash previously with Apple. It is the safer long term move that is worth a shorter term delay as it is a deeper dive with bigger benefits. Right now there is a little turbulence.

I'd say overall, yes 64 bit ios player should have started earlier as with the WebGL/WebPlayer PPAPI issue/Chrome. Unity hopefully will be a watchdog on Apple future changes and jump on it next time as the main focus, however the 64 bit change is a one time massive change that does take time. Because it is so big, Apple did do something drastic, another good reason Unity should control its own destiny in C++ in final build exports at least, which they are doing.

My only issue with the situation is that 2 days before Feb 1st, Unity released 4.6.2 IL2CPP version, while maybe working for some, was not a good solid release. Because they put out that build and made it seem like everything was all set, developers took some heat as projects got delayed, time was wasted. I'd have appreciated it if they just would have said it was good for some but many will still be sidelined as they work on it and they are doing their best. I have a client game and company game that are both new that I need to get out the door. So I am speaking from a point of feeling the heat as well.

Hopefully IL2CPP bugs are coming together. Side note, hashing, encryption or compression (some of my bugs) are very common in game development with any in-apps, server apis, file comparisons, secure profiles etc. So these aren't really edge cases and should be part of the testing, the immense pressure has also probably made it hard to setup all of the support around it. They'll get there and they always do.

Unity so far is really knocking out bugs fast, and the 4 I have reported were all fixed and I am waiting on 4.6.3p2, a couple builds away. In the meantime I am shipping on Android and working on other games. Everything with Unity development and other platforms are still fully available and you shouldn't let a slight ripple in the engine team stop you from making games. We have an awesome engine team (Unity) and when developing games there can be delays in all departments of tech. Since IL2CPP is also used on Unity 5 and WebGL export, this developer pressure testing will be good for those platforms, even though there is a short term delay and cost.