Dear plugin developers, Make sure your code compiles on all platforms.

Unity Engine
1

Hey Plugin developers,

This is just a general shout out to hopefully get some awareness of my situation and probably the situation of many developers in the Unity community.

My message is simple. If you are making a plugin, even if you explicitly say you only support 1 platform be it iOS, Android or whatever, please make sure that you appropriately #define out your code or use whatever means you deem appropriate so that your plugin does not break (have compile errors) when other platforms are selected. Just because your plugin does not support all platforms doesn’t mean the projects it is used in don’t either.

Thanks for your better plugins in future.

Cheers,
Antony.

2

+1

3

I agree with the general idea, however, what would you propose developers do in the case of Dll’s (they can’t have preprocessor code)?

4

Wrong section of the forum by a mile. What plugin did you get ? Give more details pls. I like to vent too.

5

I don’t have the solutions, I’m just reporting a problem I’ve found with a lot of plugins I’ve used.

I’m not going to single anyone out as it seems like a common problem with plugins. It would be unfair to single out the developers of plugins that I specifically have used.

6

Any best practices here? Is it enough to switch to the wanted platform to get compile errors or do I have to force a recompile?
Is it possible that part of the problems only show at runtime or are all problems caught at compile time?

For reference:

PlatformDependentCompilation
MonoCompatibility
MobileDotNet
iphone-playerSizeOptimization (only page mentioning micro level)

Also what about Editor Scripts? Does everything in Mono/.Net 3.5 and Mono/.Net 4.0 also run on Mac?

7

Pretty expensive request there
I only have a windows machine, and to make sure that everything works on my machine I test at every stage; it’s not so simple to ask someone with a mac/android/iOS to just test the finished product, because they will miss some specific case that I was able to test as it was implemented
And I can’t test it myself, without the outlay of much moneys to buy each myself.

If it says explicitly that it’s for a specific platform, you can’t expect it to work flawlessly elsewhere.

8

Asset Store needs to be extended with improved descriptions on Assets to make things clearly for the buyers and protect the sellers from unhappy customers.

For instance when uploading the asset there should be a checkbox or something that you can hit to confirm that it works (or was tested) on each platform.

9

I don’t believe it’s that bad. Every plugin I install with this issue takes me about 30 minutes to go through and make sure it at the very least compiles on all platforms. The reason is that I have artists working with me that cannot solve these issues them selves. Every minute they cannot work is wasted money and I attribute that cost to the plugins I buy. If a plugin I buy costs me more money in the long run then I’m not going to buy more plugins from the same developer in future. I’m sure I’m not the only person that thinks this way.

Yes this means you’ll need Mac OSX and Windows but if you’re making and selling developer tools you should probably already have both of these. I have both on my Mac laptop running in bootcamp so it’s not like I needed to buy two computers.

Basically if your plugin is for iOS only then place all the code inside #if UNITY_IPHONE tags. The only exception to that is behaviours that must be attached to game objects because they’ll go ‘missing’ on other platforms. Simply def out the contents of those classes but leave the public variables and class definition for the inspector serialisation. Yes it’s a bit ugly but hey it compiles on Android and Standalone and Windows Phone now!

The alternative to the plugin developers not doing this is me having to do it each and everytime your plugins are updated and I can tell you that’s a right pain in the ***

10

Your artists shouldn’t be losing any time on this - if it’s you that’s buying the plugins and integrating them into your project, then it is you who should then check it compiles on all platforms before publishing to your artists, just the same as if you’d written the code yourself.

I would prefer plugin developers who can’t test some platforms to leave their code alone and hope it does work. Most code does. I don’t want to have to go in and remove a load of over-cautious ifdefs around trivial code that just hasn’t been tested yet on some particular platform.

It’s also not reasonable to expect a one-man-team selling assets for $10 a pop to invest in thousands of pounds’ worth of hardware on the off-chance that the assets will sell well enough to recoup the investment. I’m sure most don’t!

