Xcode Project vs. Xcode Workspace - Diferencias

Estoy tratando de entender cómo funciona todo el ecosistema de iOS.
Hasta ahora, podría encontrar una respuesta para la mayoría de mi pregunta (y confía en mí, ha habido muchas), pero para esta, parece que todavía no hay una respuesta clara.

¿Cuál es la diferencia entre los archivos XcodeProject y XcodeWorkspace?

1. ¿Cuál es la diferencia entre los dos?
2. ¿De qué son responsables?
3. ¿Con cuál de ellos debería trabajar cuando estoy desarrollando mis aplicaciones en equipo / solo?
4. ¿Hay algo más que deba tener en cuenta en relación con estos dos archivos?

Creo que hay tres elementos clave que debe comprender con respecto a la estructura del proyecto: objetivos , proyectos y espacios de trabajo . Los objetivos especifican en detalle cómo se construye un producto / binario (es decir, una aplicación o biblioteca). Incluyen configuraciones de compilación, como indicadores de compilador y enlazador, y definen qué archivos (código fuente y recursos) pertenecen realmente a un producto. Cuando construye / ejecuta, siempre selecciona un objetivo específico.

Es probable que tenga algunos objetivos que compartan código y recursos. Estos objetivos diferentes pueden ser versiones ligeramente diferentes de una aplicación (iPad / iPhone, diferentes marcas, ...) o casos de prueba que naturalmente necesitan acceder a los mismos archivos fuente que la aplicación. Todos estos objetivos relacionados se pueden agrupar en un proyecto . Si bien el proyecto contiene los archivos de todos sus objetivos, cada objetivo elige su propio subconjunto de archivos relevantes. Lo mismo ocurre con la configuración de compilación: puede definir configuraciones predeterminadas para todo el proyecto en el proyecto, pero si uno de sus objetivos necesita configuraciones diferentes, siempre puede anularlas allí:

Configuración de proyecto compartida que heredan todos los objetivos, a menos que la anulen

Configuración de objetivos concretos: el iPhone PSE anula la Base SDKconfiguración del proyecto

En Xcode, siempre abre proyectos (o espacios de trabajo, pero no objetivos), y todos los objetivos que contiene pueden construirse / ejecutarse, pero no hay forma / definición de construir un proyecto, por lo que cada proyecto necesita al menos un objetivo para ser más que una simple colección de archivos y configuraciones.

Seleccione uno de los objetivos del proyecto para ejecutar

En muchos casos, los proyectos son todo lo que necesita. Si tiene una dependencia que construye desde la fuente, puede incrustarla como un subproyecto . Los subproyectos se pueden abrir por separado o dentro de su superproyecto.

demoLib es un subproyecto

Si agrega uno de los objetivos del subproyecto a las dependencias del superproyecto, el subproyecto se creará automáticamente a menos que no haya cambiado. La ventaja aquí es que puede editar archivos tanto de su proyecto como de sus dependencias en la misma ventana de Xcode, y cuando construye / ejecuta, puede seleccionar entre los objetivos del proyecto y sus subproyectos:

Sin embargo, si su biblioteca (el subproyecto) es utilizada por una variedad de otros proyectos (o sus objetivos, para ser precisos), tiene sentido colocarla en el mismo nivel jerárquico, para eso son los espacios de trabajo . Los espacios de trabajo contienen y gestionan proyectos, y todos los proyectos que incluye directamente (es decir, no sus subproyectos) están en el mismo nivel y sus objetivos pueden depender unos de otros (los objetivos de los proyectos pueden depender de los objetivos de los subproyectos, pero no al revés).

Estructura del espacio de trabajo

En este ejemplo, ambas aplicaciones ( AnotherApplication / ProjectStructureExample ) pueden hacer referencia a los objetivos del proyecto demoLib . Esto también sería posible al incluir el proyecto demoLib en los otros dos proyectos como un subproyecto (que es solo una referencia, por lo que no es necesaria la duplicación), pero si tiene muchas dependencias cruzadas, los espacios de trabajo tienen más sentido. Si abre un espacio de trabajo, puede elegir entre los objetivos de todos los proyectos al construir / ejecutar.

Todavía puede abrir los archivos de su proyecto por separado, pero es probable que sus objetivos no se creen porque Xcode no puede resolver las dependencias a menos que abra el archivo del espacio de trabajo. Los espacios de trabajo le brindan el mismo beneficio que los subproyectos: una vez que cambia una dependencia, Xcode lo reconstruirá para asegurarse de que esté actualizado (aunque he tenido algunos problemas con eso, no parece funcionar de manera confiable).

Sus preguntas en pocas palabras :

1) Los proyectos contienen archivos (código / recursos), configuraciones y objetivos que crean productos a partir de esos archivos y configuraciones. Los espacios de trabajo contienen proyectos que pueden referenciarse entre sí.

2) Ambos son responsables de estructurar su proyecto general, pero en diferentes niveles.

3) Creo que los proyectos son suficientes en la mayoría de los casos. No use espacios de trabajo a menos que haya una razón específica. Además, siempre puede insertar su proyecto en un espacio de trabajo más adelante.

4) Creo que para eso es el texto anterior ...

Hay un comentario para 3): CocoaPods , que maneja automáticamente las bibliotecas de terceros para usted, utiliza espacios de trabajo. Por lo tanto, también debe usarlos cuando los usa CocoaPods(lo que hace mucha gente).

Un espacio de trabajo es una colección de proyectos. Es útil organizar sus proyectos cuando existe una correlación entre ellos (por ejemplo: el proyecto A incluye una biblioteca, que se proporciona como un proyecto en sí mismo como proyecto B. Cuando construye el espacio de trabajo, el proyecto B se compila y vincula en el proyecto A).
Es común usar un espacio de trabajo en los populares CocoaPods . Cuando instala sus pods, se colocan dentro de un espacio de trabajo, que contiene su proyecto y las bibliotecas de pod.

En breve

• Xcode 3 introdujo el subproyecto, que es la relación padre-hijo, lo que significa que el padre puede hacer referencia a su objetivo hijo, pero no al revés
• Xcode 4 introdujo el espacio de trabajo, que es una relación entre hermanos, lo que significa que cualquier proyecto puede hacer referencia a proyectos en el mismo espacio de trabajo

Cuando utilicé CocoaPods para desarrollar proyectos de iOS, hay un .xcworkspacearchivo, debes abrir el proyecto con el .xcworkspacearchivo relacionado con CocoaPods.

Pero cuando Show Package Contentscon .xcworkspacearchivo, se encuentra el contents.xcworkspacedataarchivo.

<?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>

presta atención a esta línea:

location = "group:BluetoothColorLamp24G.xcodeproj"

El .xcworkspacearchivo tiene referencia con el .xcodeprojarchivo.

Entorno de desarrollo:

macOS 10.14
Xcode 10.1

1. ¿Cuál es la diferencia entre los dos?
   Workspace es un conjunto de proyectos

2. ¿De qué son responsables?
   El proyecto es responsable del código fuente. Workspace es responsable de las dependencias entre proyectos

3. ¿Con cuál de ellos debería trabajar cuando estoy desarrollando mis aplicaciones en equipo / solo?
   Su elección debería depender de un tipo de su proyecto. Por ejemplo, si su proyecto se basa en el administrador de dependencias de CocoaPods, crea un espacio de trabajo.

4. ¿Hay algo más que deba tener en cuenta en relación con estos dos archivos?
   Un competidor del espacio de trabajo es cross-project references^{[Acerca de]}

[Componentes de Xcode]