In iOS18, WKWebView's default cookie SameSite value is Lax. Prior to iOS18, the default value is None. Is this intentional, or a bug? This change is not documented anywhere. I made a sample XCode project (ViewController code below) to show this change. It loads www.apple.com into a WKWebView and prints cookies. That site has several cookies, but it only explicitly sets SameSite to None for one cookie, s_vi. Every other cookie relies on default WKWebView behavior. When looking at cookies, either in the console or in Safari's Web Inspector, the SameSite value differs. If older than iOS18, every cookie has SameSite of None. If iOS18, all cookies except s_vi have SameSIte of Lax. I also tried manually setting the following cookies: testCookie-none with SameSite set to None testCookie-lax with SameSite set to Lax testCookie-strict with SameSite set to Strict testCookie- with SameSite set to an empty string When looking at these cookies, testCookie-none and testCookie- have their SameSite of None if older than iOS18, but are both Lax in iOS18. So, it seems we cannot manually set the SameSIte to None either. I realize updating the server to return the SameSite value would resolve this. However, in my app where I'm struggling with this issue, that server is Salesforce. Only they can update their response headers. Since this change isn't documented by Apple, I am assuming it is a bug and not intentional. Are there any workarounds? Any input by Apple on a fix? Below is the ViewController code, and images of the cookies in Safari's Web Inspector. import UIKit import WebKit class ViewController: UIViewController, WKNavigationDelegate { var webView: WKWebView! override func loadView() { // Create WKWebView let config = WKWebViewConfiguration() webView = WKWebView(frame: .zero, configuration: config) // Allow inspection in Safari debugger webView.isInspectable = true // Track the request to load our website webView.navigationDelegate = self // Manually add four cookies: // testCookie-none with SameSite set to None // testCookie-lax with SameSite set to Lax // testCookie-strict with SameSite set to Strict // testCookie- with SameSite set to an empty string addTestCookies() view = webView } override func viewDidLoad() { super.viewDidLoad() // Load a website let urlString = "https://www.apple.com" self.webView.load(URLRequest(url: URL(string:urlString)!)) } // Once the website loads, print the cookies. func webView(_ webView: WKWebView, didFinish navigation: WKNavigation!) { WKWebsiteDataStore.default().httpCookieStore.getAllCookies { cookies in for cookie in cookies { print(cookie) } } } /* Manually add the following cookies for domain .apple.com testCookie-none with SameSite set to None testCookie-lax with SameSite set to Lax testCookie-strict with SameSite set to Strict testCookie- with SameSite set to an empty string In older iOS versions, both testCookie-none and testCookie- will have their SameSite as none. In iOS18, no cookie will have SameSite as None. */ func addTestCookies() { let httpCookieStore = WKWebsiteDataStore.default().httpCookieStore for sameSitePolicy in ["none", "lax", "strict", ""] { httpCookieStore.setCookie(HTTPCookie(properties: [ HTTPCookiePropertyKey.path: "/", HTTPCookiePropertyKey.name: "testCookie-"+sameSitePolicy, HTTPCookiePropertyKey.value: "1", HTTPCookiePropertyKey.domain: ".apple.com", HTTPCookiePropertyKey.secure: true, HTTPCookiePropertyKey.sameSitePolicy: sameSitePolicy ])!) } } }

Previously this code would trigger fine on pressesBegan in iOS 17 and earlier versions, but no longer works in iOS 18. How can I start capturing pressesBegan in iOS 18? It seems like UIResponder is just not capturing the keyboard anymore? struct ContentView: View { var body: some View { KeyBoardView() } } //To Use in SwiftUI struct KeyBoardView: UIViewRepresentable{ func makeUIView(context: Context) -> KeyEventView { KeyEventView() } func updateUIView(_ uiView: KeyEventView, context: Context) { } class KeyEventView: UIView { init() { super.init(frame: CGRect(x: 0, y: 0, width: 0, height: 0)) } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } override func pressesBegan(_ presses: Set<UIPress>, with event: UIPressesEvent?) { print("test") } } }

Hi all, Firebase statistics show that some crashes seem to occur suddenly. Can you give me some suggestions? Users also meet the following requirements: iOS18 and above RTL language From the stack frame, the crash occurred in the transition animation project, but I did not reproduce this stack frame A very small number of users can experience it twice The crashed page is relatively complex, and it is a mixture of auto-layout and frame I retrieved some other articles, but they don’t seem to be the same problem https://developer.apple.com/forums/thread/693118 https://stackoverflow.com/questions/56027014/collectionview-crashing-in-nsisengine-after-a-few-scrolls Thank you for reading, looking forward to your reply ；) CoreAutoLayout: _engineVar_rawRemove

