SwiftUI

How can very large reorderable SwiftUI lists be optimized?

• SwiftUI is aware of performance issues with very large lists and is investigating.
• File feedback with the specific use case, detailing why developers need to display that many items and the nature of the data structure.
• This feedback helps the team ensure APIs support diverse use cases.

What is the NavigationTransition protocol, and are custom transitions supported?

• The NavigationTransition protocol allows SwiftUI to expose types that conform to it for navigation transitions.
• Currently, there are predefined transitions like crossfade, zoom, and automatic.
• These transitions apply to sheets as well as navigation stacks.
• Use AnyNavigationTransition to switch between transition styles (e.g., crossfade vs. zoom).
• For custom transitions not tied to a navigation stack, developers can drive animations using modifiers and Animatable.
• If developers need custom navigation transitions, file feedback with the use case to inform future API development.

How can coding intelligence help SwiftUI development with Liquid Glass?

• Xcode's new coding skills provide insights into new APIs and best practices.
• Use Xcode's preview rendering for iterating on designs like Liquid Glass.
• Skills are usable with the model of choice, allowing for experimentation.
• Skills can be exported for use with other agentic systems.

How should the glass effect be applied to buttons and other UI elements?

• Buttons in navigation bars and top toolbars automatically adopt a glass appearance.
• For custom glass effects on buttons, use the glass button style or glass prominent style.
• Consider using buttonBorderShape for specific button shapes.
• Avoid applying glass effects within the content area of a view unless there's content to refract; often, simpler designs are better.
• To hide the glass background on toolbar items (e.g., for profile photos), use sharedBackground(hidden: true).
• New APIs allow removing content margins from toolbar buttons while keeping the glass rim aligned on push and pop transitions.

What is the best way to manage screen sizes and window resizing in SwiftUI apps?

• Avoid hardcoding for specific window sizes; aim for layouts that adapt to any size.
• Use ViewThatFits to pick the best layout variant for the available space.
• Utilize size classes to define different user experiences (e.g., multi-column for regular, constrained for compact).
• Ensure true flexibility beyond just size class transitions, as windows can occupy intermediate sizes.
• Consider using system containers like TabView (which can adapt to sidebars) for built-in responsiveness.
• Custom layouts and custom containers offer powerful ways to create flexible, reusable controls that adapt to various sizes.
• Use AnyLayout to maintain structural view identity when switching between different layouts.

When should GeometryReader be used versus onGeometryChange for handling size changes?

• onGeometryChange is generally preferred for reacting to size changes, especially for breakpoint-based layouts.
• onGeometryChange has two closures: one for real-time geometry, and another to determine when an action should be called, allowing for threshold-based updates.
• Using GeometryReader within subviews can be expensive; onGeometryChange is more efficient.
• Avoid view invalidations on every frame; onGeometryChange helps limit updates to when thresholds are crossed.
• For precise placement and complex layouts, combine onGeometryChange with custom layouts.
• Alignment guides can also be used for efficient, single-pass layout solutions.

What are the best practices for learning data management and passing data between views in SwiftUI?

• Focus on making views lightweight and mapping information to view data.
• Build self-contained state machines and logical components.
• When view code becomes messy, simplify the model or logic layer data.
• SwiftUI is architecture-agnostic; build apps modeling different data types to discover appropriate patterns.
• Build sample apps in domains developers are familiar with to stay motivated and focus on solving the problem.
• Use Instruments' SwiftUI timeline to understand data flow and how data updates affect view bodies.
• Consider using dynamic properties to replace onChange for more efficient updates that occur before body renders.
• Avoid using onChange to mutate view state; prefer a data model that vends new values as others change.
• Critically evaluate the usage of APIs like AnyView and onChange to ensure they are justified and not used as a crutch.
• For asynchronous loading (e.g., images), use dynamic properties to vend cached values before the body renders, avoiding unnecessary re-renders.
• onAppear timing now aligns with Task due to Swift concurrency improvements in iOS 27 — no extra isolation hop between them.
• Wrapping views in AnyView can block container-value and preference propagation; be aware when using type erasure in layout containers.

What is Apple's recommendation for conditionally hiding elements, and what are the implications of using if statements?

