Corrupted info.plist file

I just encountered an issue that I thought I would document the solution of here in case others run into it.

When exporting to iOS, I was getting a message in Xcode saying "The data couldn’t be read because it has been corrupted." referring to the info.plist file.

The problem was that I had used an ampersand in the display title for my game. Since the ampersand is an escape character, this caused problems when Xcode tried to parse the Info.plist file.

Changing the ampersand to "and" fixed the problem - you can do it either in the Unity IDE or in the Info.plist file directly using a text editor. (The problem could also occur if the filenames for icon files have ampersands in them, presumably.)

Hope this saves someone some hair pulling.

 

For this tips !!

 

Yes thank you!

 

you did indeed save a great deal of lost hair, many thanks!

Matt

 

Thanks a lot

 

thanks a lot !!

 

Thanks a lot haha!

 

Woohoo, saving hair for over one year

 

Another reason for the corruption...

When building for iOS, the Info.plist is being corrupted whenever Default Orientation is set to Auto Rotation. The Info.plist file is created properly on the first build, but subsequent builds results in...

<key>UIInterfaceOrientation</key>
<string></string>
</string>

... at this point Xcode fails to build the project.

 

I can confirm this behavior - and I thought I was the only one who 's been experiencing this. I have the plist file open in a text editor permanently to manually remove that extra tag.

 

Thank you, Nephilim - another head of hair saved!

 

Your tips was really appreciated thank you very much!

 

THis tip is better than the energisor bunny. 2 years later and still keeps saving people including me.

 

God bless thread owner, solved my problem

 

Thank you! It's the gift that keeps on giving! Solved my problem too.

 

Saved me too !!! you'd think they would make an appropriate error message.... "invalid characters used in App Name, use alphanumeric only"

 

We are talking about Apple here...

 

I am experiencing this exact issue in Unity 4.3.4f1 when using the "Build and Run" function for iOS. Has this been solved or reported as a bug to the Unity team?

 

Original bug was fixed, and if I'm correct fix is available since 4.5. http://issuetracker.unity3d.com/iss...nnot-be-parsed-if-a-project-name-contains-and

Not sure about the default orientation thingy, but if you still get it with 4.5, then please fill a bug report.

 

I am still seeing this in 4.5.1f3. It occurs when using the Facebook plugin (version 6.0), which adds an odd property block to info.plist (pasted below), while leaving default orientation set to autorotate:
<key>CFBundleURLTypes</key>
<array>
<dict>
<key>CFBundleURLSchemes</key>
<array>
<string>fbYOUR_APP_ID</string>
</array>
</dict>
</array>

Using append builds, on the second time through, it causes the orientation field to show up as:
<key>UIInterfaceOrientation</key>
<string></string>
</string>

 

The more direct cause of this is that a newline is added within the string field due to system.XmlDocument being used to read and rewrite info.plist. If the input file looks like this (which seems ok):
<key>UIInterfaceOrientation</key>
<string>
</string>
...then an append build will make it look like this (which is broken):
<key>UIInterfaceOrientation</key>
<string></string>
</string>

 

I found a fix (related to this post http://forum.unity3d.com/threads/facebook-sdk-for-unity-plist-fix.217876/), to be added to PlistMod.cs. I didn't take all of the suggestions in that post. What this does is add a space to the empty string. That seems to keep system.XmlDocument from splitting the line, and the next append build stops blowing up.

//Strip whitespace from empty strings
Regex nonwhite = new Regex("\\S");
XmlNodeList elemList = doc.GetElementsByTagName("string");
for (int i = 0; i < elemList.Count; i++)
{
if (!nonwhite.IsMatch(elemList.InnerText))
{
// Replace with something that keeps formatter from splitting the line.
elemList.InnerText = " ";
}
}

doc.Save(fullPath);

 

I'm now seeing this with 4.6.0, while I didn't have it with 4.5.5.