# Block device setting for Picture in Picture **URL:** \ **Category:** Feature Requests\ **Tags:** ios, bitmovin, pip\ **Created:** [December 22, 2022, 12:05pm UTC](https://community.bitmovin.com/t/block-device-setting-for-picture-in-picture/1592 "2022-12-22T12:05:24Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![mart.zonneveld](https://sea1.discourse-cdn.com/flex015/user_avatar/community.bitmovin.com/mart.zonneveld/32/550_2.png) [@mart.zonneveld](https://community.bitmovin.com/u/mart.zonneveld)\ **Post date:** [December 22, 2022, 12:05pm UTC](https://community.bitmovin.com/t/block-device-setting-for-picture-in-picture/1592/1 "2022-12-22T12:05:25Z")
While using the Bitmovin implementation of Picture in Picture, the device setting to activate PiP by default is blocked by the SDK. But when we want a custom implementation, this blockage is removed. This results in behaviour we cannot control. We’d like an option in the Bitmovin SDK to still block this device setting, even though we are using our custom PiP logic. Right now this isn’t possible. ```auto // Blocks device setting BitmovinPlayer.PlayerConfig.playbackConfig.isBackgroundPlaybackEnabled = true BitmovinPlayer.PlayerConfig.playbackConfig.isPictureInPictureEnabled = true // Allows for custom PiP implementation, adhering device setting, activating PiP when we don't want to BitmovinPlayer.PlayerConfig.playbackConfig.isBackgroundPlaybackEnabled = false BitmovinPlayer.PlayerConfig.playbackConfig.isPictureInPictureEnabled = false ``` ![Screenshot 2022-12-22 at 09.58.19](https://us1.discourse-cdn.com/flex015/uploads/bitmovin/original/1X/adfdcd4342a9874fcbc1b023e29775c7211d5bf2.png) ---
**Author:** ![davidsteinacher](https://sea1.discourse-cdn.com/flex015/user_avatar/community.bitmovin.com/davidsteinacher/32/163_2.png) [@davidsteinacher](https://community.bitmovin.com/u/davidsteinacher)\ **Post date:** [January 2, 2023, 10:08am UTC](https://community.bitmovin.com/t/block-device-setting-for-picture-in-picture/1592/2 "2023-01-02T10:08:11Z")
Hi, In [3.32.0](https://bitmovin.com/docs/player/releases/ios/ios-3-32-0) we added a new [PictureInPictureConfig](https://cdn.bitmovin.com/player/ios/3/docs/Classes/PictureInPictureConfig.html) where you can now configure the desired behaviour. You can block this system setting by setting `shouldEnterOnBackground` to `false`. A few notes on this: - The `PictureInPictureConfig` is part of a new [PlayerViewConfig](https://cdn.bitmovin.com/player/ios/3/docs/Classes/PlayerViewConfig.html) that can be passed to the `PlayerView`s initializer. The old `playbackConfig.isPictureInPictureEnabled` configuration was deprecated in favour of this new config. - This is only available from iOS 14.2 onwards. - If the system setting `Start PiP Automatically` is turned off, setting `shouldEnterOnBackground` to `true` also has no effect. The system setting has precedence in this case. Hope that helps 🙂 ---
**Author:** ![mart.zonneveld](https://sea1.discourse-cdn.com/flex015/user_avatar/community.bitmovin.com/mart.zonneveld/32/550_2.png) [@mart.zonneveld](https://community.bitmovin.com/u/mart.zonneveld)\ **Post date:** [January 6, 2023, 12:26pm UTC](https://community.bitmovin.com/t/block-device-setting-for-picture-in-picture/1592/3 "2023-01-06T12:26:02Z")
Hi David, thanks for your response. As the new config is working fine for a regular `PlayerView`-instantiation, it doesn’t work with a custom implementation. This is easily reproducible with the Bitmovin example project with some changes posted by Alberto to achieve the custom implementation: > [@iOS Picture in Picture player controls visibility](https://community.bitmovin.com/t/ios-picture-in-picture-player-controls-visibility/1504/2): > > Hi Mart, Thanks for posting this. Could you please give the below code a try on your end? It’s a modified version of our [BasicPictureInPicture](https://github.com/bitmovin/bitmovin-player-ios-samples/tree/main/BasicPictureInPicture) app after following [this article](https://bitmovin.com/docs/player/tutorials/how-to-get-picture-in-picture-to-work-on-ios-without-bitmovin-web-ui), and it seems to work fine for me both on 3.16.0 and 3.29.0 on iOS16.1. Note that I’m calling self.playerView.enterPiP() instead of self.playerView.enterPictureInPicture() import UIKit import Foundation //added by alberto import BitmovinPlayer //added by alberto class CustomPiPView: PlayerView, AVPictureInPictureContro… ---
**Author:** ![davidsteinacher](https://sea1.discourse-cdn.com/flex015/user_avatar/community.bitmovin.com/davidsteinacher/32/163_2.png) [@davidsteinacher](https://community.bitmovin.com/u/davidsteinacher)\ **Post date:** [January 9, 2023, 8:06am UTC](https://community.bitmovin.com/t/block-device-setting-for-picture-in-picture/1592/4 "2023-01-09T08:06:24Z")
We discovered similar issues recently internally based on another request. Unfortunately, custom PiP handling in combination with subclassing our `PlayerView` is not supported and results in unexpected behaviour. The problem with this is that our `PlayerView` does not know about the external PiP implementation and can not react accordingly. Can you help me understand what is your use case for using a custom PIP implementation? ---
**Author:** ![mart.zonneveld](https://sea1.discourse-cdn.com/flex015/user_avatar/community.bitmovin.com/mart.zonneveld/32/550_2.png) [@mart.zonneveld](https://community.bitmovin.com/u/mart.zonneveld)\ **Post date:** [January 9, 2023, 9:41am UTC](https://community.bitmovin.com/t/block-device-setting-for-picture-in-picture/1592/5 "2023-01-09T09:41:23Z")
We use the subclassing of `PlayerView` for the management of the player controls inside of the PiP view. We’ve got usecases for disabling the seekbuttons: ```auto controller?.requiresLinearPlayback ``` And disabling play/pause/stop button: ```auto controller?.setValue(enabled ? 0 : 1, forKey: "controlsStyle") ``` Small implementations which wouldn’t be difficult to refactor for us if Bitmovin chooses to implement it in the SDK ---
**Author:** ![davidsteinacher](https://sea1.discourse-cdn.com/flex015/user_avatar/community.bitmovin.com/davidsteinacher/32/163_2.png) [@davidsteinacher](https://community.bitmovin.com/u/davidsteinacher)\ **Post date:** [January 9, 2023, 10:40am UTC](https://community.bitmovin.com/t/block-device-setting-for-picture-in-picture/1592/6 "2023-01-09T10:40:57Z")
Ok I see. At least for the first use-case (`requiresLinearPlayback`) we introduced [PictureInPictureConfig.showSkipControls](https://cdn.bitmovin.com/player/ios/3/docs/Classes/PictureInPictureConfig.html#/c:@M@BitmovinPlayer@objc(cs)BMPPictureInPictureConfig(py)showSkipControls) to configure this. I’m not sure if the second use-case is something we want to have in our SDK as there is no ‘official’ API to control the play/pause/stop button. I also wonder if Apple will let that through the review process. ---
**Author:** ![mart.zonneveld](https://sea1.discourse-cdn.com/flex015/user_avatar/community.bitmovin.com/mart.zonneveld/32/550_2.png) [@mart.zonneveld](https://community.bitmovin.com/u/mart.zonneveld)\ **Post date:** [January 9, 2023, 10:57am UTC](https://community.bitmovin.com/t/block-device-setting-for-picture-in-picture/1592/7 "2023-01-09T10:57:28Z")
The `"controlsStyle"` alteration is indeed not completely intended behaviour by Apple, but they are still approving our builds so far. We couldn’t find any other, neater, solution. If you do know a different approach, we’re all open to it 🙂