The specifics of how your app should work are going to vary a lot depending on your specific use cases and app design, but our general recommendation for push to talk apps is that you shift to using standard push notifications instead of PushKit for message delivery. More specifically, on the receiver side your Notification Service Extension should download the relevant audio and attach that sound to your particular message.
To support that approach, starting in iOS 13, the system looks for possible sound files in the apps group container(s) as well as the preexisting search locations. The documentation hasn't been updated for this yet (<rdar://problem/49122720>), but there is header file documentation describing the details in the comments for "soundNamed:" in "UNNotificationSound.h":
// The sound file to be played for the notification. The sound must be in the Library/Sounds folder of the app's data container or the Library/Sounds folder of an app group data container. If the file is not found in a container, the system will look in the app's bundle.
Breaking that down in detail, we look for sound files in the following order and locations:
- Your apps direct container in "Library/Sounds".
- Your apps group(s) directory in a directory named "Library/Sounds"
- Your apps bundle
The main things to keep in mind here:
- Directory #2 is "Library/Sounds", not just "Sounds". You'll need to create a "Library" directory with a "Sounds" directory inside it, not just a "Sounds" directory.
- The apps direct container is still the first place we'll look, so you'll need to be careful about how you name your files. I would recommend either using the group directory for all sounds or following a naming convention for the two different locations so that they never collide. Your Network Service Extension can't see the contents of directory #1, so it can't know whether or not a particular name will collide.
