Report

What did you do?

Assume I have a project, which includes a playground. I run pod install on a Podfile like that:

use_frameworks!

pod "Alamofire"
target "MyApp"

What did you expected to happen?

I'd expect that I could successfully import Alamofire into my playground. This would have worked with the old scoping until 0.39, but broke with the 1.0 prereleases.

What happened instead?

The framework isn't found, because pod targets are now scoped by default and playgrounds don't support to extend their framework search paths.

Solutions

I see two actual possible solutions for this issue and not solving the issue as a possible alternative decision.

A: Naive Solution

Only scope pod targets, if there are different conflicting pod variants, which would require that. (Note: Different pod variants per platform are not conflicting as the default configuration build dir is already scoped by platform.) But this might be easily overseen and doesn't really behave predictable for users. This will cause unnecessary confusion.
But having conflicting pod variants is in general fine, so warning on the installation, that there are dependencies, which can't be used in playgrounds doesn't seem to be appropriate. Informing isn't enough, because it wouldn't appear without verbose mode. Scanning the project directory for playgrounds and scanning all contained Swift files for their imports would happen to early and miss imports, which would be added after running pod install.

B: Elaborate Solution

Allow to declare the playground explicitly in the Podfile:

use_frameworks!

pod "Alamofire"
playground "MyApp.playground"
target "MyApp"

This would tell the analyzer to generate the Pod dependencies at least once unscoped. If necessary, pod targets can be duplicated.
This would make the behavior of pods in playgrounds explicit and predictable.
Using different pod variants for different playgrounds would lead to conflicts, which would have to fail the installation. e.g.

use_frameworks!

playground "Foo.playground" do
  pod "BananaKit/PalmTree"
end

playground "Bar.playground" do
  pod "BananaKit/Fruit"
end

Tasks

This would require the following subtasks to be solved:

• Extend the Podfile DSL to support the playground declaration. This should work similar to target, but wouldn't support any of the installer directives as inherit!, use_frameworks! etc.
• Extend the Podfile linter to forbid use_frameworks!(false) for declared playgrounds.
• Extend the Core model to support a PlaygroundDefinition (subclass of TargetDefinition)
• Extend the analyzer to generate unscoped pod targets for playgrounds or recognize that there is a conflict and throw an exception

C: Rejection - That's not among CocoaPods' responsibilities.

We can build plugins, which helps to workaround this issue as https://github.com/neonichu/ThisCouldBeUsButYouPlaying. If the Xcode team should ever decide to support adding additional framework search paths or even xcconfigs for playgrounds, we could re-evaluate this discussion and utilize these new functionalities to treat playgrounds mostly like usual targets.

/c @neonichu