4 ms·

SPM has a lot of issues, though. For example: if you depend on a static library, it will both statically link it _and_ embed the binary; likewise, a static libr

SPM has a lot of issues, though. For example: if you depend on a static library, it will both statically link it _and_ embed the binary; likewise, a static library dependency in a framework will cause build failures ~70% of the time when clean. There's others around resources, etc. I do not believe SPM is mature enough to be the entire platform, and worst yet if you experience any problems it is entirely impossible to customize the behavior. I think it's going to be another year or 2 before dropping CocoaPods entirely is a fair choice for libraries -- SPM works for the most basic use cases, but not all.

tspike 5y ago
Carthage has been a happy middle ground for us. It doesn't dictate the structure or configuration of your project.
- lyptt 5y ago
  Only annoyance for me with Carthage is needing to strip architectures out of the built frameworks in order for the app to be validated when uploading to App Store Connect. It's an awesome solution though, and much better than CocoaPods.
  - AJRF 5y ago
    Carthage supports XCFrameworks now which means this is no longer required.
    - lyptt 5y ago
      Nice! Glad to hear that's finally been fixed
AJRF 5y ago
> if you depend on a static library, it will both statically link it _and_ embed the binary That's fixed in Xcode 12.5 https://developer.apple.com/documentation/xcode-release-notes/xcode-12_5-beta-release-notes https://developer.apple.com/documentation/xcode-release-note...
- ChrisMarshallNY 5y ago
  Ah. I see why this has not been an issue with me for most (maybe not all) of my projects. Most have only a single-layer dependency. Looks like this happens for chained dependencies ("a Swift package with binary dependencies", below), in apps with extensions (I have none). This is from the 12.4 notes[0]: > If you use a Swift package with binary dependencies in an app with extensions, the build system incorrectly embeds the binary dependencies alongside the extension in the PlugIns directory, causing validation of the archived app to fail. (69834549) (FB8761306) Workaround: Add a scheme post-build action which removes the embedded binaries from the PlugIns directory after the build, e.g. rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app"/PlugIns/.framework.* I do not see a note in the 12.5 notes addressing this[1]. [0] https://developer.apple.com/documentation/xcode-release-notes/xcode-12_4-release-notes#Swift-Packages https://developer.apple.com/documentation/xcode-release-note... [1] https://developer.apple.com/documentation/xcode-release-notes/xcode-12_5-beta-release-notes https://developer.apple.com/documentation/xcode-release-note...
  - AJRF 5y ago
    Do you know the difference between dynamic and embedded binaries?
    - ChrisMarshallNY 5y ago
      Any particular reason for the insult? I don't remember saying anything bad about you. Maybe, we could have found more in common than you may think. We both seem to be passionate about the same kind of stuff. I was under the impression that we should make an effort to be a wee bit more respectful with each other, than we might in venues like Reddit or SO (where they have the "digital sneer" down to a science). That was the only thing I could find that mentioned anything like it at all. I checked my builds every which way from Sunday, and I never had a double-embedded static lib. I was wondering if they may have been mixed up. Otherwise, there's nothing at all about it. I pretty much always use static libs, but sometimes, I may need a .framework. I've been using SPM for months, and have published a bunch of libs. I do tend to be conservative, and reduce the surface of dependencies wherever possible. I eat my own dog food, and am the only consumer (that I know of) of my packages. My chains tend to be short.
danpalmer 5y ago
> I think it's going to be another year or 2 before dropping CocoaPods entirely is a fair choice for libraries For libraries this is probably true, but I would imagine that most apps could start on SPM from today and never need to introduce CocoaPods or Carthage (we did, ~1 year ago). There are certainly limitations, but they are disappearing fairly rapidly, and the advantage of simpler builds, no Ruby setup, simpler Xcode project structures, etc, are worthwhile.
ChrisMarshallNY 5y ago
Well, I won't go into the issues that prevent me from using CocoaPods, and why I'm not going to be publishing my libraries on them, from now on, but SPM has worked well for me. I am very careful about what I include in my projects. Most of my dependencies are fairly small ones that I wrote and published. Many are a single source file. I don't see the libraries being embedded in my project, but maybe I need to use something like iMazing to look at the package.

