I found that the page gets stuck after completing face authentication when using ASWebAuthenticationSession to call webauthn JSAPI. This issue has occurred on both 15.4 and 15.1.1 systems.

Hello! This is a follow up to this thread but how do you set the number of lines in a UIButtonConfiguration? I'm assuming that maybe we can do this through using attributedTitle/NSAttributedString, but not sure which property or specific attribute to use. Can I get any help towards setting the amount of lines? Any help is appreciated!

Hey, I am writing a drawing app for iPad and Apple Pencil. Since today I am getting weird readings from my Apple Pencil. The first 2-6 touches the UITouch event gives me a 0.33333333 force reading. After these first UITouches it continues reading correctly. It's very inconsistent between Pencil touches. It was working correctly earlier today. I thought I might have changed something in my code to cause it, but I reverted it to a prior state and it still kept happening. With the 0.333333 at the start I don't know what causes it, or if its a device problem. I tested with two pencils already.

When I scrolled down my CollectionView, sometimes I got a message like "[connection] nw_connection_add_timestamp_locked_on_nw_queue [C1] Hit maximum timestamp count, will start dropping events". and more scroll down, "[connection] nw_connection_add_timestamp_locked_on_nw_queue [C2] Hit maximum timestamp count, will start dropping events" How can I solve this problem? I'm using UIKit, diffableDatasource, collectionView

Follow up to this thread, does adjustsFontSizeToFitWidth also follow the same thinking? Is it assumed that if we use a font style, this doesn't need to be set in a UIButton if we're using UIButtonConfiguration?

I am having issues with the Font Sizes on iOS17 Beta. When running the app in the simulator and on the device, the font weight for my app suddenly changed. For example, it has always been "Regular" and it changed to "Semibold" even thought its set to be in "Regular". I am also adding a new label, and no matter what I do to the size, it does not change. On the storyboard is shows the correct size I set, but then running it on the simulator or in my device running iOS17 Beta it shows smaller or the the regular size of 17. Is anyone else experiencing this issue?

Hi all, hope ur doing well. Recently I found a strange behavior on UINavigationController popToViewController:animated:. I setup a dummy app with an UINavigationController and insert multiple UIViewControllers into it (no less than 4 view controllers). After that, I call [navigationController popToViewController:navigationController.viewControllers[0] animated:YES] to pop to the root view controller and monitors the status of navigationController.viewControllers instantly after it (in the same block). What I found is that UIKit instead of just popping all view controllers on top of the previous root view controller, it also inserts the previous top view controller to the bottom of the stack. This seems like a intermediate behavior and from the UI everything looks fine. Example: Before popTo: [A, B, C, D] Calling popTo: [navigationController popToViewController:navigationController.viewControllers[0] animated:YES] After popTo: [D, A] Would like to get some help to understand if this is an expected behavior and the reason. Thanks!

In an objective C app I'm now using (in every view controller): (void) traitCollectionDidChange: (UITraitCollection *) previousTraitCollection { ..... } to handle dark mode changes. This is all very easy to implement. traitCollectionDidChange is deprecated in iOS 17. In the documentation there is no objective C example on how to work with the new iOS17 registerForTraitChanges function. Hard to figure out how to do this. Am not familiar with Swift, so the wwdc video could not help me. Where can I find some objective C examples? Best regards/Rolf Netherlands

