How to use SwiftUI

⚠️ This page is under construction

SwiftUI vs UIKit

When faced with the choice between SwiftUI and UIKit, refer to the attached decision tree diagram to determine the appropriate approach for your specific project needs.

Applicable Areas for SwiftUI Adoption

SwiftUI should be prioritized for:

• New Features & Screens with native components (Example: Any new settings screens or preference panel that aligns with the decision tree)
• UI Components with Minimal Refreshes (Example: Static screens such as About pages and settings sub-pages)
• Self-Contained Components (Example: Circular progress indicators, autofill message cards)
• Existing UIKit Components that we can refactor (Example: Alert modals, bottom sheets, and simple lists)
• Refactoring Current Views
  • Only if:
    • UX is aligned with existing flows.
    • Accessibility (VoiceOver, text scaling) is fully supported.
    • Refactoring does not introduce instability and improves maintainability.
    • Works well with our app flow and does not introduce frequent refreshes.

Areas Where UIKit Should Be Retained

SwiftUI should not be used in areas requiring:

• Frequent UI Updates & Refreshes
  • Views that update often, such as real-time data displays, should remain in UIKit.
• Highly Customized UI Components
  • Components that require deep customization beyond SwiftUI’s capabilities should stay in UIKit.
• Accessibility Constraints
  • If full accessibility (VoiceOver, Dynamic Type, etc.) is not easily achievable in SwiftUI, UIKit should be used.

Themening

Theming should utilize @Environment(.themeManager) from EnvironmentValues. For more details see Themeing: SwiftUI View