Поделиться общим кодом между 2 iOS приложениями: Swift Package Manager? Cocoapods? Monorepo? - PullRequest
Новая
       54

Поделиться общим кодом между 2 iOS приложениями: Swift Package Manager? Cocoapods? Monorepo?

0 голосов
/ 22 марта 2020

Я собираюсь начать работу над двумя новыми iOS приложениями, которые будут использовать несколько бизнес-логик c, например, весь уровень API и модели. Вместо того, чтобы копировать общий код в обоих проектах и ​​пытаться сохранить его в синхронизированном состоянии c, я хочу использовать какой-то способ для совместного использования кода.

Сначала я хотел использовать диспетчер пакетов Swift , Создать новый пакет в XCode очень просто, но я не знаю, как использовать локальную версию общего пакета в обоих приложениях, пока я над ним работаю, а также заставить его работать для других разработчиков (или CI! ) проверить приложения. Неужели я не могу зафиксировать приложения, имеющие локальную зависимость от пути, потому что это будет работать только для меня, верно?

Итак, могу ли я использовать локальную версию этого основного пакета, работая над двумя приложениями и этим ядром? пакет, но все же есть все это отправлено в GitHub и что он компилируется на CI и для других разработчиков? Или он будет работать только на моей машине, поскольку он будет ссылаться на локальный путь?

Будет ли использование Cocoapods с частным модулем упростить задачу или я столкнусь с той же самой проблемой работы с зависимостью локального пути от моего компьютер, но хотите, чтобы он работал и для других разработчиков?

Или мне просто go с монорепо, содержащим как приложения, так и общий код, и просто чтобы все использовали относительные пути? Будет ли полезен пакет SPM внутри monorepo в этой ситуации, или просто использовать относительные пути в обоих приложениях?

1 Ответ

2 голосов
/ 22 марта 2020

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

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

def library_pod
  src = ENV["POD_SOURCE"]
  if src == nil && File.file?(".pod_source")
    src = File.foreach(".pod_source").first.chomp
  end
  src = (src || "").split(":")
  case src[0]
  when "dev"
    # local dev pod, editable
    pod 'MyLibrary', :path => '../mylibrary', :inhibit_warnings => false
  when "head"
    pod 'MyLibrary', :git => 'https://github.com/mycompany/MyLibrary'
  when "branch"
    pod 'MyLibrary', :git => 'https://github.com/mycompany/MyLibrary', :branch=> src[1]
  else
    # default: use the release version 
    pod 'MyLibrary'
  end
end

target 'MyApp' do
  pod 'Pod1'
  pod 'Pod2'
  library_pod
end

, где обычно у меня есть POD_SOURCE=dev в среде на моей машине разработчика. .pod_source содержит release на ведущем устройстве и любое подходящее имя ветви в функциональных ветвях, так что мой CI может работать правильно.

...