We're trying to implement a backup/restore data feature in our business productivity iPad app using UIDocumentPickerViewController and AppleArchive, but discovered AppleArchive crashes instead of failing gracefully when decrypting a corrupt archive. As described in forum post 765101, UIDocumentPickerViewController can handoff a corrupt copy of an archive to UIDocumentPickerDelegate under specific circumstances. We've duplicated this behavior with iPadOS 16.6.1 and 17.7 when building our app with Xcode 15.4 targeting minimum deployment of iPadOS 16. We haven't tested this with the bleeding edge iPadOS 18. Our app is primarily Objective-C, but it utilizes the Swift-based AppleArchive 'EncryptingAndDecryptingDirectories' sample code associated with WWDC21 session: 10233: Bring Encrypted Archives and Performance Improvements to Your App with Accelerate. The WWDC21 'EncryptingAndDecryptingDirectories' Swift sample project crashes in a similar manner when a corrupt archive file created by UIDocumentPickerViewController is dropped into the sample app's window for decryption (see attached crash log). Does anyone know if there's a workaround for the 'EncryptingAndDecryptingDirectories' sample project to prevent AppleArchive from crashing when decrypting a corrupt archive? crash log.txt

We're trying to implement a backup/restore data feature in our business productivity iPad app using UIDocumentPickerViewController and AppleArchive, but discovered odd behavior of [UIDocumentPickerViewController initForOpeningContentTypes: asCopy:YES] when reading large archive files from a USB drive. We've duplicated this behavior with iPadOS 16.6.1 and 17.7 when building our app with Xcode 15.4 targeting minimum deployment of iPadOS 16. We haven't tested this with bleeding edge iPadOS 18. Here's our Objective-C code which presents the picker: NSArray* contentTypeArray = @[UTTypeAppleArchive]; UIDocumentPickerViewController* docPickerVC = [[UIDocumentPickerViewController alloc] initForOpeningContentTypes:contentTypeArray asCopy:YES]; docPickerVC.delegate = self; docPickerVC.allowsMultipleSelection = NO; docPickerVC.shouldShowFileExtensions = YES; docPickerVC.modalPresentationStyle = UIModalPresentationPopover; docPickerVC.popoverPresentationController.sourceView = self.view; [self presentViewController:docPickerVC animated:YES completion:nil]; The UIDocumentPickerViewController remains visible until the selected external archive file has been copied from the USB drive to the app's local tmp sandbox. This may take several seconds due to the slow access speed of the USB drive. During this time the UIDocumentPickerViewController does NOT disable its tableview rows displaying files found on the USB drive. Even the most patient user will tap the desired filename a second (or third or fourth) time since the user's initial tap appears to have been ignored by UIDocumentPickerViewController, which lacks sufficient UI feedback showing it's busy copying the selected file. When the user taps the file a second time, UIDocumentPickerViewController apparently begins to copy the archive file once again. The end result is a truncated copy of the selected file based on the time between taps. For instance, a 788 MB source archive may be copied as a 56 MB file. Here, the UIDocumentPickerDelegate receives a 56 MB file instead of the original 788 MB of data. Not surprisingly, AppleArchive fails to decrypt the local copy of the archive because it's missing data. Instead of failing gracefully, AppleArchive crashes in AAArchiveStreamClose() (see forums post 765102 for details). Does anyone know if there's a workaround for this strange behavior of UIDocumentPickerViewController?

Can anyone help me to resolve this issue? I have two collectionviews in a tableview and each time you try to scroll the collecctionview after clicking a cell, it crashes with the following error: *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Expected dequeued view to be returned to the collection view in preparation for display. When the collection view's data source is asked to provide a view for a given index path, ensure that a single view is dequeued and returned to the collection view. Avoid dequeuing views without a request from the collection view. For retrieving an existing view in the collection view, use -[UICollectionView cellForItemAtIndexPath:] or -[UICollectionView supplementaryViewForElementKind:atIndexPath:]

I am using Storyboard to present a UIImagePickerController on a view controller (a simple initial view without any navigation or tab bar). Due to a requirement, we need to exclude the arm64 architecture. However, when I try to present the screen, it gets stuck. I am unable to select an image, and the screen becomes inaccessible. It's happening only on simulator. Does anyone have any solution.

I just finished updating my app to support the new screen sizes for the iPhone 16 series devices (iPhone16 Pro and iPhone 16 Pro Max). In testing the changes, I've come across what I hope is simply a bug in the Xcode 16 simulators. I don't have any actual devices (yet) that I can use to test. In landscape mode, my app presents a "tab" on the right side of the screen that can be tapped to bring out another view. Activating the tab is based on capturing the screen coordinates from a "tap". In Xcode 16, using the iPhone16 simulators on IOS 18, the area of the tab does not recognize that a tap has occurred. After hours of banging my head against my laptop, it dawned on me that the area of the screen that hosts the "tab" is in exactly the same location as "unavailable area" that represents the camera on the simulator. I have arrived at the assumption that the issue is that the simulator is treating the same space at the bottom of the device as it treats that reserved area at the top of the screen. Has anyone else experienced this? Is this a bug in the simulator or is this expected behavior on the iPhone 16 series devices?

I have issue with unwanted changing offset in collection view to top or to near top. It is happening in collection view with vertical scroll when estimatedItemSize is not set to zero (main factor). If estimatedItemSize is zero it is always fine. It is SDK that provides items that should be loaded in few cells, items have dynamic height which is received from server and can be updated several times. Scenario when it happens (when was noticed) is 2 sections, in section 0 item is at index 4 of 14, section 1 is with only one cell with dynamic height item. If specific item is at index 0 in section 0 or have 1 cell per section (tried 15 sections and set items in sections 5 and 15) all is good regardless of estimatedItemSize. When new height is received if I call invalidateLayout or reloadItemAtIndexPaths it will “jump”. That same height is set in sizeForItemAtIndexPath. In some combinations it happens and in some not and that is the most annoying part. I tried setting estimated height to received height and it didn’t help (other cell may be smaller or larger). Also if I put items in one section at indexes 4 and 14 it “jumps”. I managed to make it work by setting at specific moment estimatedItemSize to zero then put back to one that SDK user set and didn’t see any issues but I was wondering if there is any other solution for this and did anyone had issue like this. It would be nice to have solution to keep one estimatedItemSize if it is not the default one (zero).

iPadOS18 Tab Bar has been moved to top of screen. Everything looks ok when translucent=true. But there is an unwanted white space at bottom of screen when setting translucent=false. Is it iPadOS bug? See white area at bottom of attached screenshot.

As you can see, when I swipe to see the context actions in the collectionview, the searchbar flicks. Same story when, in a popover, i change the PreferredContentSize.

Hi there, I'm trying to migrate my app to using the UIDocumentViewController so I can use the new launch experience. My app exports a custom file type and uses UIDocument + UIDocumentBrowserViewController. I tried creating a UIDocumentViewController and making it the root view of my app but it doesn't recognise my custom document type. class Document_VC: UIDocumentViewController { var storyCardsDocument: PlotCardDocument? { self.document as? PlotCardDocument } override func viewDidLoad() { super.viewDidLoad() configureViewForCurrentDocument() } override func documentDidOpen() { configureViewForCurrentDocument() } func configureViewForCurrentDocument() { guard let document = storyCardsDocument, !document.documentState.contains(.closed) && isViewLoaded else { return } print("Document opened: \(document.fileURL)") } } The app opens but when I navigate to a document made in a previous version of the app it is greyed out. I also don't see a 'New' button in the launcher view. To try and see what I was doing wrong, I tested the markdown app sample code. When I make the UIDocumentViewController the root and try to open or create a new markdown document I get the following error: no document class found. Define the correct UIDocument subclass with the key UIDocumentClass in the info.plist's CFBundleDocumentTypes dictionary.

I am making an IOS application using XCode Storyboard. I have a UICollectionViewController in the following structure UIViewController -> UIView -> UITabBarController -> UICollectionViewController The app loads without crashing, and UICollectionViewController.viewDidLoad() and .numberOfSections() execute correctly. But anything that I put in override func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) does not seem to execute. Once the app loads, no cells load. And any print statement in the function doesn't execute either. All elements have their corresponding class correctly assigned in the Storyboard Identity Inspector, and the cells have the correct reusable identifier. How can I make it work correctly? My Collection View Controller: class ValidCardsCollectionViewController: UICollectionViewController { let dataSource: [String] = ["hearts", "clubs", "diamonds", "spades"] override func viewDidLoad() { super.viewDidLoad() print(dataSource) } override func numberOfSections(in collectionView: UICollectionView) -> Int { print("Loading \(dataSource.count) cells") return dataSource.count } override func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell { var cell = UICollectionViewCell() if let cardCell = collectionView.dequeueReusableCell(withReuseIdentifier: "CardCell", for: indexPath) as? CardCollectionViewCell{ cardCell.configure(with: dataSource[indexPath.row]) cell = cardCell } print("loading cell") return cell } My UICollectionViewCell: class CardCollectionViewCell: UICollectionViewCell { @IBOutlet weak var lblStr: UILabel! func configure(with str:String){ lblStr.text = str } } Storyboard layout: Simulator:

