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.
Topic:
App & System Services
SubTopic:
Core OS
Tags: