Xcode Project vs Xcode Workspace - Differences

Question

I am trying to understand how the whole ecosystem of iOS works.
Until now, I could find an answer for most of my question (and trust me, there have been a lots of them), but for this one, there seems to be no clear answer yet.

What is the difference between XcodeProject and XcodeWorkspace files?

What is the difference between the two of them?
What are they responsible for?
Which one of them should I work with when I'm developing my Apps in team/alone?
Is there anything else I should be aware of in matter of these two files?

User · Answer

A workspace is a collection of projects  It s useful to organize your projects when there s correlation between them  e g   Project A includes a library  that is provided as a project itself as project B  When you build the workspace project B is compiled and linked in project A   It s common to use a workspace in the popular CocoaPods  When you install your pods  they are placed inside a workspace  that holds your project and the pod libraries

User · Answer

Xcode Workspace vs Project

What is the difference between the two of them?

Workspace is a set of projects

What are they responsible for?

Workspace is responsible for dependencies between projects. Project is responsible for the source code.

Which one of them should I work with when I'm developing my Apps in team/alone?

You choice should depends on a type of your project. For example if your project relies on CocoaPods dependency manager it creates a workspace.

Is there anything else I should be aware of in matter of these two files?

A competitor of workspace is cross-project references^[About]

[Xcode components]

User · Answer

I think there are three key items you need to understand regarding project structure  Targets  projects  and workspaces  Targets specify in detail how a product binary  i e   an application or library  is built  They include build settings  such as compiler and linker flags  and they define which files  source code and resources  actually belong to a product  When you build run  you always select one specific target   It is likely that you have a few targets that share code and resources  These different targets can be slightly different versions of an app  iPad iPhone  different brandings      or test cases that naturally need to access the same source files as the app  All these related targets can be grouped in a project  While the project contains the files from all its targets  each target picks its own subset of relevant files  The same goes for build settings  You can define default project-wide settings in the project  but if one of your targets needs different settings  you can always override them there     Shared project settings that all targets inherit  unless they override it    Concrete target settings  PSE iPhone overrides the project   s Base SDK setting  In Xcode  you always open projects  or workspaces  but not targets   and all the targets it contains can be built run  but there   s no way definition of building a project  so every project needs at least one target in order to be more than just a collection of files and settings     Select one of the project   s targets to run  In a lot of cases  projects are all you need  If you have a dependency that you build from source  you can embed it as a subproject  Subprojects can be opened separately or within their super project     demoLib is a subproject  If you add one of the subproject   s targets to the super project   s dependencies  the subproject will be automatically built unless it has remained unchanged  The advantage here is that you can edit files from both your project and your dependencies in the same Xcode window  and when you build run  you can select from the project   s and its subprojects    targets     If  however  your library  the subproject  is used by a variety of other projects  or their targets  to be precise   it makes sense to put it on the same hierarchy level     that   s what workspaces are for  Workspaces contain and manage projects  and all the projects it includes directly  i e   not their subprojects  are on the same level and their targets can depend on each other  projects    targets can depend on subprojects    targets  but not vice versa      Workspace structure  In this example  both apps  AnotherApplication   ProjectStructureExample  can reference the demoLib project   s targets  This would also be possible by including the demoLib project in both other projects as a subproject  which is a reference only  so no duplication necessary   but if you have lots of cross-dependencies  workspaces make more sense  If you open a workspace  you can choose from all projects    targets when building running     You can still open your project files separately  but it is likely their targets won   t build because Xcode cannot resolve the dependencies unless you open the workspace file  Workspaces give you the same benefit as subprojects  Once a dependency changes  Xcode will rebuild it to make sure it   s up-to-date  although I have had some issues with that  it doesn   t seem to work reliably    Your questions in a nutshell   1  Projects contain files  code resouces   settings  and targets that build products from those files and settings  Workspaces contain projects which can reference each other   2  Both are responsible for structuring your overall project  but on different levels   3  I think projects are sufficient in most cases  Don   t use workspaces unless there   s a specific reason  Plus  you can always embed your project in a workspace later   4  I think that   s what the above text is for     There   s one remark for 3   CocoaPods  which automatically handles 3rd party libraries for you  uses workspaces  Therefore  you have to use them  too  when you use CocoaPods  which a lot of people do

User · Answer

In brief   Xcode 3 introduced subproject  which is parent-child relationship  meaning that parent can reference its child target  but no vice versa Xcode 4 introduced workspace  which is sibling relationship  meaning that any project can reference projects in the same workspace

User · Answer

When I used CocoaPods to develop iOS projects, there is a .xcworkspace file, you need to open the project with .xcworkspace file related with CocoaPods.

But when you Show Package Contents with .xcworkspace file, you will find the contents.xcworkspacedata file.

<?xml version="1.0" encoding="UTF-8"?>
<Workspace
   version = "1.0">
   <FileRef
      location = "group:BluetoothColorLamp24G.xcodeproj">
   </FileRef>
   <FileRef
      location = "group:Pods/Pods.xcodeproj">
   </FileRef>
</Workspace>

pay attention to this line:

location = "group:BluetoothColorLamp24G.xcodeproj"

The .xcworkspace file has reference with the .xcodeproj file.

Development Environment:

macOS 10.14
Xcode 10.1

[xcode] Xcode Project vs. Xcode Workspace - Differences

The answer is

Examples related to xcode

Tags