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.

Hi everyone, I'm encountering a persistent build error in a SwiftUI iOS app and I'm running out of ideas. Setup: My ContentView uses two @EnvironmentObjects (GameViewModel, SettingsStore). The GameViewModel has an AppState enum (.welcome, .setup, .game). The ContentView body uses a switch viewModel.currentAppState (wrapped in a Group) to display one of three different views (WelcomeView, SetupView, GameView). Navigation between states is triggered by changing viewModel.currentAppState within withAnimation blocks in the respective subviews. Problem: I consistently get the build error 'buildExpression' is unavailable: this expression does not conform to 'View' pointing to the lines inside the .setup and .game cases of the switch statement in ContentView. Code (ContentView.swift - Simplified Test Version that STILL fails): // Zweck: Steuert die Hauptnavigation basierend auf AppState // KORRIGIERTE VERSION OHNE .animation(...) am Ende import SwiftUI struct ContentView: View { // Zugriff auf das ViewModel, um den AppState zu lesen @EnvironmentObject var viewModel: GameViewModel // SettingsStore wird von untergeordneten Views benötigt @EnvironmentObject var settingsStore: SettingsStore var body: some View { // Optional: Group um das switch-Statement, kann manchmal helfen (kannst du auch weglassen) Group { // Wechsle die Ansicht basierend auf viewModel.currentAppState switch viewModel.currentAppState { case .welcome: WelcomeView() // EnvironmentObjects an WelcomeView übergeben .environmentObject(viewModel) .environmentObject(settingsStore) // Übergangsanimation .transition(.opacity) case .setup: SetupView() // EnvironmentObjects an SetupView übergeben .environmentObject(viewModel) .environmentObject(settingsStore) // Übergangsanimation .transition(.asymmetric(insertion: .move(edge: .trailing), removal: .move(edge: .leading))) case .game: GameView() // EnvironmentObjects an GameView übergeben .environmentObject(viewModel) .environmentObject(settingsStore) // Übergangsanimation .transition(.asymmetric(insertion: .move(edge: .trailing), removal: .move(edge: .leading))) } } // Ende der optionalen Group // !!! WICHTIG: KEIN .animation(...) Modifier hier !!! } } // Vorschau struct ContentView_Previews: PreviewProvider { static var previews: some View { // Erstelle Instanzen für die Vorschau let vmWelcome = GameViewModel() vmWelcome.currentAppState = .welcome let vmSetup = GameViewModel() vmSetup.currentAppState = .setup let vmGame = GameViewModel() vmGame.currentAppState = .game vmGame.currentCard = Card.defaultCards.first let settings = SettingsStore() // Zeige verschiedene Zustände in der Vorschau an Group { ContentView() .environmentObject(vmWelcome) .environmentObject(settings) .previewDisplayName("Welcome State") ContentView() .environmentObject(vmSetup) .environmentObject(settings) .previewDisplayName("Setup State") ContentView() .environmentObject(vmGame) .environmentObject(settings) .previewDisplayName("Game State") } } } Troubleshooting Steps Taken (No Success): Ensured correct placement of .environmentObject modifiers on subviews within the switch. Removed a previous .animation() modifier applied directly to the switch. Ensured state changes triggering transitions are wrapped in withAnimation. Wrapped the switch in a Group. Multiple "Clean Build Folder". Deleted entire Derived Data folder (with Xcode closed). Restarted Xcode and the Mac multiple times. Deleted and recreated ContentView.swift with the code above. Crucially: The errors persist even when replacing WelcomeView(), - - - --- SetupView(), and GameView() with simple Text("...") views inside the switch cases (as shown in the code snippet above). Environment: Xcode Version: newest macOS Version: newest Question: Does anyone have any idea why the compiler would still fail to type-check this switch structure, even when the views inside are simplified to basic Text? What else could I try to diagnose or fix this? Could it be related to the subviews (SetupView/GameView) potentially having their own NavigationView or complexity, even when replaced by Text in the failing ContentView? Thanks for any suggestions!

