Question

My app is bundled with two preinstalled videos, and the user can purchase more through in-app-purchase.

Each video episode is an objective-C object with an ivar called _videoFilePath (property NSString* videoFilePath)

When a video finished downloading, the file path is appropriately set. For preinstalled episodes, it is set once at startup with code like this:

NSString* fileName = [NSString stringWithFormat:@"Chapter_%03d", _episodeNumber];
self.videoFilePath = [[NSBundle mainBundle] pathForResource:fileName ofType:@"m4v"];

(Episode metadata is initialized from a bundled .plist on the first run, and a copy of that .plist is saved in /Documents and used on subsequent runs. This is because the metadata is read/write, but bundled resources are read-only)

I’ve noticed that some users can play the preinstalled videos after upgrading my app. I am currently investigating this, so I deleted the app from the Device, installed version 1.0 (from Xcode->Run), Archived version 1.1 as AdHoc and installed that on top.
As expected, the preinstalled episodes won’t play.

So this time I built/run version 1.1 from Xcode, on top of the AdHoc install, with some breakpoints enabled.

Purchased (downloaded) episodes are saved to the cache, so the presence of a valid file path is not enough to guarantee playback (might be deleted by the system). So I use NSFileMananger to check if the file exists before attempting playback, with code like this:

if (_videoFilePath) {
        // Video File Path is Set...

        if ([[NSFileManager defaultManager] fileExistsAtPath:_videoFilePath]) {
            // ...and file exists in system; 
            // Can Play:

            return YES;                
        }
        else{
            // ...but file has been deleted, possibly as a result of a 
            // restore from iTunes backup; 
            // Can Not Play:

            return NO;
        }
    }

The breakpoints revealed that the fileExistsAtPath: test fails; However the console shows the value of _videoFilePath as:

/var/mobile/Applications/CEAA80EF-A85F-4C60-929D-9BA18E8D1702/[App Name]/Chapter_001.m4v

So, what gives?

Note: Deleting the app and reinstalling version 1.1 seems to fix the problem.
The bug only manifests itself when you upgrade to 1.1 on top of 1.0.

ADDENDUM

After a second of thought (writing things down does help), I think I’ve figured it out. The file path for the resource is obtained on the first run of version 1.0, and saved in the /Documents folder with the rest of the metadata. On upgrade, I assume the ‘Random numbers, letters and hyphens’ part of the app’s path changes to something else, and thus the ‘hard-coded’ path from version 1.0 becomes a broken URL. Must NSLog the full path on both v1.0 and v1.1 to confirm this, but I think I got it.
Answers and comments are still welcome.

Answer 1

So, as I realized after some thought, the full path for bundled resources seems to change slightly on each upgrade of the app; Specifically, the “Long, autogenerated random string of numbers and letter” intermediate directory. My mistake was in saving (i.e., hard-coding) the path on the first install, and using that value even after app upgrades.
I solved it by not caching the path and instead using

-pathForResource:ofType:

each time.