Is embedding a UIHostingController inside a UICollectionViewCell or UITableViewCell considered "misuse"?

With the release of UIHostingConfiguration for iOS 16 and above, I've seen a few different blog posts and libraries that try to back-port this functionality to older iOS versions.

All of the solutions I've come across will have a UIHostingController inside of the cell and will sometimes have some kind of attempt to handle the parent/child relationship of the ViewController.

Would this approach be recommended or would it be considered a misuse of the UIHostingController? Is something similar happening under the hood with UIHostingConfiguration?

Here is one example of an implementation you can find online: https://gist.github.com/kylebrowning/044b837a9a98135a15ccbb34f664e31f

Accepted Reply

UIHostingConfiguration is the only officially supported way to render SwiftUI content inside of collection & table view cells. Embedding a UIHostingController inside of cells is not officially supported, and you may run into various issues doing this. (On that note, embedding view controllers inside of UICollectionView or UITableView cells is discouraged in general in UIKit, it's tricky to implement correctly and you can run into some unexpected behaviors.)

If you have a deployment target lower than iOS 16, the recommended approach is to continue to use UIKit to configure collection & table view cells on those older OS versions, and only use SwiftUI inside of cells on iOS 16 and later via UIHostingConfiguration.

With that said, if you really want to use SwiftUI for your cells on older OS versions and you are willing to thoroughly test your implementation on those older OS versions, you can try the approach of embedding a UIHostingController to see if that works well enough for your use case, provided that you always use UIHostingConfiguration when running on iOS 16 and later. Even though this has never been officially supported, if you thoroughly test your implementation on the older OS versions and verify it works well enough for you, then it is safe enough to ship on those older OS versions because the system frameworks (UIKit & SwiftUI) don't change on shipped OS versions, and you will be using the officially supported UIHostingConfiguration API on iOS 16 and all newer OS versions. Just keep in mind that you really do need to test your implementation thoroughly on each older OS version because this approach for older OS versions is entirely "at your own risk" without any warranty 😊 and some SwiftUI features may not work or may behave unexpectedly.

Replies

UIHostingConfiguration is the only officially supported way to render SwiftUI content inside of collection & table view cells. Embedding a UIHostingController inside of cells is not officially supported, and you may run into various issues doing this. (On that note, embedding view controllers inside of UICollectionView or UITableView cells is discouraged in general in UIKit, it's tricky to implement correctly and you can run into some unexpected behaviors.)

If you have a deployment target lower than iOS 16, the recommended approach is to continue to use UIKit to configure collection & table view cells on those older OS versions, and only use SwiftUI inside of cells on iOS 16 and later via UIHostingConfiguration.

With that said, if you really want to use SwiftUI for your cells on older OS versions and you are willing to thoroughly test your implementation on those older OS versions, you can try the approach of embedding a UIHostingController to see if that works well enough for your use case, provided that you always use UIHostingConfiguration when running on iOS 16 and later. Even though this has never been officially supported, if you thoroughly test your implementation on the older OS versions and verify it works well enough for you, then it is safe enough to ship on those older OS versions because the system frameworks (UIKit & SwiftUI) don't change on shipped OS versions, and you will be using the officially supported UIHostingConfiguration API on iOS 16 and all newer OS versions. Just keep in mind that you really do need to test your implementation thoroughly on each older OS version because this approach for older OS versions is entirely "at your own risk" without any warranty 😊 and some SwiftUI features may not work or may behave unexpectedly.