Currently, there seems to be an all or nothing approach to supporting rotation on iPhone. Either every screen in your UI supports rotation, or none of them do.
For a some apps however, that approach won't work. They have a number of screens that don't adapt well to a super letterboxed screen size, and a number of others that would benefit from the additional screen space.
Previous discussion on this issue recommends the use of size classes, but this advice fails to recognise that some use cases simply aren't suited to being super letterboxed. Apple's own UI design is tacit acknowledgement of this: For example, the main UI of the Camera app stays fixed in the portrait orientation in the shooting mode, but presents a rotatable modal to review photos and videos. Even Springboard, the home screen of the iPhone, remains locked in the portrait orientation whilst allowing an app to be presented in landscape. Social media and news apps are another example: generally anchored around a portrait newsfeed that doesn't adapt well to extreme letterboxing, but surfacing rich media such as images, videos, charts and other interactive elements that could use the flexibility of landscape presentation. (News app, looking at you.)
Is it time to re-visit the rotation characteristics of the phone vs. tablet idioms? Is this all-or-nothing approach to rotation serving the platform well?
Regardless, app designers at Apple and elsewhere are creating apps that use this hybrid approach to rotation. And as things stand today, SwiftUI makes it very difficult. A rough equivalent can be made using a ZStack and observing the device orientation, but this requires hiding the status bar and provides no way to honor a user's portrait lock settings.
The only other option, as far as I can tell, is building the app using UIKit view controllers, to thread through supportedInterfaceOrientations hooks.
Personally, what I'd love to see is a new presentationInterfaceOrientations(_:) hook on View, that allows a fullScreenCover presentation to be specified as supporting an alternative orientation set. This could be iPhone only, and should serve the majority of use cases.
However, in the meantime, it would be great to know if there's a technique that can get the UIKit behavior in a SwiftUI app that doesn't require rewriting the entire container view hierachy in UIKit.