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).
