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.