At WWDC25 we launched a new type of Lab event for the developer community - Group Labs. A Group Lab is a panel Q&A designed for a large audience of developers. Group Labs are a unique opportunity for the community to submit questions directly to a panel of Apple engineers and designers. Here are the highlights from the WWDC25 Group Lab for UI Frameworks. How would you recommend developers start adopting the new design? Start by focusing on the foundational structural elements of your application, working from the "top down" or "bottom up" based on your application's hierarchy. These structural changes, like edge-to-edge content and updated navigation and controls, often require corresponding code modifications. As a first step, recompile your application with the new SDK to see what updates are automatically applied, especially if you've been using standard controls. Then, carefully analyze where the new design elements can be applied to your UI, paying particular attention to custom controls or UI that could benefit from a refresh. Address the large structural items first then focus on smaller details is recommended. Will we need to migrate our UI code to Swift and SwiftUI to adopt the new design? No, you will not need to migrate your UI code to Swift and SwiftUI to adopt the new design. The UI frameworks fully support the new design, allowing you to migrate your app with as little effort as possible, especially if you've been using standard controls. The goal is to make it easy to adopt the new design, regardless of your current UI framework, to achieve a cohesive look across the operating system. What was the reason for choosing Liquid Glass over frosted glass, as used in visionOS? The choice of Liquid Glass was driven by the desire to bring content to life. The see-through nature of Liquid Glass enhances this effect. The appearance of Liquid Glass adapts based on its size; larger glass elements look more frosted, which aligns with the design of visionOS, where everything feels larger and benefits from the frosted look. What are best practices for apps that use customized navigation bars? The new design emphasizes behavior and transitions as much as static appearance. Consider whether you truly need a custom navigation bar, or if the system-provided controls can meet your needs. Explore new APIs for subtitles and custom views in navigation bars, designed to support common use cases. If you still require a custom solution, ensure you're respecting safe areas using APIs like SwiftUI's safeAreaInset. When working with Liquid Glass, group related buttons in shared containers to maintain design consistency. Finally, mark glass containers as interactive. For branding, instead of coloring the navigation bar directly, consider incorporating branding colors into the content area behind the Liquid Glass controls. This creates a dynamic effect where the color is visible through the glass and moves with the content as the user scrolls. I want to know why new UI Framework APIs aren’t backward compatible, specifically in SwiftUI? It leads to code with lots of if-else statements. Existing APIs have been updated to work with the new design where possible, ensuring that apps using those APIs will adopt the new design and function on both older and newer operating systems. However, new APIs often depend on deep integration across the framework and graphics stack, making backward compatibility impractical. When using these new APIs, it's important to consider how they fit within the context of the latest OS. The use of if-else statements allows you to maintain compatibility with older systems while taking full advantage of the new APIs and design features on newer systems. If you are using new APIs, it likely means you are implementing something very specific to the new design language. Using conditional code allows you to intentionally create different code paths for the new design versus older operating systems. Prefer to use if #available where appropriate to intentionally adopt new design elements. Are there any Liquid Glass materials in iOS or macOS that are only available as part of dedicated components? Or are all those materials available through new UIKit and AppKit views? Yes, some variations of the Liquid Glass material are exclusively available through dedicated components like sliders, segmented controls, and tab bars. However, the "regular" and "clear" glass materials should satisfy most application requirements. If you encounter situations where these options are insufficient, please file feedback. If I were to create an app today, how should I design it to make it future proof using Liquid Glass? The best approach to future-proof your app is to utilize standard system controls and design your UI to align with the standard system look and feel. Using the framework-provided declarative API generally leads to easier adoption of future design changes, as you're expressing intent rather than specifying pixel-perfect visuals. Pay close attention to the design sessions offered this year, which cover the design motivation behind the Liquid Glass material and best practices for its use. Is it possible to implement your own sidebar on macOS without NSSplitViewController, but still provide the Liquid Glass appearance? While technically possible to create a custom sidebar that approximates the Liquid Glass appearance without using NSSplitViewController, it is not recommended. The system implementation of the sidebar involves significant unseen complexity, including interlayering with scroll edge effects and fullscreen behaviors. NSSplitViewController provides the necessary level of abstraction for the framework to handle these details correctly. Regarding the SceneDelagate and scene based life-cycle, I would like to confirm that AppDelegate is not going away. Also if the above is a correct understanding, is there any advice as to what should, and should not, be moved to the SceneDelegate? UIApplicationDelegate is not going away and still serves a purpose for application-level interactions with the system and managing scenes at a higher level. Move code related to your app's scene or UI into the UISceneDelegate. Remember that adopting scenes doesn't necessarily mean supporting multiple scenes; an app can be scene-based but still support only one scene. Refer to the tech note Migrating to the UIKit scene-based life cycle and the Make your UIKit app more flexible WWDC25 session for more information.