If anything perhaps you should campaign for Unity Technologies to do this testing before approving assets, and send the appropriate feedback to developers of assets that don’t compile on unsupported platforms - they are in a much better position to test this than your average Asset Store vendor.

11

This also begs the question if unity is doing enough to inform developers as to which API(s) are available on which platform(s). Because right now it seems like unity just randomly gets rid of certain API’s based on the platform.

My main point is why doesn’t unity make it CLEAR the platforms that each API runs on, instead leaving it as a black whole for us to guess. This would make it completely obvious as to what code needs platform dependent compilation.

12

See my links above

13

He’s not asking for it to work, he’s asking for it to not break other things.

As has been discussed at length elsewhere, Unity is a bit behind the eight ball in regards to including modern technologies/approaches that handle this kind of stuff (that’s not a complaint, things are moving forward, it just hasn’t got to this stuff). But as the OP has said, you can still go a long way towards it by simply making sure that any platform specific code is appropriately defined.

I too have often had to manually mess with code in platform-specific plugins to stop them from breaking other platforms, and so far it’s always been a matter of adding defines.

And since multi-platform support is one of Unity’s big ticket features and strengths, failing to take simple steps to preserve it shows a significant lack of professionalism, in my opinion. If you’re selling someone code it shouldn’t mess with things outside of its scope, and that definitely includes not mucking up the build pipeline.

Also, for what it’s worth, testing it isn’t such a huge issue now is it? Lets be clear: we’re talking about compile testing. You don’t need to buy hardware to test that. PC/Mac/Linux all have identical compilation from my experience. Both iOS and Android build options are now available from free licenses, and even iOS can now be built from Windows. Since it’s a compile issue, if you can platform switch and build to all of the above without problems then you’ve solved the issue that the OP is talking about. And if you’re going to sell something (ie: imply a commercial level of quality) then surely it’s not unreasonable to expect that at least that level of QA has been performed on it?

Whether or not it works correctly on the additional platforms is a different issue, but one that’s already covered when you announce the platforms you support - if you don’t support a platform then we know we can’t rely on it even if it happens to compile. And that’s fine, because if we buy a platform specific plugin then we probably don’t intend to use whatever it does on other platforms anyway.

I’m not completely sure, but doesn’t Unity have built in ways to look after platform specific DLLs? Put them in the appropriate platform folder and they only get included on the corresponding platforms, if I recall? At any rate, this in particular has never been an issue for me.

14

If the code is obviously platform-specific then fair enough.

Ah, I didn’t realise that, on either point. It helps a lot. There are still other platforms that won’t be covered - Xbox 360, PS3, Wii - and it’s not reasonable to expect those to work. Partly why I said what I did was past experience with targetting Xbox 360, where compilation would fail if you accessed certain standard library features. Very few people have Xbox 360 licenses, they are hard to get hold of, and it wouldn’t be reasonable to expect people to own these.

So a line has to be drawn somewhere. But you’re right, expecting vendors to compile on all platforms that Unity Free can target is not unreasonable.

I still think it would be better if UT did some of this testing and published the results - I mean, surely they already do, otherwise what happens during the approval process?

For native plugins, you can put them in a subdirectory of “Plugins” named after the target platform, and they’ll only apply on that platform. I’m not sure whether the same applies to managed DLLs, and I’m pretty sure there’s no way to define platform-specific CS files in bulk in the editor, which is a shame. Maybe one day they’ll extend the existing directory name convention to do that too.

15

I’m just hitting this problem now with a plugin we’re developing internally. We’re using DLLs because I want to easily share the code between projects. Even though the DLL is in the Plugins/Android folder, it’s getting compiled for all platforms. #ifs only work during compilation, so that won’t work here. This is a huge deficiency with Unity–why is it grabbing managed code from plugin directories targeted for other platforms? The only solution I’ve read about so far is a compile script that literally changes the name of the DLL during compilation, which seems like a ridiculous workaround.