Hi, As I stated in the title, how do you maintain the same project in multiple platforms? (iOS, Android, etc) What is the best practice in this?
1- Duplicate project for each platform and do platform specific things as you like.
2- Use the same project and share the same scripts by using #if UNITY_IPHONE, etc.
3- Something else?
So, I want to hear your practices in the subject. Thanks.
Use SVN, switch platform and make builds for both iOS and Android.
If it works on iOS and Android, you can ship it.
#2 is what I do with minibowling
I do a separate project after an experience losing an entire project while converting between ios/android. Or at least make a complete backup before switching…have had it eat my entire scripts folder as well.
@eskimojoe, are you using a specific SVN plug-in?
@lmbarns , that’s terrible. Which version of Unity did that?
What I think you should do is have a master copy, this is the copy you work in, make updates. For the other platforms you want to have as little change as possible, because lets say you make an update in the IOS, then you would have to make the update in both versions. The lightmaps seem to get screwed up, the textures could get screwed up, a whole bunch of things could break when switching platforms. Some android plugins will screw up the IOS build and vice versa.
Also abstract as much as possible and reasonable. Anything that is platform specific, modularize so you don’t have to change too much when you do need to update. For example game logic, that shouldn’t be any different, keep that separate so it doesn’t know or care about the build target.
Just use the TortoiseSVN. You really do not need any plug-in.
I use one project and a lot of clear directives, Application.platform calls and so forth - prefer to write once deploy to many. So far the only wall I’ve hit with this approach is that unity’s input manager is insufficient but I’ll be rewriting this at some point with a custom job.
It’s pretty tricky in a team based environment having a lot of separate versions, even if by source control you manage to share the same scripts. You want to share them or bug fixing and changes get out of sync.
1 project benefits: works well within team, and any fixes, updates, changes are deployed across all the platforms in one go. It’s the easiest way.
1 project issues: unity lags behind here in a few key areas: The input manager doesn’t allow for per platform input options (its one set for all). And Application.platform (and the rest of unity) should allow custom defines.
I use #2 a lot i.e. In my PerformanceManager.IsSlowDevice, on iOS I have it check if its an iPhone4 / iPod4, on Android I check how many cores the device has.
@hippocoder, did you know you can do custom defines these days?
Custom defines! I’m feeling out of touch now. Thanks a lot Lukas, that’s a help.
Wahhh! Since when!? I had no idea. That’s super helpful dang. I used to code two separate projects for server/client. No longer :).
Its a really new feature, 4.1.x something, and only 3 lines of text in the manual so don’t blame yourself missing it 
4.1.5… I think part of it is the mac I was using though, it would freeze randomly 1x daily to the point I had to power off and on, but when it came back on the entire standard assets folder was simply gone and all the script associations were broken. My boss got me a new PC and haven’t had the same problem since…
At work we build for android then port to ios after we have the finished android build (finished and sent to client)…then we backup, make new project and convert it to ios and get that build working.
I didn’t realize you could use custom defines…will have to try that…mainly we work with android first for several reasons, we can’t use Unity remote with the plugins we use and have to build->deploy to the device and it’s time consuming to pass it into xcode every time we want to test a build, and we develop apps for other businesses and can simply send them builds throughout development without having to be in an app store.
Me too. The only issues I’ve had are 3rd party plugins which aren’t well designed for multi-platform use. Unity itself is surprisingly nice in this regard.
Directives and Application.platform calls are pretty rare for me, as I’ve handled most things at design time. Where I do need them, I typically try to keep them to their own object (eg: the on-screen joystick for touch-only platforms) and have a component that enables/disables them based on platform.
I think it’s been there for ages as an undocumented feature if you stick stuff in a file with a particular name. It’s a pretty recent addition to the GUI, though, maybe 4.0 or 4.1?
You have iOS already. Simply purchase Unity3D for Android. Make a backup, switch platform and then make an Android build.
#if UNITY_IPHONE
#if UNITY_IPHONE || UNITY_ANDROID
The same resizing aspect ratio code would work the same.
Use #if for platform specific codes, such as AppStore and Google Marktplace IAP purchases.
Use the same project and use the same scripts.
You need to buy a Samsung, Toshiba, Sony tablet, Samsung handphone, Sony XPeria phone. Try to buy the older ones if you use it just for testing purposes.
Well, you can maintain code/projects in seperate branches in your source control system of course.
Although it depends on the platforms too.
For instance for PC/Mac/Web/Metro, you may get away with a few #if tags in your code, and keep them all on the same branch.
For mobile though, you’ll probably have a whole bunch of mobile specific assets, plugins and shaders in your project, that wouldn’t be relevant to non-mobile builds, so you’ll keep everything on a mobile branch.
Talking of branching, here is a great description of a branching model that you can use for all your development…
It refers to GIT though you could apply a similar model to any version control system.
http://nvie.com/posts/a-successful-git-branching-model/
Lots of useful information provided, thanks all. So, it seems using the same project across all platforms (at least for mobile) is the most common practice. Also we should remember to backup our project before switching platforms as it’s somewhat risky.
@eskimojoe, thanks for the steps. I hate android platform just for the last one
I really advice some sort of versioning system, which also acts as your backup.
I’m a sole developer but versioning, in my case SVN, saved my butt several times. I once had an issue with MonoDevelop screwing up the undo and the code was just a total non compiling mess, luckily I could revert that script to the previous state. Another example would be Unity 4.1.2 and switching platform while a scene with NGUI was open. It would crash Unity.
So long story short, use a versioning system like SVN or GIT incombination with platform directives and optionally unity cache server and your golden
I’m surprised so many people still use SVN. May I ask why you’re not using something newer like Git or Marcurial? Sticking with the familiar, or the “distributed” bit seems like an over-complication, or just haven’t bothered?