• For visual hiding, use modifiers like opacity with a conditional expression. This keeps the element in the view hierarchy.
• If developers need to remove an element from the layout entirely, conditionalizing its presence is acceptable.
• Avoid using if statements at the top level of views within lazy containers (List, LazyStack) as it can prevent views from being deallocated and lead to unexpected behavior.
• Wrap conditional branches within lazy containers in a unary container (e.g., VStack, Group, AnyView) to ensure a single view is always resolved.
• Conditionalizing view modifiers can be problematic if the modifier doesn't have an "inert" state, potentially causing unnecessary relayouts or state resets.
• Prefer passing inert values to modifiers or using conditional logic within the modifier's arguments rather than an if statement.
• Be cautious with if statements inside view modifier bodies, as they can lead to unexpected state resets due to view hierarchy changes.
• Some SwiftUI modifiers are intentionally static for performance; switching these on the fly may require an if-else structure.

What are the concrete costs of type erasing with AnyView, and when is it a concern?

• AnyView is useful when the type of a view is unknown at compile time.
• The primary cost arises when the underlying type of AnyView changes, which tears down and rebuilds the view hierarchy.
• Avoid changing the underlying type of AnyView frequently to maintain performance.
• In lazy containers, AnyView can prevent the container from determining the number of resolved views, potentially requiring wrapping it in a unary container like VStack.

What are some tips for making SwiftUI layouts more adaptable, especially with resizable Xcode previews?

• Design custom layouts to accept any size as an input parameter and handle it reasonably.
• Use resizable previews and test the app on resizable devices (like iPad) to identify assumptions and layout breaks.
• Observe how other apps and websites handle resizing for inspiration on creative space utilization.
• Identify "magic numbers" in the layout code that cause breaks at different sizes and refactor them.

How can full-screen SwiftUI overlays appear above sheets?

• Presenting a full-screen overlay on top of existing modals in SwiftUI can be challenging with current APIs.
• Consider coordinating the navigation and data models to manage presentations effectively.
• For complex layering needs, dropping down to UIKit and using a UIWindow or UIWindowScene might be necessary.
• Developers can host SwiftUI views within a UIKit UIHostingController in a UIWindow.
• Be mindful of the "last UI window wins" principle if multiple UI windows are created.
• Evaluate if a full-screen cover is the most appropriate design; consider alternative flows like rewinding the navigation stack.
• File feedback with the specific use case when developers encounter limitations with SwiftUI's current presentation APIs.

How can a SwiftUI custom control expand over other elements?

• Consider using existing UIKit or AppKit controls via framework interop if a suitable control already exists.
• SwiftUI is compositional; developers can combine building blocks to create powerful custom controls.
• To avoid impacting the layout of other elements, a child view can report a stable size to its parent while drawing larger using overlay.
• Be aware that drawing outside reported bounds in a ScrollView might lead to views being removed from the hierarchy.
• overlay provides isolation and prevents affecting surrounding layout.
• Custom controls require careful consideration of edge cases, such as how they behave during scrolling or user interaction.
• Consider using custom styles for existing controls before building a completely new custom control to leverage built-in accessibility and behaviors.
• SwipeActions can now be applied to any container using the swipeActionsContainer() modifier (not just List), and the actions themselves can be any view.

How small should SwiftUI views be broken down for performance?

• Breaking views into smaller pieces is about isolating data dependencies that trigger updates.
• Split views when different parts of the UI can update independently to avoid unnecessary re-renders of the entire view.
• If dependencies are shared across all parts of a view, splitting it won't provide performance benefits.
• The goal is to create boundaries where SwiftUI can determine if a view needs to update.
• View builder computed properties do not offer the same isolation as separate struct views, as they are functionally part of the same view body.
• Aim to group related dependencies. A view re-evaluates if any of its inputs (bindings, environment, etc.) change.
• Move frequently changing dependencies and their associated UI logic into separate, smaller views to prevent larger, less frequently changing parts from re-rendering.
• Use Observable objects to allow subviews to update independently without triggering updates in their parent views.
• Don't be afraid of creating many small views; struct views are value types and are inexpensive.

What are notable SwiftUI accomplishments from the framework's evolution?

• Custom Containers API: Distilled complex concepts into an essence that enables powerful user creations.
• Semantic Pieces over Device-Specific Rendering: Rethinking UI systems in terms of data flow and semantic components (e.g., TabView behaving as standard tabs or a paginated scroll view).
• Internal Adoption and Maturity: SwiftUI is now mature enough to be used for core UI components across Apple's applications, even those not fully rebuilt in SwiftUI.
• Team Collaboration and Culture: The strong team dynamic, shared humor, and collaborative problem-solving are as important as the framework itself.
• API Evolution based on Usage: Identifying suboptimal patterns (like GeometryReader) and introducing new APIs (onGeometryChange, onScrollVisibilityChange) to address user needs.
• Exposing Lower-Level Building Blocks: Providing tools that were previously internal, enabling developers to build more custom and innovative experiences.