On Demand Resources - NSCocoaErrorDomainCode 4994

Solved by upgraded to XCode 7.3

I've changed nothing in my app.

Not particularly happy with Apple developer communications.

Hi,

I have successfully implemented the ODR for an app at debug level and everything worked fine on Xcode 7.2.

Suddenly I started getting this error after I restarted the MAC.

now spent many hours and upgraded to Xcode 7.3.1 today.

But I am having the same ERROR :

Error Domain=NSCocoaErrorDomain Code=4994 "Die angeforderten App-Daten sind nicht vorhanden." UserInfo={NSLocalizedFailureReason=Request could not be completed. Invalid tag in set '{(

GERMAN

)}.'}

But I KNOW that my Tags exist. i am hosting the Asset packs on a private server.

Any APPLE staff... reading this ????

same problem here. I am trying to use this feature for the first time.

Hi,

Were you able to figure out the issue and solve it?

I get the same error message. But, for me, it doesn't work only on specific devices (2 of the 10 tested devices - iPad Air & iPad Mini 1). On iPhones, it downloads fine.

TestFlight build shows that my ODR Asset pack is available.

Any ideas?

Hi,

Did you figure it out? I am in the same situation but iPhoneSE and iPad air 2 are not working in my case. Both of my devices are ios10.0.1 what are yours?

when app runs from Testflight, On-Demand Resource

beginAccessingResources returns following error:

error.localizedDescription

The requested application data doesn't exist

error.localizedFailureReason

InvalidTag

I have a game live in the App Store. About 30% of my players are experiencing this issue. Its very frustrating.

Symptoms are that the ODR assets pack with tag "BK035" (in my case) are marked for "Initial Install" but when the app launches the call to beginAccessingResources returns a "The requested application data doesn't exist" error. This corresponds to the 4994 error; "Invalid Tag".

The tag definitely does exist because the other 70% of players can access it just fine. This is getting us bad reviews in the App Store.

Other information:

** I've logged a TSI with Apple. They took several days to respond, and then asked for an IPA file. I gave them that end of last week.

** I believe this is some sort of race condition or similar and its a bug within Apple's ODR system. It is not reliably reproducible.

** It never happens on connection with Xcode in the debugging case

** It sometimes happens with a Test Flight build, and sometimes happens with a live produciton (App Store) build.

** It seems to be sticky: once a device manifests the issue, even re-installing the app doesn't fix it.

It is going to be a massive amount of re-work for our tiny team to code our own ODR solution. Apple, what's going on?

I am having the same issue. What seems particularly problematic is the part about uninstalling and reinstalling having no effect on the problem. Are ODR resources stored outside of an app's bundle or sandbox. I am thinking I will need to rip out all the ODR code and serve the content up manually. Apple's services are proving to be really unreliable. Makes it hard to have confidence in using them.

Got a response from Apple, basically indicating that my emails or the details of the issue hadn't even been read. Turns out the IPA file they wanted was the one you upload to the App Store if you use the old Application Loader, as you had to prior to Xcode having an "Upload to App Store" button.

I responsded to this with a big long paint-by-numbers email, included a new IPA file, and describing the issue all over again.

I have done a bit more forensics on it as far as I can - but still no further ahead. Basically this ODR Fail issue is crippling our operation. I'm going to have to try ripping all of the ODR stuff out and hosting the content in Firebase.

I used the Charles proxy to examine the behaviour of the app on download from TestFlight and then on launch. I see in the Charles console the IPA package being downloaded. On launch there's various calls for things like Game Center and our Google stuff. As far as I can tell there is no check on the App Store or via the internet at all when the app tries to open the ODR content. In fact the API call to `beginAccessingResources()` does not call out to Apple's servers as far as I can tell - it simply returns straight away with the 4994 _The requested application data doesn't exist_ error.

I interpret this to mean that something is wrong with the IPA package that is downloaded to the device from the App Store (or from Test Flight as the issue manifests there as well). In particular I think something is going wrong with the App Thinning IPA package generation on Apple's servers. I believe there is some sort of race condition or whatever in Apple's server side App Thinning package build and that for whatever reason the result is that the information about the asset tags is corrupted or incomplete.

No-one else seems to have solved this issue either.

https://forums.developer.apple.com/message/125315#125315

https://forums.developer.apple.com/message/139828#139828

