Cocoapods: `pod update` changes the selected scheme

[RomainBoulay]

Hey,

I noticed that with one of the last pod version, after a pod update the selected scheme is changed to the aggregated pods one. So when I'm back on XCode, I always have to change the scheme back to the previous one (which is the app scheme for probably everyone).

Is there a way to fix this?

Thanks.

[orta]

This is a side-effect of https://github.com/CocoaPods/CocoaPods/pull/3600 - so far there's not been an answer that solves the problem of being able to share a scheme and to not have Xcode change the scheme.

[staminajim]

+1 This is exceptionally annoying for those of us who have to pod install / update often. Perhaps the scheme sharing could be optional so as to avoid this?

[orta]

Yeah, I know where you're coming from ( I get this every time on all of my projects too ) - perhaps the scheme sharing should be opt-in, making the pod attributes only look like:

pod "ORStackView", :path => "/my/path", :shared => true

@neonichu @segiddins @kylef opinions?

[neonichu]

I don't think it should be opt-in, but we could offer a way to opt-out.

[alloy]

More options :sob:

I wonder, though, #3600 is about development pods, whereas the OP here mentions the aggregate target. What gives?

[neonichu]

Good point, @alloy :ok_hand:

@RomainBoulay can you please double check if it is actually the aggregate target's scheme being shared, because that would be a bug.

[RomainBoulay]

@neonichu I doubled check and there's no bug. I was referring about a development pod. Sorry about the aggregate target confusion, I got mislead by a terrible naming in this project...

So here's a hopefully better description:

