DEV Community

Cover image for Libraries, Frameworks, Packages: Swift Package.
Sergey Leschev
Sergey Leschev

Posted on • Updated on

Libraries, Frameworks, Packages: Swift Package.

Swift is a cross-platform language and requires a cross-platform tool for building the Swift code. One of the goals Swift Package Manager (SwiftPM) is simplified distribute source code in the Swift ecosystem.

Swift Package contains source files and manifest file (Package.swift). Manifest describes the configuration for the Swift package.

Swift package consists of 3 parts: dependencies, targets and products.

Dependencies: other swift packages, that you are using inside your package. In Package file each dependency specified by source location and version.

Target: As Apple's document says, Targets are the basic building blocks of a package. Is may be either a library or an executable as its product. Before Xcode 12 Swift package could contain only Swift, Objective-C/C++, or C/C++ files. And now the Swift package can contain other resources types: images, storyboards, JSON files, Shell scripts, and much more. You can also localize those resources. That is great and desired improvement. Thank you to all who have contributed to making this available.

Products: the output of your package, either a library or an executable produced by a package, and make them visible to other packages.

Pros:

  • Dependencies managed by Xcode
  • Versions managed by Xcode
  • No binary compatibility requires, package can be compiled for multiple platforms in the same build operation. There is no need anymore to create separate framework target for each platform
  • Distribution in Source form allows inspect the code and step into it while debugging.
  • Swift package can contain images, storyboards, XCFrameworks and more other file types.

Cons:

  • Distribution in Source form will not fit for framework providers, who don't want to share source code.

When you are making architectural choice between static libraries, frameworks or Swift Packages for your iOS application, you should take into account the limitations of each specific project.

Linking too many static libraries into an app produces large app executable files, slow launch times and large memory footprints. Frameworks gives you much more flexibility than static libraries, they can contain resources. But each embedded framework added to project increases startup time as well.

Next Article: Libraries.


Contacts
I have a clear focus on time-to-market and don't prioritize technical debt. And I took part in the Pre-Sale/RFX activity as a System Architect, assessment efforts for Mobile (iOS-Swift, Android-Kotlin), Frontend (React-TypeScript) and Backend (NodeJS-.NET-PHP-Kafka-SQL-NoSQL). And I also formed the work of Pre-Sale as a CTO from Opportunity to Proposal via knowledge transfer to Successful Delivery.

🛩ī¸ #startups #management #cto #swift #typescript #database
📧 Email: sergey.leschev@gmail.com
👋 LinkedIn: https://linkedin.com/in/sergeyleschev/
👋 LeetCode: https://leetcode.com/sergeyleschev/
👋 Twitter: https://twitter.com/sergeyleschev
👋 Github: https://github.com/sergeyleschev
🌎 Website: https://sergeyleschev.github.io
🌎 Reddit: https://reddit.com/user/sergeyleschev
🌎 Quora: https://quora.com/sergey-leschev
🌎 Medium: https://medium.com/@sergeyleschev
🖨ī¸ PDF Design Patterns: Download

Top comments (0)