Cocoapods: "pod install" converts *.xcodeproj/project.pbxproj to XML format which prevents merging branches

[oleganza]

I have two branches that have diverged pbxproj files (iOS6 maintenance branch and iOS7 branch with some files added/reordered/removed). Normally, I have no problem applying fixes in iOS6 branch to iOS7 — git is capable of merging pbxproj files.

Now I need to add CocoaPods support to my project, and keep the ability to merge changes in iOS6 branch to iOS7 branch. I don't care if iOS6 branch has CocoaPods or not.

1. If I install pods on iOS6 branch, then I wouldn't be able to merge these changes to iOS7 branch because project file would be completely different (and reapplying all iOS7 changes by hand is very cumbersome at this point).
2. If I install pods on iOS7 branch, then I equally wouldn't be able to merge iOS6 to iOS7 for the same reason. (Only now XML file will be on iOS7 side.)

If "pod install" was just adding the stuff it needs and keeping old "plist" pbxproj format, I'd be able to merge my branches without a problem.

My question: is there a possibility to disable XML conversion and keep basic operation working? Or maybe converting to XML on demand in a temp file? Or supporting plist parsing along with XML in ruby scripts?

Thanks.

[alloy]

No, sorry. The old ASCII plist style has been deprecated from the official APIs, which is what we use. Even if we were to dump as old style plist format, we would also have to preserver the order and the comments that Xcode adds. This would take way more time to get working right than we have atm.

The workaround is to open the project in Xcode and make it save, which dumps it in the old style plist again. Also note that we don’t touch your project unless really needed, so you shouldn’t have to do this too often.

[oleganza]

Thanks for reply. Which API exactly do you mean in "deprecated from the official APIs"?

[oleganza]

Yep, making Xcode to save in old-style format before committing really helps. Thanks a lot.

[alloy]

This API: CFPropertyList.

[fabiopelosin]

This limitation will be worked around in the near future with the installation of a command line tool capable of leveraging the internal libraries of Xcode. If this tool will be available in the path of the user it will be automatically called after every save operation resolving completely this limitation.

[fabb]

This limitation will be worked around in the near future with the installation of a command line tool capable of leveraging the internal libraries of Xcode. If this tool will be available in the path of the user it will be automatically called after every save operation resolving completely this limitation.

This one? https://github.com/CocoaPods/Xcodeproj/issues/61

[fabiopelosin]

@fabb yes, see the CocoaPods changelog for more information.

[AliSoftware]

Just wrote an article about this on the Wiki as this was an easily missed one and I'm sure a lot of people are not aware of this new feature.