After a pod update the selected scheme becomes the development pod of my podfile (there's only one in this file).

To fix the issue, I tried:

• To uncheck the development pod scheme from the 'show' column in the 'manage schemes' menu
• To uncheck the development pod scheme from the 'shared' column in the 'manage schemes' menu
• To uncheck both

These tries don't work, the dev pod scheme got selected after the next pod update.

[bejo]

+1, this happens in my project as well :(

It looks exactly like the feature added in #3600 :) The new scheme gets selected automatically, which is a real bummer.

[orta]

It feels like having this behaviour by default is a bad idea though, we're only doing it to support a tiny subset of people wanting a feature, on a project we don't control, when writing a library at the cost of anyone using a dev pod for any use case.

[staminajim]

That's my feeling too. I expect more people will be inconvenienced by this bug than people having to turn on scheme sharing for dev pods.

[alloy]

It’s not a bug, it’s a feature, which is helpful to some (who want to use a pod without using CocoaPods).

The annoying behaviour is that Xcode changes the selection, so before talking about scratching that feature it would be more helpful if someone would figure out a way to fix the actual annoying behaviour.

[alloy]

@RomainBoulay Thanks for checking and clarifying!

[neonichu]

One possible fix I can think of is retaining shared state if the scheme already exists. So the first time, it'll be automatically shared when doing pod install, but if the user manually adjusts the existing scheme, CP will not share it again.

[alloy]

@neonichu I like it :+1:

[staminajim]

The optional :shared => true flag also has a use in that it if it's not set you won't get the giant list of schemes for each development pod + target which shouldn't be created by default either.

[sobri909]

Ooh, the really long list of Pod-XXX-XXX schemes is a result of this? If that's the case, then would definitely like it to be optional. Those create a very long list of schemes that we have no use for.

Whether it's opt in or out I'm not personally fussed, but it'd be great to be able to turn that off.

[alloy]

Every option we add needs more explanation, so less is better. The option to show the scheme inside Xcode is one that already exists, is already documented, and better known to people outside of CP users. So if @neonichu’s suggestion works then that’s the best of both worlds imo.

[orta]

@sobri909 - that's something else, see https://github.com/CocoaPods/CocoaPods/issues/3766 for an example, it's only pods with :path => 'xx'.

I'm cool with @neonichu's idea, given that schemes are generally in source control. :+1:

[staminajim]

The option to show the scheme inside Xcode is one that already exists, is already documented, and better known to people outside of CP users

If you uncheck show they come back again after pod update so hopefully if @neonichu's suggestion works then hopefully the show flag will be sticky.

[alloy]

@staminajim Yeah definitely, his change suggestion is for it to stick.

[RomainBoulay]

@alloy : Sure. Thanks guys for taking care of this issue!

[Buju77]

I'm cool with neonichu's idea, given that schemes are generally in source control. :+1:

yes shared schemes are in source control, but for us we only check in our own created shared schemes (with all the parameters and arguments set). Not the ones generated by CP. They are not used by us and therefore not checked in.

We generally only create schemes for our own code (mostly app target scheme and unit tests schemes). No point in creating/check-in schemes which only builds CP target. These are libraries that exists else where and have there own schemes already in their repo.

I generally delete all the CP schemes, because we don't need them and I might accidentally check-in a useless shared scheme if not deleted. And I like a tidy small list of useful schemes.

I personally like @orta idea best of opt-in option, as this feature is for a very very very small amount of people. But I also get the point that each new option needs to be explained and documented (but particularly this would only be interesting for a very small amount of people anyway).

So in addition to @neonichu idea, I would propose to also enhance the retaining state to remember if user has deleted the schemes once. If yes, then don't re-create them anymore.

[sobri909]

If it were going to a vote, I'd vote for opt in.

It doesn't seem like something that's widely used, and it creates visual clutter and confusion for those who don't need it. Our schemes list is something like 60 entries long, which seems excessive considering we only want 8 of those (ie the 8 we created ourselves).

So in addition to @neonichu idea, I would propose to also enhance the retaining state to remember if user has deleted the schemes once. If yes, then don't re-create them anymore.

+1

[neonichu]

I don't think we will be able to reliably tell if a scheme has been deleted, there is no way to tell if it ever was there unless we invent a second kind of list of schemes we have created in the past. This feature is critical for allowing the pod-template to be used for non-CP users, so I'd be strongly against making it opt-in.

[peterjenkins]

Does the issue as described on July 15 have a known workaround?

I currently need to click twice each time I pod install, before I can run the project with Command-R.

[neonichu]

The best workaround right now is closing Xcode while doing the pod install — it seems like the Xcode bug doesn't manifest in that case.

[peterjenkins]

@neonichu Thanks, that does help somewhat. In my case I also needed to make my scheme shared.

[neonichu]

Another nice way to get around this Xcode bug: https://github.com/orta/cocoapods-no-dev-schemes

[sobri909]

When is there going to be an actual fix for this in CocoaPods though? Installing a separate app to work around this seems the wrong answer.

[neonichu]

@sobri909 it's an Xcode bug, the correct answer is filing radars — we're going to do this eventually, but can't give an ETA.

[sobri909]

@neonichu Is there an ELI5 explanation for why the shared schemes are necessary by default? This doesn't make sense to me.

[AnthonyMDev]

Would making the schemes shared but also hidden help? Whenever these schemes are created, Shared AND Show are both checked. Can we programmatically uncheck Show?

[staminajim]

I'm still with @orta :

It feels like having this behaviour by default is a bad idea though, we're only doing it to support a tiny subset of people wanting a feature, on a project we don't control, when writing a library at the cost of anyone using a dev pod for any use case.

Even having to uncheck these things manually before having them stick is going to be an annoying experience for the majority of Cocoapods users. IMHO if a new feature is going to inconvenience the majority in any way at all then it should be opt-in.

I'd rather a few people googled for "How to share cocoapod projects with non-cocoapod users" and finding the Podfile option than a lot of people googling "how stop Xcode selecting wrong scheme after a pod update".

[neonichu]

It would be great if y'all with strong feelings would file radars. :satellite:

[sobri909]

@neonichu I think radars are only half the answer though. Some of us (well, me) still aren't understanding why we want this on by default in the first place. To me it's just noise, and even if the Xcode bug were fixed I'd still want to be able to remove the noise. Whether the setting is opt in or opt out, it doesn't matter to me, but I do want to opt out.

[neonichu]

@sobri909 I understand this and you're right, CP should also do something about it, that's why this issue is still open. I'm just thinking filling radars might be more productive than commenting on an issue where there's pretty much agreement that we need to improve the situation from our side.

[mattyohe]

@neonichu I'll use the plugin for the moment, but I'm curious, how can you get this Xcode "bug" to manifest outside of using Cocoapods? Curious what a radar would look like on this subject.

[neonichu]

@mattyohe write to the scheme file outside of Xcode, I presume

[peterjenkins]

If anyone is still using the mouse to switch schemes after each pod install, try Command+Control+[ instead. For me it was a huge relief.

[JanNash]

@peterjenkins made my day!!!

[stale[bot]]

This issue will be auto-closed because there hasn't been any activity for a few months. Feel free to open a new one if you still experience this problem :+1: