38

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.

jscs
  • 63,694
  • 13
  • 151
  • 195
mark
  • 1,398
  • 13
  • 30
  • 23
    Woa! An Xcode-tagged question that's actually about Xcode! :) – Almo Jul 23 '12 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 Jul 23 '12 at 18:46
  • 1
    Some reasons to use workspaces are mentioned here: https://developer.apple.com/library/ios/featuredarticles/XcodeConcepts/Concept-Workspace.html – pi3 Oct 27 '13 at 15:49

2 Answers2

20

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.

Mr. Berna
  • 10,525
  • 1
  • 39
  • 42
  • Thanks for your insight. I agree with most of your points, however even if the library is in flux I don't see the benefit of using a workspace. If your library is maintained in a Git repository you should be able to add it to projects as a submodule and then update the submodule as needed. – mark Jul 23 '12 at 19:59
  • Yes, git submodules are an alternative (and possibly better) method of managing library development. Submodules are an advanced git feature, which many iOS developers can't use for various reasons from lack of knowledge to being required to use other version control systems. In such situations workspaces may be a better choice than embedded projects. – Mr. Berna Jul 23 '12 at 20:50
  • @Mr.Berna - sorry but using git with xcode is a pain in the... you have no control whatsoever what version/branch/fork whatever are you using in every project unless you go directory by directory by hand using terminal and take notes manually. – Duck Oct 24 '13 at 10:20
  • Yes, RubberDuck, using git with Xcode is a pain, but it's less painful than the alternatives, other less integrated version control systems or no VCS. Each version of Xcode improves the integration, and Apple has chosen git over any other VCS, so I do use git regularly, but mostly from the command line. Yet to git or not to git is not the question here, it's just one of many factors to consider when choosing to use a workspace or an embedded project in any particular situation. – Mr. Berna Oct 24 '13 at 12:31
  • @Mr.Berna - Please assist me the best solution for my requirement, my requirement is "i have two projects called project A and Project B( Project B is workspace because i'm using pods ). i want to access Project B, when i click a particular button on Project A" so like this situation, what should i do. – Sri.. Aug 24 '15 at 10:00
  • @srinadh I'd solve that problem by making Project B a private CocoaPod and add that pod to Project A. If you setup the dependencies in your Project B podspec properly CocoaPods should setup the Project A workspace for you. – Mr. Berna Aug 24 '15 at 13:31
  • Mr.Berna, Thanks for reply, if i setup my Project B as private Cocopod, but some times i want to modify my old Project B, on new workspace, so at that time may be i will get a problems, if you have tutorial like make as a private cocopods, please provide me. – Sri.. Aug 24 '15 at 15:04
1

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.

Patricia
  • 5,019
  • 14
  • 72
  • 152