I must admit my knowledge of swift is limited, and I cannot wrap my head around this problem. I've defined this protocol, so I can use different auth providers in my app. protocol AuthRepository { associatedtype AuthData associatedtype AuthResponseData associatedtype RegistrationData associatedtype RegistrationResponseData func login(with data: AuthData) async throws -> AuthResponseData? func register(with data: RegistrationData) async throws -> RegistrationResponseData? } and an implementation for my server struct MyServerAuthData { let email: String let password: String } struct MyServerAuthResponseData { let token: String } struct MyServerRegistrationData { let email: String let password: String let name: String } actor AuthRepositoryImpl: AuthRepository { func login(with data: MyServerAuthData) async throws -> MyServerAuthResponseData? { ... } func register(with data: MyServerRegistrationData) async throws -> Void? { ... } } To use across the app, I've created this ViewModel @MainActor final class AuthViewModel<T: AuthRepository>: ObservableObject { private let repository: T init(repository: T) { self.repository = repository } func login(data: T.AuthData) async throws -> T.AuthResponseData? { try await repository.login(with: data) } func register(with data: T.RegistrationData) async throws { try await repository.register(with: data) } } defined in the app as @main struct MyApp: App { @StateObject var authViewModel = AuthViewModel(repository: AuthRepositoryImpl()) var body: some Scene { WindowGroup { ContentView() .environmentObject(self.authViewModel) } } } and consumed as @EnvironmentObject private var authViewModel: AuthViewModel<AuthRepositoryImpl> But with this code, the whole concept of having a generic implementation for the auth repository is useless, because changing the AuthRepostory will need to search and replace AuthViewModel<AuthRepositoryImpl> across all the app. I've experienced this directly creating a MockAuthImpl to use with #Preview, and the preview crashed because it defines AuthViewModel(repository: MockAuthImpl()) but the view expects AuthViewModel. There is a better way to do that?

I recently noticed an inconsistency in how languages are represented in Apple’s new Translation API compared to Foundation’s Locale system. Observation from the Translation API When retrieving the list of supported languages using: let availableLanguages = try await LanguageAvailability().supportedLanguages The results are: Language(components: Foundation.Locale.Language.Components(languageCode: Optional(uk), script: nil, region: Optional(UA))) Language(components: Foundation.Locale.Language.Components(languageCode: Optional(zh), script: nil, region: Optional(TW))) Language(components: Foundation.Locale.Language.Components(languageCode: Optional(ko), script: nil, region: Optional(KR))) Language(components: Foundation.Locale.Language.Components(languageCode: Optional(en), script: nil, region: Optional(GB))) Language(components: Foundation.Locale.Language.Components(languageCode: Optional(de), script: nil, region: Optional(DE))) Language(components: Foundation.Locale.Language.Components(languageCode: Optional(zh), script: nil, region: Optional(CN))) Language(components: Foundation.Locale.Language.Components(languageCode: Optional(ja), script: nil, region: Optional(JP))) Language(components: Foundation.Locale.Language.Components(languageCode: Optional(id), script: nil, region: Optional(ID))) Language(components: Foundation.Locale.Language.Components(languageCode: Optional(nl), script: nil, region: Optional(NL))) .... Key points: • The script component is always nil. • Region codes (CN, TW, etc.) determine the script for languages like Chinese (Simplified or Traditional). • Other languages (e.g., en-GB, en-US, pt-BR) also rely on region-based identification. Observation from Foundation Locale (Locale.current.language) When retrieving the user’s system language setting: systemLanguageObj = Locale.current.language I get a different format where the script component is present, but the region may vary based on user settings. This means that mapping between script and region is not consistent between the two APIs, requiring manual handling. My key questions: 1. Is my current approach correct, or is there a better way to get user language settings that match Translation API identifiers? 2. If no alternative exists, could the Translation API align its language identification method with Foundation Locale to reduce ambiguity? Any insights or suggestions would be greatly appreciated!

