Support for Frameworks / Swift

[mrackwitz]

Support Requests

Please make issues on this repo: https://github.com/CocoaPods/swift

Pull Request

Please make support requests around Swift CocoaPods on this repo: https://github.com/CocoaPods/swift

This Pull-Request makes first steps to bring the long-awaited Swift support by supporting Frameworks. Along the way it keeps full backwards-compatibility with CocoaPods 0.35 and tries to break as few stuff as needed.
This PR supersedes #2222. See this for some of the original discussions.

Steps

To make that all happen, the following path was taken, described here very roughly:

• Recognize Swift source files by file accessors
• Extend the analyzer to decide when it is required to build a framework
• Generate a framework product type if required
• Generate a custom umbrella header to import all public headers and avoid naming conflicts
• Generate a custom module map to inject the umbrella header
• Namespace frameworks in directories in build path, as their naming is constrained
  by underlying clang modules
• Migrate from a linked aggregate library to a linked framework (which is still just used instead of a target dependency to indirectly trigger the build of all pod targets)
• Link the built pod frameworks by build settings to the user target
• Set the build settings appropriate to reach all that
• Embed the built pod frameworks with a shell script build phase to the host application to allow configuration-dependent pods
• Auto opt-in OS X targets and iOS 8+ targets to dynamic frameworks (to be discussed in a separate issue, at the moment possibly more helpful for feedback)

What has happened so far:

All the steps described above. See the commits below. That's already a very condensed history, which was the result of a lot of trial-and-error and has been squashed to a reasonable length.

Checkout:

To get as much feedback as possible, feel encouraged to check out this branch in your local clone of Rainforest. If you use bundler's local gem feature, make sure that you checkout the right branches on the linked repos. (See below Dependencies for reference.) Make sure to run bundle install. You may want to make sure, that you install it to a gemset, you can use for the projects, you want to develop with. Right after that you should be able to install the CocoaPods gem with rake install to your current gemset.

If you use it and you mention a serve problem, like a crash appears or your xcodebuild fails:

1. Update your local copy. This crash could been already fixed. Please make sure to get a clean checkout from this branch as the upstream could have changed due to rebases, which could cause undesired local merges / conflicts.
2. Search if someone has already created an issue for your problem, if so please take a look and provide more helpful information. If that's not possible, please don't +1, if not explicitly asked for it. We will try to solve all problems anyway.
3. If there is no issue, please create a new issue, after reading our contribution guidelines. Prefix it with [Frameworks] and provide a reference to this Pull-Request on your newly created issue by referencing its number #2835.

Open Todos:

The following things are still open to do:

• Add an example with Swift code
• Add a fixture of SwiftPod for unit tests
• Build podspecs for some OSS projects and test pod spec lint
• Rebase after the release of 0.35.0
• Add missing unit tests
• Add dedicated integration tests
• More tests & experience with real-life projects
• Add a CHANGELOG entry

Dependencies:

This depends on the following PRs:

• Generate targets with same build settings as Xcode (related to #164) Xcodeproj#166
• Framework / Swift Support in CocoaPods Core#195
• Framework / Swift support cocoapods-integration-specs#17

Related issues:

• issue/2871 - Fix the framework copy and codesigining issues #2873 (Fix archives / code signing issues)
• [Frameworks] Incomplete Swift Runtime Libraries #2894 (Incomplete Swift Runtime Libraries)
• [Frameworks] Allow to opt-in using Podfile DSL to integrate pods as frameworks Core#204 (Allow to opt-in using Podfile DSL to integrate pods as frameworks)
• [Frameworks] Allow to customize the module name Core#205 (Allow to customize the module name)

/c @CocoaPods/core

[orta]

I think a lot of people will want to do thanks and +1s etc, please move that to twitter and show @mrackwitz some love.

In the meantime, I've tried installing this locally using Bundler. I've extended my Gemfile in the eidolon project to include the following:

gem 'cocoapods', :git => 'https://github.com/CocoaPods/CocoaPods.git', :branch => 'swift'
gem 'cocoapods-core', :git => 'https://github.com/CocoaPods/Core.git'
gem 'xcodeproj',  :git => 'https://github.com/CocoaPods/Xcodeproj.git'
gem 'claide',  :git => 'https://github.com/CocoaPods/CLAide.git'

Running with this on eidolon and doing a pod install with only Obj-C deps for now results in this integration stage error:

NoMethodError - undefined method `display_name' for nil:NilClass
/usr/local/var/rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/bundler/gems/CocoaPods-eaef33b4f672/lib/cocoapods/installer/user_project_integrator/target_integrator.rb:214:in `block (2 levels) in native_targets_to_integrate'
/usr/local/var/rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/bundler/gems/CocoaPods-eaef33b4f672/lib/cocoapods/installer/user_project_integrator/target_integrator.rb:213:in `each'
/usr/local/var/rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/bundler/gems/CocoaPods-eaef33b4f672/lib/cocoapods/installer/user_project_integrator/target_integrator.rb:213:in `any?'
/usr/local/var/rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/bundler/gems/CocoaPods-eaef33b4f672/lib/cocoapods/installer/user_project_integrator/target_integrator.rb:213:in `block in native_targets_to_integrate'
/usr/local/var/rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/bundler/gems/CocoaPods-eaef33b4f672/lib/cocoapods/installer/user_project_integrator/target_integrator.rb:212:in `select'
/usr/local/var/rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/bundler/gems/CocoaPods-eaef33b4f672/lib/cocoapods/installer/user_project_integrator/target_integrator.rb:212:in `native_targets_to_integrate'
/usr/local/var/rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/bundler/gems/CocoaPods-eaef33b4f672/lib/cocoapods/installer/user_project_integrator/target_integrator.rb:34:in `block in integrate!'
/usr/local/var/rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/bundler/gems/CocoaPods-eaef33b4f672/lib/cocoapods/user_interface.rb:49:in `section'

[orta]

The old libPods.a and their brethren are not removed if you migrate to frameworks.

[mrackwitz]

I'm finding that I have to change things like #import <Artsy+UIColors/UIColor+ArtsyColors.h> to #import <Artsy_UIColors/UIColor+ArtsyColors.h>. Is there a strong reason for only supporting _ in framework names?

Yes, there is. Framework base names (determined by PRODUCT_NAME) must be equal to their underlying PRODUCT_MODULE_NAME, which may only be a C99ext identifier. At least Xcode claims that.

[orta]

Not a specific problem with CocoaPods, but some Swift code will crash the compiler if it has any SWIFT_OPTIMIZATION_LEVEL is not set to "None". We may want to figure a way to make changing that easy. Or it has to go in specific podspecs.

( Offtopic, but this is one reason that the Eidolon app has to ship entirely unoptimized )

[segiddins]

target-specific

[AliSoftware]

💥