The Problem Push buttons (created as a PDFAnnotation using PDFKit) do not properly write the associated caption's key-value pair (within the annotation's appearance characteristics dictionary) to a PDF document. What is Happening Push button widget annotations can have a caption that is displayed as the button’s label. In the PDF 1.7 specification (ISO PDF32000-2008, s. 12.5.6.19), a widget annotation can have an ‘appearance characteristics dictionary’ (MK) with properties to construct the appearance of the widget. The caption property (CA) is used to construct a button’s caption/label. PDFKit uses the PDFAnnotation .caption property to set the value of a push button’s caption as a string. Observation 1: In an open PDF document (using PDFView), a push button widget annotation can be created and added to a PDFPage using the following code: let pushButton = PDFAnnotation(bounds: pushButtonBounds, forType: .widget, withProperties: nil) pushButton.widgetFieldType = .button pushButton.widgetControlType = .pushButtonControl pushButton.caption = "My Button" page.addAnnotation(pushButton) The PDFAnnotation .caption property is used to set the caption to the required string. As a result, the push button is correctly displayed on the PDFPage with the correct label being display on the button. While the PDF document remains open, the appearance characteristics dictionary (an PDFAppearanceCharacteristics object) retains a key-value pair for the caption with the correct value as expected. On saving/writing to the PDF file, however, the key-value pair for the caption in the appearance characteristics dictionary is not written to the PDF document’s file. Resulting PDF markup: 6 0 obj << /Rect [ 256 299.8977 356 399.8977 ] /Border [ 0 0 0 ] /T (button23) /F 4 /Subtype /Widget /DA (/.AppleSystemUIFont 13 Tf 0 g) /MK 8 0 R /C [ 0 ] /AP 9 0 R /V /Off /M (D:20250330154918Z00'00') /FT /Btn /Type /Annot /Ff 65536 >> endobj 9 0 obj << /N 10 0 R >> endobj 8 0 obj << /BG [ 0.75 ] >> endobj 10 0 obj << /Filter /FlateDecode /Type /XObject /Subtype /Form /FormType 1 /BBox [0 0 100 100] /Resources 11 0 R /Length 170 >> stream x }ê1 Ç0 Öw~≈ ahÈ KÈ q1q0\‚`ú Ÿ¿ 8¯Ôm% u0óª‰.Ô{yπ åP°H-}ª‡à y3 ¸ %≠¡‰ %› g¨$•µMVXø‡Hé†Ö ”î“¿˜® BI•L ˆ†b A pü‰Ã @ÓpB∫ †æœs ãÙ:d8Éwÿr»/}” €∂I÷Bõ B;'+gm Ô˝„ mÙ~ L*>• endstream endobj On closing the PDF document, the assigned value for the push button’s caption is not written to the file and is lost. Observation 2: On reopening the PDF document, and assigning a new value for the already-created push button’s caption, a key-value pair for the caption is again correctly added to the PDFAnnotation appearance characteristics dictionary. On saving/writing to the PDF file, this time, the caption key-value pair in the appearance characteristics dictionary is correctly written/saved to the PDF document file. Resulting PDF markup: 6 0 obj << /Border [ 0 0 0 ] /Rect [ 256 299.8977 356 399.8977 ] /T (button23) /F 4 /BS 8 0 R /Subtype /Widget /DA (/.AppleSystemUIFont 13 Tf 0 g) /MK 9 0 R /C [ 0 ] /AP 10 0 R /V /Off /M (D:20250330154918Z00'00') /FT /Btn /Type /Annot /Ff 65536 >> endobj 10 0 obj << /N 11 0 R >> endobj 9 0 obj << /BG [ 0.75 ] /CA (My Button) >> endobj 8 0 obj << /W 0 >> endobj 11 0 obj << /Filter /FlateDecode /Type /XObject /Subtype /Form /FormType 1 /BBox [0 0 100 100] /Resources 12 0 R /Length 163 >> stream x uè1 ¬@ Ö˜˛ä7∂√]ì´◊Î≠ ¡A 8à”a∑Vj·ø˜jë™ !ÅÑ|y/=ˆËA1òʺ]pDá|=0¬“Œb ø+Õ gùf2E≤∞Ê≈N` û·Xm©-BãZ†H Ÿ ¿≈ºPÄ= Ø míãp •¡ ÈÓÅ˙>é “kó· Ÿb#—¬ Ûã¶2∂Ñ2fiΠ;óDÌiÓ?ü>LÁûÊy;} endstream endobj Impact on User Experience: Push button captions may not be properly saved to the PDF document’s file. This may result in an application redrawing a push button without a caption/label. More so, an application that uses the caption value to “read” a button’s label (e.g., for accessibility purposes) will not be able to do so.