HI i have found libsystem_kernel.dylib crash. i can't reproduce this error even this is not unrecognisable. here is stack trace Crashed: com.apple.main-thread 0 libsystem_kernel.dylib 0xaac mach_msg_trap + 8 1 libsystem_kernel.dylib 0x107c mach_msg + 72 2 CoreFoundation 0x6c88 + 368 3 CoreFoundation 0xaf90 + 1160 4 CoreFoundation 0x1e174 CFRunLoopRunSpecific + 572 5 GraphicsServices 0x1988 GSEventRunModal + 160 6 UIKitCore 0x4e5a88 + 1080 7 UIKitCore 0x27ef78 UIApplicationMain + 336 8 libTweaks.dylib 0x2a6b4 _apdecr_UIApplicationMain(int, char**, NSString*, NSString*) + 108 9 libswiftUIKit.dylib 0x27ee4 $s5UIKit17UIApplicationMainys5Int32VAD_SpySpys4Int8VGGSgSSSgAJtF + 100 10 REDDI 0x214d6c main + 4368469356 (AppDelegate.swift:4368469356) 11 ??? 0x1028a84d0 (Missing)

Hello! I discovered a bug on Catalyst about a three years ago but it still seems to be not fixed. My bug report number is FB9705748. The Internet is silent on this so I'm even not sure, perhaps it's only me. So to the problem. When you display UICollectionViewController or UIViewController that contains UICollectionView, interact with the collection view then dismiss the view controller, the displayed view controller isn't released if dismissal is done through navigation bar item. The problem occurs only when the run target is My Mac (Mac Catalyst). Everything is fine when you run on iOS or via My Mac (Designed for iPad). The sample project is uploaded to GitHub. It has a video that shows this strange behavior, see the log for 'deinit' messages. I did have some workaround to fix this but it stops to work, presumable on the new macOS. Also, chances are that it's not only UICollectionView which initiates the glitch, it's just that I only encounter it with collection views.

I am trying to set my UITextView as the first responder with [self.textView becomeFirstResponder] when my view controller called viewDidAppear. But sometimes it will cause crash with the error: [__NSPlaceholderArray initWithObjects:count:]: attempt to insert nil object from objects[0] all I did is just: - (void)viewDidAppear:(BOOL)animated { [super viewDidAppear:animated]; [self.textView becomeFirstResponder]; } So if anyone can tell me what happened and how to do? when I call the [self.textView becomeFirstResponder], what will be insert into the responders list? self.textView itself? Thanks very much!

Hi everyone, I’m wondering about Core Data. When creating a private context using newBackgroundContext(), does it automatically set the parent to the view context, or is it independent? I'd appreciate it if anyone could clarify this for me. Thanks in advance! 😊

Hi, I've encountered the following phenomenon when comparing drag&drop in iOS 18.0 with iOS 17.5: Let's say you have a small child view sitting on top of a larger parent view. In iOS 18.0, when hovering over the child view with a drag object and leaving the child view, the child view will propagate a "dropInteraction:sessionDidExit:" call to the UIDropInteractionDelegate of its parent view. The parent view now thinks, that the drag object is moved away from it (which is not the case!) and in turn its delegate doesn't receive any "dropInteraction:performDrop:" calls anymore. In iOS 17.5 this case is handled correctly (without "dropInteraction:sessionDidExit:" being propagated wrongly by child views to their parent views). Is this change in behavior intended or is this a bug?

