I don't understand the use of an Xcode workspace to organize projects with dependencies on one another. For instance I see a lot of developers create workspace structures that look like this:
Workspace |-- App |-- A Common Library |-- Another Common Library
What benefit does this provide? If anyone opens the "App" project directly won't they be unable to actually build the app? They'd have to realize that a workspace exists with the necessary dependencies.
It seems to me like the better approach is to use nested projects like this:
App |-- Libraries | |-- A Common Library | |-- Another Common Library
Then no project exists that cannot be built. It also seems more in line with Git's idea of submodules.
The only use I see for a workspace is to group common projects with no dependencies on one another. I'd like to hear other people's thoughts on this because I may be missing something.
-
23Woa! An Xcode-tagged question that's actually about Xcode! :)Almo– Almo2012年07月23日 18:42:59 +00:00Commented Jul 23, 2012 at 18:42
-
1@Almo: It happens every couple of days. They usually have the opposite problem, though: tagged [objc] when it doesn't apply. :)jscs– jscs2012年07月23日 18:46:20 +00:00Commented Jul 23, 2012 at 18:46
-
1Some reasons to use workspaces are mentioned here: developer.apple.com/library/ios/featuredarticles/XcodeConcepts/…pi3– pi32013年10月27日 15:49:38 +00:00Commented Oct 27, 2013 at 15:49
2 Answers 2
I use workspaces when I want to combine projects while also maintaining project independence.
An example where I use workspaces is series of tutorial projects that progress from very simple to more complex. Each project can function as a standalone project, but grouping them together in a workspace helps my organization of the overall project.
In another instance I have an app developed for a client. The app works as both a standalone app and a module in the overall project. The independent project can build the standalone app. The other app uses a workspace that includes two projects. The module version of the app is built from a special scheme, and this combined app doesn't build without using the workspace.
One twist with the two above situations is where the build folder is stored. I have to change the Xcode preference to put the build products into unique folders for the group of tutorial projects, use a common build folder for the module within the other app setup.
In other circumstances I have plenty of projects with embedded projects. In these situations the library projects are stable. I don't attempt further development of the library projects so they are just another resource for the project. I find it easier to work where my file system organization of project resources somewhat reflects the organization of my Xcode project. So these library projects are copied into the main project's file hierarchy. It would make sense to use workspaces if I was developing the libraries and using them in multiple projects. For expedience I frequently don't bother.
Sometimes I even combine workspaces with projects containing embedded projects.
So my opinion is that both organizational tools, embedded projects and workspaces, have their merits and problems. I choose to use one or the other (or a combination) depending upon the particular circumstances.
7 Comments
We added nested projects into the Main project's Frameworks, so we could "include" them into the .framework product.
Main
|-- Main
|-- MainTests
|-- Frameworks
| |-- CommonLibrary.xcodeproj
| |-- AnotherCommonLibrary.xcodeproj
| |-- UIKit.framework
| |-- Foundation.framework
| |-- CoreFoundation.framework
|-- Products
See this Great Tutorial by Jeff Verkoeyen for adding Universal Frameworks to a project. It not easy, at first, but keep working on it and you'll get the hang of it.