Слияние кода завершено, страница обновится автоматически
Что такое Swift Package Manager? На самом деле Swift Package Manager (SwiftPM) уже существует довольно давно. Я помню, что услышал о нем впервые примерно в 2016 году, когда вышел Swift 3. Однако официальное представление произошло на конференции Apple WWDC в 2018 году.
Однако, несмотря на то, что прошло много лет, уровень распространения SwiftPM в сообществе остаётся ограниченным. Это также связано с общими усилиями по продвижению самого языка Swift. По данным отчёта Stack Overflow за 2024 год можно заметить, что текущее положение Swift немного неловко.
Почему Apple решила создать ещё один менеджер пакетов Swift Package Manager, если у них уже есть成熟的CocoaPods? Основной причиной является желание продвигать Swift, ведь использовать Swift для управления пакетами SwiftPM звучит логично.
Например, в случае Android, где уже используются Groovy/Gradle, начали продвигать использование Kotlin для написания скриптов сборки, что вполне разумно.
Конечно, сам Swift Package позволяет лучше расширять и упаковывать проекты, а также обеспечивает более удобное распространение и интеграцию с Xcode. Как "поздний" сын компании, он имеет некоторые преимущества.
SwiftPM является частью инструментальной цепочки Swift и включён в Xcode, поэтому для использования Swift не требуется установка дополнительных внешних сред.
Swift Package не использует .xcodeproj или .xcworkspace, а вместо этого зависит от структуры директорий и конфигурации через файл Package.swift. Структура проста, например:
// swift-tools-version:5.3: обязательная версионная информация
name: имя библиотеки
products: объекты после компиляции библиотеки, такие как исполняемые файлы или библиотеки
dependencies: зависимости библиотеки, URL и версия зависимых библиотек, могут быть и локальные зависимости, например .package(path:)
targets: базовые цели сборки пакета, цель может определять модуль или тестовый модуль, а также может зависеть от других целей внутри пакета и библиотек, на которые указывают зависимости пакета.```swift
// swift-tools-version:5.3
import PackageDescription
let package = Package( name: "МояБиблиотека", platforms: [ .macOS(.v10_14), .iOS(.v13), .tvOS(.v13) ], products: [ // Продукты определяют исполняемые файлы и библиотеки, которые создает пакет, и делают их видимыми для других пакетов. .library( name: "МояБиблиотека", targets: ["МояБиблиотека", "НекийУдаленныйБинарныйПакет", "НекийЛокальныйБинарныйПакет"]) ), ], dependencies: [ // Зависимости объявляют другие пакеты, от которых зависит этот пакет. ], targets: [ // Цели являются основными строительными блоками пакета. Цель может определить модуль или набор тестов. // Цели могут зависеть от других целей в этом пакете, а также от продуктов пакетов, от которых зависит этот пакет. .target( name: "МояБиблиотека", exclude: ["инструкции.md"], resources: [ .process("текст.txt"), .process("пример.png"), .copy("настройки.plist") ] ), .binaryTarget( name: "НекийУдаленныйБинарныйПакет", url: "https://url/to/some/remote/binary/package.zip", checksum: "Контрольная выдержка содержимого внутри ZIP-архива." ), .binaryTarget( name: "НекийЛокальныйБинарныйПакет", path: "путь/к/некому.xcframework" ), .testTarget( name: "ТестыМойаБиблиотеки", dependencies: ["МояБиблиотека"] ), ] )
> Неужели структура тоже проста?
**На самом деле использование SwiftPM имеет ещё одно преимущество — это визуальная поддержка**, например при добавлении пакета можно увидеть информацию о некоторых официальных пакетах и их зависимостях.
А также некоторые сторонние пакеты, такие как Firebase, **можно добавить через ввод URL Git-репозитория в поле поиска**. Это позволяет добавлять сторонние зависимости прямо в Xcode. А почему я использую такой абстрактный способ? Потому что мне неизвестно, почему метод, показанный на рисунке 2, не работает корректно.
Имеются ли недостатки у SwiftPM? Да, они есть. В дополнение к тому, что количество пакетов от сообщества намного меньше по сравнению с CocoaPods, в настоящее время существует ограничение, что отдельный target не может использовать смесь языков Swift и C. То есть **target может содержать код на Swift, Objective-C или C++, а также на C или C++, но в одном target нельзя смешивать язык Swift с языками семейства C**. Да, **в Swift Package Manager можно использовать отдельно Objective-C, поэтому ваш старый Objective-C пакет также может быть мигрирован в SwiftPM**, если выбран правильный формат, например, указание пути к заголовочным файлам с помощью `publicHeadersPath`. При отсутствии конфигурации значение по умолчанию — это директория `include`.> Таким образом, если существует смешанное использование, то SwiftPM обязательно будет иметь несколько целей зависимости. В этом случае, если ваш пакет хочет поддерживать одновременную публикацию для CocoaPods и SwiftPM, вам могут потребоваться изменения в проекте, такие как добавление макросов конфигурации, например, `swiftSettings: [.define("IS_SWIFTPM")]`, а затем использование `#if IS_SWIFTPM` для различения операций, таких как `import`.
На самом деле, мне тоже не нравится смешанное использование, так как это может привести к некоторым странным ситуациям, например:
- Библиотека B написана на Objective-C и зависит от библиотеки A, написанной на Swift;
- Библиотека C написана на Swift и зависит от библиотеки B, написанной на Objective-C.
В контексте CocoaPods смешанное использование создает множество проблем, таких как ["Flutter iOS Objective-C и Swift смешанное использование столкнулось с проблемами динамических и статических библиотек"](https://juejin.cn/post/7089338745941393438).
Однако смешанное использование является довольно распространенным требованием в реальных исторических сценариях, поэтому в настоящее время обсуждается возможность поддержки целей с источниками на разных языках, например, [swiftlang#5919](https://github.com/swiftlang/swift-package-manager/pull/5919), но пока эта идея еще не реализована.> Например, React Native, из-за отсутствия поддержки смешанного использования, продвижение в SwiftPM происходит медленно. Также были предложения добавить `SwiftPM_dependency` в CocoaPods, чтобы сделать его совместимым с SwiftPM, однако на данный момент SwiftPM кажется не поддерживающим выполнение предварительной обработки команд, что делает невозможным предварительную обработку чистых пакетов C++.
Текст уже был переведён на русский язык, поэтому нет необходимости в дополнительном переводе. Сохранены все спецификации и термины, такие как `SwiftPM_dependency`, которые остаются без изменений согласно правилам перевода.И даже по поводу того, что RN не поддерживает SwiftPM, некоторые люди высказывают недовольство, но стоит отметить, что переход на SwiftPM сам по себе требует значительных затрат, особенно для RN. Поняв некоторые основные аспекты Swift Package Manager, вернемся к теме статьи: **почему Flutter решил мигрировать на SwiftPM, если это так дорого?**
На самом деле, Flutter уже давно начал мигрировать свои плагины в экосистему Swift, и сейчас активно продвигает переход на SwiftPM. Для Flutter это означает:
- **Плагины Flutter будут более интегрированы с экосистемой Swift**
- **Упрощение установки окружения Flutter**, поскольку Xcode уже включает SwiftPM. Если проекты Flutter используют SwiftPM, то нет необходимости устанавливать Ruby и CocoaPods (по словам команды Flutter, они рассматривают возможность отказаться от использования CocoaPods).
Судя по официальным пакетам, большинство необходимых для миграции пакетов уже были перемещены, остались только документация и скрипты.
[](http://img.cdn.guoshuyu.cn/20240806_SPM/image14.png)
Команда Flutter, конечно же, хочет автоматизировать процесс миграции при обновлении Flutter CLI, но пока все попытки, связанные с SwiftPM, проводятся в главной ветке для тестирования.> В настоящее время изменения, внесённые SwiftPM, являются достаточно неразрывными, поэтому если Flutter CLI не сможет автоматически выполнить обновление, то ручная корректировка будет довольно сложной. Подробнее см.: https://docs.flutter.dev/packages-and-plugins/swift-package-manager/for-app-developersОднако скорость миграции сама по себе не является ключевой проблемой; главное — около 10 000 iOS и macOS плагинов на pub, которые должны последовательно перейти на SwiftPM. Это и есть настоящий центр внимания этой миграции.
Ранее Apple начала год с проблемой [Privacy Manifest](https://juejin.cn/post/7349895521395884069), которая затронула сообщество плагинов, и миграция на SwiftPM может оказаться еще более сложной.
**Зачем говорят, что Flutter в конечном итоге откажется от использования CocoaPods? Ранее мы упоминали, что совместимость с обоими системами может привести к значительным дополнительным расходам на обслуживание**, и команда Flutter считает, что будущее за Swift и SwiftPM.
Поэтому можно сказать, что Flutter активно переходит на SwiftPM, однако поддерживать две системы управления зависимостями неэффективно. Мы уже обсуждали причины этого ранее. Поэтому, исходя из моего опыта, **когда SwiftPM станет полноценной частью Flutter, объявление об отказе от CocoaPods не за горами**.
Однако не стоит сильно беспокоиться, так как на данный момент внедрение SwiftPM ещё впереди, например, поддержка сценария "Добавление в приложение" является одной из проблем, поскольку SwiftPM не имеет метода преобразования пакетов в xcframework, как это делает CocoaPods. В то же время, SwiftPM должен знать, где найти фреймворк, чтобы корректно его распознать.Поэтому, если вы еще не используете или не перешли на SwiftPM, можно рассмотреть возможность ознакомления или тестирования, так как общее впечатление от использования SwiftPM действительно лучше, чем у CocoaPods, а сам он более легкий и удобный. **Именно поэтому я надеюсь, что SwiftPM будет внедрен в Flutter как можно скорее, ведь нелюбовь к Objective-C и CocoaPods вполне естественна**, правда?
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )