title: Projects Vs Targets for a codebase in an XCode Workspace
body: <p>The XCode documentation on the concepts of <a href="https://developer.apple.com/library/mac/featuredarticles/XcodeConcepts/Concept-Targets.html#//apple_ref/doc/uid/TP40009328-CH4-SW1">Targets</a> and <a href="https://developer.apple.com/library/mac/featuredarticles/XcodeConcepts/Concept-Projects.html#//apple_ref/doc/uid/TP40009328-CH5-SW1">Projects</a> are helpful, but still I am not certain on the best practices to use in my situation.</p>
  
  <p>I have an existing codebase (used for Windows as well as iOS) in a single SVN repository, which has just been refactored from one single test application into a central library and an application. The idea is more applications will use this central library over time.</p>
  
  <p>An XCode project maps one set of source files to one or more targets, so I could have a single project for my whole codebase and one target for the library and one for each app. However each app will obviously have its own code, so it seems a bit clunky to throw all the source into a single project this way.</p>
  
  <p>Alternatively I could have a workspace with multiple projects, each having a single target. This is much more how I have things set up for the Windows build, where a Visual Studio solution corresponds to the Xcode workspace, and a VC++ project would map neatly against how XCode projects are organised.</p>
  
  <p>But are there 'normal' / expected ways to do things in this kind of situation, some unofficial standards I should try to follow so other developers don't get confused?</p>