Vote here https://feedback.unity3d.com/suggestions/windows-standalone-with-scripting-backend-il2cpp
Please ![]()
was wondering why this isn’t anywhere on the road map, not even in research or development
is it because not many developers want this ?
Vote here https://feedback.unity3d.com/suggestions/windows-standalone-with-scripting-backend-il2cpp
Please ![]()
was wondering why this isn’t anywhere on the road map, not even in research or development
is it because not many developers want this ?
Probably because IL2CPP will make it not possible for you to load assemblies at runtime for mods etc. They did promise a Mono upgrade for the editor and standalones though.
isn’t the mono upgrade in the far off distant future
thought i remember one of the speakers at a Unite saying that they already had IL2CPP working on standalone but one needed to be on the platform they were building for
Im not really sure about that, maybe Unity thinks its better to quickly roll out IL2CPP to all platforms and give us the Mono upgrade faster than fix the problem with the need to be on the platform your building for.
Also microsoft recently acquired Xamarin which owns Mono so we might see the Mono upgrade come sooner since Unity and Microsoft are buddies.
remember hearing that somewhere too
wow! that’s forward thinking of them
i hope this doesn’t negatively effect the partnership
Well, there are a couple of reasons why standalone player is not a target for IL2CPP yet.
First of all, today you can build windows standalone player on any platform, be it windows editor, mac editor or even linux editor. You don’t need to have anything else than Unity installed (no SDKs, no compilers, nothing). With IL2CPP, you can actually only build windows standalone player on Windows, and you have to have Visual Studio + C++ compilers/SDK installed.
Secondly, standalone player is not a platform that prevents us from making the Mono upgrade, so naturally it comes as lower priority compared to the platforms that do prevent it. We want to first roll IL2CPP out to non-desktop platforms and make the only scripting backend available: that’s a prerequisite for upgrading Mono.
so it would be similar to the Windows Store IL2CPP process
do you know how many platforms are left before it
so upgrading Mono will happen before having a IL2CPP Windows standalone build option
Some of them don’t have support yet at all:
Wii U;
Samsung TV.
Some of them are in experimental phase right now - they’re not yet on par with the main scripting backend, but they’re being actively developed and improved as we speak:
Android;
Windows Store;
Xbox One;
Playstation 4;
Playstation Vita.
I can’t promise it, but it is likely.
@Tautvydas-Zilys Thank you ![]()
feel a lot better having a general idea of whats happening with IL2CPP
I’d like to hear what’s the current standing on IL2CPP for Windows standalone.
To the original response, I don’t quite understand the concern of not being able to compile IL2CPP content on other than target platforms, that’s hardly any kind of real issue for windows game developers.
All in all, I’m bit concerned that IL2CPP on Windows standalone isn’t even mentioned on the official roadmap, is it not planned at all? Or if it’s in some plans, would it be realistic to expect that to happen with Unity 2017?
It is in our plans. No ETA when, though.
With IL2CPP, you can actually only build windows standalone player on Windows, and you have to have Visual Studio + C++ compilers/SDK installed.
Are you saying this is somehow currently possible?
Are you saying this is somehow currently possible?
No, that limitation will be in place once we do introduce IL2CPP support for Windows Standalone.
As I understand it, Steam’s DRM wrapper doesn’t work with Unity games due to them being .NET applications. Would IL2CPP backend mean all Steamworks features should work?
Unity applications aren’t .NET applications. Sure, it has .NET components (like your scripts), but the engine and the executable itself was compiled from C++.
I don’t know why Steam DRM doesn’t work (and does it really not?).
Unity applications aren’t .NET applications. Sure, it has .NET components (like your scripts), but the engine and the executable itself was compiled from C++.
I don’t know why Steam DRM doesn’t work (and does it really not?).
Apparently not: https://steamworks.github.io/faq/
From the FAQ: "
Does the Steam DRM wrapper work with Unity or XNA/Monogame?
No it doesn’t. Unfortunately the Steam DRM wrapper does not play well with .NET applications such as Unity and your application will likely fail to start if it’s wrapped. Even if it does succeed and work for you it will often fail on other computers."
I’ve not used it so I can’t speak from experience, but this seems to be a common thing I’m seeing when looking into it
I’m curious though, what is the real issue that prevents this feature to be implemented yet?
According to the old talk on 2015:

Lucas Meijer & Ralph Hauwert (Unity Technologies) talk about Unity's scripting backend, IL2CPP. Read also: http://blogs.unity3d.com/2015/05/06/an-introductio...
Unity staff has been running Windows standalone IL2CPP a long time already (video is from 2015) and only reason mentioned on the video is that IL2CPP windows standalone toolchain could only run on windows so cross-platform compiling wouldn’t work.
I really struggle to understand that reason though as every team who dev a game for windows will have a computer that runs windows.
The issue with cross-compilation is that a number of users compile standalone players for macOS or Linux from Windows (which works fine with the Mono scripting backend). That won’t work with IL2CPP. Still, that is not really a big technical hurdle, we can just document the restriction.
The bigger reason why IL2CPP is not supported on desktop platforms is lack of time to make it production quality and support it. As with anything else, there are trade-offs, and we’ve simply not put the resources on this feature yet, as they have been used elsewhere.
The bigger reason why IL2CPP is not supported on desktop platforms is lack of time to make it production quality and support it. As with anything else, there are trade-offs, and we’ve simply not put the resources on this feature yet, as they have been used elsewhere.
Yup, this pretty much sums it up. It’s a prioritization issue right now. But we do have plans to get to it soon™.
Just throwing it out there, but IL2CPP also makes it harder for hackers to reverse-engineer our hard work ![]()
So IL2CPP on standalone will be appreciated on that aspect too ![]()