koobas.hobune.stream
Best practices for working on an iPhone game with a team, especially one that uses native code
I'm trying to figure out the best work flow for keeping the xcode project itself versioned and accessible between teams.
First the two main problems associated with just having a local copy of the built unity project:
- Building the project in Unity seems to override certain settings and files, which is especially annoying if you're trying to create a universal app
- If new native code files get added, or project settings changed, it would require each person on the team to make them to their own version of the project
I'm guessing it's probably not a good idea to add the built unity project and the compiled .s and .a files under the asset server
Thinking about this for a while, it seemed like the best way to fix this would be to have each person have Unity build the project into a standard directory (probably a sibling to Assets), and then have a second version of the project file itself in a separate folder (probably under a folder that's versioned by asset server). This separate project would have its settings/plist/included code and frameworks set, and simply point to the standard relative locations for the unity generated files for the projects. That way when unity rebuilds the project, our custom xcode project won't get overridden, and there's a standard, versioned project that developers can use to build.
I haven't tried doing this yet, but has anybody tried doing something similar to this? Do you have a better work flow that solves some of the issues I've delineated earlier?
Well I went through and did the rigamarole of creating a separate project, and it turns out it isn't too terrible.
- build the project in a fixed location (I used a folder that was a sibling of Assets).
- copy this built project to a location that you want to work out of (i.e. somewhere under source control, I put it under Assets/Editor so I didn't have to use two source control solutions)
- delete everything in your working project's Library folder
- point to the files in the Library folder in under the built project
- modify the run script that copies the /Data folder into the app to point to the built data folder (for me it was changing the first parameter of cp -Rf to use relative pathing)
- (optional) change the project settings "Place Build Products In" and "Place Intermediate Build Files In" folders to somewhere else so they're not under source control (I used ~/Dev/
Project Unity Folder/build since ~/Dev/ is standard for us) - Whenever you need to do an update, build to the fixed location in step 1, and build the XCode project you created in step 2
This way I get the new Library and Data files (the important things that unity builds), and have a pristine XCode project that I can modify without worrying about Unity overwriting my target build settings or plist values. This project is also in source control for other people to pull down.
It does require some standardized locations of files and folders, but for me this pipeline serves my needs.
I think the optimal solution is a two way solution:
Project
- Handle that however you did so far (like package sharing, Unity Asset Server)
XCode Project
- SVN the xcode projects folder generated by unity
Potentialy you can get rid of 2 completely by just creating appropriate postbuildscripts that in combination with applescripts reapply whatever you do so far manually.
I thought about doing that, but I don't know applescript well enough to do what I need to do in XCode, and I'm really lazy and didn't want to create a SVN repository when I'm already using asset server.
