Общая база кода для разработки iOS и OS X

У нас есть довольно богатое приложение для электронного обучения, построенное в основном с использованием cocos2d. В настоящее время мы находимся в альфе и хотим настроить нашу структуру проекта, чтобы мы могли также создать версию Mac для таргетинга на магазин Mac App. Это около 80% cocos2d с некоторыми интуитивными экранами в UIKit, которые нужно будет портировать на Mac (переписано).

Какова рекомендуемая настройка для таргетинга на магазины приложений Mac и iOS из одной базы кода? Я предполагаю, что выбор:

Создайте 2 проекта xCode в одной корневой папке исходного кода приложения и используйте каждый проект для создания единой цели. Это будет: Project.xcodeproj и ProjectMac.xcodeproj
Добавьте новую цель для Mac в наш существующий проект приложения iPad, а затем поиграйте с целевым членством, чтобы получить желаемые результаты. Это будет просто: Project.xcodeproj

Далее усложняется ситуация, когда мы используем cocos2d как статическую библиотеку для приложения iOS. У нас также есть библиотека под названием CoreInfrastructure, в которой есть много кода, который мы используем во всех наших проектах. Недавно я выяснил, что я могу создать проект для одновременного создания инфраструктуры таргетинга на Mac и библиотеки, ориентированной на iOS, с той же базы кода. Это делается с помощью проекта рамки и добавления цели для создания статической библиотеки для iOS.

Так просто хотел получить все мнение и прозрение. Кто-нибудь знает о каких-либо предостережениях, о которых следует помнить в приведенных выше вариантах? Кто-нибудь, кто строит для Mac и магазинов приложений iOS, одновременно заботится о том, чтобы поделиться своей структурой? Добавление цели, обработанной в нашем библиотечном коде... - это то, что нужно для приложения?

Есть ли проблемы с сборкой архивов и дистрибутивов для любого выбора?

Спасибо заранее.

Ответ 1

Для приложений используются два отдельных проекта. Использование нескольких целей для iOS и Mac в одном проекте очень полезно, если они делят библиотеку или фреймворк. Однако в вашем приложении верхнего уровня почти ничего не используется. Код UIKit должен быть полностью переписан для использования AppKit, зависимости будут разными, и даже большинство параметров проекта будут отличаться.

Конечно, если вы действительно хотите увидеть все сразу, вы можете разместить как проекты приложений для конкретной платформы, так и все общие проекты зависимых библиотек/рамок в одном рабочем пространстве. Это скорее вопрос стиля работы. Если вы хотите переключаться между ними часто, это имеет смысл. Если вы хотите упростить то, что вы смотрите, вы можете поместить их в отдельные рабочие пространства, в которых используются одни и те же проекты. Отдельные рабочие пространства имеют тот недостаток, что проект может быть открыт только в одном рабочем пространстве за раз, поэтому вы можете работать только по одному за раз.

Ответ 2

WWDC session "Обмен кодом между iOS и OS X" отвечает на все основные вопросы в этом разделе. Команда iWork представила, как они ушли с созданием Pages, Keynote и Numbers с общей базой кода для iOS и OS X.

Ключом к их проекту было использование:

отдельные цели Xcode для iOS и OS X
отдельный проект для общего кода в виде .framework
целевая зависимость от фреймворка от точки выше

Я рекомендую посмотреть видео или прочитать стенограмму с этого сеанса:

WWDC 2014 Обмен кодом между iOS и OS X

стенограмма ASCIIWWDC

Ответ 3

Недавно я использовал kstenerud iOS Universal Framework для создания общей кодовой базы фреймворка, которая работает как для приложений iOS, так и для Mac. Мне просто нужно было вручную добавить цель для структуры Cocoa после создания проекта для iOS-структуры. Таким образом, я могу развить разделяемый код один раз в рамках и связать его как в приложениях iOS, так и в Mac. Вы даже можете сделать фреймворк содержащим UIKit-специфический код для вашего приложения iOS и специфического для AppKit кода для ваших приложений Mac. Я написал об этом в своем блоге, если вы заинтересованы.

Ответ 4

Я использую многоплатформенные статические объекты библиотеки для общих источников. Однако вам нужно расширить это на зависимости. Если у вас есть реализации, зависящие от платформы, вы можете создать дополнительные библиотеки экспорта для этих символов.

Таким образом, ваша структура может иметь следующую форму:

CoreInfrastructure - межплатформенная статическая библиотека.
PlatShared - межплатформенная статическая библиотека.
PlatSpecific-OS X - статическая библиотека OS X (или фреймворк).
PlatSpecific-iOS - статическая библиотека iOS.

Приложение OS X связано с CoreInfrastructure, PlatShared, PlatSpecific-OSX, Cocos для OS X и системными библиотеками.

Приложение iOS связывается с CoreInfrastructure, PlatShared, PlatSpecific-iOS, Cocos для iOS и sys libs.

Проблема (я обнаружил), есть много людей, у которых не было много опыта и опыта разработки и поддержки сложных структур проекта в Xcode. Это боль (IMO) для настройки повторяющихся целей и правильного поддержания их по мере их роста - даже если все они относятся к тем же исходным файлам. Поэтому я предпочитаю минимальные цели и правильную структуру зависимостей.