We probably need to add this info somewhere in those pages on docs.cocoapods.org too? _(Don't know if I can edit them and how)_

[orta]

@AliSoftware we've got that covered, with the https://github.com/CocoaPods/blog.cocoapods.org and https://github.com/CocoaPods/guides.cocoapods.org

Will probably end up merging it into a guide once those are up and running sometime this / next week.

[AliSoftware]

Thanks @orta, but actually I'm not sure I understood your answer. By "we've got that covered" did you mean:

• to answer my "don't know if I can edit them and how" question, by "we got covered the possibility for you (me) to contribute to docs.cocoapods.org thru those two github repos"? _(in that fact I've to admit that I'm not really familiar/at ease with the way those two repos work and are organized, where are the pages, and how those stuff with rake deploy and all work… I would be afraid to break it all ^^)_
• or "we got that covered, we will do that ourselves — using your magic tools that are somewhere in there and regenerate the pages automagically form the wiki or something? — so don't worry about it we will take care of it" ?

Thx.

By the way I agree that multiplying the sources and locations for the documentation is probably not a good idea, we will end up with many different versions of the documentation, some most likely not up-to-date, and some inconsistencies between each version… so totally agree for merging all these :beers:

[mtitolo]

@AliSoftware I've updated the CONTRIBUTING on the working branch of the guides repo to include sine if this information. We'll probably also blog about it once the guides are released.

And yes, the wikis will be going away. All of them. The guides site currently contains all the content (except edits within the past week) from those separate places. Once it's released, the community can fork/edit at will. We'll explain more once it's released.

[AliSoftware]

Ok thanks a lot @mtitolo I got focused on the blog.cocoapods.org repo which was confusing me, so I didn't go as far as finding the CONTRIBUTING.md on the guides repo hidden in a non-master branch :smile: .

Can't wait to see all those places merged so we can finally have a clean place for all of this. :cool:

[orta]

@AliSoftware - that's actually really valid input. We should make the READMEs have a section saying how you can find the articles to edit inline using the github editor. Thanks!

[sairasamdanii]

I have downloaded this project to my mac. But I run command "sudo xcodebuild -target xcproj install DSTROOT=/", it throws DVTAssertions: ASSERTIONS FAILURE. Can someone help me with this.
Secondly, where this project should be placed? in root directory of my project?

[anknetau]

Hi,

Can you be more specific as to what functionality is deprecated? A quick look at the Core Foundation API you linked seems to include alternative ways of reading and writing the same formats without using the deprecated functions.

Thanks!

[kylef]

@anknetau There is no public API to write ASCII-style (OpenStepFormat) property lists in Core Foundation.

[kyleclegg]

Just ran into this issue today. @alloy's suggestion was helpful: "The workaround is to open the project in Xcode and make it save, which dumps it in the old style plist again."

I wanted to note that for the "make it save" piece I changed the version number (anything in the info plist will do) to something else and changed it back and Xcode updated the .pbxproj file correctly. There were a few other changes Xcode made to the .pbxproj file, but those appear to be intended in the current version of Xcode, whereas changing everything to XML was not.

[anknetau]

Note that the source code for core foundation is available. It would be easy to incorporate these routines.

[neonichu]

@anknetau We intentionally do not use C extensions anymore, see also CocoaPods/Xcodeproj#167

[anknetau]

Would the CocoaPods team accept a patch to write to the modern format, or
is the roadmap tied to an external utility?

Thanks for your hard work.

On Fri, Dec 12, 2014 at 8:24 PM, Boris Bügling [email protected]
wrote:

@anknetau https://github.com/anknetau We intentionally do not use C
extensions anymore, see also CocoaPods/Xcodeproj#167
https://github.com/CocoaPods/Xcodeproj/issues/167

—
Reply to this email directly or view it on GitHub
https://github.com/CocoaPods/CocoaPods/issues/1275#issuecomment-66749477
.

[anknetau]

Oh, I see what you mean - you expect all this to happen in Ruby, is that
what you are saying?

On Fri, Dec 12, 2014 at 8:44 PM, Andres Kievsky andres.[email protected]
wrote:

Would the CocoaPods team accept a patch to write to the modern format, or
is the roadmap tied to an external utility?

Thanks for your hard work.

On Fri, Dec 12, 2014 at 8:24 PM, Boris Bügling [email protected]
wrote:

@anknetau https://github.com/anknetau We intentionally do not use C
extensions anymore, see also CocoaPods/Xcodeproj#167
https://github.com/CocoaPods/Xcodeproj/issues/167

—
Reply to this email directly or view it on GitHub
https://github.com/CocoaPods/CocoaPods/issues/1275#issuecomment-66749477
.

[orta]

Yep, adding a compilation step to the gem install cocoapods meant it was difficult for a lot of people to install.

( I don't know enough to talk about how it could be fixed though )

[anknetau]

Understood. It's a tricky problem. Thanks for the information.

[michaelochs]

I ran into the same problem, however, the current Xcode betas do NOT update the project file back to the old format. This could become a big issue, soon!

[kylef]

@michaelochs CocoaPods 0.36 no longer does this.

[itsthejb]

Had never experience this problem before, but it's creeping in with Xcode 7.2.1 and a new project that was probably created in 7.1+. Note that you can still fix it, but you'll have to modify the project to force the save - ie. move a file into different position in a group, something mundane

[ghost]

This is still an issue, and a rather annoying one. Is there an update on how to prevent this from happening? I really hate having to open every *.xcodeproj and forcing Xcode to save it in ASCII format, vs. XML.

[EvanGeminika]

A work around that take to solve this issue is like below:

1. take a backup of android & ios directory
2. delete android & ios directory
3. in project folder execute "react-native eject" which will create android & ios directory.
4. just in case you have some custom setting you can take it from the backup in step 1.