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

Up vote post of Simbad_Marino Down vote post of Simbad_Marino
1.2k views
Posted by
Simbad_Marino
Reply
Add a Comment

Accepted Reply

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"

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Post marked as solved
Add a Comment

Replies

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"

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Post marked as solved
Add a Comment

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

Posted by
Simbad_Marino
Up vote reply of Simbad_Marino Down vote reply of Simbad_Marino
Add a Comment