I have this exception backtrace in my app. I'm not sure if this crash is from my implementation or from the OS. From the frame 2 we can see that this is the one that throwing exception, but I still have no idea about it. Does anyone can help? Thanks Here is the back complete crash log and the backtrace: 2023-07-20_10-12-23.5237_+0700-e3c7635495de265f5efcc92a0d27dd1d0f7bede7.crash Last Exception Backtrace: 0 CoreFoundation 0x1b6838d78 __exceptionPreprocess + 220 (NSException.m:200) 1 libobjc.A.dylib 0x1cf49d734 objc_exception_throw + 60 (objc-exception.mm:565) 2 CoreFoundation 0x1b6890024 +[NSException raise:format:] + 112 (NSException.m:156) 3 UIKitCore 0x1b9617e20 -[UIDocument writeContents:toURL:forSaveOperation:originalContentsURL:error:] + 616 (UIDocument.m:1329) 4 UIKitCore 0x1b9617a9c -[UIDocument writeContents:andAttributes:safelyToURL:forSaveOperation:error:] + 492 (UIDocument.m:1286) 5 UIKitCore 0x1b9619264 __59-[UIDocument saveToURL:forSaveOperation:completionHandler:]_block_invoke_3 + 224 (UIDocument.m:1490) 6 UIKitCore 0x1b96190cc __59-[UIDocument saveToURL:forSaveOperation:completionHandler:]_block_invoke_2 + 380 (UIDocument.m:1524) 7 UIKitCore 0x1b961865c __59-[UIDocument _coordinateWritingItemAtURL:error:byAccessor:]_block_invoke.623 + 184 (UIDocument.m:1407) 8 Foundation 0x1b803cf98 -[NSFileCoordinator _invokeAccessor:thenCompletionHandler:] + 100 (NSFileCoordinator.m:430) 9 Foundation 0x1b8083774 __73-[NSFileCoordinator coordinateWritingItemAtURL:options:error:byAccessor:]_block_invoke + 132 (NSFileCoordinator.m:473) 10 Foundation 0x1b8194e30 __85-[NSFileCoordinator(NSPrivate) _coordinateWritingItemAtURL:options:error:byAccessor:]_block_invoke.350 + 264 (NSFileCoordinator.m:1083) 11 Foundation 0x1b8073538 -[NSFileCoordinator(NSPrivate) _withAccessArbiter:invokeAccessor:orDont:andRelinquishAccessClaim:] + 620 (NSFileCoordinator.m:960) 12 Foundation 0x1b80866c0 -[NSFileCoordinator(NSPrivate) _coordinateWritingItemAtURL:options:error:byAccessor:] + 784 (NSFileCoordinator.m:1080) 13 Foundation 0x1b7fa0710 -[NSFileCoordinator coordinateWritingItemAtURL:options:error:byAccessor:] + 120 (NSFileCoordinator.m:472) 14 UIKitCore 0x1b9618288 -[UIDocument _coordinateWritingItemAtURL:error:byAccessor:] + 472 (UIDocument.m:1404) 15 UIKitCore 0x1b9618cd8 __59-[UIDocument saveToURL:forSaveOperation:completionHandler:]_block_invoke + 336 (UIDocument.m:1476) 16 libdispatch.dylib 0x1b649de68 _dispatch_call_block_and_release + 32 (init.c:1517) 17 libdispatch.dylib 0x1b649fa2c _dispatch_client_callout + 20 (object.m:560) 18 libdispatch.dylib 0x1b64a7124 _dispatch_lane_serial_drain + 668 (inline_internal.h:2622) 19 libdispatch.dylib 0x1b64a7c80 _dispatch_lane_invoke + 392 (queue.c:3944) 20 libdispatch.dylib 0x1b64b2500 _dispatch_workloop_worker_thread + 648 (queue.c:6732) 21 libsystem_pthread.dylib 0x2278420bc _pthread_wqthread + 288 (pthread.c:2599) 22 libsystem_pthread.dylib 0x227841e5c start_wqthread + 8 (:-1)

iOS 17 custom keyboard, when the keyboard is hidden, the custom view is hidden in advance

