We've seen an issue when using a LazyVGrid inside a List. The app crashes with: Thread 1: Fatal error: <UpdateCoalescingCollectionView 0x600000ca0d20> is stuck in a recursive layout loop When debugging the issue, we were able to narrow down the issue to a minimum reproducible example below: struct ContentView: View { let columns = [ GridItem(.adaptive(minimum: 43)) ] var body: some View { List { LazyVGrid(columns: columns) { ForEach(0..<15) { value in if value == 0 { Text("a") } else { Color.clear } } } } } } The issue can be reproduced on iPhone 15 Pro Max and iOS 18.x specifically. In a production app we have a similar layout, but instead of GridItem(.adaptive) we use GridItem(.flexible).

Summary In iOS 18, the UICollectionViewDelegate method collectionView(_:targetIndexPathForMoveOfItemFromOriginalIndexPath:atCurrentIndexPath:toProposedIndexPath:) is not being called when moving items in a UICollectionView. This method works as expected in iOS 17.5 and earlier versions. Steps to Reproduce Create a UICollectionView with drag and drop enabled. Implement the UICollectionViewDelegate method: func collectionView(_ collectionView: UICollectionView, targetIndexPathForMoveOfItemFromOriginalIndexPath originalIndexPath: IndexPath, atCurrentIndexPath currentIndexPath: IndexPath, toProposedIndexPath proposedIndexPath: IndexPath) -> IndexPath { print("🐸 Move") return proposedIndexPath } Run the app on iOS 18. Attempt to drag and drop items within the collection view. Expected Behavior The method should be called during the drag and drop operation, and "🐸 Move" should be printed to the console. Actual Behavior The method is not called, and nothing is printed to the console. The drag and drop operation still occurs, but without invoking this delegate method. Configuration iOS Version: 18 Xcode Version: Xcode 16.0.0

Hello Apple engineers, could you help me understand whether this crash is a UIKit bug or something in our code that causes it. Based on the documentation it is an invalid fetch instruction, that's why I suspect UIKit. I've found a similar crash here on the forums reported a year ago, it seemed to be a UIKit bug - https://forums.developer.apple.com/forums/thread/729448. I've attached the full crash report (the app name was replaced with ): Thread 0 Crashed: 0 libobjc.A.dylib 0x000000019daf7c20 objc_msgSend + 32 (:-1) 1 UIKitCore 0x00000001a3020c50 -[UIView _wrappedProcessTraitChanges:withBehavior:] + 1288 (UIView.m:0) 2 UIKitCore 0x00000001a3020720 -[UIView _processChangesFromOldTraits:toCurrentTraits:withBehavior:] + 196 (UIView.m:7840) 3 UIKitCore 0x00000001a3020618 -[UIView _updateTraitCollectionAndProcessChangesWithBehavior:previousCollection:] + 112 (UIView.m:7831) 4 UIKitCore 0x00000001a2fa90c0 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 944 (UIView.m:19850) 5 QuartzCore 0x00000001a22dfc28 CA::Layer::layout_if_needed(CA::Transaction*) + 496 (CALayer.mm:10944) 6 QuartzCore 0x00000001a22df7b4 CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 148 (CALayer.mm:2638) 7 QuartzCore 0x00000001a2336914 CA::Context::commit_transaction(CA::Transaction*, double, double*) + 472 (CAContextInternal.mm:2613) 8 QuartzCore 0x00000001a22b57c4 CA::Transaction::commit() + 648 (CATransactionInternal.mm:420) 9 QuartzCore 0x00000001a22f8a0c CA::Transaction::flush_as_runloop_observer(bool) + 88 (CATransactionInternal.mm:928) 10 UIKitCore 0x00000001a303f568 _UIApplicationFlushCATransaction + 52 (UIApplication.m:3326) 11 UIKitCore 0x00000001a303cb64 __setupUpdateSequence_block_invoke_2 + 332 (_UIUpdateScheduler.m:1652) 12 UIKitCore 0x00000001a303c9d8 _UIUpdateSequenceRun + 84 (_UIUpdateSequence.mm:136) 13 UIKitCore 0x00000001a303c628 schedulerStepScheduledMainSection + 172 (_UIUpdateScheduler.m:1171) 14 UIKitCore 0x00000001a303d59c runloopSourceCallback + 92 (_UIUpdateScheduler.m:1334) 15 CoreFoundation 0x00000001a080c328 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 (CFRunLoop.c:1970) 16 CoreFoundation 0x00000001a080c2bc __CFRunLoopDoSource0 + 176 (CFRunLoop.c:2014) 17 CoreFoundation 0x00000001a0809dc0 __CFRunLoopDoSources0 + 244 (CFRunLoop.c:2051) 18 CoreFoundation 0x00000001a0808fbc __CFRunLoopRun + 840 (CFRunLoop.c:2969) 19 CoreFoundation 0x00000001a0808830 CFRunLoopRunSpecific + 588 (CFRunLoop.c:3434) 20 GraphicsServices 0x00000001ec7e81c4 GSEventRunModal + 164 (GSEvent.c:2196) 21 UIKitCore 0x00000001a336eeb0 -[UIApplication _run] + 816 (UIApplication.m:3844) 22 UIKitCore 0x00000001a341d5b4 UIApplicationMain + 340 (UIApplication.m:5496) 23 UIKitCore 0x00000001a3757fa8 UIApplicationMain(_:_:_:_:) + 104 (UIKit.swift:565) 24 <Redacted> 0x00000001028bde64 specialized static UIApplicationDelegate.main() + 28 (/<compiler-generated>:16) 25 <Redacted> 0x00000001028bde64 static AppDelegate.$main() + 28 (AppDelegate.swift:0) 26 <Redacted> 0x00000001028bde64 main + 116 27 dyld 0x00000001c61f6ec8 start + 2724 (dyldMain.cpp:1334) 2024-12-27_20-53-28.2129_-0500-353aaa194e6232c0d1fae767296bdb8c47c30498.crash

