SBAppContextHostView is a UIView subclass that is used for displaying an application when it is not actually open, or when it is being manipulated. In iOS 5, Apple split the management and tracking of contexts into SBAppContextHostManager, leaving SBAppContextHostView to simply be a container for the CALayerHosts which represent each window.
Where it is used
SBAppContextHostView is used for effects that need to seem as if they manipulate the application itself, for example, the multitasking switcher. When the switcher is shown, it slides the application up to reveal the bar, without affecting the app itself. This is accomplished by enabling context hosting, via the app's corresponding SBAppContextHostManager class. This allows the SBAppContextHostView to display the app, rather than having the app display normally, and take up the entire screen.
How it fits into SpringBoard
Each SBApplication has an SBAppContextHostManager to monitor the applications contexts. Each SBAppContextHostManager has an SBAppContextHostView. Below iOS 4 the SBAppContextHostView managed displaying the CALayerHosts and tracking contexts. In iOS 5 and above this has been split up into 2 separate parts so that access to the view can be controlled by the SBAppContextHostManager, now that there are more classes using it. When an object asks an SBAppContextHostManager for the view it instead returns an SBHostWrapperView with the SBAppContextHostView as a subview, so that it can then hand it to another object without causing the first any problems (besides a now empty SBHostWrapperView).
Special considerations
Resizing
As this UIView is little more than a container view for CALayerHosts, the weirdness that comes from working with them is inherited by SBAppContextHostView. For example, the view (semi) ignores its frame and renders at the size it wants to. This is not completely true as with clipsToBounds turned on it will crop the part of the application showing to the rect specified as the frame, but the application will not scale for it. For a more detailed overview of the potential problems with using this class, look at CALayerHost itself.
Render tree and superviews
An SBAppContextHostView always wants to be in the render tree. If they aren't and the app creates a new UIWindow (copy and paste menu, UIAlertViews and UIActionSheets are a few examples) then it will crash the render server (SpringBoard until iOS 6 when it became BackBoard). This means it always has to have a superview. Using SBAppContextHostManagers methods to enable and disable context hosting will prevent this problem from happening.
Don't touch SBAppContextHostView itself
You should never use SBAppContextHostView directly. Instead go through the SBAppContextHostManager which will give you an SBHostWrapperView to use with the SBAppContextHostView as a subview. This allows the SBAppContextHostManager to manage all the different objects that want to use the SBAppContextHostView for different things with minimal conflicts.