Below is a basic test app to resemble an actual app I am working on to hopefully better describe an issue I am having with tab view. It seems only in split screen when I am triggering something onAppear that would cause another view to update, or another view updates on its own, the focus gets pulled to that newly updated view instead of staying on the view you are currently on. This seems to only happen with views that are listed in the more tab. In any other orientation other than 50/50 split this does not happen. Any help would be appreciated. struct ContentView: View { @State var selectedTab = 0 var body: some View { NavigationStack { NavigationLink(value: 0) { Text("ENTER") }.navigationDestination(for: Int.self) { num in TabsView(selectedTab: $selectedTab) } } } } struct TabsView: View { @Binding var selectedTab: Int @State var yikes: Int = 0 var body: some View { if #available(iOS 18.0, *) { TabView(selection: $selectedTab) { MyFlightsView(yikes: $yikes) .tabItem { Label("My Flights", systemImage: "airplane.circle") }.tag(0) FlightplanView() .tabItem { Label("Flight Plan", systemImage: "doc.plaintext") }.tag(1) PreFlightView() .tabItem { Label("Pre Flight", systemImage: "airplane.departure") }.tag(2) CruiseView(yikes: $yikes) .tabItem { Label("Cruise", systemImage: "airplane") }.tag(3) PostFlightView() .tabItem { Label("Post Flight", systemImage: "airplane.arrival") }.tag(4) MoreView() .tabItem { Label("More", systemImage: "ellipsis") }.tag(5) NotificationsView() .tabItem { Label("Notifications", systemImage: "bell") }.tag(6) }.tabViewStyle(.sidebarAdaptable) } } }

I have an app which uses Scene var body: some Scene { WindowGroup { RootView(root: appDelegate.root) .edgesIgnoringSafeArea(.all) .onOpenURL { url in let stringUrl = url.absoluteString if (stringUrl.starts(with: "http")) { handleUniversalLink(url: stringUrl) } else if (stringUrl.starts(with: "fb")) { let _ = ApplicationDelegate.shared.application( UIApplication.shared, open: url, sourceApplication: nil, annotation: [UIApplication.OpenURLOptionsKey.annotation]) } } } } I need to detect when a user taps on status bar. And call some functions when he does it. Is it possible in Swift?

As SwiftUI adoption grows, developers face challenges in effectively measuring and optimizing SwiftUI app performance within automated tests. Currently, the only viable approach to analyzing SwiftUI performance is through Profiling (Instruments), which, while powerful, lacks the ability to be incorporated into automated testing workflows. It would be incredibly valuable if XCTest could introduce new performance metrics specifically tailored for SwiftUI, allowing us to write tests against common performance bottlenecks. Suggested Metrics: View Body Evaluation Count – Tracks how often a SwiftUI body is recomputed to detect unnecessary re-renders. Slow View Bodies – Flags SwiftUI views that take a significant amount of time to compute their body. These metrics would help developers identify inefficiencies early, enforce performance best practices through CI/CD pipelines, and ensure a smooth user experience. I believe adding these performance metrics would be a game-changer for SwiftUI development. Thank you for your time and consideration!

I'm attempting to write a macOS version of https://stackoverflow.com/a/74935849/2178159. From my understanding, I should be able to set the menu property of an NSResponder and it will automatically show on right click. I've tried a couple things: A: set menu on an NSHostingController's view - when I do this and right or ctrl click, nothing happens. B: set menu on NSHostingController directly - when I do this I get a crash Abstract method -[NSResponder setMenu:] called from class _TtGC7SwiftUI19NSHostingControllerGVS_21_ViewModifier_...__. Subclasses must override C: manually call NSMenu.popup in a custom subclasses of NSHostingController or NSView's rightMouseDown method - nothing happens. extension View { func contextMenu(menu: NSMenu) -> some View { modifier(ContextMenuViewModifier(menu: menu)) } } struct ContextMenuViewModifier: ViewModifier { let menu: NSMenu func body(content: Content) -> some View { Interaction_UI( view: { content }, menu: menu ) .fixedSize() } } private struct Interaction_UI<Content: View>: NSViewRepresentable { typealias NSViewType = NSView @ViewBuilder var view: Content let menu: NSMenu func makeNSView(context: Context) -> NSView { let v = NSHostingController(rootView: view) // option A - no effect v.view.menu = menu // option B - crash v.menu = menu return v.view } func updateNSView(_ nsView: NSViewType, context: Context) { // part of option A nsView.menu = menu } }

Hi, I have noticed a major change to a SwiftUI API behavior in iOS18.4beta1 which breaks my app's functionality, and I've started hearing from users running the new beta that the app doesn't correctly work for them anymore. The problem is with views that contain a List with multiple-selection, and the contextMenu API applied with the ‘primaryAction’ callback that is triggered when the user taps on a row. Previously, if the user tapped on a row, this callback was triggered with the 'selectedItems' showing the tapped item. With iOS18.4beta, the same callback is triggered with ‘selectedItems’ being empty. I have the code to demonstrate the problem: struct ListSelectionTestView: View { @State private var items: [TimedItem] = [ TimedItem(number: 1, timestamp: "2024-11-20 10:00"), TimedItem(number: 2, timestamp: "2024-11-20 11:00"), TimedItem(number: 3, timestamp: "2024-11-20 12:00") ] @State var selectedItems = Set<TimedItem.ID>() var body: some View { NavigationStack { List(selection: $selectedItems) { ForEach(items) { item in Text("Item \(item.number) - \(item.timestamp)") } } .contextMenu(forSelectionType: TimedItem.ID.self, menu: {_ in Button(action: { print("button called - count = \(selectedItems.count)") }) { Label("Add Item", systemImage: "square.and.pencil") } }, primaryAction: {_ in print("primaryAction called - count = \(selectedItems.count)") }) } } } struct TimedItem: Identifiable { let id = UUID() let number: Int let timestamp: String } #Preview { ListSelectionTestView() } Running the same code on iOS18.2, and tapping on a row will print this to the console: primaryAction called - count = 1 Running the same code on iOS18.4 beta1, and tapping on a row will print this to the console: primaryAction called - count = 0 So users who were previously selecting an item from the row, and then seeing expected behavior with the selected item, will now suddenly tap on a row and see nothing. My app's functionality relies on the user selecting an item from a list to see another detailed view with the selected item's contents, and it doesn't work anymore. This is a major regression issue. Please confirm and let me know. I have filed a feedback: FB16593120

Hi, I am trying to create a local backup + restore when using SwiftUI and CoreData but I am facing errors left and right. the latest error I am stuck on is: *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'executeFetchRequest:error: A fetch request must have an entity.' Here is what am trying to do: Creating a backup (already solved using NSPersistentStoreCoordinator.migratePersistentStore(_:to:options:type:)) Create a new NSPersistentContainer and call its NSPersistentContainer.loadPersistentStores(completionHandler:) (already solved, load is successful) Update the .environment(.managedObjectContext, viewModel.context) so that SwiftUI uses the new context. (HERE is where the error appears) Any help would be appreciated. Here is some sample code of SwiftUI part of the main view: class ViewModel: ObservableObject { @Published var context: NSManagedObjectContext } @main struct MyApp: App { @StateObject var viewModel: ViewModel var body: some Scene { WindowGroup { ContentView() .environment(\.managedObjectContext, viewModel.context) } } }

Hi everyone! I'm thrilled to share that I'm conducting a field research as part of my final university project, focused on iOS architecture. The goal is to dive deeper into the best practices, challenges, and trends in the iOS development world. To make this research truly impactful, I need your help! If you're an iOS developer, I’d love it if you could take a few minutes to answer a short survey. Your insights and experiences will be invaluable for my research, and I greatly appreciate your support! Here is the link: https://docs.google.com/forms/d/e/1FAIpQLSdf9cacfA7my1hnlazyl7uJraa2oTsQ7dJBWvFtZ_4vbYenRA/viewform?usp=send_form Thank you so much in advance for helping me out—feel free to share this post with others who might also be interested. Let’s build something amazing together! 💡✨

I plan to use the entire screen height minus 40 pixels approximately to not overlap with the time, batter and carrier data. However, I noticed that in the code shared below the vstack with pink background is not displayed at the top of the screen. The interesting part is that it's actually occupying an offset at the top of the screen. What's more, when I set an offset greater than 70 pixels, then the pink vstack displays on the view! Thus, I'm looking for an explanation to this swiftui rendering issue. Offset less than 70 pixels: Offset greater or equal than 70 pixels: GeometryReader { proxy in let offset = 40.0 let height = proxy.size.height - offset ZStack { VStack(spacing:0){ VStack{Text("heasdas")}.frame(width: 300,height: offset,alignment: .leading) .background(.pink) VStack { HStack(alignment:.center,spacing:10){ Text("Shapecloud") .font(.callout) .fontWeight(.semibold) .frame(alignment: .leading) SLine() } .frame(maxWidth: .infinity,alignment: .leading) Text("Digital Twin Solutions\nServices") .font(.largeTitle) .fontWeight(.medium) .frame(maxWidth: .infinity,alignment: .leading) } .frame(maxWidth: .infinity,maxHeight: 0.3*height,alignment: .top) .background(.red) VStack { VideoPlayer(player: player) .frame(maxWidth: .infinity,maxHeight: 300) } .frame(maxWidth: .infinity,maxHeight: 0.4*height) .background(.yellow) VStack{ Button { } label: { Text("Subscribe now").foregroundStyle(.black) .font(.headline) .fontWeight(.semibold) } .frame(maxWidth: .infinity,maxHeight: 50) .border(Color.black, width: 2) Button { } label: { Text("Sign In").foregroundStyle(.white) .font(.headline) } .frame(maxWidth: .infinity,maxHeight: 50) .background(Color.theme.primary) } .frame(maxWidth: .infinity,maxHeight: 0.3*height) .background(.green) } .padding(.horizontal, 32) .background(.cyan) .ignoresSafeArea(.all) } .ignoresSafeArea(.all) } .ignoresSafeArea(.all)

If you add the .scaleEffect() modifier to a parent view inside of which there are children with contextMenu()-s, the context menu preview unfortunately keeps the original, unscaled size of the child view. This results in a very weird, glitchy user experience. Unfortunately, providing a custom preview that is scaled up also does not help, since even though it is the right size, it gets cropped to the unscaled size of the child view. Adding scaleEffect() to each child element individually (BEFORE the contextMenu() modifier!) does make the problem disappear. However, I would like to avoid this, since my use case is zooming into a complex graph with context menus on its nodes, and having to recalculate the position of each node manually seems to perform much worse than delegating that work to scaleEffect(). Tested on iOS 18.2 (device + emulator) Is there a workaround? Here is a minimal working example that demonstrates the problem: struct ContentView: View { var body: some View { VStack(spacing: 20) { Rectangle() .frame(width: 100, height: 100) .contextMenu { Button("Test") {} Button("Test") {} } Rectangle() .frame(width: 100, height: 100) .contextMenu { Button("Test") {} Button("Test") {} } } .scaleEffect(1.5) } } Screenshot (problem: The two squares are the same size. However, the long-tapped upper square got shrunk down before the context menu got displayed.)

I am having issues with my app on visionOS. It works fine on iOS. The app is presenting a ImagePicker, I had tried converting to PhotoPicker and the behavior did not change. The relevant code is in the EditGreetingCardView - // // Created by Michael Rowe on 1/2/24. // import AVKit import SwiftData import SwiftUI struct EditGreetingCardView: View { @Environment(\.modelContext) private var modelContext @Environment(\.dismiss) private var dismiss @Query(sort: \EventType.eventName) private var events: [EventType] var greetingCard: GreetingCard? private var editorTitle: String { greetingCard == nil ? "Add Greeting Card" : "Edit Greeting Card" } @State var frontImageSelected: Image? = Image("frontImage") @State var sourceType: UIImagePickerController.SourceType = .photoLibrary @State var frontPhoto = false @State var captureFrontImage = false var eventTypePassed: EventType? @State private var eventType: EventType? @State private var cardName = "" @State private var cardManufacturer = "" @State private var cardURL = "" @State private var cardUIImage: UIImage? @State private var cameraNotAuthorized = false @State private var isCameraPresented = false @State private var newEvent = false @AppStorage("walkthrough") var walkthrough = 1 init(eventTypePassed: EventType?) { if let eventTypePassed { _eventType = .init(initialValue: eventTypePassed) } } init(greetingCard: GreetingCard?) { self.greetingCard = greetingCard _eventType = .init(initialValue: greetingCard?.eventType) } var body: some View { NavigationStack { Form { Section("Occasion") { Picker("Select Occasion", selection: $eventType) { Text("Unknown Occasion") .tag(Optional<EventType>.none) //basically added empty tag and it solve the case if events.isEmpty == false { Divider() ForEach(events) { event in Text(event.eventName) .tag(Optional(event)) } } } } .foregroundColor(Color("AccentColor")) Section("Card details") { } .foregroundColor(Color("AccentColor")) Section("Card Image") { HStack(alignment: .center){ Spacer() ZStack { Image(uiImage: cardUIImage ?? UIImage(named: "frontImage")!) .resizable() .aspectRatio(contentMode: .fit) .shadow(radius: 10 ) Image(systemName: "camera.fill") .foregroundColor(.white) .font(.largeTitle) .shadow(radius: 10) .frame(width: 200) .onTapGesture { self.frontPhoto = true } .actionSheet(isPresented: $frontPhoto) { () -> ActionSheet in #if !os(visionOS) ActionSheet( title: Text("Choose mode"), message: Text("Select one."), buttons: [ ActionSheet.Button.default(Text("Camera"), action: { checkCameraAuthorization() self.captureFrontImage.toggle() self.sourceType = .camera }), ActionSheet.Button.default(Text("Photo Library"), action: { self.captureFrontImage.toggle() self.sourceType = .photoLibrary }), ActionSheet.Button.cancel() ] ) #else ActionSheet( title: Text("Choose mode"), message: Text("Select one."), buttons: [ ActionSheet.Button.default(Text("Photo Library"), action: { self.captureFrontImage.toggle() self.sourceType = .photoLibrary }), ActionSheet.Button.cancel() ] ) #endif } .fullScreenCover(isPresented: $captureFrontImage) { #if !os(visionOS) ImagePicker( sourceType: sourceType, image: $frontImageSelected) .interactiveDismissDisabled(true) #else ImagePicker( image: $frontImageSelected) .interactiveDismissDisabled(true) #endif } } .frame(width: 250, height: 250) Spacer() } } } .alert(isPresented: $cameraNotAuthorized) { Alert( title: Text("Unable to access the Camera"), message: Text("To enable access, go to Settings > Privacy > Camera and turn on Camera access for this app."), primaryButton: .default(Text("Settings")) { openSettings() } , secondaryButton: .cancel() ) } .toolbar { } .onAppear { } .onChange(of: frontImageSelected) { oldValue, newValue in cardUIImage = newValue?.asUIImage() } } } }

Is there a way to observe the currentEDRHeadroom property of UIScreen for changes? KVO is not working for this property... I understand that I can query the current headroom in the draw(...) method to adapt the rendering. However, our apps only render on-demand when the user changes parameters. But we would also like to re-render when the current EDR headroom changes to adapt the tone mapping to the new environment. The only solution we've found so far is to continuously query the screen for changes, which doesn't seem ideal. It would be better if the property would be observable via KVO or if there would be a system notification to listen for. Thanks!

I am implementing a new Intents UI Extension and am noticing that the viewWillDisappear, viewDidDisappear, and deinit methods are not being called on my UIViewController that implements INUIHostedViewControlling, when pressing the "Done" button and dismissing the UIViewController. This causes the memory for the UI Extension to slowly increase each time I re-run the UI Extension until it reaches the 120MB limit and crashes. Any ideas as to what's going on here and how to solve this issue? Worth noting that while the memory does continuously increase on iOS versions before iOS 17, only in 17 and later does the 120MB memory limit kick in and crash the extension.

So I am looking to use a custom NSWindow application (so I can implement some enhanced resizing/dragging behavior which is only possible overriding NSWindow). The problem is my whole application is currently SwiftUI-based (see the project here: https://github.com/msdrigg/Roam/blob/50a2a641aa5f2fccb4382e14dbb410c1679d8b0c/Roam/RoamApp.swift). I know there is a way to make this work by dropping my @main SwiftUI app and replacing it with a SwiftUI root view hosted in a standard AppKit root app, but that feels like I'm going backwards. Is there another way to get access (and override) the root NSWindow for a SwiftUI app?

Hi, folks. I know that in the new observation, class property changes can be automatically notified to SwiftUI, which is very convenient. But in the new observation framework, how to monitor the property changes of different model classes? For example, class1 has an instance of class2, and I need to notify class1 to perform some actions and make some changes when some properties of class2 are changed. How to do it in observation? In the past, I could use combined methods to write the second part of the code for monitoring. However, using the combined framework in observation is a bit confusing. I know this method can be withObservationTracking(_:onChange:) but it needs to be registered continuously. If Observation is not possible, do I need to change my design structure? Thanks. // Observation @Observable class Sample1 { var count: Int = 0 var name = "Sample1" } @Observable class Sample2 { var count: Int = 0 var name = "Sample2" var sample1: Sample1? init (sample1 : Sample1) { self.sample1 = sample1 } func render() { withObservationTracking { print("Accessing Sample1.count: \(sample1?.count ?? 0)") } onChange: { [weak self] in print("Sample1.count changed! Re-rendering Sample2.") self?.handleSample1CountChange() } } private func handleSample1CountChange() { print("Handling count change in Sample2...") self.count = sample1?.count ?? 0 } } // ObservableObject class Sample1: ObservableObject { @Published var count: Int = 0 var name = "Sample1" } class Sample2: ObservableObject { @Published var count: Int = 0 var name = "Sample1" var sample1: Sample1? private var cancellables = Set<AnyCancellable>() init (sample1 : Sample1) { self.sample1 = sample1 setupSubscribers() } private func setupSubscribers() { sample1?.$count .receive(on: DispatchQueue.main) .sink { [weak self] count in guard let self = self else { return } // Update key theory data self.count = count self.doSomeThing() } .store(in: &cancellables) } private func doSomeThing() { print("Count changes, need do some thing") } }

I'm creating an app which gamifies Screen Time reduction. I'm running into an issue with apples Screen Time setting where the user can disable my apps "Screen Time access" and get around losing the game. Is there a way to detect when this setting is disabled for my app? I've tried using AuthorizationCenter.shared.authorizationStatus but this didn't do the trick. Does anyone have an ideas?

Starting from Sequoia release 15.2 apps crash with following call stack, when adding static text controls. First call to [NSTextField setStringValue] causes following crash 0 libobjc.A.dylib 0x19f2f5820 objc_msgSend + 32 1 AppKit 0x1a3355460 -[NSCell _objectValue:forString:errorDescription:] + 144 2 AppKit 0x1a3355348 -[NSCell setStringValue:] + 48 3 AppKit 0x1a33af9fc -[NSControl setStringValue:] + 104 4 AppKit 0x1a3d1f190 -[NSTextField setStringValue:] + 52 It happens on specific MacBook Pro models(16 in MacBook Pro). Crash analysis found that isa pointer of the object was corrupted for the object NSCell. Enabled Zombies in debugging, not found any issue. Also tried address sanitizer. Since the issue started with a recent release of macOS, any changes in the Appkit in the recent releases trigger the crash? Any help/suggestions would be appreciated.

Hi, I’m practicing with NavigationSplitView for macOS and customizing the sidebar. I’ve managed to adjust most parts, but I couldn’t remove the sidebar’s divider. It seems like it’s not possible in modern SwiftUI. My AppKit knowledge is also not very strong. How can I remove the sidebar divider? I want to use a plain background. I also solved it by creating my own sidebar, but I wanted to try it using NavigationSplitView.

I have an attributedString with 100 NSTextAttachments(contains image of 400kb). When i scroll the textview, it is lagging, When i did the same in textkit 1, it is butter smooth. It can be because of how textkit 1 & 2 layout the elements. let attachment = NSTextAttachment() attachment.image = UIImage(named: "image2") let attachmentString = NSAttributedString(attachment: attachment) let mutableAttributedString = NSMutableAttributedString(attributedString: textView.attributedText) for _ in 0...100 { mutableAttributedString.append(NSAttributedString(string: "\n")) mutableAttributedString.append(attachmentString) } textView.attributedText = mutableAttributedString How to handle images in textkit 2 so that it feels smooth while scrolling textview?