Shared library is not being sandboxed on physical device

Hello community! I created an app with a golang shared library which runs a mkdir command at start. The app is working properly on emulator but not on physical device, looks like the emulator is properly sandboxing (wrapping) the shared library but in my iPhone I get a permission denied error (probably due to the app trying to write on File system)

How can I reproduce the same sandboxing approach on my physical iPhone as in the emulator?

Below you can see how the path for each looks like:

Emulator installation path(All goo here):

/Users/simbadmarino/Library/Developer/CoreSimulator/Devices/E6258FFC-CA3F-4B7F-BAAE-DDF717096A91/data/Containers/Data/Application/6BA771DD-BE68-454A-926E-A525188CBE38/.btfs

Phone installation path(Permission errors here):

/private/var/mobile/Containers/Data/Application/CB3B300F-07D8-4641-A6FA-4F584D4C6530/.btfs

Answered by DTS Engineer in 714398022

How can I reproduce the same sandboxing approach on my physical iPhone as in the emulator?

The simulator is not an emulator. The simulator runs on the native macOS kernel and when you start digging into the details you’ll find lots of places where it differs from a device. It’s fine to do basic testing on the simulator but the source of truth is a real device. If you find places where the simulator fails to simulate a real device in some particularly annoying way, feel free to file a bug about that.

Below you can see how the path for each looks like:

As to your specific problem, it looks like you’re trying to write a file to the root of the app’s container. That won’t work on a real device. You’ll need to redirect that to a location appropriate for the data you’re trying to store. A good option for this is the Application Support directory, which you can locate with code like this:

try FileManager.default.url(for: .applicationSupportDirectory, in: .userDomainMask, appropriateFor: nil, create: true)

The fact that the simulator doesn’t simulate this restriction is definitely bugworthy IMO.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Accepted Answer

How can I reproduce the same sandboxing approach on my physical iPhone as in the emulator?

The simulator is not an emulator. The simulator runs on the native macOS kernel and when you start digging into the details you’ll find lots of places where it differs from a device. It’s fine to do basic testing on the simulator but the source of truth is a real device. If you find places where the simulator fails to simulate a real device in some particularly annoying way, feel free to file a bug about that.

Below you can see how the path for each looks like:

As to your specific problem, it looks like you’re trying to write a file to the root of the app’s container. That won’t work on a real device. You’ll need to redirect that to a location appropriate for the data you’re trying to store. A good option for this is the Application Support directory, which you can locate with code like this:

try FileManager.default.url(for: .applicationSupportDirectory, in: .userDomainMask, appropriateFor: nil, create: true)

The fact that the simulator doesn’t simulate this restriction is definitely bugworthy IMO.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks, I tried storing the files at root/Documents and now its working perfectly, thank you for the explanation!

Shared library is not being sandboxed on physical device
 
 
Q