The reorganization of source files and their enclosing directories in large commercial projects tends to be nasty, in my experience.
1) On Macs at least, they use CVS as their source code management (SCM) system. CVS can’t handle moving files and folder gracefully. At best, you delete the files in one place and check them in somewhere else, which abandons their history in the original location. And you can’t delete directories at all. Instead, you leave the old, dead, empty directories there and instruct everyone to use -P when they do their checkouts and updates, so that empty directories are pruned for local repositories.
2) The major IDEs on the platform treat the visual representation of the Groups & Files in your project as something entirely different than the actual files and directories on disk.
“Groups” (yellow folders) in Xcode are only meaningful as an in-project organizing principle. Moving them, or the file representations within them, around in your project window, won’t change what’s on disk.
And conversely, if you move files and directories around on disk, the project won’t automatically be updated to the new arrangement.
So for a reorganization, after you move everything around on disk, you can look forward to doing the exact same thing again in your IDE user interface. This, as you can imagine from how I’m describing it, frustrates me to no end. But it gets worse.
For newer projects, you can fix 1) by switching to Subversion, where both files and directories can be moved around easily with complete retention of their history. But you can’t somehow execute the moving around Subversion commands in the Xcode UI itself, because of 2).
Why did anyone think keeping Groups & Files completely unrelated to disk directories and files was a good idea? Every commercial project I’ve ever worked on has made its Groups & Files tree mirror the on-disk directory structure whenever possible – the only times they diverged was due to maintenance error.
The only good reason I’ve had for a different Groups & Files structure was for a library where all the library headers needed to be available in the same top-level directory. So on disk, it was an undifferentiated list, but I used a 3-4 level deep group hierarchy in the project itself to be able to organize the files better conceptually. But, as I said, I’ve never seen this in the wild.
I’ve just seen hours upon hours spent maintaining hierarchies in two places, both for project creation and the inevitable reorganizations that followed.
Weaponized Fluff 
Every developer I know keeps projects organised sensibly. The fact IDEs (and it’s not just Xcode, of course) do their own ‘groups’ is just plain irritating.
I want four main things from an IDE:
– Version control operations that are as simple as the command-line equivalents (check in this file, update this file, compare revisions, remove this file, add this file)
– A tree which shows the organisation of the project relative to the defined project root
– The ability to hide certain files (e.g., those generated by build logic, or whatever) from the project tree.
– The ability to easily override the basic build steps (prepare, build, install) – this is the one most IDEs *really* struggle with. For example, I want to be able to invoke a configure or autogen.sh-type script instead of the IDE’s built-in (and possibly dummy) preparation step, and run ‘make’ instead of letting the IDE do it.
My pet peeve is IDEs which both try and do everything for you/differently (which for cross-platform projects means you have to re-specify -everything- for each platform you work on) and do it badly.
Xcode 1.x is pretty much middling in my experience, though I don’t have access to a Tiger machine to try out 2.0.
I should clarify — excepting explicitly hidden files, I think IDEs should just show everything below the project root directory. The whole “add this file to a project” thing is possibly more irritating than grouping them. If the IDE doesn’t know what to do with a file, a default of ‘do nothing’ is both sane and intuitive (again, so long as the developer has the option to specify custom rules, or whatever).
Andrew: Why did anyone think keeping Groups & Files completely unrelated to disk directories and files was a good idea?
I think you’ve answered this one yourself, Andrew: When Xcode was originally developed, Subversion didn’t exist. Having a group tree independent of the disk structure allowed users to reorganize their projects in the IDE without having to deal with moving the files around in their CVS repository, with all the drawbacks that that entails.
This will continue to be a useful feature for that reason as long as CVS is a major SCM system. (I will be surprised if this happens before the end of the decade.)
I don’t buy that.
I think Xcode did it because every other IDE did.
Use of version control systems (certainly of the likes of CVS) hasn’t been widespread for nearly as long as IDEs have. The groups/files thing came about (as far as I can tell) because a way was needed to organise sources — prior to that, everything in a project in an IDE was just flat. IDE developers were lazy, and instead of taking advantage of the intrinsically heirachical nature of most filesystems, went ahead and reinvented the wheel, badly.
I’m pretty sure you can make your groups folder references in Xcode instead of ephemeral thingies. Then you should be able to move files around and have things work.
I haven’t tried this, though.