Has any one come across file corruption issues with tvOS 26?
I am tracking an issue where files in my app's NSCachesDirectory are getting corrupted (not deleted) when my app is in the background. The issue is sporadic and very hard to reproduce, but is definitely a new issue with 26.
Has any one come across file corruption issues with tvOS 26?
This is the first time I've heard of this. Can you provide more details about what's actually going on (file type, how you're accessing it, what damage has occurred in the file, etc.)?
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
Hi - thanks for asking. My app will download a JSON file which contains a list of image urls which are downloaded and stored in the NSCachesDirectory. I understand the NSCachesDirectory can get deleted by the OS when the app is not running, so on subsequent launch, the app will check for the presence of these files in NSCachesDirectory and will redownload them if they are not available.
This has worked pretty reliably in production for nearly two years. With tvOS 26, there are now inconsistent and sporadic instances when the app exhibits behavior as if these files have been deleted. ie. the images are either missing from the playlist page, or the app uses an onboard backup "failsafe" JSON file to populate a playlist with temporary data if it cannot find or load the JSON file.
I suspect something is getting corrupted because once this issue occurs, the only way to get the app to perform normally again is to delete and reinstall the app. Simply relaunching the app will not fix the issue, as programmed in my app logic and used with success up to this point.
I realize this info is still pretty vague but I am pressed to recreate this issue aside from letting the app "sit" in the background for hours & days during normal Apple TV usage. Is there any way I can trigger tvOS 26 to force-quit my app while it is in the background so I can perform some additional testing? Thanks.
Is there any way I can trigger tvOS 26 to force-quit my app while it is in the background so I can perform some additional testing?
There isn't any tool/app for this, but there are two techniques you can use to achieve similar results:
Your app can stop "itself" at any time by calling either exit() or abort() (which will generate a crash log as well as exiting). We recommend against calling that’s, but that's simply because, in the foreground, it will make your app look like it crashed. I certainly don't have any issue with using it in a development build.
If you want to generate a more "natural" termination, you can use a second app that artificially consumes memory to force the system to terminate your primary app. You'll need to tweak how much and how quickly it touches memory (too much or too fast and the system will kill the foreground app), but once that's done you'll have an app that will force termination anytime you want.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
I'll keep digging...
Good luck and please let me know if you run into anything of have any questions!
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
