Cocoapods: Find a way to hide all the Pod Schemes
I have a project that now has 68 additional schemes in my Xcode scheme dropdown since CocoaPods now builds a single target for each library. I have several nested project targets in my Podfile, so it get's pretty noisy when AFNetworking is included in 4 different project targets (since CocoaPods builds a new target for each project target).
I'd like to find a way to auto hide all these schemes in my dropdown menu. It might require a script that goes through my .xcuserdata folder and mucks with the settings there to auto hide them...
Any other ideas?
kcharwood
All 15 comments
I have no existing ideas. Please do experiment and find out what we would have to generate to make this work automatically after generating Pods.xcodeproj.
alloy
on 5 Jul 2013
I have the same issue and was rather surprised by the change when I updated Cocoapods to 0.22.1 on Friday. I'm not sure I understand the motivation for adding each pod in a separate Xcode scheme. Is there a discussion somewhere that details the benefits that the cocoapods development team is after with this change?
BennettSmith
on 5 Jul 2013
The discussion is scattered across issues, the main benefits are:
​- Clean environment to build the Pods, not polluted by the build settings of the other Pods of the target.
​- Pave the way to support different Pods based based on the build settings.
​
Note that we were after building Pods in dedicated targets. The separate schemes are a side effect which could be fixed by making shared schemes in CP and hiding those of the Pods.Â
—
Sent from my iPhone
On Fri, Jul 5, 2013 at 6:50 PM, Bennett Smith [email protected]
wrote:
I have the same issue and was rather surprised by the change when I updated Cocoapods to 0.22.1 on Friday. I'm not sure I understand the motivation for adding each pod in a separate Xcode scheme. Is there a discussion somewhere that details the benefits that the cocoapods development team is after with this change?
Reply to this email directly or view it on GitHub:
https://github.com/CocoaPods/CocoaPods/issues/1185#issuecomment-20528481
fabiopelosin
on 6 Jul 2013
The Show value for shared schemes does not appear to get saved for other users.
Kevin Harwood
Sent from my iPhone
On Jul 6, 2013, at 4:34 AM, Fabio Pelosin [email protected] wrote:
The discussion is scattered across issues, the main benefits are:
​- Clean environment to build the Pods, not polluted by the build settings of the other Pods of the target.​- Pave the way to support different Pods based based on the build settings.
​
Note that we were after building Pods in dedicated targets. The separate schemes are a side effect which could be fixed by making shared schemes in CP and hiding those of the Pods.—
Sent from my iPhoneOn Fri, Jul 5, 2013 at 6:50 PM, Bennett Smith [email protected]
wrote:I have the same issue and was rather surprised by the change when I updated Cocoapods to 0.22.1 on Friday. I'm not sure I understand the motivation for adding each pod in a separate Xcode scheme. Is there a discussion somewhere that details the benefits that the cocoapods development team is after with this change?
Reply to this email directly or view it on GitHub:
https://github.com/CocoaPods/CocoaPods/issues/1185#issuecomment-20528481
—
Reply to this email directly or view it on GitHub.
kcharwood
on 6 Jul 2013
The Show value for shared schemes does not appear to get saved for other users.
@kcharwood I’ll file a radar tonight to request that, we can’t be the only ones that would find it annoying to have to re-apply that setting every time.
alloy
on 8 Jul 2013
Is there any reason that the schemes shouldn't be shared?
@tonyarnold I fail to see the relevancy in this context, can you elaborate on why you ask?
alloy
on 8 Jul 2013
No, carry on.
tonyarnold
on 8 Jul 2013
Mentioned this problem before. It's too noisy when you have many pods.
kejinlu
on 9 Jul 2013
One solution is to not create the schemes in the first place. After you create your project go to Product -> Scheme -> Manage Schemes and deselect "Autocreate schemes". The targets that cocoapods now adds on install will not have a scheme generated for them. When you do need a scheme for a new target, it takes 5 mouse clicks to do it manually. If you already have a ton of schemes, you can shift+select them in the scheme manager and press the "-" button to get rid of them.
almasmith
on 18 Jul 2013
@almasmith Brilliant, no idea why I didn’t try that before. Thanks!
@kcharwood With this suggestion, do we really need more code in CocoaPods for this?
alloy
on 18 Jul 2013
@almasmith that's a creative solution.
Looking at the diff when I change that property, the shared workspace settings file (WORKSPACENAME.xcworkspace/xcshareddata/WorkspaceSettings.xcsettings) gets created/modified. That file has the following contents:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>IDEWorkspaceSharedSettings_AutocreateContextsIfNeeded</key>
<false/>
</dict>
</plist>
What if before every pod update/install you do the following:
- Check for that file
- If it doesnt exist, create it.
- Cache the current value of IDEWorkspaceSharedSettings_AutocreateContextsIfNeeded
- Set IDEWorkspaceSharedSettings_AutocreateContextsIfNeeded to false.
- Run update/install
- Restore the cached value
I imagine it wouldn't be that difficult using plistbuddy.
Also, this value must be stored in the workspace settings, not the project settings, so if you don't have workspace when running pod install, you wont get this behavior. If Cocoapods handled this as part of the workspace creation process, then users will get that behavior for free.
My flight attendent is making me put my computer up now! Be back later with more comments.
kcharwood
on 18 Jul 2013
Actually, I'm not sure that would work. If a user clones the project into a new local folder with IDEWorkspaceSharedSettings_AutocreateContextsIfNeeded set to True, then I think it will populate all of the schemes. We need IDEWorkspaceSharedSettings_AutocreateContextsIfNeeded to be set the shared settings to ensure it doesn't get populated.
With that said, perhaps Cocoapods can by default set IDEWorkspaceSharedSettings_AutocreateContextsIfNeeded to be false whenever a workspace is created using pod install?
kcharwood
on 18 Jul 2013
In addition, would be ice that Cocoapods on first install will change the current schemes to "shared schemes". So other contributors to a project will have same structure
xslim
on 23 Sep 2013
Another possible strategy could be to disable the show flag of the schemes. Currently we don't create the schemes and let Xcode to handle them, however the support for doing so is already present in Xcodeproj.
fabiopelosin
on 23 Sep 2013
fabiopelosin
on 7 Oct 2013
Related issues
k06a
·
3Comments
Curtis-Halbrook
·
3Comments
marzapower
·
3Comments
Mingmingmew
·
3Comments
spencerkohan
·
3Comments
Most helpful comment
One solution is to not create the schemes in the first place. After you create your project go to Product -> Scheme -> Manage Schemes and deselect "Autocreate schemes". The targets that cocoapods now adds on install will not have a scheme generated for them. When you do need a scheme for a new target, it takes 5 mouse clicks to do it manually. If you already have a ton of schemes, you can shift+select them in the scheme manager and press the "-" button to get rid of them.