Modifying application bundle during development

[rilian]

Scenario:

• I am the lone developer - only person running Xcode on my team. App is compiled for 0S 2.0.
• Level designer is running a tool I developed that can modify the level data
  directly in the application, *after* i've compiled it in Xcode and handed them the application.
• We are modifying one file in the .app (the levels file). We are not modifying PNG's, or anything else in the .app. (PNG's are transformed by the build process, and you can't change them without re-running the build).

We tested this early on, and level designer was able to run the signed app on the iPhone even after modifying level data.

We're now trying to deploy this modified app on a variety of devices. iPod Touch (newest gen), iPhone 3G, iPhone original, OS 2.1, OS 2.2, etc.

We seem to be having trouble running/installing the modified app on the new iPod touches, iPhone 3G, and potentially OS2.2 (iPod touch is running this new OS, no other device is). iPhone original with OS2.1 is running the modified app fine. We get an error that says "unable to install application because it could not be verified" (or something close to this).

Does anyone know the limitations given this scenario? Are 1st gen iPhone's known to have lax .app bundle checking? (i'd think this would be an OS thing, not hardware specific thing, but who knows?)

Has anyone successfully worked in a small team environment like I describe with people modifying data in the compiled .app without sending everything back to the engineer for every single change, or recompiling the app in Xcode (handing around source code to every team member)?

Thanks for reading!

[PhoneyDeveloper]

I believe that there is a plist file that you can create that will exempt a particular file in the bundle from being signed. This way you can allow that file to change without screwing with the signing. You have to add the filename to this plist file and it will ignore that file when signing and verifying.

I don't recall the details but you should be able to look that up.

[rilian]

Phoney,

I've spent a good bit of time searching around for some sort of plist-based solution to exclude a file in the app bundle from signing. I'm not finding it, probably because i'm searching on the wrong things.

Do you have any more specific information that you might be able to lay your hands on more easily than I can? It'd be much appreciated.

[rilian]

I should let you know what i've found so far. I believe the correct term is "sealed resource".

Issuing "codesign -vvvv blah.app" returns the following on the modified .app:

blah.app: a sealed resource is missing or invalid
/Users/foo/Desktop/blah.app/bar.res: resource modified

Issuing "codesign -dvvvv blah.app" returns the following on the modified .app:

Executable=/Users/foo/Desktop/blah.app/blah
Identifier=com.yourcompany.blah
Format=bundle with Mach-O thin (armv6)
CodeDirectory v=20001 size=1165 flags=0x0(none) hashes=50+5 location=embedded
CDHash=505215a391371b9dad458a0f38854c90cf31484b
Signature size=4273
Authority=iPhone Developer: xxxx yyyyyyyy
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Signed Time=Dec 21, 2008 9:00:41 AM
Info.plist entries=17
Sealed Resources rules=3 files=35
Internal requirements count=0 size=12

I still have not found a way to specify an exclusion to the sealed resource list. I imagine it has something to do with the "rules=3 files=35" line above.

Still looking.

[SkylarEC]

Have you tried just putting the file in the Documents directory then having your app read it from there? The sandbox expects the Documents to be messed with (albeit, by your application).

[rilian]

I actually do have a code path that reads this particular data path from the documents directory, but the problem is, how do I get the file to that location?

I could post it on a website for the development team, and have it optionally downloaded and saved in the documents directory - not hard. However, that leads to potential mistakes where I no longer can tell what version of this level file someone is running when they report a bug/problem. Very hard as the engineer to track down the problem if I don't have the same data they do. Then again, giving control to the level designer already sorta exposes us to that problem.

Good suggestion, I will look to use this as a workaround. In the meantime, I would still like to know if anyone has found this codesign "exception" or "unsealed resource" list.

Thanks!

[rilian]

Ok, more breadcrumbs if anyone sees this thread and finds it interesting. Sorry for all the posts.

ResourceRules.plist is probably the file I want. A single copy lives in each SDK directory (default location would be /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS2.x.sdk).

There is a build setting under "code signing" that points to this file. I'm going to try to make an application specific version of this file that "omits" the level data file from signing. Hopefully this will work.

[PhoneyDeveloper]

I think it's the resource-rules file. See

Technical Note TN2206: Mac OS X Code Signing In Depth

Chris Suter's Blog: July 2008 Archives

Code Signing Resource Rules