The iOS app that I’m helping to develop displays the following behavior, observed on an iPad Pro (4th generation) running iOS 18.1.1: The app uses UIAlertController to show an action sheet with two buttons (defined by two UIAlertAction objects). Each button has a handler block, and the first thing each handler does is to log that it was called. When the user taps one of the buttons and the action sheet disappears, most of the time the appropriate UIAlertAction handler is called. But sometimes there is no log entry for either of the action handlers, nor does the app do anything else associated with the chosen button, in which case I conclude that the handler was not called. I want to emphasize that I’m describing instances of the same action sheet displayed by the same code. Most of the time the appropriate button handler is called, but sometimes the handler is not called. The uncalled handler problem occurs about once per hour during normal use of the app. The problem has continued to occur across many weeks of testing. What could cause UIAlertController not to call its action handler?

My App Clip is associated with three domains: • nfc.ttwifi.net • qr.ttwifi.net Currently, I’m experiencing an issue where scanning a QR code from qr.ttwifi.net correctly launches my App Clip. However, when I scan a QR code from nfc.ttwifi.net, it successfully displays the App Clip card but then shows the message “App Clip unavailable.” I checked the Website Status in App Store Connect, and both domains have their Debugging Status and Cache Status marked as Verified. One important detail to note: Yesterday, while submitting a new version for review, I noticed that nfc.ttwifi.net showed “Unable to connect to AASA file” in the Cache Status in App Store Connect. The cache status update time was March 27, 2025, at 6:52 PM. However, when I checked today, both domains appeared to be fine, and the cache status update time was March 27, 2025, at 7:07 PM. How can I restore the App Clip functionality for my nfc.ttwifi.net domain?

On iOS17, UIDevice.current.batteryLevel is returning values rounded to 0.05, such as 1, 0.95, 0.9. Which used to be a 1% granularity in iOS16. Is this a bug or a new feature?

How should I program the globe key? If possible, could you teach me in C language?

Hi Apple team and community, We’re encountering a strange issue with Live Activity that seems related to memory management or background lifecycle. ❓ Issue: Our app updates a Live Activity regularly (every 3 minutes) using .update(...). However, after the app remains in the background for around 8 hours, the Live Activity reverts to the initial state that was passed into .request(...). Even though the app continues sending updates in the background, the UI on the Lock Screen and Dynamic Island resets to the original state.

Title: SIGTRAP Crash in QuartzCore/CALayer during UI Lifecycle Changes Description: My app is experiencing occasional crashes triggered by a SIGTRAP signal during UI transitions (e.g., scene lifecycle changes, animations). The crash occurs in QuartzCore/UIKitCore code paths, and no business logic appears in the stack trace. Crash Context: Crash occurs sporadically during UI state changes (e.g., app backgrounding, view transitions). Stack trace involves pthread_mutex_destroy, CA::Layer::commit_if_needed, and UIKit scene lifecycle methods. Full crash log snippet: Signal: SIGTRAP Thread 0 Crashed: 0 libsystem_platform.dylib 0x... [symbol: _platform_memset$VARIANT$Haswell] 2 libsystem_pthread.dylib pthread_mutex_destroy + 64 3 QuartzCore CA::Layer::commit_if_needed(...) 4 UIKitCore UIScenePerformActionsWithLifecycleActionMask + 112 5 CoreFoundation _CFXNotificationPost + 736 Suspected Causes: Threading Issue: Potential race condition in pthread_mutex destruction (e.g., mutex used after free). UI Operation on Background Thread: CALayer/UIKit operations not confined to the main thread. Lifecycle Mismatch: Scene/UI updates after deallocation (e.g., notifications triggering late UI changes). Troubleshooting Attempted: Enabled Zombie Objects – no obvious over-released objects detected. Thread Sanitizer shows no clear data races. Verified UIKit/CoreAnimation operations are dispatched to MainThread. Request for Guidance: Are there known issues with CA::Layer::commit_if_needed and scene lifecycle synchronization? How to debug SIGTRAP in system frameworks when no app code is in the stack? Recommended tools/approaches to isolate the mutex destruction issue.