My iOS app crashes, when kept idle in the background for sometime. Below is the detailed crash report. Incident Identifier: 90DF0404-7A1D-4AF3-8892-19AB744DF0FD Distributor ID: com.apple.AppStore Hardware Model: iPhone13,3 Process: Runner [35073] Path: /private/var/containers/Bundle/Application/894B2440-D20C-4C01-B278-A0DC4B199530/Runner.app/Runner Identifier: com.era.tk Version: 5.0.2 (5) AppStoreTools: 15F31e AppVariant: 1:iPhone13,3:15 Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition: com.era.tk [793] Date/Time: 2024-09-25 13:17:31.3101 +0100 Launch Time: 2024-09-25 12:29:23.1866 +0100 OS Version: iPhone OS 17.6.1 (21G93) Release Type: User Baseband Version: 4.70.01 Report Version: 104 Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000001, 0x0000000100c75e48 Termination Reason: SIGNAL 5 Trace/BPT trap: 5 Terminating Process: exc handler [35073] Triggered by Thread: 0 Thread 0 Crashed: 0 Runner 0x0000000100c75e48 0x100c2c000 + 302664 1 Runner 0x0000000100c75e80 0x100c2c000 + 302720 2 UIKitCore 0x00000001a7e937e8 -[UIViewController _setViewAppearState:isAnimating:] + 1224 (UIViewController.m:6441) 3 UIKitCore 0x00000001a80520b0 -[UIViewController __viewWillDisappear:] + 108 (UIViewController.m:6705) 4 UIKitCore 0x00000001a8602cec -[UINavigationController _startCustomTransition:] + 1476 (UINavigationController.m:2260) 5 UIKitCore 0x00000001a7e97400 -[UINavigationController _startDeferredTransitionIfNeeded:] + 496 (UINavigationController.m:8062) 6 UIKitCore 0x00000001a7efc248 -[UINavigationController __viewWillLayoutSubviews] + 96 (UINavigationController.m:8369) 7 UIKitCore 0x00000001a81be688 -[UILayoutContainerView layoutSubviews] + 172 (UILayoutContainerView.m:89) 8 UIKitCore 0x00000001a7da7918 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 1528 (UIView.m:20054) 9 QuartzCore 0x00000001a720626c CA::Layer::layout_if_needed(CA::Transaction*) + 504 (CALayer.mm:10816) 10 QuartzCore 0x00000001a7205df0 CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 148 (CALayer.mm:2598) 11 QuartzCore 0x00000001a7260fd8 CA::Context::commit_transaction(CA::Transaction*, double, double*) + 464 (CAContextInternal.mm:2760) 12 QuartzCore 0x00000001a71d5ee0 CA::Transaction::commit() + 648 (CATransactionInternal.mm:432) 13 QuartzCore 0x00000001a721fc34 CA::Transaction::flush_as_runloop_observer(bool) + 88 (CATransactionInternal.mm:942) 14 UIKitCore 0x00000001a7e50ee8 _UIApplicationFlushCATransaction + 52 (UIApplication.m:3181) 15 UIKitCore 0x00000001a7e4e660 _UIUpdateSequenceRun + 84 (_UIUpdateSequence.mm:119) 16 UIKitCore 0x00000001a7e4e2a4 schedulerStepScheduledMainSection + 172 (_UIUpdateScheduler.m:1058) 17 UIKitCore 0x00000001a7e4f148 runloopSourceCallback + 92 (_UIUpdateScheduler.m:1221) 18 CoreFoundation 0x00000001a5b6b834 CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION + 28 (CFRunLoop.c:1957) 19 CoreFoundation 0x00000001a5b6b7c8 __CFRunLoopDoSource0 + 176 (CFRunLoop.c:2001) 20 CoreFoundation 0x00000001a5b69298 __CFRunLoopDoSources0 + 244 (CFRunLoop.c:2038) 21 CoreFoundation 0x00000001a5b68484 __CFRunLoopRun + 828 (CFRunLoop.c:2955) 22 CoreFoundation 0x00000001a5b67cd8 CFRunLoopRunSpecific + 608 (CFRunLoop.c:3420) 23 GraphicsServices 0x00000001ea5b51a8 GSEventRunModal + 164 (GSEvent.c:2196) 24 UIKitCore 0x00000001a81a1ae8 -[UIApplication _run] + 888 (UIApplication.m:3713) 25 UIKitCore 0x00000001a8255d98 UIApplicationMain + 340 (UIApplication.m:5303) 26 Runner 0x0000000100c4e660 0x100c2c000 + 140896 27 dyld 0x00000001c933f154 start + 2356 (dyldMain.cpp:1298)

When I write code in shareExtension like below: dispatch_async(dispatch_get_global_queue(0, 0), ^{ UIResponder *responder = [self nextResponder]; while ((responder = [responder nextResponder]) != nil) { if ([responder respondsToSelector:@selector(openURL:)] == YES) { [responder performSelector:@selector(openURL:) withObject:[NSURL URLWithString:APP_SCHEME]]; break; } } }); Will output in the console： BUG IN CLIENT OF UIKIT: The caller of UIApplication.openURL(:) needs to migrate to the non-deprecated UIApplication.open(:options:completionHandler:). Force returning false (NO).