[Overview] After building the UI with SwiftUI, when the data is updated through an API, new data is added at the top of the ScrollView, and new UI blocks are added. However, the scroll position remains at the previous location, and it does not move to the top. [Reproduction Steps] Build the view using ScrollView and LazyVGrid. In the LazyVGrid, set up blocks A/B/C/D/E to appear conditionally (using ForEach and Switch). Initially, the array only contains C/D/E. After the API call, add A/B to the array. [Details] This issue does not occur on all devices and has been occurring since iOS 18.1. The affected device list is as follows: iPhone 14 Pro iPhone 15 Pro iPhone 16 Pro Max If this issue occurred equally across all devices, the resolution would be quicker. However, please note that it only occurs on some devices. Below is a part of the code I wrote: [MainV] RefreshableScrollView(onRefresh: { done in // pullToRefresh Action ...... }, progress: { _ in ... }, detectOffSetY: { offsetY in // Scroll Detect Action ... }) { switch tab.item { case .home: HomeView(store: homeStore) .onAppear { homeViewStore.send(.blurblur { tabbarAction blurblur }) } [HomeView] Section( header: HomeNaviView(data: navidata, naviShadowShowYn: Yn) ) { ForEach(viewStore.state.menuList, id: \.self) { menu in switch menu { case .A: A(data: data) case .B: B(data: data) case .C: C(data: data) P.S. The structure is SwiftUI + TCA, and the TCA version is 1.12.0 or later.

When scrolling a basic NSScrollView there seems to be a sudden jump after each flick. Scrolling does not appear smooth and is disorientating. A scroll jump seems to happen directly after letting go of a scroll flick using a trackpad/mouse. Right at that moment the scroll turns into a momentum scroll, slowly decreasing the speed. But the first frame after the gesture the content jumps forward, more than what is expected. Observations: Counterintuitively, scrolling appears to be smoother when disabling NSScrollView.isCompatibleWithResponsiveScrolling. If disabled using a custom NSScrollView subclass there is no large jump anymore. Scrolling also appears to be smoother using a SwiftUI ScrollView. I assume that has the same behaviour as a disabled isCompatibleWithResponsiveScrolling Ironically a WKWebView scrolls much smoother. No sudden jump is observable. It also seems to scroll with faster acceleration, but the individual frames do appear smoother. Why is this better than a native NSScrollView? Elastic scrolling at the bounds of the scroll view also appears much smoother for WKWebViews. When pulling to refresh there is a jump for NSScrollView/SwiftUI, but not for WKWebView. When using an NSScrollView with isCompatibleWithResponsiveScrolling disabled, scrolling appears just as smooth as WKWebView on macOS 13 Ventura and below. On macOS 14 Sonoma scrolling behaviour is suddenly different. Please see a sample project with 4 different scroll views side by side: https://github.com/floorish/ScrollTest Screen recordings show the sudden jumps when scrolling and when elastic scrolling. Tested on Intel & Arm Macs, macOS 11 Big Sur through 15 Sequoia, built with Xcode 16. Should isCompatibleWithResponsiveScrolling be disabled on Sonoma+? Are there any drawbacks? There is also no overdraw anymore since Monterey, as described in https://developer.apple.com/library/archive/releasenotes/AppKit/RN-AppKitOlderNotes/#10_9Scrolling Even with responsive scrolling disabled, why is WKWebView scrolling much smoother than NSScrollView?

In iPadOS18 UITabBarController not releasing viewControllers after deinit with sidebar enabled. On checking the memory Graph Debugger we could see that the viewControllers are hold by UITab which in turn hold by UITabSidebarItem. We don't have control over the UITabSidebarItem and unable to remove the reference. The issue not happens when tabbarController mode is set to 'tabBar' instead of 'sidebar'. We have event tried to set empty tabs before dismiss the view but still the original tabs are not removing in memory and holding the viewcontollers as well. Anyone assist on this issue. Sharing the sample code here

My App always encounter with CoreAutoLayout invade My SnapKit layout constraint as follow: popBgView.snp.makeConstraints { make in make.centerY.equalToSuperview() make.leading.equalTo(assistantTeacherView.snp.trailing).offset(.isiPad ? -50 : -40) if TTLGlobalConstants.isCompactScreen320 { make.width.lessThanOrEqualTo(300) } else { let widthRatio = .isiPad ? 494.0 / 1024.0 : 434.0 / 812.0 make.width.lessThanOrEqualTo(TTLGlobalConstants.screenWidth * widthRatio) } bubbleViewRightConstraint = make.trailing.equalToSuperview().constraint } ..... popBgView.addSubview(functionView) msgLabel.snp.remakeConstraints { make in make.leading.equalToSuperview().inset(Metric.msgLabelHorizantalInset) make.centerY.equalToSuperview() make.trailing.lessThanOrEqualToSuperview().inset(Metric.msgLabelHorizantalInset) make.top.equalTo(Metric.msgLabelVerticalInset) } functionView.snp.makeConstraints { make in make.leading.equalTo(msgLabel.snp.trailing).offset(Metric.msgLabelFunctionSpacing) make.centerY.equalToSuperview() make.trailing.equalToSuperview().offset(-Metric.msgLabelHorizantalInset) } msgLabel and functionView superview is popBgView However, when I try remove from superview for functionView, There is low probability crash: OS Version: iOS 16.1.1 (20B101) Report Version: 104 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: SEGV_NOOP Crashed Thread: 0 Application Specific Information: Exception 1, Code 1, Subcode 14967683541490370463 > KERN_INVALID_ADDRESS at 0xcfb7e4e0f8fe879f. Thread 0 Crashed: 0 CoreAutoLayout 0x382555f44 -[NSISEngine positiveErrorVarForBrokenConstraintWithMarker:errorVar:] 1 CoreAutoLayout 0x382555e9c -[NSISEngine positiveErrorVarForBrokenConstraintWithMarker:errorVar:] 2 CoreAutoLayout 0x3825557e4 -[NSISEngine removeConstraintWithMarker:] 3 CoreAutoLayout 0x382555198 -[NSLayoutConstraint _removeFromEngine:] 4 UIKitCore 0x34d87961c __57-[UIView _switchToLayoutEngine:]_block_invoke 5 CoreAutoLayout 0x382556e8c -[NSISEngine withBehaviors:performModifications:] 6 UIKitCore 0x34d8a1c38 -[UIView(AdditionalLayoutSupport) _switchToLayoutEngine:] 7 UIKitCore 0x34d7f01b0 __57-[UIView _switchToLayoutEngine:]_block_invoke_2 8 UIKitCore 0x34d879770 __57-[UIView _switchToLayoutEngine:]_block_invoke 9 CoreAutoLayout 0x382556e8c -[NSISEngine withBehaviors:performModifications:] 10 UIKitCore 0x34d8a1c38 -[UIView(AdditionalLayoutSupport) _switchToLayoutEngine:] 11 UIKitCore 0x34d8a1848 __45-[UIView _postMovedFromSuperview:]_block_invoke 12 UIKitCore 0x34e7ff8d0 -[UIView _postMovedFromSuperview:] 13 UIKitCore 0x34d85e3c8 __UIViewWasRemovedFromSuperview 14 UIKitCore 0x34d85b1a4 -[UIView(Hierarchy) removeFromSuperview] 15 Collie-iPad 0x203001550 [inlined] InClassAssistantView.functionView.didset (InClassAssistantView.swift:105)

In my visionOS app, which starts in windowed mode, when I enter immersive mode and then exit back to windowed mode, I notice that the window appears dimmer. I start a simple project with settings as image shown below, and took screenShots of my window before and after entering immersive space then quit, compare them, the color value did become dimmer. How can I fix this issue? Or operations I may miss leading to this situation?

In iOS 18, we encountered a crash: Thread 4 name: com.apple.root.user-interactive-qos Thread 4 Crashed: 0 CoreFoundation 0x18c4f9b10 __CFCheckCFInfoPACSignature + 4 1 CoreFoundation 0x18c53ed64 CFBundleGetInfoDictionary + 24 2 CoreFoundation 0x18c53ed1c CFBundleGetIdentifier + 16 3 Foundation 0x18b153740 -[NSUserDefaults(NSUserDefaults) _initWithSuiteName:container:] + 84 4 UIKitCore 0x18ef26ef0 ___UIKitUserDefaults_block_invoke + 40 5 libdispatch.dylib 0x1941ee0d0 _dispatch_client_callout + 20 6 libdispatch.dylib 0x1941ef918 _dispatch_once_callout + 32 7 UIKitCore 0x18ef9de28 _UIKitUserDefaults + 80 8 UIKitCore 0x18f058a7c ___UIKitPreferencesOnce_block_invoke + 20 9 libdispatch.dylib 0x1941ee0d0 _dispatch_client_callout + 20 10 libdispatch.dylib 0x1941ef918 _dispatch_once_callout + 32 11 UIKitCore 0x18f056c8c _UIKitPreferencesOnce + 80 12 UIKitCore 0x18f0563b8 ___UIApplicationMainPreparations_block_invoke + 20 13 libdispatch.dylib 0x1941ec370 _dispatch_call_block_and_release + 32 14 libdispatch.dylib 0x1941ee0d0 _dispatch_client_callout + 20 15 libdispatch.dylib 0x1941fff60 _dispatch_root_queue_drain + 860 16 libdispatch.dylib 0x194200590 _dispatch_worker_thread2 + 156 17 libsystem_pthread.dylib 0x2136ffc40 _pthread_wqthread + 228 18 libsystem_pthread.dylib 0x2136fc488 start_wqthread + 8 Below image show more details: And after set a symbol breakpoint: [NSUserDefaults _initWithSuiteName:container:] We found that at the beginning of app launch, the system will call it: It not always crash, but sometimes especially when app upgrade, what the root cause maybe?

Based on crash reports for our app in production, we're seeing these SwiftUI crashes but couldn't figure out why it is there. These crashes are pretty frequent (>20 crashed per day). Would really appreciate it if anyone has any insight on why this happens. Based on the stacktrace, i can't really find anything that links back to our app (replaced with MyApp in the stacktrace). Thank you in advance! Crashed: com.apple.main-thread 0 libdispatch.dylib 0x39dcc _dispatch_semaphore_dispose.cold.1 + 40 1 libdispatch.dylib 0x4c1c _dispatch_semaphore_signal_slow + 82 2 libdispatch.dylib 0x2d30 _dispatch_dispose + 208 3 SwiftUICore 0x77f788 destroy for StoredLocationBase.Data + 64 4 libswiftCore.dylib 0x3b56fc swift_arrayDestroy + 196 5 libswiftCore.dylib 0x13a60 UnsafeMutablePointer.deinitialize(count:) + 40 6 SwiftUICore 0x95f374 AtomicBuffer.deinit + 124 7 SwiftUICore 0x95f39c AtomicBuffer.__deallocating_deinit + 16 8 libswiftCore.dylib 0x3d783c _swift_release_dealloc + 56 9 libswiftCore.dylib 0x3d8950 bool swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1>>::doDecrementSlow<(swift::PerformDeinit)1>(swift::RefCountBitsT<(swift::RefCountInlinedness)1>, unsigned int) + 160 10 SwiftUICore 0x77e53c StoredLocation.deinit + 32 11 SwiftUICore 0x77e564 StoredLocation.__deallocating_deinit + 16 12 libswiftCore.dylib 0x3d783c _swift_release_dealloc + 56 13 libswiftCore.dylib 0x3d8950 bool swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1>>::doDecrementSlow<(swift::PerformDeinit)1>(swift::RefCountBitsT<(swift::RefCountInlinedness)1>, unsigned int) + 160 14 MyApp 0x1673338 objectdestroyTm + 6922196 15 libswiftCore.dylib 0x3d783c _swift_release_dealloc + 56 16 libswiftCore.dylib 0x3d8950 bool swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1>>::doDecrementSlow<(swift::PerformDeinit)1>(swift::RefCountBitsT<(swift::RefCountInlinedness)1>, unsigned int) + 160 17 SwiftUICore 0x650290 _AppearanceActionModifier.MergedBox.__deallocating_deinit + 32 18 libswiftCore.dylib 0x3d783c _swift_release_dealloc + 56 19 libswiftCore.dylib 0x3d8950 bool swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1>>::doDecrementSlow<(swift::PerformDeinit)1>(swift::RefCountBitsT<(swift::RefCountInlinedness)1>, unsigned int) + 160 20 SwiftUICore 0x651b44 closure #1 in _AppearanceActionModifier.MergedBox.update()partial apply + 28 21 libswiftCore.dylib 0x3d783c _swift_release_dealloc + 56 22 libswiftCore.dylib 0x3d8950 bool swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1>>::doDecrementSlow<(swift::PerformDeinit)1>(swift::RefCountBitsT<(swift::RefCountInlinedness)1>, unsigned int) + 160 23 libswiftCore.dylib 0x3b56fc swift_arrayDestroy + 196 24 libswiftCore.dylib 0xa2a54 _ContiguousArrayStorage.__deallocating_deinit + 96 25 libswiftCore.dylib 0x3d783c _swift_release_dealloc + 56 26 libswiftCore.dylib 0x3d8950 bool swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1>>::doDecrementSlow<(swift::PerformDeinit)1>(swift::RefCountBitsT<(swift::RefCountInlinedness)1>, unsigned int) + 160 27 SwiftUICore 0x4a6c4c type metadata accessor for _ContiguousArrayStorage<CVarArg> + 120 28 libswiftCore.dylib 0x3d783c _swift_release_dealloc + 56 29 libswiftCore.dylib 0x3d8950 bool swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1>>::doDecrementSlow<(swift::PerformDeinit)1>(swift::RefCountBitsT<(swift::RefCountInlinedness)1>, unsigned int) + 160 30 SwiftUICore 0x4a5d88 static Update.dispatchActions() + 1332 31 SwiftUICore 0xa0db28 closure #2 in closure #1 in ViewRendererHost.render(interval:updateDisplayList:targetTimestamp:) + 132 32 SwiftUICore 0xa0d928 closure #1 in ViewRendererHost.render(interval:updateDisplayList:targetTimestamp:) + 708 33 SwiftUICore 0xa0b0d4 ViewRendererHost.render(interval:updateDisplayList:targetTimestamp:) + 556 34 SwiftUI 0x8f1634 UIHostingViewBase.renderForPreferences(updateDisplayList:) + 168 35 SwiftUI 0x8f495c closure #1 in UIHostingViewBase.requestImmediateUpdate() + 72 36 SwiftUI 0xcc700 thunk for @escaping @callee_guaranteed () -> () + 36 37 libdispatch.dylib 0x2370 _dispatch_call_block_and_release + 32 38 libdispatch.dylib 0x40d0 _dispatch_client_callout + 20 39 libdispatch.dylib 0x129e0 _dispatch_main_queue_drain + 980 40 libdispatch.dylib 0x125fc _dispatch_main_queue_callback_4CF + 44 41 CoreFoundation 0x56204 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16 42 CoreFoundation 0x53440 __CFRunLoopRun + 1996 43 CoreFoundation 0x52830 CFRunLoopRunSpecific + 588 44 GraphicsServices 0x11c4 GSEventRunModal + 164 45 UIKitCore 0x3d2eb0 -[UIApplication _run] + 816 46 UIKitCore 0x4815b4 UIApplicationMain + 340 47 SwiftUI 0x101f98 closure #1 in KitRendererCommon(_:) + 168 48 SwiftUI 0xe2664 runApp<A>(_:) + 100 49 SwiftUI 0xe5490 static App.main() + 180 50 MyApp 0x8a7828 main + 4340250664 (MyApp.swift:4340250664) 51 ??? 0x1ba496ec8 (Missing)

When using: [[NSUserDefaults alloc] initWithSuiteName:@"TestSuiteName"]; It sometimes cause crash, the crash detail is: Thread 4 name: com.apple.root.user-interactive-qos Thread 4 Crashed: 0 CoreFoundation 0x1963f9b10 __CFCheckCFInfoPACSignature + 4 1 CoreFoundation 0x19643ed64 CFBundleGetInfoDictionary + 24 2 CoreFoundation 0x19643ed1c CFBundleGetIdentifier + 16 3 Foundation 0x195053740 -[NSUserDefaults(NSUserDefaults) _initWithSuiteName:container:] + 84 4 UIKitCore 0x198e26ef0 ___UIKitUserDefaults_block_invoke + 40 5 libdispatch.dylib 0x19e0ee0d0 _dispatch_client_callout + 20 6 libdispatch.dylib 0x19e0ef918 _dispatch_once_callout + 32 7 UIKitCore 0x198e9de28 _UIKitUserDefaults + 80 8 UIKitCore 0x198f58a7c ___UIKitPreferencesOnce_block_invoke + 20 9 libdispatch.dylib 0x19e0ee0d0 _dispatch_client_callout + 20 10 libdispatch.dylib 0x19e0ef918 _dispatch_once_callout + 32 11 UIKitCore 0x198f56c8c _UIKitPreferencesOnce + 80 12 UIKitCore 0x198f563b8 ___UIApplicationMainPreparations_block_invoke + 20 13 libdispatch.dylib 0x19e0ec370 _dispatch_call_block_and_release + 32 14 libdispatch.dylib 0x19e0ee0d0 _dispatch_client_callout + 20 15 libdispatch.dylib 0x19e0fff60 _dispatch_root_queue_drain + 860 16 libdispatch.dylib 0x19e100590 _dispatch_worker_thread2 + 156 17 libsystem_pthread.dylib 0x21d7dfc40 _pthread_wqthread + 228 18 libsystem_pthread.dylib 0x21d7dc488 start_wqthread + 8 and for more detail crash info can see the attachment image . And Refer to the API's description: /// -initWithSuiteName: initializes an instance of NSUserDefaults that searches the shared preferences search list for the domain 'suitename'. For example, using the identifier of an application group will cause the receiver to search the preferences for that group. Passing the current application's bundle identifier, NSGlobalDomain, or the corresponding CFPreferences constants is an error. Passing nil will search the default search list. - (nullable instancetype)initWithSuiteName:(nullable NSString *)suitename API_AVAILABLE(macos(10.9), ios(7.0), watchos(2.0), tvos(9.0)) NS_DESIGNATED_INITIALIZER; It seems using a constants string is a wrong way. Does any one know what to root cause?

Description Our app (and sample app) are using associated domains to support deep linking. As an unintended side effect we get full support for auto-filling passwords with the QuickType bar on our login screen. However, after the username and password fields are filled and the user taps the Login button, the keyboard stays on screen. We have tried everything I can think of including @FocusState UIKit resignFirstResponder, and many other iterations of testing. Our login screen is in a fullscreencover or sheet. When the sheet dismisses the keyboard stays. In my sample app if I use a navigation stack and push the next view onto the stack, the keyboard closes. I can't provide a useful video because the iOS screen recorder will hide the keyboard when focus is in a SecureField. Note: If we remove the associated domain from the project everything works as expected. Code Example struct ContentView: View { @State private var name: String = "" @State private var password: String = "" @State private var showLogin = false @FocusState private var isFocused: Bool var body: some View { VStack { Button("Login") { showLogin.toggle() } } .fullScreenCover(isPresented: $showLogin) { VStack { TextField("Enter your name", text: $name) .textFieldStyle(.roundedBorder) .focused($isFocused) SecureField("Enter password", text: $password) .autocapitalization(.none) .autocorrectionDisabled(true) .textContentType(.password) .focused($isFocused) Button("Login") { isFocused = false showLogin = false } .buttonStyle(.borderedProminent) } } } } Steps to Reproduce Launch sample app Tap 'Login' Place keyboard focus in the first text field (name) Keyboard with QuickType bar opens Tap 'Passwords' Create a new password for this login item (choose any username) Passwords will close Tap 'Login' to close the sheet Force close the app Reopen the app Tap 'Login' Place keyboard focus in the first text field (name) Keyboard with QuickType” bar opens Tap the auto-fill password button (password for atomicrobot.com in my case) User name and password fields are filled out Keyboard with QuickType bar is still open; keyboard focus is in "password" field Tap 'Login' Sheet closes, keyboard is still open

Description Our app (and sample app) are using associated domains to support deep linking. As an unintended side effect we get full support for auto-filling passwords with the QuickType bar on our login screen. However, after the username and password fields are filled and the user taps the Login button, the keyboard stays on screen. We have tried everything I can think of including @FocusState and UIKit resignFirstResponder, among other things. Our login screen is in a fullscreencover or sheet. When the sheet dismisses the keyboard is still present. In my sample app (and the code below) if I use a navigation stack and push the next view onto the stack, the keyboard closes. I'm not able to provide a useful video because the iOS keyboard closes when focus is in a SecureField. *Note: If we remove the associated domain from our app (and website) the backup iOS password functionality takes over and the keyboard works as expected. Code struct ContentView: View { @State private var name: String = "" @State private var password: String = "" @State private var showLogin = false @FocusState private var isFocused: Bool var body: some View { VStack { Button("Login") { showLogin.toggle() } } .fullScreenCover(isPresented: $showLogin) { VStack { TextField("Enter your name", text: $name) .textFieldStyle(.roundedBorder) .focused($isFocused) SecureField("Enter password", text: $password) .autocapitalization(.none) .autocorrectionDisabled(true) .textContentType(.password) .focused($isFocused) Button("Login") { isFocused = false showLogin = false } .buttonStyle(.borderedProminent) } } } } Steps to Reproduce Launch sample app Tap 'Login' Place keyboard focus in the first text field (name) Keyboard with QuickType bar opens Tap 'Passwords' Create a new password for this login item (choose any username) Passwords will close Tap 'Login' to close the sheet Force close the app Reopen the app Tap 'Login' Place keyboard focus in the first text field (name) Keyboard with QuickType” bar opens Tap the auto-fill password button (password for atomicrobot.com in my case) User name and password fields are filled out Keyboard with QuickType bar is still open; keyboard focus is in "password" field Tap 'Login' Sheet closes, keyboard is still open

Description We are developing a app for iOS and iPadOS that involves extensive custom drawing of paths, shapes, texts, etc. To improve drawing and rendering speed, we use CARenderer to generate cached images (CGImage) on a background thread. We adopted this approach based on this StackOverflow post: https://stackoverflow.com/a/75497329/9202699. However, we are experiencing frequent crashes in our production environment that we cannot reproduce in our development environment. Despite months of debugging and seeking support from DTS and the Apple Feedback platform, we have not been able to fully resolve this issue. Our recent crash reports indicate that the crashes occur when calling CATransaction.commit(). Crash traceback The method names in this traceback are mapped to those in the code sample below. The app name has been masked. Crashed: com.apple.root.user-initiated-qos.cooperative 0 MyApp 0x887408 specialized static CAUtils.commitCATransaction() + 4340151304 (<compiler-generated>:4340151304) 1 MyApp 0x887408 specialized static CAUtils.commitCATransaction() + 4340151304 (<compiler-generated>:4340151304) 2 MyApp 0x8874a4 specialized static CAUtils.addDrawingItemsToRenderer(***) + 250 (CAUtils.swift:250) 3 MyApp 0x887710 specialized static CAUtils.drawOnCGImageWithCARenderer(***) + 267 (CAUtils.swift:267) 4 MyApp 0x8878c0 specialized static CAUtils.drawOnCGImageWithCARendererWithRetry(***) + 315 (CAUtils.swift:315) 5 MyApp 0x736294 XXXManager.generateCGImages(***) + 570 (XXXManager.swift:570) 6 MyApp 0x73404c closure #1 in XXXManager.updateCachedCGImages(***) + 427 (XXXManager.swift:427) 7 libswift_Concurrency.dylib 0x61104 swift::runJobInEstablishedExecutorContext(swift::Job*) + 252 8 libswift_Concurrency.dylib 0x62514 swift_job_runImpl(swift::Job*, swift::SerialExecutorRef) + 144 9 libdispatch.dylib 0x15d8c _dispatch_root_queue_drain + 392 10 libdispatch.dylib 0x16590 _dispatch_worker_thread2 + 156 11 libsystem_pthread.dylib 0x4c40 _pthread_wqthread + 228 12 libsystem_pthread.dylib 0x1488 start_wqthread + 8 Code Sample Below is a sample of our code. While the complete snippet is too long, the issue occurs in addDrawingItemsToRenderer. Please refer to the other methods for completeness and reference purposes. private let transactionLock = NSLock() private let deviceLock = NSLock() private let device = MTLCreateSystemDefaultDevice()! /// This is the method we call from outside. @inline(never) static func drawOnCGImageWithCARenderer( layerRect: CGRect, drawingItems: [DrawingItem] ) -> CGImage? { guard let (texture, renderer) = addDrawingItemsToRenderer( layerRect: layerRect, drawingItems: drawingItems ) else { return nil } renderer.beginFrame(atTime: 0, timeStamp: nil) renderer.render() renderer.endFrame() guard let colorSpace = CGColorSpace(name: CGColorSpace.sRGB), let ciImage = CIImage(mtlTexture: texture, options: [.colorSpace: colorSpace]) else { return nil } let context = CIContext() return context.createCGImage(ciImage, from: ciImage.extent) } /// This is the method will the crash happens @inline(never) fileprivate static func addDrawingItemsToRenderer( layerRect: CGRect, drawingItems: [DrawingItem] ) -> (MTLTexture, CARenderer)? { // We have encapsulated everything related to CALayer and its // associated creations and manipulations within CATransaction // as suggested by engineers from Apple Feedback Portal. beginCATransaction() defer { commitCATransaction() // The crash happens here } let (layer, imageWidth, imageHeight) = addDrawingItemsToLayer(layerRect: layerRect, drawingItems: drawingItems) return createTextureAndRenderer( layer: layer, imageWidth: imageWidth, imageHeight: imageHeight ) } // Below are all internal methods. We have split the method into very // granular parts and marked them as @inline(never) to prevent the // compiler from inlining our code, which may otherwise obscure usage // trackback information in our crash reports. @inline(never) fileprivate static func beginCATransaction() { transactionLock.lock() CATransaction.begin() } @inline(never) fileprivate static func commitCATransaction() { // From our crash report, we believe the crash happens on this line. CATransaction.commit() // It is unlikely that the lock cause the crash as we added it only recently // to ensure that there is only one transaction on our background thread, // and after we added this lock, the crash rate indeed lowered, but still // not fully disappear transactionLock.unlock() } -------------------------------- // The methods below are provided for reference and completeness. While // they may have issues, they do not frequently appear in our crash // reports as the one caused by `CATransaction.commit()` @inline(never) fileprivate static func addDrawingItemsToLayer( layerRect: CGRect, drawingItems: [DrawingItem] ) -> (layer: CALayer, imageWidth: CGFloat, imageHeight: CGFloat) { let layer = CALayer() layer.isGeometryFlipped = SharedAppUtils.isIOS layer.anchorPoint = CGPoint.zero layer.bounds = layerRect layer.masksToBounds = true for drawingItem in drawingItems { // We have thousands or hundred thousands of drawing items to add. // Each drawing item may produce a CALayer, CAShapeLayer or CATextLayer. // This is also why we want to utilise CARenderer to leverage GPU rendering. let sublayerForDrawingItem = drawingItem.createCALayerOrCATextLayerOrCAShapeLayer() layer.addSublayer(sublayerForDrawingItem) } let imageWidth = max(1, layer.frame.size.width * UIScreen.main.scale) let imageHeight = max(1, layer.frame.size.height * UIScreen.main.scale) layer.transform = CATransform3DMakeScale(UIScreen.main.scale, UIScreen.main.scale, 1) layer.frame = .init(origin: .zero, size: .init(width: imageWidth, height: imageHeight)) return (layer, imageWidth, imageHeight) } @inline(never) fileprivate static func createTextureAndRenderer( layer: CALayer, imageWidth: CGFloat, imageHeight: CGFloat ) -> (MTLTexture, CARenderer)? { deviceLock.lock() defer { deviceLock.unlock() } let textureDescriptor = MTLTextureDescriptor.texture2DDescriptor( pixelFormat: .rgba8Unorm, width: Int(imageWidth), height: Int(imageHeight), mipmapped: false ) textureDescriptor.usage = [MTLTextureUsage.shaderRead, .shaderWrite, .renderTarget] guard let texture = device.makeTexture(descriptor: textureDescriptor) else { return nil } let renderer = CARenderer(mtlTexture: texture) renderer.bounds = layer.frame renderer.layer = layer.self return (texture, renderer) }

In SwiftUI, the content and cursor are intermittently outside the bounds of the TextEditor. struct ContentView: View { @State private var text = "" var body: some View { VStack { TextEditor(text: $text) .frame(maxWidth: .infinity, maxHeight: .infinity) .border(Color.gray, width: 1) } .padding() } } I enter multiline text into TextEditor. The content and cursor are intermittently outside the bounds of the TextEditor at the bottom. Screen recording: The problem also appears on my iPad. I guess it may be related to the input method. Is it possible to solve this problem?

Some of our users keep reporting that occasionally some widgets (which initially were working perfectly) are now broken and show only skeletons. Note that the app has multiple widgets, and this happens only to some of them (that is when some widgets get broken, some other widgets are still working normally). While developing the app, I came across this symptom as well, and when I read the device console, I found the following errors in the console (which the system was repeatedly reporting to the console): Unable to get connection interface: Error Domain=LNConnectionErrorDomain Code=1100 "Unable to locate com.example.app.MyAppntents for the com.apple.intents-service extension point" UserInfo={NSLocalizedDescription=Unable to locate com.example.app.MyAppIntents for the com.apple.intents-service extension point} The affected widgets use the 'UserDefaults with groups' to read the data that is stored by the host app. And I think that sometimes the widget fails (or even crashes) while reading the data from the UserDefaults and it ends up showing the skeleton. The only remedy I found was Uninstall the app Reboot the device Install the app again. After this, the widget starts to work again.. So, what can be the reason behind this? Is this an iOS bug or what and how to fight it?

Hi team. I am working on an app that uses the Screen Time API. I got access to the family controls (distribution) capability through the request process for my main app. I added a DeviceActivityReport extension in XCode, but haven't been able to get the extension to show up on the screen. I noticed that the extension only has the development version of the family controls capability available. Is this the source of my errors? I was able to get the screen time displayed in a test app I built where both the main app and extension used the development version of the capability, which led me to believe that discrepancy could be the issue. Let me know if there is anything I can provide to help in the debugging process. I didn't send a minimal example in this request due to the fact that I would have to remove most of my functionality to create a "minimal" example (since the signing is only for my main app), but I can do that if needed. Thanks! I looked through the logs in the console for the phone (I'm testing on a real iPhone 13 Pro Max), but didn't see anything that popped out after looking (not exactly sure what to look for though). STEPS TO REPRODUCE: Create an app with the Family Controls, Distribution capability. Then create the DeviceActivityReport with the Family Control, Development capability. Attempt to see the DeviceActivityReport in the main app. NOTE: I was successfully able to create a minimal test app completely separately that used the Development versions of the capabilities for both with the exact same extension code. That's why I think the issue could be due to the capability version discrepancy.

Demo project link https://cdn.pokekara.com/int/other/1737343007_fbcdee810da429552b12ffa2644d928c.zip

There is an assumption that this is a bug and it is reproduced only on a real device, it cannot be reproduced on a simulator. I make a simple sheet with a state, hang PresentationDetens on the sheet elements and just quickly try to open a modal window and immediately close it (we close it with a swipe), and immediately open another or the same modal window and we get that our modal window opens on the entire screen, and not what we expected let's say presentationsDetens 500 how to fix this?

Hello, I am currently encountering an issue where SwiftUI View Previews cannot be displayed when the View is defined in a Static Framework target. This issue only occurs under specific conditions. Environment Xcode: 16.2 Scheme Structure: MainApp Test Target: TestHogeFeature Test Setting: Gather coverage (Code coverage collection) enabled(all) Target Structure: MainApp (Application target) Dependencies: [HogeFeature, Core] HogeFeature (Static Framework target) Dependencies: [Core] Core (Framework target) Dependencies: None TestHogeFeature (Unit test target) Dependencies: [HogeFeature] Summary I am currently working on a SwiftUI-based project and have encountered an issue where Previews fail to display under specific conditions. Below are the details: Issue In the MainApp scheme, when the code coverage collection setting (Gather coverage for) is enabled, Previews for SwiftUI Views within the HogeFeature (Static Framework) target fail to display correctly. However, the issue is resolved by taking one of the following actions: Change HogeFeature from a Static Framework to a Dynamic Framework. Remove the build setting MACH_O_TYPE: staticlib Disable the Gather coverage setting in the MainApp scheme. I have attached the actual error log from the failed Preview. preview error log Questions Why does this issue occur only when using a Static Framework with code coverage enabled? Is there any way to resolve this issue while maintaining the current configuration (Static Framework with code coverage enabled)? I would appreciate any advice or insights regarding the cause and potential solutions.

Hello, given this following simple SwiftUI setup: struct ContentView: View { var body: some View { CustomFocusView() } } struct CustomFocusView: View { @FocusState private var isFocused: Bool var body: some View { color .frame(width: 128, height: 128) .focusable(true) .focused($isFocused) .onTapGesture { isFocused.toggle() } .onKeyPress("a") { print("A pressed") return .handled } } var color: Color { isFocused ? .blue : .red } } If I run this via Mac – Designed for iPad, the CustomFocusView toggles focus as expected and cycles through red and blue. Now if I run this same exact code via Mac Catalyst absolutely nothing happens and so far I wasn't able to ever get this view to accept focused state. Is this expected? I would appreciate if anyone could hint me on how to get this working. Thank and best regards!

I am wondering how I change the measurement units on screen in my CPMapTemplate. In my screenshot below the distance is in miles, but how can I change that to kilometers? Does this need to come from my route data? I am not seeing this anywhere in the CarPlay programming guide or in the documentation.

I filed FB16332997 about the VERY high snowfall estimates I'm seeing in WeatherKit and iOS Weather. I initially thought something was wrong with my weather app but I verified the numbers with the iOS Weather app and another third party weather app. For Atlanta last week it was saying 7.5" when it ended up being 2" (which I can live with). Two days ago it reported there could be 16" of snow in northern Florida. That's impossible! This morning it was reporting that Niceville could have 6-7" of snow, which would be significantly more than highest amount in recorded history for Florida (where snow is extremely rare). It almost makes me wonder if the liquid precipitation value is actually the snowfall amount in reality. And then that is incorrectly being converted to the snowfall amount.