CocoaPods: Authoring & Publishing a Pod

The Podspec

# MyLibrary.podspec — the manifest describing a publishable pod
Pod::Spec.new do |s|
  s.name             = 'MyLibrary'
  s.version          = '1.2.0'
  s.summary          = 'A short one-line description.'
  s.homepage         = 'https://github.com/user/MyLibrary'
  s.license          = { :type => 'MIT', :file => 'LICENSE' }
  s.author           = { 'Author Name' => 'author@example.com' }
  s.source           = { :git => 'https://github.com/user/MyLibrary.git', :tag => s.version.to_s }

  s.ios.deployment_target = '13.0'
  s.swift_version         = '5.9'

  s.source_files     = 'Sources/**/*.swift'
  s.resource_bundles = { 'MyLibrary' => ['Sources/Resources/*.xcassets'] }

  s.dependency 'Alamofire', '~> 5.8'

  # Optional sub-modules — consumers write pod 'MyLibrary/Networking'
  s.subspec 'Networking' do |networking|
    networking.source_files = 'Sources/Networking/**/*.swift'
    networking.dependency 'MyLibrary/Core'
  end

  s.subspec 'Core' do |core|
    core.source_files = 'Sources/Core/**/*.swift'
  end
end

Validating & Publishing

# Lint the podspec locally — actually attempts to build the library
# against its declared dependencies and platform before you publish
pod lib lint
pod lib lint --allow-warnings   # when warnings are expected/acceptable

# Register with CocoaPods Trunk (one-time, ties publishes to your identity)
pod trunk register you@example.com 'Your Name'

# Publish — validates again server-side, then adds the spec to the
# public registry that `pod install` resolves against
pod trunk push MyLibrary.podspec

# Publishing a new version: bump s.version in the podspec, tag the
# release in git to match (s.source uses :tag => s.version.to_s),
# then push again
git tag 1.2.0 && git push --tags
pod trunk push MyLibrary.podspec

Static Libraries vs Frameworks

• Without `use_frameworks!`, CocoaPods historically built pods as static libraries — problematic for Swift's module system.

• `use_frameworks!` builds pods as dynamic frameworks by default, which most modern Swift-based pods require.

• `use_frameworks! :linkage => :static` (newer CocoaPods) builds static frameworks — combining static linking's smaller app size/faster launch with Swift-framework compatibility.

• A pod with only Objective-C source and no Swift dependencies can still work fine as a plain static library.

CocoaPods vs Swift Package Manager vs Carthage

• SPM is Apple's first-party solution, built into Xcode — no external gem/tool install, no generated workspace files to manage or commit.

• CocoaPods has the largest legacy ecosystem and the most flexible resource-bundling story (asset catalogs, storyboards inside a pod).

• Carthage builds dependencies as prebuilt frameworks you link manually — less "magic" integration than CocoaPods, no generated workspace.

• Many mature codebases still run CocoaPods because migrating dozens of pinned dependencies to SPM is nontrivial, even as new projects default to SPM.