I have some apps using SwiftData document based. They work as expected under iOS17, but not under iOS18: install the app on a iPad 11 pro (first gen) from my MacBook open the app and open an existing fils (perfect under iOS17) it shows a blank, white screen, no data I can create a new document, blank screen, no data When I open that newly created file on a iOS 17 iPad pro, it works perfect, as expected The apps were created from scratch under macOS 14.7 with the corresponding Xcode/Swift/UI version. iOS devices under iOS17 Are there any known problems with document based SwiftData-apps under iOS18, are there any changes one has to made? Thank You so much for any help!

Hello, In my SwiftUI App i'm trying to create a custom UI trait and a matching bridged SwiftUI environment key. I want to override the environment key in a swift view and then have that reflect in the current UITraitCollection. I'm following the pattern in the linked video but am not seeing the changes reflect in the current trait collection when I update the swift env value. I can't find anything online that is helping. Does anyone know what I am missing? https://developer.apple.com/videos/play/wwdc2023/10057/ // Setup enum CustomTheme: String, Codable { case theme1 = “theme1”, theme2 = “theme2” } struct customThemeTrait: UITraitDefinition { static let defaultValue = brand.theme1 static let affectsColorAppearance = true static let identifier = "com.appName.customTheme" } extension UITraitCollection { var customTheme: CustomTheme { self[customThemeTrait.self] } } extension UIMutableTraits { var customTheme: CustomTheme { get { self[customThemeTrait.self] } set { self[customThemeTrait.self] = newValue } } } private struct customThemeKey: EnvironmentKey { static let defaultValue: CustomTheme = .theme1 } extension customThemeKey: UITraitBridgedEnvironmentKey { static func read(from traitCollection: UITraitCollection) -> CustomTheme { traitCollection.customTheme } static func write(to mutableTraits: inout UIMutableTraits, value: CustomTheme) { mutableTraits.customTheme = value } } extension EnvironmentValues { var customTheme: CustomTheme { get { self[customThemeKey.self] } set { self[customThemeKey.self] = newValue } } } // Attempted Usage extension Color { static func primaryBackground() -> Color { UITraitCollection.current.customTheme == .theme1 ? Color.red : Color.blue } } struct ContentView: View { @State private var theme = .theme1 var body: some View { if (dataHasLoaded && themeIsSet) { HomeView() .environment(\.customTheme, theme) } else { SelectThemeView( theme: self.theme, setContentThemeHandler) } } func setContentThemeHandler(theme: customTheme) { self.theme = theme } } struct HomeView() { @Environment(\.customTheme) private var currentTheme: customTheme var body: some View { VStack { Text("currentTheme: \(currentTheme.rawValue)") .background(Color.primaryBackground()) Text("currentUITrait: \(UITraitCollection.current.customTheme.rawValue)") .background(Color.primaryBackground()) } } } OUTCOME: After selecting theme2 in the theme selector view and navigating to the homeView, the background is still red and the env and trait values print the following: currentTheme: theme2 currentUITrait: theme1 Can anyone help me identify what I am missing?

It seems that NSTextView has an issue with deleting text and setting any attribute at the same time, when it also has a textContainerInset. With the code below, after 1 second, the empty line in the text view is automatically deleted and the first line is colored red. The top part of the last line remains visible at its old position. Selecting the whole text and then deselecting it again makes the issue disappear. Is there a workaround? I've created FB16897003. class ViewController: NSViewController { @IBOutlet var textView: NSTextView! override func viewDidAppear() { textView.textContainerInset = CGSize(width: 0, height: 8) let _ = textView.layoutManager textView.textStorage!.setAttributedString(NSAttributedString(string: "1\n\n2\n3\n4")) textView.textStorage!.addAttribute(.foregroundColor, value: NSColor.labelColor, range: NSRange(location: 0, length: textView.textStorage!.length)) DispatchQueue.main.asyncAfter(deadline: .now() + 1) { [self] in textView.selectedRange = NSRange(location: 3, length: 0) textView.deleteBackward(nil) textView.textStorage!.beginEditing() textView.textStorage!.addAttribute(.foregroundColor, value: NSColor.red, range: NSRange(location: 0, length: 2)) textView.textStorage!.endEditing() } } }

