I know that we must use Il2cpp for final builds because its supports the 64-bit architecture. But I want to know from the other developers which one you prefer.
If possible I would love to stay with mono due a couple of things:
Mono provides almost the same behaviour between the Editor and the iOS device. You don’t have to worry with platform specific bugs.
The build size was so smaller. For my tests, even building with only one architecture the mono produces smaller sizes.
I don’t care much about scripting performance. Most of time I’m GPU bound… I would say that if you are CPU bound you are probably doing something wrong… or at least, something that can be optimized. (at least in most of the cases)
Build time increased
My iOS builds was much more stable than they are now. The apps that I worked normally have more than 99% of crash free sessions. With il2cpp they vary between 96% and 99%. It’s much better know after several Unity updates. But it’s not so stable like before. I’m talking about engine crashes like:
Matrix4x4.h line 304
UI::UIGeometryJob(UI::UIGeometryJobData*)
Bulk_UnityEngine_0.cpp line 11049
RectTransform_get_sizeDelta_m5054
Bulk_UnityEngine_0.cpp line 15846
Object_IsNativeObjectAlive_m7694
Bulk_Assembly-CSharp-firstpass_0.cpp line 4121
EcmaScriptIdentifier_IsReservedWord_m83
Runtime.cpp line 326
il2cpp::vm::Runtime::RaiseExecutionEngineExceptionIfMethodIsNotFound(MethodInfo const*)
LinkedList.h line 299
Coroutine::CleanupCoroutine(void*)
UIJobs.cpp line 26
UI:populate(UI::RenderableUIInstruction&, UI::UIInstruction const
Sure that some can not be il2cpp related, but my mono builds of the same project looks like to not have the same issues.
But don’ take me wrong. I know the limitations of mono and 64-bits and I understand why Unity moved to il2cpp.
For my stuff, I’ve found IL2CPP and Mono to have the same behavior by now (there were some issues early on). If you find something that doesn’t work as it should, report a bug.
That’s really not true at all. Also, certain devices may have underpowered GPUs, but you definitely can’t rely on things to stay like that.
Again, report a bug. IL2CPP isn’t going away, and Mono isn’t coming back, so the best thing to do is help make sure IL2CPP gets improved.
I’ll echo the sentiments of @Eric5h5 , please submit a bug report for any crash you see with IL2CPP or any difference in behavior from Mono. We really want to correct all of these issues. Although we don’t get to correct all of the bugs as quickly as we want to, we will investigate and correct any bugs you submit that we can.
The build size was so smaller. For my tests, even building with only one architecture the mono produces smaller sizes
Also, I’m wondering about the build size difference you see. I’m assuming this is a build for ARMv7 on both Mono and IL2CPP. Can you share details about how to computed the build size and what the actual size numbers are? For ARMv7 the IL2CPP build size should be significantly smaller because IL2CPP can use thumb instructions, but Mono cannot. If there is a case we’ve missed here where the build size is worse on IL2CPP, I would really like to correct it.
Build time increased
Build time is still much better on Mono than on IL2CPP. This is our largest area of active development now, so hopefully you should see improvements in future releases. Now we support incremental builds in Xcode (see this post), and we’ve have some changes committed this week to make incremental builds more robust.
Thanks for bringing these issues up! Let’s see if we can work things out to improve the situation.
Well, unless you stumble upon a bug, the differences are few and very specific.
That has improved a lot lately. I think they are comparable now.
Well… Draw calls are a CPU thing for example, so it’s not like CPU and GPU are completely independent. CPU is not purely code. In any case, I don’t see many people agreeing with "I don’t care about whatever performance*.
I’ll give you that one. The build times are a bit on the insane side.
There is a few others, but I unfortunately I don’t have much info about them. Only the stacktrace…
But these crashes are a good example of the differences between the Mono and IL2CPP. I’m not saying that they have different behaviours. What I’m trying to say is that you will face different bugs on them.
And I think that I did not make myself clear when I mentioned the scripting performance. It’s a great thing and I’m not frustrated about that. I was trying to say that this is not enough IMHO to beet the other issues that I’m facing right now. But I know that will get better with time.
The build sizes really improved in Unity 5.2.2. I think that my previous experiments could be wrong because it was prior Unity 5.2.2 and I was building with Append (as @JoshPeterson sad, this was improved in Unity 5.2.2 and Unity 5.2.3).
Thanks for submitting that bug report. If you end up with a reproducible case, please add it to the bug report, as that will help us to track down the cause. As it is though, we’ll keep that call stack in mind and determine if we see other similar issues occur.
Looks like we found a solution which can help you too.
We have some UI position calculations in LateUpdate() cycle. Once calculated, new positions and states (like fillAmount, color properties in sprites etc) are applied to UI transforms and components in LateUpdate() body immediately.
In this implementation, we catch a crash randomly in UI::UIGeometryJob
As far as I understand, unity UI thread already running when LateUpdate() executed and changing any UI transforms or components properties can change data which UI thread working with in his own thread
So our solution was as simple as possible - we move all UI property/positions applying to Update() cycle
Profit! Out app is not crashing anymore! I hope Unity will fix this bug in future releases, but this hint can save some hair on head 8)
I think not only LateUpdate() can cause these crashes, but also some late-executing methods too (e.g. OnPostRender), so try to avoid any UI components changing anywhere except Update()
Do you have a test case that you can use to reproduce this bug? If so, please submit a bug report and include it. That will really help us to correct the problem in a future release.