WedX - журнал о программировании и компьютерных науках

Быстрое создание скомпилированного SDK для iOS с зависимостью от сторонних разработчиков (с использованием CocoaPods)

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

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

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

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

Я создаю XCFramework, а затем podspec с этим XCFramework, поставляемым как vendored_framework (используя CocoaPods 1.9.0-beta2, который в настоящее время является единственным, который в настоящее время поддерживает XCFrameworks как vendored_framework).

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

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

Спасибо!


  • Вы смогли найти решение этого Марко? 16.02.2021
  • Нет, шон, мы просто заблокировали все версии зависимостей для определенной второстепенной версии в podspec, и мы распространяем SDK таким образом, и до сих пор, похоже, все в порядке. 17.02.2021
  • Привет, Марко, вы можете преобразовать все кокоподы в зависимость от Swift Package Manager. Все перечисленные библиотеки, вероятно, имеют версию SPM. Вот как я это решил. Вам не обязательно использовать кокоподы. 26.04.2021

Ответы:


1

Когда вы говорите 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, он будет статическим, поэтому не имеет значения возможность появления новых сторонних зависимостей, чтобы обновить SDK, который вам нужен. чтобы выпустить новую версию для клиента, чтобы вы могли загрузить ее при необходимости ... Клиент не может обновить SDK самостоятельно, совсем нет.

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

23.01.2020
  • Я знаю концепцию скомпилированного SDK, я думаю, вместо этого вы не поняли мой вопрос;) Я знаю, что тот, кто будет использовать скомпилированный sdk, ЯВНО, не может обновить / изменить сам скомпилированный sdk для поддержки более новой версии третьего партийная библиотека, потому что она ... СОСТАВЛЯЕТСЯ. Вместо этого возникает вопрос: если вы заблокируете версию сторонних зависимостей в podspec скомпилированного sdk, приложение будет привязано к этим версиям зависимостей (или диапазону версий), поэтому в приведенном выше примере приложение не иметь возможность установить, например, Alamofire 4.3.0 в свой Podfile. 23.01.2020
  • Новые материалы

    Как создать диаграмму градиентной кисти с помощью D3.js
    Резюме: Из этого туториала Вы узнаете, как добавить градиентную кисть к диаграмме с областями в D3.js. Мы добавим градиент к значениям SVG и применим градиент в качестве заливки к диаграмме с..

    Я хотел выучить язык программирования MVC4, но не мог выучить его раньше, потому что это выглядит сложно…
    Просто начните и учитесь самостоятельно Я хотел выучить язык программирования MVC4, но не мог выучить его раньше, потому что он кажется мне сложным, и я бросил его. Это в основном инструмент..

    Лицензии с открытым исходным кодом: руководство для разработчиков и создателей
    В динамичном мире разработки программного обеспечения открытый исходный код стал мощной парадигмой, способствующей сотрудничеству, инновациям и прогрессу, движимому сообществом. В основе..

    Объяснение документов 02: BERT
    BERT представил двухступенчатую структуру обучения: предварительное обучение и тонкая настройка. Во время предварительного обучения модель обучается на неразмеченных данных с помощью..

    Как проанализировать работу вашего классификатора?
    Не всегда просто знать, какие показатели использовать С развитием глубокого обучения все больше и больше людей учатся обучать свой первый классификатор. Но как только вы закончите..

    Работа с цепями Маркова, часть 4 (Машинное обучение)
    Нелинейные цепи Маркова с агрегатором и их приложения (arXiv) Автор : Бар Лайт Аннотация: Изучаются свойства подкласса случайных процессов, называемых дискретными нелинейными цепями Маркова..

    Crazy Laravel Livewire упростил мне создание электронной коммерции (панель администратора и API) [Часть 3]
    Как вы сегодня, ребята? В этой части мы создадим CRUD для данных о продукте. Думаю, в этой части я не буду слишком много делиться теорией, но чаще буду делиться своим кодом. Потому что..


    Для любых предложений по сайту: [email protected]