tspike 5y ago

Carthage has been a happy middle ground for us. It doesn't dictate the structure or configuration of your project.

lyptt 5y ago
Only annoyance for me with Carthage is needing to strip architectures out of the built frameworks in order for the app to be validated when uploading to App Store Connect. It's an awesome solution though, and much better than CocoaPods.
- AJRF 5y ago
  Carthage supports XCFrameworks now which means this is no longer required.
  - lyptt 5y ago
    Nice! Glad to hear that's finally been fixed

AJRF 5y ago

> if you depend on a static library, it will both statically link it _and_ embed the binary That's fixed in Xcode 12.5 https://developer.apple.com/documentation/xcode-release-notes/xcode-12_5-beta-release-notes https://developer.apple.com/documentation/xcode-release-note...

ChrisMarshallNY 5y ago
Ah. I see why this has not been an issue with me for most (maybe not all) of my projects. Most have only a single-layer dependency. Looks like this happens for chained dependencies ("a Swift package with binary dependencies", below), in apps with extensions (I have none). This is from the 12.4 notes[0]: > If you use a Swift package with binary dependencies in an app with extensions, the build system incorrectly embeds the binary dependencies alongside the extension in the PlugIns directory, causing validation of the archived app to fail. (69834549) (FB8761306) Workaround: Add a scheme post-build action which removes the embedded binaries from the PlugIns directory after the build, e.g. rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app"/PlugIns/.framework.* I do not see a note in the 12.5 notes addressing this[1]. [0] https://developer.apple.com/documentation/xcode-release-notes/xcode-12_4-release-notes#Swift-Packages https://developer.apple.com/documentation/xcode-release-note... [1] https://developer.apple.com/documentation/xcode-release-notes/xcode-12_5-beta-release-notes https://developer.apple.com/documentation/xcode-release-note...
- AJRF 5y ago
  Do you know the difference between dynamic and embedded binaries?
  - ChrisMarshallNY 5y ago
    Any particular reason for the insult? I don't remember saying anything bad about you. Maybe, we could have found more in common than you may think. We both seem to be passionate about the same kind of stuff. I was under the impression that we should make an effort to be a wee bit more respectful with each other, than we might in venues like Reddit or SO (where they have the "digital sneer" down to a science). That was the only thing I could find that mentioned anything like it at all. I checked my builds every which way from Sunday, and I never had a double-embedded static lib. I was wondering if they may have been mixed up. Otherwise, there's nothing at all about it. I pretty much always use static libs, but sometimes, I may need a .framework. I've been using SPM for months, and have published a bunch of libs. I do tend to be conservative, and reduce the surface of dependencies wherever possible. I eat my own dog food, and am the only consumer (that I know of) of my packages. My chains tend to be short.

danpalmer 5y ago

> I think it's going to be another year or 2 before dropping CocoaPods entirely is a fair choice for libraries For libraries this is probably true, but I would imagine that most apps could start on SPM from today and never need to introduce CocoaPods or Carthage (we did, ~1 year ago). There are certainly limitations, but they are disappearing fairly rapidly, and the advantage of simpler builds, no Ruby setup, simpler Xcode project structures, etc, are worthwhile.

ChrisMarshallNY 5y ago

Well, I won't go into the issues that prevent me from using CocoaPods, and why I'm not going to be publishing my libraries on them, from now on, but SPM has worked well for me. I am very careful about what I include in my projects. Most of my dependencies are fairly small ones that I wrote and published. Many are a single source file. I don't see the libraries being embedded in my project, but maybe I need to use something like iMazing to look at the package.