Управление несколькими версиями приложения iOS

Ответ 1

Я работаю в корпоративной среде, и у нас есть мобильное приложение, которое является продуктом компании, в которой я работаю. Мы продаем лицензии этого программного обеспечения нашим клиентам, которые всегда являются огромными компаниями. Наше приложение не проходит через App Store.

Каждый из наших клиентов имеет какую-то настройку в приложении, либо просто меняя свои логотипы, либо даже добавляя некоторые конкретные функции для одного из них. Я имею в виду: мы должны ежедневно разбираться с ситуацией, очень близкой к тому, что вы описываете, и здесь мои два цента.

Заранее: извините, если я слишком честен иногда, я не хочу никого обижать.

1. Управляйте приложениями отдельно, поместите их в один каталог и укажите общие файлы в первом (приложение для футбола).

Ну... Это странное решение, но оно наверняка сработает. При использовании SVN/ Git (особенно при работе в команде) может быть трудно поддерживать локально и даже сложнее.

У меня были некоторые проблемы до того, как раньше были связаны с символическими ссылками, но я не уверен, что это то, о чем вы говорите в этой опции. Если вы объясните немного лучше, я могу отредактировать это и попытаться дать вам лучшее мнение.

2. Создайте другую цель для каждого приложения в одном проекте

Что лучше, на мой взгляд.

Мы используем этот подход в основном для обработки различных возможных серверных серверов. Например, одна из наших целей использует наш сервер поддержки разработки, в то время как другая цель использует производственный сервер. Это помогает нам гарантировать, что мы можем использовать приложение, ориентированное на разработку, не рискуя серьезными издержками для нашей команды (из-за ошибочно упорядоченного порядка, например).

В вашем случае вы можете, например, настроить макросы препроцессора для целей, чтобы включить/отключить некоторую целевую функцию, вызываемую кодом. Вы также можете использовать разные раскадровки для каждой цели.

Недостатком этой опции является то, что код будет грязным, потому что каждый фрагмент кода будет в одном проекте. Это основная причина, по которой я бы выбрал вариант № 3.

3. Создайте рабочую область с одним проектом, который будет содержать общий код и проект для каждого проекта.

Опять же, я бы пошел на это. Честно говоря, мы не используем это в нашей компании YET, но по внутренним причинам. Я пытаюсь как можно скорее добиться этого для наших проектов.

Я бы не назвал его легким в настройке, но если все сделано правильно, это может помочь вам сэкономить время из-за причин обслуживания. Вы сможете повторно использовать любой код, который можно повторно использовать, и по-прежнему сможете сохранять ваши целевые изображения, классы и представления в своем собственном "контейнере" (проекте).

Таким образом вы получите проект по умолчанию (само приложение), несколько целей для него и "структуру", чтобы сохранить код для каждой из целей. Другими словами, вы сможете обмениваться кодами между несколькими целями/приложениями, и в то же время вы сможете отделить то, что принадлежит каждому из них. Нет грязного проекта:)

Я не уверен, как CoreData скомпилирован Xcode, поскольку мы его не используем. Но проверьте ответ, который я только что сделал для другого вопроса. Это не Swift, но это не должно иметь большого значения, поскольку почти все ответы касаются настройки рабочего пространства для достижения этого решения. К сожалению, я думаю, что он слишком велик, поэтому я связываю ответ, а не вставляя его здесь.

Если вам нужна какая-либо помощь, сообщите мне, и я сделаю все возможное, чтобы помочь вам.

Ответ 2

Это может быть излишним для вас, но это решение является масштабируемым. Нам пришлось построить ~ 15 приложений из одной кодовой базы

Проблема, которую мы должны решить, - это брендинг. Конструкция и поток приложений в основном были одинаковыми, а также структура данных, которые мы получили. На нашем сервере CI был проведен большой тяжелый подъем.

У нас было основное приложение со всем пользовательским интерфейсом и некоторой общей бизнес-логикой. это было известно как Белое приложение.

Тогда у нас был конкретный проект (рамки не существовали тогда) для каждой из разных конечных точек, моделей данных и картографов в моделях просмотра White-app. Эти приложения были частными контейнерами и управлялись cocoa pods.

Наш CI был настроен таким образом, что он будет компилировать все приложения "Branded", копируя, компилируя, подписывая все различные plist, активы, строковые файлы в каждое приложение вместе с каждой из конкретных моделей данных для каждого приложения. Поэтому, когда была запущена сквозная сборка, она создавала все различные фирменные приложения.

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

Это решение также предоставит вам .xcworkspace (в основном используемый cocoa pods), который содержит ссылку на различные модели pod

Это решение, потому что он работает над настройкой, то есть при создании в Xcode мы создали специальную схему, которая установила модуль и скопировала все правильные активы (как CI)

Ответ 3

