Skip to main content
  1. Series/

SwiftUI Group Session Notes

··641 words·4 mins
IOS Wwdc
wwdc25 - This article is part of a series.
Part : This Article

At this year’s WWDC, Apple released a major change to the design system: Liquid Glass. Notes from the group session regarding SwiftUI:

  • Use color sparingly, as the new design system is intended to be mostly monochrome. Overusing colors can be very distracting and attract users’ attention inappropriately.

  • For use cases where a property is used only within a container or a specific view, make use of Container Values & Preferences for restricted properties.

  • Designs are in beta. Apple has adapted Glass into all Apple apps because they want feedback to improve the design before the beta release.

  • Advice on Custom Tab Bars:

    • Use the standard tab bar as much as possible. Apple has introduced many new APIs for tab bar design to make it better.
    • If building a custom tab bar, make use of the new glass effects, container, and safe area bar APIs to build the tab bar and make it comply with the design system.
    • File feedback if you have mandatory requirements for tab bar functionality to get it into the design system or framework.
  • Apple can’t anticipate every use case, so provide your use cases and needs as feedback for them to design and improve the system.

  • Unit Testing SwiftUI Views:

    • Move logic from SwiftUI to models to test the logic, so you don’t test the UI itself in unit tests.
  • Lazy VStack without Performance Problems for Thousands of Image Loadings (Overall Performance Guide):

    • Use Swift concurrency.
    • Start coding with single-threaded code, then introduce concurrency (SwiftUI concurrency).
    • Use Swift Instruments for performance issues and debugging expenses.
    • Tip: Set a background color to your images and see if the image is actually flickering during app usage, which means the images are invalidating due to some issue. Use this technique to debug.
  • Date picker doesn’t respect Dynamic Type. This is a known issue—file feedback, as there’s no workaround for now.

  • Common Anti-patterns in SwiftUI:

    • Don’t use if statements to apply modifiers to views. These are very performance-inefficient. Every time the conditional value changes, the view is forced to invalidate because changing view modifiers entirely causes new views to be redrawn. It’s recommended to use ternary operators within the modifier parameters to handle different cases. Apple has supported ternary operators for most view modifiers. If any modifier doesn’t have this option, file feedback to get it supported. (Additional resource on this topic)
    • Don’t use if statements to switch between containers/navigation-specific views (split navigation, sidebar column, detail views). Instead, have the if statements within the containers like NavigationStack to handle different use cases.
    • For SwiftUI accessibility representation, custom styles & controls, and hidden views in the accessibility system, use more representable APIs to generate more semantic meaning for views. Standard UI is accessible by itself—use these techniques for custom views.
    • State & State Maintenance: Be aware of how you manage state when conditionally switching views, as this can cause performance issues.
  • Best Practices for App Architecture & Other Patterns:

    • Not many comments on architecture were provided.
    • Lean into Observable, which is compatible with UIKit from iOS 26 onwards.
  • Observables:

    • Look into Swift forums for more information.
    • Make sure observables are not holding large structs.
    • Keep in mind the granularity of each observable to avoid unwanted behaviors.
  • Debug Techniques:

    • Use profiling instruments.
    • Use breakpoints and conditional breakpoints.
    • Apply colors to view backgrounds to debug SwiftUI views better.
    • Use print debugging in initializers and check lifecycles of views to see the flow and question the flow.
    • Comment out code to find problems and fix broken points.
    • let _ = Self._printChanges() provides insight when a view’s state changes or gets redrawn/invalidated. This is a private API that can be used within a view’s body.
    • Set breakpoints to play system sounds and continue execution without stopping. This helps identify flow changes by playing a sound when hitting a breakpoint without interrupting app execution.

Thanks for reading.

Reply by Email
Abilash S
Author
Abilash S
Software engineer passionate about clean code, productivity systems, and knowledge management. I write about development practices, tool discoveries, and the intersection of technology and organized thinking. When not coding, you’ll find me tinkering with Emacs configurations or exploring new ways to capture and connect ideas.
wwdc25 - This article is part of a series.
Part : This Article

Related

Foundation Model Group Session Notes
··184 words·1 min
IOS Wwdc
Short notes on the Foundation Model Group session of WWDC25. Notes include some tips and other informations related to the Model and its limitations.
UI Frameworks Group Session Notes
··956 words·5 mins
IOS Wwdc
Short notes on the UI Frameworks Group session of WWDC25. Q&A on the new design system, including questions on accessibility, advices on adapting the new design, support for older platform targets
Under Maintenance
·23 words·1 min
Image by freepik Currently working on some improvements, until then look around. Maybe visit my feeds to learn something interesting about my work.