The drama continues….

In Tech Note TN2247, Apple claims an audio component is sandbox-safe if it does 
not require any access whatsoever to the file system or network, among other 
things. It gives a temporary workaround for older audio unit types, where one 
would substitute the key ’sandboxSafe' in the plist with


<!-- This AU is not sandbox safe so describe it's resource usage -->




    <key>resourceUsage</key>


    <dict>


        <key>iokit.user-client</key>


        <array>


            <string>CustomUserClient1</string>


            <string>CustomUserClient2</string>


        </array>


        <key>mach-lookup.global-name</key>


        <array>


            <string>MachServiceName1</string>


            <string>MachServiceName2</string>


        </array>


        <key>network.client</key>


        <true/>


        <key>temporary-exception.files.all.read-write</key>


        </true>


    </dict>



However, the above keys do not work with AUv3 audio components! Furthermore, in 
order to host them, the enclosing app needs to declare in its entitlements the 
following


<key>com.apple.security.temporary-exception.audio-unit-host</key>


 <true/>



All the above seem to be meant for macOS only, and apparently the temporary 
exceptions are gone with Sierra. So is there any hope for an iOS AUv3 to access 
files from its own sandbox? I am not even asking for the ubiquity container, or 
network access, which would be great, but how is this such a tremendous threat 
that one cannot load a simple audio file the user specifies into an application 
whose sole purpose is to make music?

Any help would be greatly appreciated!





 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list      (Coreaudio-api@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to