Issue Description: In iOS 18, when setting the root view controller of a UINavigationController and immediately pushing another view controller, the root view controller's lifecycle methods, such as viewDidLoad(), are not called as expected. This issue does not occur in previous iOS versions. There is no mention of this behavior in the iOS 18 release notes, and it is causing significant issues in our application. Steps to Reproduce: Set the root view controller of a UINavigationController. Immediately push another view controller. Observe that the root view controller's lifecycle methods, such as viewDidLoad(), are not called. Example Code: Swift import UIKit class HomeViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() print("HomeViewController viewDidLoad") } } class SecondViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() print("SecondViewController viewDidLoad") } } @UIApplicationMain class AppDelegate: UIResponder, UIApplicationDelegate { var window: UIWindow? func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool { window = UIWindow(frame: UIScreen.main.bounds) let home = HomeViewController() let rootNav = UINavigationController(rootViewController: home) window?.rootViewController = rootNav window?.makeKeyAndVisible() let secondViewController = SecondViewController() home.navigationController?.pushViewController(secondViewController, animated: true) return true } } Expected Behavior: The root view controller's lifecycle methods, such as viewDidLoad(), should be called when setting it as the root view controller of a UINavigationController. Actual Behavior: In iOS 18, the root view controller's lifecycle methods are not called when it is set as the root view controller and another view controller is immediately pushed. Impact: This issue affects the proper initialization and setup of the root view controller, causing significant disruptions in our application's workflow. Device Information: iOS Version: iOS 18 Test Devices: iPhone 15, iPhone 16 Additional Information: We would appreciate any insights or updates on whether this is an intended optimization or a potential bug. This issue is causing significant disruption to our application, and a timely resolution would be greatly appreciated.

When my iOS app runs on macOS in "designed for iPad" mode, the system foreground colour RGBA values seem strange. Looking at [UIColor labelColor], [UIColor secondaryLabelColor] etc. on iOS, I see values like these: (Light Mode) // R G B A fg0 = 0 0 0 255 fg1 = 10 10 13 153 fg2 = 10 10 13 76 fg3 = 10 10 13 45 Note in particular that fg0, aka labelColor, is solid black. When I run it on my Mac, the values I see are: // R G B A fg0 = 0 0 0 216 fg1 = 0 0 0 127 fg2 = 0 0 0 66 fg3 = 0 0 0 25 Here, fg0 has alpha = 216. The result is that it looks like a dark grey, on a white background. Of course it's reasonable for macOS to have a different colour palette than iOS - but native macOS apps seem to have solid 100% black as their foreground colour. Do others see this? What should I be doing? Note that I'm getting colour values using UIColor's getRed: blue: green: alpha: method and then using these colour values for some custom GPU drawing. Previously I was using solid black and white, but at some point I updated it to use UIColor in order to respond to light/dark-mode changes.