This sample code exhibits two issues: struct ContentView: View { @State private var myColor = Color.red var body: some View { VStack() { List() { Text("Object") Text("Object") Text("Object") .listRowSeparatorTint(myColor) Text("Object") } Button(action:{myColor = Color.green}) {Text("Change color")} } .foregroundColor(myColor) } } the row separator isn't redraws when the @State property change listRowSeparatorTint apply to two lines The first point is really disappointing. Is there anyone which know if this is a bug or there is a more correct way to use listRowSeparatorTint with changing parameter?

All the threads only contain system calls. The crashed thread only contains a single call to my app's code which is main.swift:13. What could cause such a crash? crash.crash

Hi everyone! I am having a bit of trouble with why my Map() is overwriting my customized tabBar settings. Specifically my tab bar background. (White -> Black) Map(position: $cameraPosition) { UserAnnotation() } .toolbarBackground(.hidden, for: .tabBar) This above ^ is a view which acts as a tab view for my tab bar. I have customized my tab bar as follows just so it was obvious to see me changes. let tabAppearance = UITabBarAppearance() tabAppearance.configureWithOpaqueBackground() tabAppearance.backgroundColor = .white UITabBar.appearance().standardAppearance = tabAppearance UITabBar.appearance().scrollEdgeAppearance = tabAppearance I have tried implementing solutions which is seen with my .toolbar attempt but nothing has help. I would like the tab bar to be consistent with all of my views and from my understanding the Map is overwriting those settings.

I am developing a MacOS app with a vertically oriented ScrollView. Inside that View I use a LazyVStack. In the LazyVStack I have a column of images. I want the images to occupy as much of the LazyVStack width as possible so I created a frame for the VStack with a maxWidth: .infinity. When the user grabs the edge of the window and drags it to reduce the window width, the Views of the window adjust themselves to fit the reduced space. This includes reducing the width of the images. I maintain a fixed aspect ratio for the images, so the height of the images is reduced too. My problem arises when the width of the images (and height) reduces to the point where the scroll bar is no longer needed because all of the images fit within the height of the ScrollView, and the ScrollView removes the scroll bar. That triggers a redraw of the images, with a slightly bigger size because the width used by the scroll bar is now available. When the the images get bigger they don't all fit within the height of the ScrollView anymore and the scrollbar is restored. That, of course, reduces the space available for the images, so they are reduced in size again - which then triggers the ScrollView to remove the scrollbar again. The whole thing goes into a spasm of flickering images (bigger and smaller) and scrollbar (off and on) until finally I get the dreaded error message: The window has been marked as needing another Display Window pass, but it has already had more Display Window passes than there are views in the window. There seems to be no way to prevent this behavior by setting an option on the ScrollView. It would be great if one could indicate that the scroll bar should always remain visible, or at least that the space occupied by the scroll bar remain, even if it is just empty. The only way I could solve this problem was to go through a somewhat involved calculation to set the image width in such a way that it still responds to window width changes (and some other size changes I allow in some of the other app's Views). This complication would not be necessary if there were better controls on the scroll bar. Is there a reason for not providing adequate controls for the ScrollView? Its uncontrollable behavior complicates the programming.

