File Provider Extension Sandbox Prevents Shared Library from having write access to temporary storage or App Group.

Question

Created 2w

Replies 1

Boosts 0

Participants 1

I'm not sure if I have found a bug with iOS or if it's just unexpected behavior with my implementation. I have a gomobile library that sets up a local http server. It needs to be able to write to temporary storage. If I use the shared library from my main apps process it can write to the file manager.default temporary storage.

while Xcode is running a debug session I can use that same process from my file provider replicated extension and it works fine. However I realized running my file provider extension where it starts the gomobile shared library directly instead of first from my app the library fails to write anything to the file provider manager default temporary storage or the file provider manager for my file provider domain temporary storage or even the app group library.

it is odd, because I have a swift URL extension that confirms the temporary storage can be written to from swift. I have monitored console logs for fileproviderd, my file extension and have tried writing data to a log file. nothing seems to catch exactly what causes the file provider extension to crash and restart.

I also cannot keep the shared gomobile server running in the background on iOS even if I were to force the user to "authenticate" with the main app first. Im pretty sure the file provider extension needs to run the gomobile library for it to work right.

I'm wondering if something may be wrong with the iOS sandbox that could be preventing the file provider extension to let a c based gomobile shared library from accessing the temporary storage.

Any guidance for further things to try would be greatly appreciated. I have tried every avenue I can think of.

I cannot run just the appex itself on either my m4 pro MacBook or my iPhone so attaching the debugger has been tricky and I don't see much in the way of useful logs in console app either just a swarm of noise.

Im fairly confident it's an issue to writing to temporary storage from the gomobile c library and not much else. App was working great on macOS designed for iPad which just seemed rather ironic that an iOS code base runs better on macOS than it was able to on my iPhone 16 pro max. Like im all for the sandbox I just wish it didn't treat c level gomobile libraries different than it treats the swift code itself.

Boost

Answer 1

HelloBlaine OP

1w

I was able to setup further tests and I am convinced it is a possible sandbox bug on iOS.

The gomobile library is compiled into an xcframework that seems to contain some obj-c code that probably calls C code from the go source code being compiled for apple platforms.

I was able to setup logging and output and confirmed that when I run the file provider extension the swift classes can write to the app group documents url, the file provider domain I configure's manager's temporary storage url just fine.

adding a simple file permissions check to ensure a filesystem path is writable to the go library immediately causes the file provider extension to crash.

removing the write permission check from go allows the file provider extension to startup ok but any attempts to write to the folder from the go library I'm using causes the file provider extension to crash instantly.

in go I'm using standard os.... file operations.

If I make calls to the go library that doesn't write anything to the filesystem it seems to run fine and responses are handled properly.

This is very much an issue with go, gomobile, c, or objc not having write access to the same filesystem paths that swift code is able to write to.

This screams sandbox issues.

It's not an issue if the go library makes writable calls from the main app process instead of the extension, however I cannot figure out a way to keep the main app process running when accessing the file provider extension from the files app.

Also because it works great if the main app process is the process handling the go library calls to write to the app group url or even the file manager default temporary storage. this makes me believe is not iOS in its entirety, just the sandbox around the file provider extension.

Also because the same go module can work fine on the main app process and not work the same on the file provider extension process it can't be the go module or even the go library that's the issue.

The only difference is sandbox or some other bug for file provider extensions that is preventing my go library from writing to anywhere on disk if run from the file provider extension.

I have an app the is built, runs great on macOS, and doesn't work right on iOS, all App Store Connect details are ready to submit. The only hold up seems to be some bug on iOS 18.4 that is preventing my go library from writing to anywhere on disk if run from the file provider extension process.

I'd love to know the feasibility of getting this bug fixed and what timeline that may even happen.

Surely what I'm asking is not unreasonable for code in a file provider extension to be able to write to temporary storage regardless of language, or frameworks used to make the calls.

0