One further bit of theorizing: I noticed that for a given device if the ODR Fail issue occurred on the device it would continue to occur through subsequent app deletions and re-installs off Test Flight or the App Store **for that build version**. Just bumping the build version could make it start working again. We have a few dozen devices across our testers and beta-test community and what we'd see is that say 1.4 (8) would work on device A but fail on device B, then we would make a new build with 1.4 (9) and that would ODR fail on device A and work on device B. There was no discernable pattern across devices, OS or whatever. It was not due to lack of space on a device, being signed in or out of the App Store. Nohting.

If I'm right that the IPA package is being corrupted on the server, then what is happening IMHO is that the Test Flight App or the App Store App has a local HTTP cache (the application's NSURLCache) which stores the download IPA that was retrieved (having been generated on-the-fly by Apple's servers. So on a subsequent reinstall it just gets the corrupted IPA from the web cache again. That would explain this **sticky ODR Fail** behaviour.

Have you had any luck since your last post?

We are experiencing the similar problems. Our On-Demand Resources in our 3-month old app version have recently stopped working.

We have limited means to diagnose this now in the App Store version. Reboots, re-installs, switching networks makes no difference.

My App has the same problem. The ODR are marked as "Initial Install" and work only on some devices.

Don't know if it is going to be of any help, but I'd like to add an additional finding:
For debug builds, the build setting EMBED_ASSET_PACKS_IN_PRODUCT_BUNDLE is set to YES.

But even then, the ODR fail to load on some of our test devices with error code 9449 (NSBundleOnDemandResourceInvalidTagError).

So there is no TestFlight or Apple Server involved, but the problem occurs anyway.

I double and tripple-checked all my ODR related settings but can't find any issue.

From what I have read in this thread I am conviced that it is a bug on Apple's side but I am not having much hope that this issue will be fixed any time soon.

I am just gonna remove all ODR stuff from my app and replace it with a custom solution...

I have been getting this message "randomly" with no solid reproducible steps for the past 6mo or so since I started using ODR in my app.

Really frustrating. Tried everything under the sun. Clean, EMBED_ASSET_PACKS_IN_PRODUCT_BUNDLE yes and no, version / build bump, etc

I agree this must be an apple issue as there is nothing I can do.

At my wits end...

I have recently switched one of my most popular apps over to ODR, and I am also encountering what seems like random failures among vast swaths of my users. This seems to be wholly unrelated to the actual quality of the network connection and just seems to happen seemingly at random.

However I think I may have a theory that would tie this to the erratic behavior that the App Store seems to have with the App Store receipts installed alongside the app. From analytics logging such failures, it appears that these receipts are not getting installed properly with downloaded apps for at least 10% of my user base (which is a huge number for something so crucial).

The receipt can be located with the appStoreReceiptURL property of NSBundle. Parsing the receipt is quite involved, and I used to rely on it for anti-piracy measures and as a quick shortcut to get a list of past in-app purchases. Months ago I was forced to stop relying solely on this as it became clear that the whole receipt delivery system has been randomly broken and that Apple seems to have no interest in attempting to fix it.

Now what does this have to do with ODR? My theory is that data from these receipts must be used as part of some kind of authentication mechanism to access ODR in production. If it is somehow missing or corrupt (which happens way too often for a production environment), it seems to correlate with the user's inability to access ODR in an otherwise sane network environment.

My evidence for this is that I have asked some of the users who have contacted me directly when faced with this issue. On a whim, I asked them to try to use the "Restore IAP" button in my app, which in effect restores (or installs if it was missing) the App Store receipt. This may be anecdotal, but in turn this seems to allow the users to then access the ODR they couldn't access before.

So a potential workaround may be to use SKReceiptRefreshRequest to force the download of the missing receipt to the device. What's crazy is that you shouldn't have to do that since Apple should do it for you, and it is utterly confusing for the user to have to enter their App Store credentials to make a basic feature just function as it should.

In any case, whether or not this is the root of the issue, this is certainly a problem on Apple's end, and they really need to fix it ASAP. I may be forced to go back to hosting my own resources as well until they do.

Hey catloafsoft, have you had any positive progress with your ODR issues since Jan? I have now opened a TSI with apple as ODR failing is really an issue on the critical path of our app https://itunes.apple.com/us/app/eyelovebirds-bird-identifier-with-calls-sounds/id956417417?mt=8

Unfortunately this is still happening and I get complaints from users about this almost daily. You would think with iOS 11 on the horizon they would at least try to address these issues... For a little while it seemed to be happening less but as of right now we're back in completely unpredictable territory it seems.