I am writing to report an issue I encountered with iOS 18 beta that affects my application, which has been available on the App Store for over two years and currently has over 60,000 active users. My application utilizes a UITabBarController to manage multiple tabs, where each tab hosts a UIViewController embedded within a UINavigationController. The application operates in two different states, where users may have either 5, 4, or 3 tabBarItems depending on their configuration. The issue arises when fewer than 5 tabs are present. In these cases, I add child view controllers to the UITabBarController to ensure they are displayed above the tab bar, rather than below it. The relevant code snippet is as follows: tabBarController.addChild(childController) tabBarController.view.addSubview(childController.view) Prior to iOS 18, this implementation functioned as expected. However, with the release of iOS 18, adding a child view controller to the UITabBarController results in the child being incorrectly added as a UITabBarItem. This misbehavior leads to an application crash when the unintended tab is selected. The crash trace is as follows: "Inconsistency in UITabBar items and view controllers detected. No view controller matches the UITabBarItem '<UITabBarItem: 0x142d9c480> selected'." I have attached screenshots from iOS 18 and previous versions to illustrate the issue, which compares the expected behavior in earlier iOS versions with the problematic behavior in iOS 18. I appreciate your attention to this matter and look forward to any guidance or resolution you can provide.

I found when I put a webView on the screen and then remove it, several properties in TableView including firstResponderView, FirstResponderIndexPath, and FirstResponderViewType have changed. These properties are hidden and I cannot change them. firstResponderView strong holds my cell, resulting in my cell not being able to call didEndDisplayCell when it slides out of the screen as expected. What should I do to avoid firstResponderView from strong holding my cell, or what should I do to release it?

I’m trying to record videos with AvAssetWriter but sometimes my videos exempt audio buffers recorded and when audio is included, the stream of video buffers stops. the gist below is my code. https://gist.github.com/kwameaj67/70a3409c84d48cf758b3734c08a46244

