Eu acho que existem três itens principais que você precisa entender sobre a estrutura do projeto: Destinos , projetos e áreas de trabalho . Os destinos especificam em detalhes como um produto / binário (isto é, um aplicativo ou biblioteca) é construído. Eles incluem configurações de compilação, como sinalizadores de compilador e vinculador, e definem quais arquivos (código fonte e recursos) realmente pertencem a um produto. Ao criar / executar, você sempre seleciona um destino específico.
É provável que você tenha alguns destinos que compartilhem código e recursos. Esses diferentes destinos podem ser versões ligeiramente diferentes de um aplicativo (iPad / iPhone, marcas diferentes ...) ou casos de teste que naturalmente precisam acessar os mesmos arquivos de origem do aplicativo. Todos esses destinos relacionados podem ser agrupados em um projeto . Enquanto o projeto contém os arquivos de todos os seus destinos, cada destino escolhe seu próprio subconjunto de arquivos relevantes. O mesmo vale para as configurações de compilação: você pode definir configurações padrão para todo o projeto no projeto, mas se um de seus destinos precisar de configurações diferentes, sempre poderá substituí-las lá:
Configurações de projeto compartilhado que todos os destinos herdam, a menos que o substituam
Configurações de destino concretas: o iPhone PSE substitui a Base SDKconfiguração do projeto
No Xcode, você sempre abre projetos (ou áreas de trabalho, mas não destinos), e todos os destinos que ele contém podem ser construídos / executados, mas não há como definir um projeto, portanto, todo projeto precisa de pelo menos um destino para ser mais do que apenas uma coleção de arquivos e configurações.
Selecione um dos destinos do projeto para executar
Em muitos casos, os projetos são tudo o que você precisa. Se você tiver uma dependência criada a partir da fonte, poderá incorporá-la como um subprojeto . Os subprojetos podem ser abertos separadamente ou dentro do super projeto.
demoLib é um subprojeto
Se você adicionar um dos destinos do subprojeto às dependências do super projeto, o subprojeto será construído automaticamente, a menos que permaneça inalterado. A vantagem aqui é que você pode editar arquivos do seu projeto e de suas dependências na mesma janela do Xcode e, ao criar / executar, você pode selecionar os destinos do projeto e de seus subprojetos:
Se, no entanto, sua biblioteca (o subprojeto) for usada por vários outros projetos (ou seus destinos, para ser mais preciso), faz sentido colocá-la no mesmo nível de hierarquia - é para isso que servem os espaços de trabalho . Os espaços de trabalho contêm e gerenciam projetos, e todos os projetos incluídos diretamente (ou seja, não seus subprojetos) estão no mesmo nível e seus destinos podem depender um do outro (os destinos dos projetos podem depender dos destinos dos subprojetos, mas não vice-versa).
Estrutura da área de trabalho
Neste exemplo, os dois aplicativos ( AnotherApplication / ProjectStructureExample ) podem fazer referência aos destinos do projeto demoLib . Isso também seria possível incluindo o projeto demoLib nos dois outros projetos como um subprojeto (que é apenas uma referência, portanto não é necessária duplicação), mas se você tiver muitas dependências cruzadas, os espaços de trabalho farão mais sentido. Se você abrir um espaço de trabalho, poderá escolher entre os destinos de todos os projetos ao criar / executar.
Você ainda pode abrir seus arquivos de projeto separadamente, mas é provável que seus destinos não sejam construídos porque o Xcode não pode resolver as dependências, a menos que você abra o arquivo da área de trabalho. As áreas de trabalho oferecem o mesmo benefício que os subprojetos: uma vez que uma dependência seja alterada, o Xcode o reconstruirá para garantir que esteja atualizado (embora eu tenha tido alguns problemas com isso, parece não funcionar de maneira confiável).
Suas perguntas em poucas palavras :
1) Os projetos contêm arquivos (código / recursos), configurações e destinos que constroem produtos a partir desses arquivos e configurações. As áreas de trabalho contêm projetos que podem se referir um ao outro.
2) Ambos são responsáveis por estruturar todo o seu projeto, mas em diferentes níveis.
3) Eu acho que os projetos são suficientes na maioria dos casos. Não use áreas de trabalho, a menos que haja um motivo específico. Além disso, você sempre pode incorporar seu projeto em um espaço de trabalho posteriormente.
4) Acho que é para isso que serve o texto acima ...
Há uma observação para 3): o CocoaPods , que lida automaticamente com bibliotecas de terceiros para você, usa espaços de trabalho. Portanto, você também deve usá-los quando o usa CocoaPods(o que muitas pessoas fazem).
