FAQ

This page collects some of the most commonly asked questions for Epoxy iOS.

Why would I use Epoxy and UIKit instead of SwiftUI?

SwiftUI is a declarative UI framework that was introduced by Apple in the iOS 13 SDK. We've found that SwiftUI has a fantastic API and is certainly the future of building UI on Apple platforms in the long term. However, in the short to medium term we have found that SwiftUI is not a good fit for most of our production use cases:

• SwiftUI behavior is unstable across iOS versions, with large behavior differences between minor and even patch iOS versions, especially on iOS 13
• It is not possible to substitute a SwiftUI View for a UIView, which makes it hard to mix UIKit and SwiftUI in large apps or gradually migrate to SwiftUI, especially in apps with many custom UI components
• SwiftUI does not yet have the flexibility or maturity of the equivalent UIKit APIs, requiring you to "drop down" to UIKit, often after implementing a large fraction of your requirements using SwiftUI APIs
• SwiftUI hides the underlying view rendering system from consumers, limiting flexibility and introspection capabilities
• SwiftUI requires Swift reflection metadata, which large Swift apps often strip via the SWIFT_REFLECTION_METADATA_LEVEL=none build setting to reduce their binary size

How does Epoxy for iOS differ from Epoxy for Android?

Epoxy iOS isn't an attempt to implement the Epoxy Android APIs on iOS. Instead, Epoxy for iOS shares the same top-level goal of providing declarative UI APIs that wrap imperative platform APIs (e.g. UICollectionView on iOS, RecyclerView on Android). If you've worked with Epoxy for Android in the past and now find yourself using Epoxy for iOS, we hope that you find the concepts of declarative UI API wrappers familiar, but the details of interacting with them will likely differ.

Have a question that's not answered here?

Feel free to open an issue.