Лучше создать фреймворк, который будет содержать наиболее общий код, который вам нужен во всех трех вариантах. Кроме того, первый вариант является плохим в любом случае. Для лучшего контроля лучше иметь вариант 2 или 3. Рабочее пространство более предпочтительное, imho, поскольку оно не повредит другим подпроектам, если вы, например, решите использовать cocoapods. Рабочее пространство также позволяет вам иметь различный набор локализаций в каждом проекте. Кроме того, в списке целей будут отображаться только целевые объекты, относящиеся к конкретному проекту, что лучше, чем куча цели в одной куче (если у вас есть, например, расширение общего доступа во всех продуктах - будет сложно найти тот, который вы необходимость). То, что вы выбираете, зависит от ваших потребностей, но как второй, так и третий варианты достаточно хороши.

Ответ 4

Это вопрос, о котором многие разработчики много раз задумывались, и они придумали разные решения, отвечающие их потребностям. Вот мои мысли об этом.

Помещение общих частей, которые вы можете видеть в качестве ядра, во что-то отдельное, - это хорошо. Помимо поддержки повторного использования, он часто улучшает качество кода благодаря четкому разделению и чистым интерфейсам. По моему опыту, это облегчает тестирование. Как вы упаковываете это определяется тем, что вы там вложили. Статическая библиотека - довольно неплохое начало для основной бизнес-логики, но не имеет поддержки для Swift, а ресурсы - больно включать. Рамки великолепны, но повышают планку минимальной цели разработки iOS. Конечно, если вы просто используете очень мало файлов, просто добавление папки в ваши проекты приложений может также работать, поэтому обновление структуры проекта может быть автоматизировано (это делает dropbox/djinni), но это не -ривиальный подход.

Тогда есть фактические продукты для сборки, которые должны включать основной модуль и отдельные части. Это может быть проект с несколькими целями или рабочее пространство с несколькими проектами или сочетание обоих. В данном контексте я принимаю решение в зависимости от того, насколько близки приложения. Если кто-то является незначительным изменением от другого, например, сменой спортивной команды или настройкой некоторых функций, как в свете против pro, это будет разные цели в одном проекте. С другой стороны, я бы использовал разные проекты (возможно, организованные в рамках общей рабочей области), если приложения явно отличаются друг от друга, например, клиент Facebook и клиент Twitter, приложение для настольных игр для офлайн-игры и онлайн-игровое приложение и т.д.

Конечно, есть еще много вещей, чтобы рассмотреть. Например, если вы создаете приложение для клиентов и отправляете источники, возможно, нужны отдельные проекты ,

Ответ 5

Я думаю, что лучший способ сделать это - это то, что охватывает все 3.
Сначала я бы создал настраиваемую структуру, которая разделяет все цели, все, что у них общего, от пользовательского интерфейса (таких элементов, как пользовательские предупреждения и т.д.) До бизнес-логики.
Затем я создам разные пакеты или папки для каждой целевой проверки целевого объекта членства (таким образом вы гарантируете только импорт точных ресурсов), а затем используя макрос препроцессора, вы можете создать конструктор путей, специфичный для правильного пакета или каталога, в котором находятся ваши ресурсы.
За эти годы я собрал несколько интересных ссылок о лучшей практике. Вот они:
Использовать каталог активов с несколькими целями
Использовать несколько тегов XCode 6
Группы XCode против папок
Создать библиотеки с ресурсами
Создать бесплатную и про версию приложения

Я знаю, что в SWIFT они внесли некоторые изменения в макросы препроцессора, поэтому некоторые статьи все еще действительны, но немного устарели.

Ответ 6

Мы все сталкиваемся с такой ситуацией. Но вот что я делаю, и, возможно, вы можете выбрать что-то здесь, что может вам помочь. (Надеюсь).

• имеет проект, содержащий основные функции
• имеют модульные проекты, которые могут использоваться другими вариантами продукта.
• управлять проектом под управлением версиями или потоком git, который поможет сохранить основной источник/проект под основной ветвью, доступной через ветки/функции
• при необходимости создайте новую ветку/функцию для варианта проекта или просто включите/отключите или используйте модули проекта, необходимые для этого варианта (что наиболее подходит для текущей настройки).
• Если приложение имеет веб-службу, к которой он подключается, предоставляйте этап лицензирования, когда мобильное приложение будет делать это сначала, когда-либо запрашивает общий (для всех вариантов или даже всех мобильных приложений) URL веб-службы. Эта веб-служба интерпретирует запрос и отвечает данной информацией тем, что будут настройки приложения (например, веб-служба для подключения к указанному номеру лицензии, модули, которые будут включены, логотип клиента и т.д.).
• основные проекты и созданные модули могут быть преобразованы в рамки, библиотеки или даже пакеты для ресурсов и активов в зависимости от уровня или частоты внесенных изменений в эти элементы. Если эти предметы постоянно меняются или обновляются другими, то не сжимайте их; иметь рабочее пространство с целями, которые связывают весь проект/модуль с текущим вариантом проекта, чтобы изменения в этих модулях отражались сразу (с учетом контроля версий, конечно).