Developing Enterprise iOS Applications

Chapter 2. Concurrent Development with iOS

Enterprise application development at most companies is usually about teams, often large teams. The Agile movement has done little to change this tendency, and in fact embraces the idea of team development, with a backlog of stories that are apportioned out to the pool of developers on the team on a sprint by sprint basis.

So what does this mean for iOS applications development? Well, if you’re a Java programmer working in Eclipse, you can split up development pretty easily. Eclipse is largely directory based, and the Eclipse project file is fairly stable. Xcode…not so much. Xcode is the obsessive-compulsive poster child of IDEs. It wants to manage every single file at a micromanager level, and it’s not enough to drop new files into a directory, you need to tell Xcode to use them in specific build targets, and all of that info is stored in a single xcodeproj file.

If you’re not very careful when creating new files in Xcode, you tend to end up with everything in one flat directory. Using groups can give structure to the project view inside Xcode, but it does nothing to organize the physical file system layout. And as you may have already discovered, trying to go in after the fact and move files around on disk is messy, because there’s no way to notify Xcode that you’re doing it. The best I’ve ever done is to delete the references (which turn red when you move the files), then re-add them and hope that you haven’t screwed up your build manifests ...