Hello, I am turning to this forum because I suspect I am "doing it wrong" when it comes to implementing VoiceOver accessibility in my collection view. I suspect this because the system has resisted everything I have tried to do, fought it tooth and nail, and I can't see any way to get this to work. The Collection View I have a collection view that displays a large dataset. It uses a custom collection view layout to create a spreadsheet-like view. It has hundreds of rows, and each row can have hundreds of items. The items in each row do not conform to specific column widths. Their width is defined by the data they display, and for the purposes of this discussion, can be considered to be arbitrary. To the left of the "table" is a column of sticky headers whose position remains fixed in relation to the content. On top of the "table" is a row of headers, whose position also remains fixed. The Problem The default accessibility behavior that Apple has baked into UICollectionView is completely impractical for this application. Each row can contain hundreds of items, so a user who is attempting to navigate by swiping right would have to swipe through hundreds of items just to reach the second row (of hundreds). The Desired Behavior I want the user to be able to swipe through just the cells that are onscreen. To scroll, they can use the standard three-finger gesture. When scrolling occurs, VoiceOver should announce the range of data that is being displayed. Attempted Solution 1: Setting the accessibilityElements array I can set the accessibilityElements array of the UICollectionView to only contain the elements that are onscreen. I also can override the accessibilityScroll method to perform the paging upon a three-finger scroll. This works okay, but has some pretty fatal flaws: As the user swipes through elements, the collection view insists upon scrolling horizontally to try and fit the element into view. It also insists upon scrolling vertically to keep the focused element in the middle of the view. This not only causes the content offset to jump around wildly in a disorienting way, but it also brings content into view that VoiceOver does not know about because I have not added it to the accessibilityElements array. A low-vision user, or a user who pans their finger across the screen, would not be able to access those visible elements. VoiceOver refuses to read my paging announcement. No matter when I post a pageScrolled notification, the system will not read it. Setting accessibilityFrame In an attempt to fix the scroll jumping described above, I tried setting the accessibilityFrame of my collection view cells. This did nothing to alter the scroll jumping behavior, and had the added downside that, as the view jumped around, the accessibility frames did not follow it. A bridge too far? Overriding contentOffset I was about to override contentOffset on the collection view so that only I could set it. That would probably work. But it would do nothing to fix the paging announcement. Attempted Solution 2: Ignore the Cells! Use proxy UIAccessibilityElements I tried setting the accessibilityElements array of my collection view to a collection of UIAccessibilityElement instances whose accessibilityFrame matched the frame of the cells they represent. This worked pretty well! No more scrolling nonsense when swiping through cells, and my paging announcements were being read. This approach has a different, equally fatal flaw: If the user attempts to three finger-scroll too quickly, the VoiceOver process will become confused. It acts as though the last selected element is the only element that exists; swiping right or left does nothing. Three finger-scrolling also does nothing. As best as I can tell, it gets stuck with the last selected element as the only one it knows about. I have since replaced all of the elements in the collection view's accessibilityElements array and posted a layoutDidChange notification, which VoiceOver ignores completely. The only way out of this state is to tap on a cell, causing VoiceOver to refresh its collection of views that it knows about. I guess? No idea what's happening there. Now what? I'm at a complete and total loss. I'm at my wit's end. It feels like this seemingly simple customization is entirely impossible. Does anyone know what I'm doing wrong? Thanks!

Hello community, I'm trying to open a window with larger than the original initial dimensions. Because the native Freeform app doing it just fine with wider-than-usual window dimensions. But I found on the documentation saying that "In visionOS, all windows open with the same initial dimensions." I tried to set a greater width on the window frame but there indeed seems to be a hard fixed max length on it since I can make the window to be smaller but not bigger programmatically. Am I doing something wrong or missing anything? What are your thoughts on how the larger window of Freeform even gets implemented? Or it could even not be a window for example might be a layered on a large reality view? Any input would be appreciated!

I have a child view controller added and its view gets viewSafeAreaInsetsDidChange() called every time a frame change happens. how do I avoid this? So far I am using these: self.viewRespectsSystemMinimumLayoutMargins = false self.view.insetsLayoutMarginsFromSafeArea = false self.view.preservesSuperviewLayoutMargins. = false However, viewSafeAreaInsetsDidChange() is till being called. Is there a way to stop that?