I need a really modal alert, i.e., one which runs and allows the user interaction and closes and returns the selected option inside of a single method. (I need to serve an API which calls my callback, presuming I show an alert, get the user's decision, and return it from that very callback. The callback comes in the main thread.) What's the proper way to do this in i(Pad)OS 18+? Thanks! For reference, up to 17, the following code worked nicely; in 18, it does not anymore: volatile BOOL __block stillRuns=YES; UIAlertController* ac=[UIAlertController alertControllerWith... preferredStyle:UIAlertControllerStyleAlert]; [ac addAction:[UIAlertAction actionWith... handler:^(UIAlertAction * _Nonnull action) { stillRuns=NO; }]]; ... [UIApplication.sharedApplication.keyWindow.rootViewController presentViewController:ac animated:YES completion:nil]; while (stillRuns) [NSRunLoop.currentRunLoop runUntilDate:[NSDate dateWithTimeIntervalSinceNow:.1]];

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

private let datePicker = { let picker = UIDatePicker() picker.backgroundColor = .clear picker.datePickerMode = .dateAndTime picker.preferredDatePickerStyle = .compact return picker }()

Hello, and an early "Merry Christmas" to all, I'm building a SwiftUI app, and one of my Views is a fullscreen UIViewRepresentable (SpriteView) beneath a SwiftUI interface. Whenever the user interacts with any SwiftUI element, the UIView registers a hit in touchesBegan(). For example, my UIView has logic for pinching (not implemented via UIGestureRecognizer), so whenever the user holds down a SwiftUI element while touching the UIView, that counts as two touches to the UIView which invokes the pinching logic. Things I've tried to block SwiftUI from passing the gesture down to the UIView: Adding opaque elements beneath control elements Adding gestures to the elements above Adding gesture masks to the gestures above Converting eligible elements to Buttons (since those seem immune) Adding SpriteViews beneath those elements to absorb gestures So far nothing has worked. As long as the UIView is beneath SwiftUI elements, any interactions with those elements will be registered as a hit. The obvious solution is to track each SwiftUI element's size and coordinates with respect to the UIView's coordinate space, then use exclusion areas, but this is both a pain and expensive, and I find it hard to believe this is the best fix for such a seemingly basic problem. I'm probably overlooking something basic, so any suggestions will be greatly appreciated

I have an app that uses UITextView for some text editing. I have some custom operations I can do on the text that I want to be able to undo, and I'm representing those operations in a way that plugs into NSUndoManager nicely. For example, if I have a button that appends an emoji to the text, it looks something like this: func addEmoji() { let inserting = NSAttributedString(string: "😀") self.textStorage.append(inserting) let len = inserting.length let range = NSRange(location: self.textStorage.length - len, length: len) self.undoManager?.registerUndo(withTarget: self, handler: { view in view.textStorage.deleteCharacters(in: range) } } My goal is something like this: Type some text Press the emoji button to add the emoji Trigger undo (via gesture or keyboard shortcut) and the emoji is removed Trigger undo again and the typing from step 1 is reversed If I just type and then trigger undo, the typing is reversed as you'd expect. And if I just add the emoji and trigger undo, the emoji is removed. But if I do the sequence above, step 3 works but step 4 doesn't. The emoji is removed but the typing isn't reversed. Notably, if step 3 only changes attributes of the text, like applying a strikethrough to a selection, then the full undo chain works. I can type, apply strikethrough, undo strikethrough, and undo typing. It's almost as if changing the text invalidates the undo manager's previous operations? How do I insert my own changes into UITextView's NSUndoManager without invalidating its chain of other operations?

Hi all, I have been trying to get Apple's assistive touch's snap to item to work for a unity game built using Apple's Core & Accessibility API. The switch control recognises these buttons however, eye tracking will not snap to them. The case in which it needs to snap is when an external eye tracking device is connected and utilises assistive touch & assistive touch's snap to item. All buttons in the game have a AccessibilityNode with the trait 'Button' on them & an appropriate label, which, following the documentation and comments on the developer forum, should allow them to be recognised by snap to item. This is not the case, devices (iPads and iPhones) do not recognise the buttons as a snap to target. Does anyone know why this is the case, and if this is a bug?

UITabBarController | | VC_Tab1 --------------------------- VC_Tab2 | | | | VC_Tab1_Child VC_Tab2_Child | (HeaderView) | (MyButton) The structure of the view controllers and views in the project is as described above. <case 1> self.navigationController?.popToRootViewController(animated: false) tabBarController.selectedIndex = 1 When popToRootViewController(animated: false) is called in VC_Tab1_Child, followed by setting the tab controller’s selectedIndex = 1, the following results are observed: viewWillAppear(_:), <VC_Tab2_Child> deinit, <VC_Tab1_Child> viewDidAppear(_:), <VC_Tab2_Child> The originally expected results are as follows viewWillDisappear(_:), <VC_Tab1_Child> viewDidDisappear(_:), <VC_Tab1_Child> deinit, <VC_Tab1_Child> deinit, <HeaderView> deinit, <MyButton> headerView.backButton.rx.tap -> Event completed headerView.backButton.rx.tap -> isDisposed viewWillAppear(_:), <VC_Tab2_Child> viewDidAppear(_:), <VC_Tab2_Child> The HeaderView belonging to VC_Tab1_Child was not deallocated, and the resources associated with that view were also not released. Similarly, VC_Tab1_Child.viewWillDisappear and VC_Tab1_Child.didDisappear were not called. <case 2> self.navigationController?.popToRootViewController(animated: false) DispatchQueue.main.async { tabBarController.selectedIndex = 1 } After performing the pop operation as shown in the code and waiting for a short period before testing, the expected results were generally achieved. (However, rarely, the results were similar to those observed when called without async.)” <case 3> self.navigationController?.popToRootViewController(animated: false) DispatchQueue.main.asyncAfter(deadline: .now() + 0.1) { tabBarController.selectedIndex = 1 } When a sufficient delay was ensured as described above, the expected results were achieved 100% of the time.” The abnormal behavior is more pronounced in iOS versions prior to 18 and varies depending on the iOS version. I couldn’t find any documentation explaining the unexpected behavior shown in the results above. What could be the cause? The simulation code is provided below. https://github.com/linusix/UITabBarController_Test2

On iOS you can create a new Lock Screen that contains a bunch of emoji, and they'll get put on the screen in a repeating pattern, like this: When you have two or more emoji they're placed in alternating patterns, like this: How do I write something like that? I need to handle up to three emoji, and I need the canvas as large as the device's screen, and it needs to be saved as an image. Thanks! (I've already written an emojiToImage() extension on String, but it just plonks one massive emoji in the middle of an image, so I'm doing something wrong there.)

My code extension MyViewController: UICollectionViewDelegate, UICollectionViewDataSource { func collectionView( _ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath ) -> UICollectionViewCell { if let cell = collectionView.dequeueReusableCell( withReuseIdentifier: "CollectionViewCellID", for: indexPath ) as? CollectionViewCell { cell.setup() return cell } return UICollectionViewCell() } func collectionView( _ collectionView: UICollectionView, didSelectItemAt indexPath: IndexPath ) { // Unnecessary dequeue guard collectionView.dequeueReusableCell( withReuseIdentifier: "CollectionViewCellID", for: indexPath ) is CollectionViewCell else { return } // My action for selecting cell print("Cell Selected") } } Error: *** Assertion failure in -[UICollectionView _updateVisibleCellsNow:], UICollectionView.m:5673 *** 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:]. Solution: The problem was doing unnecessary dequeuing in didSelectItemAt when selecting the cell. In previous iOS like 17 or 16 or lower, it was allowed to dequeue where it is not really needed but from iOS 18, it may restricted to unnecessary dequeuing. So better to remove dequeue and use cellForItem(at) if we need to get cell from collection view. Example extension MyViewController: UICollectionViewDelegate, UICollectionViewDataSource { func collectionView( _ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath ) -> UICollectionViewCell { if let cell = collectionView.dequeueReusableCell( withReuseIdentifier: "CollectionViewCellID", for: indexPath ) as? CollectionViewCell { cell.setup() return cell } return UICollectionViewCell() } func collectionView( _ collectionView: UICollectionView, didSelectItemAt indexPath: IndexPath ) { guard collectionView.cellForItem(at: indexPath) is CollectionViewCell else { return } // My action for selecting cell print("Cell Selected") } }

Description: When using UIDocumentPickerViewController in iOS, if the user taps two or more files in quick succession, the picker view controller dismisses itself automatically twice. This results in an unintended behavior, leading to inconsistent screen states or redundant dismiss animations. Steps to Reproduce: Initialize a UIDocumentPickerViewController instance in UIDocumentPickerModeImport. UIDocumentPickerViewController *documentPicker = [[UIDocumentPickerViewController alloc] initWithDocumentTypes:@[(NSString *)kUTTypeData] inMode:UIDocumentPickerModeImport]; documentPicker.delegate = self; documentPicker.modalPresentationStyle = UIModalPresentationFullScreen; documentPicker.allowsMultipleSelection = NO; [self presentViewController:documentPicker animated:YES completion:nil]; Launch the document picker. Quickly tap two or more files in succession. Expected Behavior: The UIDocumentPickerViewController should dismiss once and call the delegate method documentPicker:didPickDocumentsAtURLs: with the selected file(s). Actual Behavior: The UIDocumentPickerViewController automatically dismisses twice. This issue occurs even when no explicit call to dismissViewControllerAnimated: is made in the delegate method. Observed Results: The didPickDocumentsAtURLs: callback is invoked after the picker is already dismissed. During this process, unintended behavior such as multiple dismiss animations, view controller state corruption, or UI inconsistencies may occur. Impact: This issue disrupts the user experience and causes UI glitches when selecting documents. It prevents developers from having full control over dismiss behavior or mitigating the problem programmatically. Environment: iOS Version: iOS 15.0 and later (also reproduced on iOS 17.4) Device: Reproducible on multiple iPhone and iPad models Framework: UIKit Conclusion: This appears to be a system-level issue with UIDocumentPickerViewController. The automatic dismiss behavior is not correctlyhandling multiple taps, causing unintended dismiss events. Developers have no explicit way to prevent this behavior or gain full control over the dismissal process. We kindly request Apple to investigate and resolve this issue to ensure UIDocumentPickerViewController behaves as expected when interacting with multiple taps.

Hello, I am using Xcode 15.3 and doesn't add any support for Apple Intelligence yet as it requires Xcode 16+. But I see many crashlogs related to Apple Intelligence, I assume crash is related to UITextView element of UIKit. Can you please help me to resolve this issue, how can I fix it? There are few lines of the crashlog, they are all similar. Thread 0 name: Thread 0 Crashed: 0 UIKitCore 0x0000000196692d74 specialized UITextView._intelligenceCollectContent(in:collector:) + 2748 (UITextView_IntelligenceSupport.swift:37) 1 UIKitCore 0x0000000196691eb0 @objc UITextView._intelligenceCollectContent(in:collector:) + 60 (<compiler-generated>:17) 2 UIIntelligenceSupport 0x000000026b91f1e4 UIIntelligenceElementCollector.performCollection(_:) + 424 (UIIntelligenceElementCollector.swift:46) 3 UIKitCore 0x0000000196473b70 specialized UIView._intelligenceElement(in:using:transformToRoot:) + 1440 (UIView_IntelligenceSupport.swift:132) 4 UIKitCore 0x000000019647a800 specialized UIView._intelligenceCollectElement(for:in:using:transformToRoot:) + 424 (UIView_IntelligenceSupport.swift:84) 5 UIKitCore 0x00000001964792ec @objc UIView._intelligenceCollectElement(for:in:using:transformToRoot:) + 136 (<compiler-generated>:77) 6 UIKitCore 0x0000000196472c20 closure #1 in UIView._intelligenceCollectSubelements(in:using:transformToRoot:) + 256 (UIView_IntelligenceSupport.swift:55) 7 UIIntelligenceSupport 0x000000026b91f728 UIIntelligenceElementCollector.performElementCollection(_:) + 424 (UIIntelligenceElementCollector.swift:61) v 8 UIKitCore 0x00000001964728f4 UIView._intelligenceCollectSubelements(in:using:transformToRoot:) + 928 (UIView_IntelligenceSupport.swift:54) 9 UIKitCore 0x0000000196473354 @objc UIView._intelligenceCollectSubelements(in:using:transformToRoot:) + 136 (<compiler-generated>:0) 10 UIKitCore 0x0000000196479810 closure #3 in UIView._intelligenceElement(in:using:transformToRoot:) + 256 (UIView_IntelligenceSupport.swift:165) 11 UIIntelligenceSupport 0x000000026b91fb54 UIIntelligenceElementCollector.performElementArrayCollection(_:) + 144 (UIIntelligenceElementCollector.swift:78) ... ... 225 UIIntelligenceSupport 0x000000026b8ee630 closure #1 in IntelligenceCollectionListener.collectFragments(_:) + 192 (IntelligenceCollectionListener.swift:60) 226 UIIntelligenceSupport 0x000000026b91b138 thunk for @escaping @callee_guaranteed () -> () + 36 227 CoreFoundation 0x000000019376b6e4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 28 (CFRunLoop.c:1818) 228 CoreFoundation 0x0000000193759910 __CFRunLoopDoBlocks + 356 (CFRunLoop.c:1860) 229 CoreFoundation 0x00000001937595f4 __CFRunLoopRun + 2432 (CFRunLoop.c:3217) 230 CoreFoundation 0x0000000193758830 CFRunLoopRunSpecific + 588 (CFRunLoop.c:3434) 231 GraphicsServices 0x00000001df7381c4 GSEventRunModal + 164 (GSEvent.c:2196) 232 UIKitCore 0x00000001962beeb0 -[UIApplication _run] + 816 (UIApplication.m:3844)

I have a UIKit application and it contains multiple UI components like UIWindow, UIView, UIButton, etc. I wanted to perform error handling for different OS calls in my application. For example, when creating a UIImage using init(named:) initialiser, the documentation clearly states that if the UIImage object cannot be created then the initialiser returns nil value. However, there are other UI components like UIButton (or like UIView), which when created using init(frame:) initialiser, the documentation does not mention for any return value. I wanted to know how to identify If the UIButton initialisation has failed? How is it that apple recommends should we handle these api's, If they fail to create a button. suppose If there is a case where it fails due to insufficient memory. Or is it that apple guarantees the Api's never fail?Is there some exception that is throw? I wanted somewhat detailed answer to these questions.