Создание iOS скомпилированного SDK в swift, который имеет стороннюю зависимость (используя CocoaPods) - PullRequest
Новая
       64

Создание iOS скомпилированного SDK в swift, который имеет стороннюю зависимость (используя CocoaPods)

1 голос
/ 23 января 2020

У меня есть SDK в Swift 5.1 , который наш клиент хотел бы распространять (продавать) в виде скомпилированного SDK вместо предоставления его источников.

К сожалению, этот SDK зависит от некоторой трети сторонние библиотеки, интегрированные с использованием CocoaPods (Alamofire, RealmSwift, ReachabilitySwift и др. c ...). Я знаю, что вы должны избегать сторонних зависимостей в ваших фреймворках / библиотеках, но, к сожалению, мы начали работать над этим проектом после того, как другое агентство запустило его. Этот SDK на самом деле является модулем Cocoapod, но это не скомпилированный модуль.

Каков наилучший подход для распространения этого SDK в виде скомпилированного SDK (во избежание предоставления исходных файлов конечным потребителям, которые ' куплю)?

Насколько я понял, если вы компилируете свой sdk с зависимостью от третьего лица, вы должны быть уверены, что приложение будет использовать те же библиотеки с теми же apli c apis, что и тот, который используется скомпилированным sdk, иначе приложение взломает sh во время выполнения. Насколько я понимаю, единственный способ сделать это - указать очень скомпилированную версию каждой сторонней зависимости в скомпилированном sdk podspe c. Например, Alamofire, '~> 4.2.0'. Но мне не нравится этот подход, потому что таким образом приложение не может использовать более новую версию Alamofire (или другие зависимости), только потому, что скомпилированный SDK был скомпилирован с этой версией.

I'm создание XCFramework, затем podspe c с этим XCFramework, продаваемым как vendored_framework (с использованием CocoaPods 1.9.0-beta2, единственной, которая в настоящее время поддерживает XCFrameworks как vendored_framework).

Я пробовал много разных подходов, например пытаясь собрать скомпилированный sdk как библиотеки stati c и связать его сторонние зависимости как библиотеки stati c, но в этом случае при использовании его в приложении вместе с такими же зависимостями (например, Alamofire) я вижу в консоль "Класс X реализован как в Y, так и в Z. Какой использовать неопределенно" (где Y и Z - sdk и приложение).

Есть ли у вас какие-либо предложения? Как бы вы это сделали?

Спасибо!

1 Ответ

0 голосов
/ 23 января 2020

Когда вы говорите For example, Alamofire, '~> 4.2.0'. But I don't like this approach because this way the app can't use a newer version of Alamofire (or the other dependencies), only because the compiled sdk has been compiled with that version. Я не думаю, что вы поняли концепцию скомпилированного SDK ... Когда вы упаковываете SDK, он будет иметь статус c, поэтому не имеет значения возможность появления новой сторонней версии. зависимости, чтобы обновить SDK, вам нужно выпустить новую версию для клиента, чтобы вы могли загружать ее при необходимости ... Клиент не может обновить SDK самостоятельно, совсем нет.

(должен быть комментарий, но слишком большой для него)

...