I am using Xcode 15 beta 5 with iOS 17 beta 4 SDK. By building with the iOS 17 SDK my app got all the new inks which work great. Saving/encoding the PKDrawing to Data also works fine. However if I want to load the same PKDrawing again, on the same simulator or device (i.e., same iOS version) it fails with "Apple Drawing Format is from a future version that is too new.". From my understanding, reading https://developer.apple.com/documentation/pencilkit/supporting_backward_compatibility_for_ink_types?changes=_2 this is the expected behaviour when trying to load such a PKDrawing on an older iOS version which doesn't support the new ink types. Here is a short example, which prints the error: var drawing = PKDrawing() let strokePoints = [ PKStrokePoint(location: CGPoint(x: 0, y: 0), timeOffset: 0, size: CGSize(width: 3.0, height: 3.0), opacity: 2, force: 1, azimuth: 1, altitude: 1) ] let strokePath = PKStrokePath(controlPoints: strokePoints, creationDate: Date()) drawing.strokes.append(PKStroke(ink: .init(.watercolor), path: strokePath)) do { let data = drawing.dataRepresentation() let drawing2 = try PKDrawing(data: data) print("success") } catch { print(error) } } Saving & loading a PKDrawing which does not use any of the new ink types works fine.

Feedback report: FB12748529 Many of our users have received a new identifierForVendor (IDFV) when updating our apps. We released some app updates around 7/19/2023-7/21/2023, which is around the time we are seeing the IDFV change. After checking the contents of our updates, we aren’t sure why the IDFV has suddenly changed for these users. One thing we noticed is that our provisioning profiles were automatically updated to include the "xrOS" platform. This seems similar to this old thread: https://developer.apple.com/forums/thread/4202 Has anyone else seen recent changes with IDFV and/or xrOS?

As per apple documentation we are setting textContentType with "" in order to disable password auto fill view option on keyboards which is working fine in all iOS versions below 17 beta. Seems like it broke & password auto fill view option appearing on keyboards for iOS 17 beta versions even on setting textContentType with "" & inputAccessoryView as nil self.username.textContentType = @""; self.password.textContentType = @"";

I'm Using UICollectionViewCompositionalLayout with a section provider and I set the NSCollectionLayoutSectionVisibleItemsInvalidationHandler on a particular section. The NSCollectionLayoutSectionVisibleItemsInvalidationHandler hands back an array of objects conforming to the NSCollectionLayoutVisibleItem protocol which has a name property which always appears to be nil. I figured there must be a way to use this name property to make it easier to do look up for the NSCollectionLayoutVisibleItem objects I'm actually looking. Is there a way to make this property nonnil? Does it get set to the UICollectionViewCell's reuse identifier or something (I'm currently using UICollectionViewCellRegistration)? Is there any documentation on the name property? https://developer.apple.com/documentation/uikit/nscollectionlayoutvisibleitem/3199122-name?language=objc

As title desc. Before iOS 16.6 is smooth. But iOS 16.6 is lagging. Seems iOS 17 beta4 is ok.. Maybe Apple should post a hotfix for iOS 16.6

When using maskedCorners to set a single rounded corner, if the size of the corner is greater than or equal to the height, it will cause abnormal behavior.

I'm using compositional layout with UICollectionView. In a particular section I configure the compositional layout to use an estimated height because I want self sizing items determined by Autolayout Constraints. Now I have a custom content configuration with autolayout constraints. At runtime I hit this log about conflicting constraints: [LayoutConstraints] Unable to simultaneously satisfy constraints. Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints) [...] <NSLayoutConstraint:0x6000024af160 UIImageView:0x120745520.height == 130 (active)> <NSLayoutConstraint:0x6000024af2a0 MyCustomContentView :0x120748d60.height >= 1.04839*UIImageView:0x120745520.height (active)> <NSLayoutConstraint:0x6000024b08c0 'UIView-Encapsulated-Layout-Height' UICollectionViewListCell:0x1214392f0.height == 44 (active)> Will attempt to recover by breaking constraint <NSLayoutConstraint:0x6000024af160 UIImageView:0x120745520.height == 130 (active)> The "UIView-Encapsulated-Layout-Height" on UICollectionViewListCell with a value of 44.0 appears to be a constraint created by the system. I'm not sure why a hard coded height of 44.0 is being used when the compositional layout is returning a section that only uses estimated heights (created via NSCollectionLayoutDimension estimatedDimension). Any ideas how I can avoid this? I'm not using custom UICollectionView cells but I am using a custom content configuration and a custom content view and setting my content configuration on a UICollectionViewListCell.