Request File Access from Unity for Apple Vision Pro

Hi, I am trying to load files from the Apple Vision Pro's storage into a Unity App (using Apple visionOS XR Plugin and not PolySpatial package). So far, I've tried using UnitySimpleFileBrowser and UnityStandaloneFileBrowser (both aren't made for the Vision Pro and don't work there), and then implemented my own naive file browser that at least allows me to view directories (that I can see from the App Sandbox). This is of course very limited:

Gray folders can't be accessed, the only 3 available ones don't contain anything where a user would put files through the "Files" app.

I know that an app can request access to these "Files & Folders":

So my question is: Is there a way to request this access for a Unity-built app at the moment? If yes, what do I need to do? I've looked into the generated Xcode project's "Capabilities", but did not find anything related to file access. Any help is appreciated!

Answered by DTS Engineer in 861995022

Hi, I am trying to load files from the Apple Vision Pro's storage into a Unity App (using Apple visionOS XR Plugin and not PolySpatial package).

So, my immediate question here is what your larger "goal" here actually is? visionOS generally uses the same file access model as iOS, which means apps get access to files through one of two broad mechanisms:

  1. The files are added to one of the app’s container directories. There are many different APIs that use the broad "flow", but the simplest case is having your app appear in File.app so that the user can directly add files. Basic access can be enabled by setting UIFileSharingEnabled and (possibly) LSSupportsOpeningDocumentsInPlace.

  2. The app uses an API like UIDocumentPickerViewController to allow the user to give their app access to specific files or directories.

Finally, apps that are built around "documents" generally use the approach described in "Building a document browser-based app", which actually provides a unified interface for both of the two approaches above.

Finally, commenting on this approach:

I then implemented my own naive file browser that at least allows me to view directories (that I can see from the App Sandbox).

This won't work. The primary goal of the App Sandbox is to protect "user data", which is exactly the kind of data you want access to. All the directories you are able to directly access like that are directories that were intentionally left "open" by the App Sandbox, generally because it made our framework easier to implement AND the contents were not considered "sensitive". If you experiment a bit further with your file browser, I believe what you'll find is:

  • Your app is only able to read some of the data it can see and can't really write anywhere it can see.

  • The user doesn't really have any good way to easily modify any of the areas you can "see".

Both of those points are intentional, as you're actually looking at the private details of our own implementation, not the "useful" file system.

All of that is what actually leads to #2 above. The system handles the interface used to select files*, then "hands" your app access to that object through the URL it returns to your app. This ensures that your app only has access to files the user specifically gave you access to.

*Note that bookmark files can be used to preserve file access using the process described in "Persist file access with security-scoped URL bookmarks".

I know that an app can request access to these "Files & Folders":

I don't have a VisionPro at hand to double-check this, so I'm not sure what actually shows up in the interface. However, the flow I've outlined above is actually how sandboxed macOS apps (which have the broadest level of file access), are expected to behave, so my general answer won't really change.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Hi, I am trying to load files from the Apple Vision Pro's storage into a Unity App (using Apple visionOS XR Plugin and not PolySpatial package).

So, my immediate question here is what your larger "goal" here actually is? visionOS generally uses the same file access model as iOS, which means apps get access to files through one of two broad mechanisms:

  1. The files are added to one of the app’s container directories. There are many different APIs that use the broad "flow", but the simplest case is having your app appear in File.app so that the user can directly add files. Basic access can be enabled by setting UIFileSharingEnabled and (possibly) LSSupportsOpeningDocumentsInPlace.

  2. The app uses an API like UIDocumentPickerViewController to allow the user to give their app access to specific files or directories.

Finally, apps that are built around "documents" generally use the approach described in "Building a document browser-based app", which actually provides a unified interface for both of the two approaches above.

Finally, commenting on this approach:

I then implemented my own naive file browser that at least allows me to view directories (that I can see from the App Sandbox).

This won't work. The primary goal of the App Sandbox is to protect "user data", which is exactly the kind of data you want access to. All the directories you are able to directly access like that are directories that were intentionally left "open" by the App Sandbox, generally because it made our framework easier to implement AND the contents were not considered "sensitive". If you experiment a bit further with your file browser, I believe what you'll find is:

  • Your app is only able to read some of the data it can see and can't really write anywhere it can see.

  • The user doesn't really have any good way to easily modify any of the areas you can "see".

Both of those points are intentional, as you're actually looking at the private details of our own implementation, not the "useful" file system.

