lazerwalker/MWOpenInKit — pull request #6 by mattt (2013-12-13 18:21:46+00:00)
Title: Using Subspecs to Modularize Application Support

Although the current set of applications is pretty manageable at the moment, it will eventually become excessive to include every application with every install (those icon files really add up).

Cocoapods subspecs offer an elegant way to modularize out functionality, allowing the consumer to specify only what they need. The proposed patch organizes apps into top level groups, representing intents, and then a sub-subspec for each individual application. This allows for the following:

#### Podfile

```ruby
pod 'MWOpenInKit' # Works the same as before
pod 'MWOpenInKit/Twitter' # Only include Twitter apps
pod 'MWOpenInKit/Twitter/Tweetbot' # Only include Tweetbot
```

I still have a few lingering concerns that I'd like to get some feedback on:

1. Categorizing sets an important precedent. It's important to make sure the way everything is named and carved up is something we won't eventually regret.
2. This could be further spec'd out to only include relevant handlers for each category. The correct relationship between these categories and handlers would be something to dwell upon.
3. CocoaPods 0.23.0 introduced [the `resource_bundle` method](https://github.com/0xced/HockeySDK-iOS/commit/9602890751209b7884382eea9a6acf5e364480b3), which is perfect for this purpose, but seems to lack the first-class support `resources` does. If we run `pod lint` on this, we get:

```
- ERROR | [iOS] The MWOpenInKit/Browsers/Chrome (0.1.0) spec is empty (no source files, resources, preserve paths, , vendored_libraries, vendored_frameworks dependencies or sub specs).
```

This is either something Cocoapods still needs to implement, or I could be misunderstanding how this feature should work.