We considered a few options:

• Wrapping an MPVolumeView into a SwiftUI view. The problem is that the customization is limited. This probably explains why Apple uses another private volume slider in AVPlayerViewController.
• Alternatively we planned to introduce a VolumeTracker, an observable object, as a way to build custom volume-related controls. Internally, though, we had to use a dummy MPVolumeView and access its subview hierarchy to make it possible to change the volume. This is doomed to fail, though, since an MPVolumeView needs to be inserted into the view hierarchy to ensure that system volume controls do not appear redundantly when changing the volume.
• This is why we considered another option, namely wrapping an almost transparent MPVolumeView into a SwiftUI view. As said above this requires accessing the underlying slider (potentially fragile) but, moreover, updates obtained through key-value observation of its value property were not smooth (when bound to a slider, the slider knob would move in large chunks, a bit erratically). Alternatively we considered key-value observation of AVAudioSession outputVolume property, documented as officially supported, but this approach requires the audio session to be somehow active, otherwise updates are not received.

For all these reasons we decided not to provide any system volume-related API. It is obvious that providing volume controls (outside MPVolumeView) is currently not properly supported by current APIs.

During our experimentations we also shared code between demo playback progress and volume sliders. We intended to provide the common generic slider implementation as a PillarboxPlayer UI component but finally decided not to, as the API design was still half-baked (should we support slider vertical orientation? A styling API?).