All of that is what actually leads to #2 above. The system handles the interface used to select files*, then "hands" your app access to that object through the URL it returns to your app. This ensures that your app only has access to files the user specifically gave you access to.

*Note that bookmark files can be used to preserve file access using the process described in "Persist file access with security-scoped URL bookmarks".

I know that an app can request access to these "Files & Folders":

I don't have a VisionPro at hand to double-check this, so I'm not sure what actually shows up in the interface. However, the flow I've outlined above is actually how sandboxed macOS apps (which have the broadest level of file access), are expected to behave, so my general answer won't really change.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thanks @DTS Engineer for your quick & detailed answer!!

So, my immediate question here is what your larger "goal" here actually is?

I am working on a Gaussian Splatting App using the UnityGaussianSplatting package and building for Apple Vision Pro. I want to be able to load splat (.ply / .splat) files from the Vision Pro's storage into the application.

This won't work. The primary goal of the App Sandbox is to protect "user data", which is exactly the kind of data you want access to.

Yeah, that was also what I suspected. Hence my question what the intended way to access files from an app would be.

apps get access to files through one of two broad mechanisms:

Thanks for referring to these, I think I stumbled upon it while researching, but did not consider them further yet because they are solutions that require editing the code in Xcode. Which poses two problems for me:

1 - I don't have a lot of experience with Swift and how Xcode apps are structured.

2 - The Xcode project is generated from Unity, so I would have to change the generated files which I don't know my way around every time I build a new version from Unity

That's why I hoped that there might be a solution to access these features from Unity directly, but I guess there isn't...

I will try approach #1, as that seems to require less effort from the Xcode side. Do you know if the "Documents folder located in the app’s home directiory" (mentioned in the documentation) has some relation to Unity's Application.PersistentDataPath? Because after all I will require some way to expose whatever path / files I have access to on the Apple Vision Pro (even if I got this access through inserting additional Swift code) to the C# / Unity side of things so I can handle file loading there.

I hope I made my problem and requirements clear. Thanks for your support!

I am working on a Gaussian Splatting App using the UnityGaussianSplatting package and building for Apple Vision Pro. I want to be able to load splat (.ply / .splat) files from the Vision Pro's storage into the application.

OK. So the main issue to be aware of here is the difference between "works fine for a developer" and "works well for a user". For development purposes, you can basically just set the two keys (UIFileSharingEnabled/LSSupportsOpeningDocumentsInPlace) and then use your Documents directory as your "working" storage. There could be issues if you edited or deleted those files while your app was actively running, but "you" will just avoid those issues... by not doing that.

On the other hand, if you're planning to ship this to end users then you'll need to use things like file coordination to avoid those issues. Similarly, apps that are more "viewer" oriented (meaning, they don't edit the files they're working with) often use an "import" model where they copy (actually clone, so they don't use additional space) the files that are added into UIFileSharingEnabled instead of working directly out of that directory. That leads them to sidestep all of modification issues.

That's why I hoped that there might be a solution to access these features from Unity directly, but I guess there isn't...

I decided to poke around in Unity's documentation. I believe the instructions at the bottom of this page describe how to add keys to your Info.plist:

https://docs.unity3d.com/2021.3/Documentation/Manual/StructureOfXcodeProject.html

Do you know if the "Documents folder located in the app’s home directory" (mentioned in the documentation) has some relation to Unity's Application.PersistentDataPath?

I didn't find an explicit answer for visionOS in their documentation, but I suspect they're the same directory. For iOS, Unity's docs say:

https://docs.unity3d.com/ScriptReference/Application-persistentDataPath.html

iOS: Application.persistentDataPath points to /var/mobile/Containers/Data/Application/<guid>/Documents.

...which is a somewhat convoluted way of saying "your app’s Documents directory".

One thing to understand here is that the "iOS app model" (which is how all of our platforms work except macOS) is built around the idea that the ONLY file system location your app has direct access to is your "apps container". Your container directory doesn't have a fixed name, but instead uses a UUID as the name which changes under various circumstances (for example, app updates). Similarly, the actual location of that directory is a private implementation detail*, which is why you won't find the path "/var/mobile/Containers/Data/Application/" anywhere in our documentation. Apps always find directories by asking the system for directory locations, never by hard coding paths.

*It already changed once, when we separated app install locations and data containers in iOS 8.0.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Request File Access from Unity for Apple Vision Pro
 
 
Q