I want record screen in my app,the method startCaptureWithHandler:completionHandler:,the sampleBuffer， It is supposed to exist but it has become nil.Not only that,but there‘s another problem,when I want to stop recording and save the video,I will check [RPScreenRecorder sharedRecorder].recording first, it will be false sometime,that problems are unusual in iOS 18.3.2 iPhoneXs Max,and unexpected,here is my code -(void)startCaptureScreen { NSLog(@"AKA++ startCaptureScreen"); if ([[RPScreenRecorder sharedRecorder] isRecording]) { return; } //屏幕录制 [[RPScreenRecorder sharedRecorder]setMicrophoneEnabled:YES]; NSLog(@"AKA++ MicrophoneEnabled AAAA startCaptureScreen"); [[RPScreenRecorder sharedRecorder]setCameraEnabled:YES]; [[RPScreenRecorder sharedRecorder] startCaptureWithHandler:^(CMSampleBufferRef _Nonnull sampleBuffer, RPSampleBufferType bufferType, NSError * _Nullable error) { if(self.assetWriter == nil){ if (self.AVAssetWriterStatus == 0) { [self setupAssetWriterAndStartWith:sampleBuffer]; } } if (self.AVAssetWriterStatus != 2) { return; } if (error) { // deal with error return; } if (self.assetWriter.status != AVAssetWriterStatusWriting) { [self assetWriterAppendSampleBufferFailWith:bufferType]; return; } if (bufferType == RPSampleBufferTypeVideo) { if(self.assetWriter.status == 0 ||self.assetWriter.status > 2){ } else if(self.videoAssetWriterInput.readyForMoreMediaData == YES){ BOOL success = [self.videoAssetWriterInput appendSampleBuffer:sampleBuffer]; } } if (bufferType == RPSampleBufferTypeAudioMic) { if(self.assetWriter.status == 0 ||self.assetWriter.status > 2){ } else if(self.audioAssetWriterInput.readyForMoreMediaData == YES){ BOOL success = [self.audioAssetWriterInput appendSampleBuffer:sampleBuffer]; } } } completionHandler:^(NSError * _Nullable error) { //deal with error }]; } and than ,when want to save it : -(void)stopRecording { if([[RPScreenRecorder sharedRecorder] isRecording]){ // The problem is sporadic,recording action failed,it makes me confused } [[RPScreenRecorder sharedRecorder] stopCaptureWithHandler:^(NSError * _Nullable error) { if(!error) { //post message } }]; }

I'm making a custom keyboard extension in Objective-C for iOS 15+. Originally I designed myCustomInputView and put all my keyboard stuff into it, using constraints for everything. I then would add it as a subview like this: [myCustomKeyboardVC.inputView addSubview:myCustomInputView] and then contain it to .inputView. That mostly worked fine, except that after making and dismissing several I had a bunch of myCustomInputView objects remaining, being referenced by _inputViewContent which isn't being used by a custom keyboard anymore. I saw a suggestion that I should do this instead: myCustomKeyboardVC.inputView = myCustomInputView so that myCustomInputView is assigned directly to the VC's .inputView rather than being a subview of it. But this has problems because I now don't know what to constrain it to, and it runs wider than the screen. (ie, how do I constrain myCustomInputView to the keyboard width)? So I guess my basic question is: must custom UIInputViews be assigned directly to .inputView or can they be a subview of it?

To get menubar size, we can call. let menuBarHeight = NSStatusBar.system.thickness That is returning 24 and it is the same as my external screen. I did command + shift + 5 and use the screen capture tool to rougly measure the size of menubar. It is roughly 24px. However, for my macbook pro 14 inches m2 pro. The menubar seem thicker because of the webcam. Is there a way to find out the size in Swift?

Hello, is there a way to implement Continuity Markup in our own apps? (This is what I'm talking about: https://support.apple.com/en-us/102269 , scroll down to "Use Continuity Markup"). Also, why does a QuickLook panel (QLPreviewPanel.shared()) not display the markup options when triggered from my app for png image files in my app's Group Container? Do I need to implement certain NSServicesMenuRequestor methods for that? Sadly, I could not find any docs on that. Thank you, – Matthias

popup window don't react to touch on iOS 18, works fine on iOS 17, this is the code: import SwiftUI extension View { public func popup<Content, Item>( item: Binding<Item?>, onDismiss: (() -> Void)? = nil, @ViewBuilder content: @escaping (Item) -> Content ) -> some View where Content: View, Item: Equatable { return self.overlay( PopupWrapper(item: item, onDismiss: onDismiss, content: content) ) } } struct PopupWrapper<Content, Item>: View where Content: View, Item: Equatable { @Binding var item: Item? var onDismiss: (() -> Void)? var content: (Item) -> Content @State var isAnimating = false var body: some View { Group { if let item { ZStack { Color.black .opacity(0.3) .ignoresSafeArea() .contentShape(Rectangle()) .gesture( TapGesture().onEnded { withAnimation(.spring(duration: 0.2)) { isAnimating = false DispatchQueue.main.asyncAfter(deadline: .now() + 0.2) { dismiss() } } } ) content(item) .scaleEffect(isAnimating ? 1 : 0.3) .opacity(isAnimating ? 1 : 0) .onAppear { withAnimation(.spring(duration: 0.3)) { isAnimating = true } } .gesture( TapGesture().onEnded { withAnimation(.spring(duration: 0.2)) { isAnimating = false DispatchQueue.main.asyncAfter(deadline: .now() + 0.2) { dismiss() } } } ) .onDisappear { dismiss() } } } else { EmptyView() } } } func dismiss() { item = nil isAnimating = false onDismiss?() } }