I have attached two images of two screens below. In one screen, bar button are enclosed within separate, distinct, rounded-rectangle 'liquid glass' capsules. In other screen, bar buttons are enclosed within separate, distinct, rounded-rectangle "liquid glass" capsules. They are not visually merged into one larger capsule. Both are having same code. But why it is not same ?

Hi team, while i am using below code, i am getting two searchBar at top & bottom. Kindly refer below code & attached image Code: override func viewDidLoad() { super.viewDidLoad() title = "Test Data" setupSearchData() DispatchQueue.main.asyncAfter(deadline: .now() + 2) { self.setupSearchData() } } func setupSearchData() { navigationController?.navigationBar.prefersLargeTitles = false let searchController = UISearchController(searchResultsController: nil) navigationItem.searchController = searchController } It is working fine for other iOS versions. In my real useCase, i will refresh screen after API completed, then this issue occurred in my app.

In beta 2 using layer.cornerRadius on a UIEffectView with the UIGlassEffect allowed you to change the corner radius of the view. In beta 3, this no longer works. WWDC videos indicate the right way to do this is to set the cornerConfiguration on the UIEffectView, but that API doesn't seem to be available yet. At this time it doesn't seem like theres a way to have a glass view that isn't pill shaped.

When using UIPageViewController inside a UITabBarController on iOS 26 with Liquid Glass adoption, visiting the PageViewController tab applies a blur effect to the navigation bar and tab bar even though the current child view controller of the pageView is not scrollable and does not reach behind these bars. Questions: Is this the expected behavior that the pageview's internal scroll view causes the bars to blur regardless of the page view's child content’s scrollability? If so, is there an official way to make the blur effect appear only when the pageview's current child view controller actually scrolls behind the navigation bar or tab bar, and not in static cases? Tried the same in SwiftUI using TabView and TabView with page style. Facing the same issue there as well. Sample screenshots for reference, Sample SwiftUI code, struct TabContentView: View { var body: some View { TabView { // First Tab: Paging View PagingView() .tabItem { Label("Pages", systemImage: "square.fill.on.square.fill") } // Second Tab: Normal View NavigationStack { ListView() } .tabItem { Label("Second", systemImage: "star.fill") } // Third Tab: Normal View PageView(color: .blue, text: "Page 3") .tabItem { Label("Third", systemImage: "gearshape.fill") } } .ignoresSafeArea() } } struct PagingView: View { var body: some View { TabView { PageView(color: .red, text: "Page 1") PageView(color: .green, text: "Page 2") PageView(color: .blue, text: "Page 3") } .tabViewStyle(.page) // Enables swipe paging .indexViewStyle(.page(backgroundDisplayMode: .always)) .ignoresSafeArea()// Dots indicator } }

Hello! I am trying to create an iOS app that is based around a very large, vertically scrolling text view. The text is broken up into many sections, and the user should be able to press buttons in the navigation, which programmatically scroll to those sections. The user can also change the font size in a settings menu. It should generally keep the user's spot when resizing fonts or rotating the screen (from portrait to landscape). The problem I've been having is that no method of lazy text loading allows accurate enough navigation, and the text is too long to calculate the whole UI all at once. Here's my process in trying to find a solution: My app is built in SwiftUI, so I started with a ScrollView and a LazyVStack, and I used .scrollPosition() and bound it to an Int?. It worked pretty well for most scroll locations both on screen and far off the screen, but when I programmatically scroll to a location that is off the screen but not very far off, it completely misses. So, I investigated UIKit, and found that UITextView was a much better fit for the way I wanted to present the long text. I could also programmatically navigate by storing the NSRange of each section. I tried to use scrollRangeToVisible(), but for long distance it would scroll so that the desired section was just below the viewport and thus off screen. Then I tried to use UITextView's textLayoutManager.textViewportLayoutController.relocateViewport() to send it to the correct NSTextRange, it would not jump all the way, but instead would do nothing until I tried to scroll again and it would jump slightly forward. I tried to use textViewportLayoutController.layoutViewport() after the jump, and that fixed the glitch when scrolling, but it still did not jump to the correct place, only slightly forward. Then, I looked into TextKit 2 and the way it worked to try to find a solution. From what I can tell, it seems that to affect the NSTextViewportLayoutController without having to rewrite it, I need an NSTextViewportLayoutControllerDelegate, but the delegate required me to manually lay out the views, and in all the examples I've seen that use a custom NSTextViewportLayoutControllerDelegate, they wrote their own custom text view instead of using the default UITextView. I started looking into writing a custom text view so I can get the programmatic scroll to work consistently. However, it felt like, from a maintainability standpoint, it would probably be best to stick with what Apple has already implemented. For now, I found a workaround that scrolls consistently. Here is the code: if let start = self.textView.position(from: self.textView.beginningOfDocument, offset: desiredLineRange.location) { let location = textView.caretRect(for: start) self.textView.setContentOffset(CGPoint(x: 0, y: location.origin.y), animated: false) } if let start = self.textView.position(from: self.textView.beginningOfDocument, offset: desiredLineRange.location) { let location = textView.caretRect(for: start) self.textView.setContentOffset(CGPoint(x: 0, y: location.origin.y), animated: false) } It does the job, because the first time it gets close enough, and the second time it gets to the precise location, but it just feels like a bit of a hack to run the same code twice. I was wondering if anyone knows what I could be doing wrong and if Apple provides any solutions for this? (Also, all my UIKit navigation attempts ran inside an @objc func, which I passed using button.addTarget(self, action: #selector(buttonTapped), for: .touchUpInside). Just so you know in case it may be a problem with the way Swift and UIKit handle concurrency/parallel tasks). Thank you!

Does anyone have any documentation for how to achieve the floating search tab item in UIKit apps that use UITabBarController? The Liquid Glass UIKit video had code for minimizing the tab bar on scroll down, but I didn't see anything on keeping the search button locked to the bottom trailing edge (as in this screenshot below).

Hello, I have been trying for some time to change the color of native UITabBar in UITabBarController through UITabBarAppearance, but nothing works and the text is still black in the Xcode Beta 3 on iPadOS 26 while it works correctly in the previous OS versions. Here is the code: let color = UIColor.white let stackedAppearance = UITabBarItemAppearance() stackedAppearance.normal.iconColor = color stackedAppearance.normal.titleTextAttributes = [ .foregroundColor: color ] stackedAppearance.selected.iconColor = color stackedAppearance.selected.titleTextAttributes = [ .foregroundColor: color ] let inlineAppearance = UITabBarItemAppearance() inlineAppearance.normal.iconColor = color inlineAppearance.normal.titleTextAttributes = [ .foregroundColor: color ] inlineAppearance.selected.iconColor = color inlineAppearance.selected.titleTextAttributes = [ .foregroundColor: color ] let tabAppearance = UITabBarAppearance() tabAppearance.compactInlineLayoutAppearance = inlineAppearance tabAppearance.inlineLayoutAppearance = inlineAppearance tabAppearance.stackedLayoutAppearance = stackedAppearance UITabBar.appearance().standardAppearance = tabAppearance UITabBar.appearance().scrollEdgeAppearance = tabAppearance

I'm working with images selected from the iOS Photos app using PHPickerViewController. Some images appear as HEIF in the Photos info panel — which I understand are stored in the HEIC format, i.e., HEIF containers with HEVC-compressed images, commonly used on iOS when "High Efficiency" is enabled. To convert these images to JPEG, I'm using the standard UIKit approach: if let image = UIImage(data: heicData) { let jpegData = image.jpegData(compressionQuality: 1.0) } However, I’ve noticed that this conversion often increases the image size significantly: Original HEIC/HEIF: ~3 MB Converted JPEG (quality: 1.0): ~8–12 MB There’s no resolution change or image editing — it’s just a direct conversion. I understand that HEIC is more efficient than JPEG, but the increase in file size feels disproportionate. Is this kind of jump expected, or are there any recommended workarounds to avoid it?

I was reading over the documentation of the CellProvider struct for the diffable data source initialiser, and the CellProvider is defined as a closure which takes three arguments, a table view, an index path, and an item identifier. My question is, who vends the index path and the item identifier to this closure? My thinking is that it is the data source who vends these items because it adopts the UITableViewDataSource protocol which acts as the source of data for this view.

Starting with iOS 26 beta, I'm encountering an intermittent crash in production builds related to Auto Layout and background threading. This crash did not occur on iOS 18 or earlier and has become reproducible only on devices running iOS 26 betas. We have already performed a thorough audit of our code: • Verified that all UIKit view hierarchy and layout mutations occur on the main thread. • Re-tested with strict logging—confirmed all remaining layout/constraint/view updates are performed on the main thread. • No third-party UI SDKs are used in the relevant flow. Despite that, the crash still occurs and always from a background thread, during internal UIKit layout commits. Fatal Exception: NSInternalInconsistencyException Modifications to the layout engine must not be performed from a background thread after it has been accessed from the main thread. 0 MyApp 0x7adbc8 FIRCLSProcessRecordAllThreads + 172 1 MyApp 0x7adfd4 FIRCLSProcessRecordAllThreads + 1208 2 MyApp 0x7bc4b4 FIRCLSHandler + 56 3 MyApp 0x7bc25c __FIRCLSExceptionRecord_block_invoke + 100 4 libdispatch.dylib 0x1b7cc _dispatch_client_callout + 16 5 libdispatch.dylib 0x118a0 _dispatch_lane_barrier_sync_invoke_and_complete + 56 6 MyApp 0x7bb1f0 FIRCLSExceptionRecord + 224 7 MyApp 0x7bbd1c FIRCLSExceptionRecordNSException + 456 8 MyApp 0x7badf4 FIRCLSTerminateHandler() + 396 9 Intercom 0x86684 IntercomSDK_sentrycrashcm_cppexception_getAPI + 308 10 libc++abi.dylib 0x11bdc std::__terminate(void (*)()) + 16 11 libc++abi.dylib 0x15314 __cxa_get_exception_ptr + 86 12 libc++abi.dylib 0x152bc __cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 90 13 libobjc.A.dylib 0x3190c objc_exception_throw + 448 14 CoreAutoLayout 0x13a4 -[NSISEngine optimize] + 314 15 CoreAutoLayout 0x1734 -[NSISEngine _optimizeWithoutRebuilding] + 72 16 CoreAutoLayout 0x1404 -[NSISEngine optimize] + 96 17 CoreAutoLayout 0xee8 -[NSISEngine performPendingChangeNotifications] + 104 18 UIKitCore 0x27ac8 -[UIView(Hierarchy) layoutSubviews] + 136 19 UIKitCore 0xfe760 -[UIWindow layoutSubviews] + 68 20 UIKitCore 0x234228 -[UITextEffectsWindow layoutSubviews] + 44 21 UIKitCore 0x27674 -[UIImageView animationImages] + 912 22 UIKitCore 0x28134 -[UIView(Internal) _viewControllerToNotifyOnLayoutSubviews] + 40 23 UIKitCore 0x18c2898 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 2532 24 QuartzCore 0xabd98 CA::Layer::perform_update_(CA::Layer*, CALayer*, unsigned int, CA::Transaction*) + 116 25 QuartzCore 0x8e810 CA::Layer::update_if_needed(CA::Transaction*, unsigned int, unsigned int) + 600 26 QuartzCore 0xad45c CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 200 27 QuartzCore 0x6e30c CA::Context::commit_transaction(CA::Transaction*, double, double*) + 540 28 QuartzCore 0x9afc4 CA::Transaction::commit() + 644 29 QuartzCore 0x16974c CA::Transaction::release_thread(void*) + 180 30 libsystem_pthread.dylib 0x4c28 _pthread_tsd_cleanup + 620 31 libsystem_pthread.dylib 0x4998 _pthread_exit + 84 32 libsystem_pthread.dylib 0x5e3c pthread_atfork + 54 33 libsystem_pthread.dylib 0x1440 _pthread_wqthread + 428 34 libsystem_pthread.dylib 0x8c0 start_wqthread + 8 Any ideas?

Hello, I have an existing AUv3 instrument plugin. In the plug in, users can access files (audio files, song projects) via a UIDocumentPickerViewController In Logic Pro, (and some other hosts, but not all), the document picker is unable to receive touches, while a keyboard case is attached to the iPad. Removing the case (this is an Apple brand iPad case) allows the interactions to resume and allows me to pick files in the usual way. One of my users reports this non-responsive behavior occurs even after disconnecting their keyboard. I have fiddled with entitlements all day, and have determined that is not the issue, since the keyboard disconnection appears to fix it every time for me. Here is my, very boilerplate, presentation code : guard let type = UTType("com.my.type") else { return } let fileBrowser = UIDocumentPickerViewController(forOpeningContentTypes: [type]) fileBrowser.overrideUserInterfaceStyle = .dark fileBrowser.delegate = self fileBrowser.directoryURL = myFileFolderURL() self.present(fileBrowser, animated: true) {

Before I file a bug report I wanted to verify that I'm not missing something. If I setup a view controller in a navigation controller and I add a view with a constraint that lines it up with the view controller's view's layoutMarginsGuide (leadingAnchor or trailingAnchor), in several cases the view will not line up with buttons added in the navigation bar. Under iOS 18 everything lines up as expected. To demonstrate, create a new iOS project based on Swift/Storyboard. Setup the storyboard to show a UINavigationController with one UIViewController. Then in ViewController.swift (the one embedded in the navigation controller), use the following code: import UIKit class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .yellow title = "Layout Margins" let leftCancel = UIBarButtonItem(systemItem: .cancel) navigationItem.leftBarButtonItem = leftCancel let rightCancel = UIBarButtonItem(systemItem: .cancel) navigationItem.rightBarButtonItem = rightCancel let leftView = UIView() leftView.backgroundColor = .blue leftView.translatesAutoresizingMaskIntoConstraints = false self.view.addSubview(leftView) let rightView = UIView() rightView.backgroundColor = .red rightView.translatesAutoresizingMaskIntoConstraints = false self.view.addSubview(rightView) NSLayoutConstraint.activate([ leftView.widthAnchor.constraint(equalToConstant: 80), leftView.heightAnchor.constraint(equalToConstant: 80), leftView.leadingAnchor.constraint(equalTo: self.view.layoutMarginsGuide.leadingAnchor), leftView.topAnchor.constraint(equalTo: self.view.layoutMarginsGuide.topAnchor), rightView.widthAnchor.constraint(equalToConstant: 80), rightView.heightAnchor.constraint(equalToConstant: 80), rightView.trailingAnchor.constraint(equalTo: self.view.layoutMarginsGuide.trailingAnchor), rightView.topAnchor.constraint(equalTo: self.view.layoutMarginsGuide.topAnchor), ]) } } This adds a "Cancel" button to both ends of the navigation bar and it adds two little square views lined up with the leading and trailing layout margins. Here's the results: iPad running iPadOS 26 beta 3 (note the misalignment). This is really jarring when trying to align another glass button below the cancel button: iPad running iPadOS 18.5 (aligned just fine): iPhone in portrait running iOS 26 beta (aligned just fine): iPhone in landscape running iOS 26 beta (no alignment at all): iPhone in portrait running iOS 18.5 (aligned just fine): iPhone in landscape running iOS 18.5 (aligned just fine): Under iOS 26 on an iPhone (simulator at least) in portrait, the cancel buttons line up with the colored squares. That's good. In landscape, the colored squares have much larger margins as expected (due to the larger safe areas caused by the notch), but the cancel buttons in the navigation bar are not using the same margins. This one is debatable. Under iOS 18 the cancel buttons use larger margins to match the larger safe area. But I can see why under iOS 26 they changed this since the navigation bar doesn't interfere with the notch. But it's inconsistent. Under iOS 26 on an iPad (simulator at least), it's wrong in any orientation. Despite the lack of any notch or need for a larger safe area, the colored squares are indented just a bit more than the buttons in the navigation bar. I see no reason for this. Under iOS 18 everything lines up as expected. My real question at this point: Is the mismatched margins on an iPad under iOS 26 between the buttons in the navigation bar and other views added to the view controller a likely bug or am I missing something?

Error: Fatal error: init(coder:) has not been implemented File: UIKitCore/UICoreHostingView.swift:54 Stack Trace Snippet: swift Copy Edit UIKitCore/UICoreHostingView.swift:54: Fatal error: init(coder:) has not been implemented Can't show file for stack frame: <DBGLldbStackFrame: 0x10ca74560> - stackNumber: 23 name: @objc ThemeableViewController.init(coder:). The file path does not exist on the file system: /

I noticed that trying to access safeAreaInsets from the active window causes an infinite run loop. This issue appeared after updating to Beta 3. Here’s an example of the code: extension UIDevice { var safeAreaInsets: UIEdgeInsets { guard let windowScene = UIApplication.shared.connectedScenes.first as? UIWindowScene, let window = windowScene.windows.first(where: { $0.isKeyWindow }) else { return .zero } return window.safeAreaInsets } } The return doesn’t happen because it ends up in some kind of recursion.

I’ve implemented a basic custom view controller presentation: the presented view controller slides up from the bottom in a manner similar to UISheetPresentationController, and can be dismissed by tapping the dimming view added on top of the presenting view controller. I want my custom presentation to be interruptible, so the user should be able to tap the dimming view while the presentation transition is in progress to smoothly convert the presentation transition into a dismissal transition. I’m using additive spring animations (by virtue of UIViewPropertyAnimator) here to make the change in direction less jarring. Unfortunately, it seems that the interruption-triggered dismissal transition is abruptly terminated by the system based on some kind of timer. The later in the presentation transition I tap the dimming view, the earlier the dismissal transition is terminated. Steps to reproduce After launching the test project: Tap the “Present” button. Tap the dimming view just before the transition completes. The test project includes a screen recording of the broken behavior.

The documentation for UIListContentConfiguration states that I can get the default content configuration of a UICollectionViewCell by getting the cells default content configuration. In practice, however, this presents an error in the compiler: let choiceRegistration = UICollectionView.CellRegistration<UICollectionViewCell, SurveyItem> { cell, indexPath, item in cell.configurationUpdateHandler = { cell, state in switch item.type { case .choice(let letter, let text): cell.defaultContentConfiguration() ... } The error shown when calling cell.defaultContentConfiguration() is Value of type 'UICollectionViewCell' has no member 'defaultContentConfiguration'. Instead, I need to initialise a content configuration using UIListContentConfiguration.cell() to get the default content configuration. This needs to be reflected in the documentation in UIKit.

I my App I use the sheetPresentationController to get a sheet that sits on top of the main view (a Map) and that can be slided up and down, similar to the Maps or FindMy Apps. This works great with iOS 18 and older. But under iOS 26 Beta I see issues, especially on the iPad. When the window is small (iPhone or compact size class on iPad), changing the height of the sheet works as expected, the sheet window is attached to the bottom of the screen and I can slide it up and down. But when the App window is wider (regular size class on the iPad), the sheet is shown at the left (as expected), but it is no longer attached to the bottom of the screen, there's a very large (but constant) gap between the bottom of the App window and the bottom of the sheet. I haven't found a way to minimize the gap, the sheet window seems to totally ignore the vertical position and size of the "sourceView" to which the sheet should be attached to (it still evaluates the horizontal position, so I can move the sheet to the right, but the vertical position can't be controlled anymore). The Maps App or FindMy Apps do not show this issue, also iOS 18 and older do not show this issue. Is this normal or can I do something to prevent this? The sheet should always be positioned to the bottom left corner of the App window, Another problem is the window background with a UIGlassContainer effect. In the Apple Maps App the sheet looses its glass effect transparency under iOS 26 when the sheet is fully expanded. The FindMy does not have this issue, here the glass effect/transparency is always present. In my App the background shows the glass effect when the window is not fully expanded when the overall App window is above a certain height (like the Apple Maps App), but when the App window is below a certain height then it is the opposite way: fully expanded it shows the glass effect and at smaller heights it is opaque. Why is this the case? How can I get the behavior of the FindMy App where the sheet window keeps its transparent glass effect in all cases? I do not want to have it changing its appearance depending of the height of the sheet. I can "solve" some of the issues when presenting the "sheet" as popover (via popoverPresentationController) and from within the popoverPresentationController use the adaptiveSheetPresentationController property to get the UISheetPresentationController (instead of directly using the sheetPresentationController property). In small App windows (iPhone or compact size class) it works exactly as when directly using sheetPresentationController. With larger App windows (iPad and regular size class) the sheet will be attached to the bottom of the App window (as expected) and the glass effect is always present. However in this case the detents which define the allowed heights of the sheet window will be always ignored, the window seems to have always the maximum height (minus some safe areas), Even when using the preferredContentSize property to set the size, only the width is respected, but never the height. Is there any way to get this working? Is this supposed to work this way or is this still a beta issue?

I'm using Swift to display some text in the middle of the screen, but I'm doing this programmatically instead of using the layout designer. So I'm starting with my version of a UILabel: class GenericLabel: UILabel I'm then creating one of these objects: let label = GenericLabel(frame: CGRect.zero) label.processResponse(componentDictionary ) view.addSubview(label) The processResponse function will set the text value, the font, fontsize, and set the bounds for where the text should be displayed on the screen. Currently I'm just wanting to position the text in the centre of the screen. During this process I send some messages to the console, like my calculation of the width and height and the bounds value. The console includes this: GenericLabel: default = centrex and centrey Utils:setSize: parent view bounds = (0.0, 0.0, 402.0, 874.0) Utils:setSize: obj size = (85.33333333333333, 20.333333333333332) Utils.setSize: centrey myframe.origin.y = 426.8333333333333 Utils.setSize: centrex myframe.origin.x = 158.33333333333334 Utils:setSize: myframe is now set to = (158.33333333333334, 426.8333333333333, 85.33333333333333, 20.333333333333332) self.frame set to (158.33333333333334, 426.8333333333333, 85.33333333333333, 20.333333333333332) Finally I set this frame to my GenericLabel self.frame = Utils.setSize(["centrex":0, "centrey":0], for: self) // You can see this message in the console above print("self.frame set to \(self.frame)") Unfortunately the text appears at (0,0) as in this screenshot. Why is the frame not working? Is there some setting overriding the frame?

Hi, In iOS 26, pushing or popping a view controller via UINavigationController shows a rounded corner effect during transition. This seems to be a new system feature. Is there a way to disable this and restore the previous full-rectangle style, as seen in earlier iOS versions (e.g. iOS 18)? Any official API or recommended approach? Thanks!

Hello Developer Forums Team, I’ve seen that some banking apps prevent screenshots on certain sensitive screens. I’m working on a similar feature in my SDK and want to confirm if my implementation complies with App Store guidelines. Since there’s no public API to block screenshots, I’m using a workaround based on the secure rendering behavior of UITextField (isSecureTextEntry = true). I embed my custom content (e.g., a UITableView) inside the internal secure container of a UITextField, which results in blank content being captured during screenshots—similar to what some banking apps do. Approach Summary I create a UITextField I detect its internal secure container by matching UIKit internal class names as strings I embed my real UI content into that container I do not use or call any private APIs, just match view class names via strings. ScreenshotPreventingView.swift final class ScreenshotPreventingView: UIView { private let textField = UITextField() private let recognizer = HiddenContainerRecognizer() private var contentView: UIView? public var preventScreenCapture = true { didSet { textField.isSecureTextEntry = preventScreenCapture } } public init(contentView: UIView? = nil) { super.init(frame: .zero) self.contentView = contentView setupUI() } private func setupUI() { guard let container = try? recognizer.getHiddenContainer(from: textField) else { return } addSubview(container) NSLayoutConstraint.activate([ container.topAnchor.constraint(equalTo: topAnchor), container.bottomAnchor.constraint(equalTo: bottomAnchor), container.leadingAnchor.constraint(equalTo: leadingAnchor), container.trailingAnchor.constraint(equalTo: trailingAnchor) ]) if let contentView = contentView { setup(contentView: contentView, in: container) } DispatchQueue.main.async { self.preventScreenCapture = true } } private func setup(contentView: UIView) { self.contentView?.removeFromSuperview() self.contentView = contentView guard let container = hiddenContentContainer else { return } container.addSubview(contentView) container.isUserInteractionEnabled = isUserInteractionEnabled contentView.translatesAutoresizingMaskIntoConstraints = false let bottomConstraint = contentView.bottomAnchor.constraint(equalTo: container.bottomAnchor) bottomConstraint.priority = .required - 1 NSLayoutConstraint.activate([ contentView.leadingAnchor.constraint(equalTo: container.leadingAnchor), contentView.trailingAnchor.constraint(equalTo: container.trailingAnchor), contentView.topAnchor.constraint(equalTo: container.topAnchor), bottomConstraint ]) } } HiddenContainerRecognizer.swift struct HiddenContainerRecognizer { private enum Error: Swift.Error { case unsupportedOSVersion(version: Float) case desiredContainerNotFound(_ containerName: String) } func getHiddenContainer(from view: UIView) throws -> UIView { let containerName = try getHiddenContainerTypeInStringRepresentation() let containers = view.subviews.filter { subview in type(of: subview).description() == containerName } guard let container = containers.first else { throw Error.desiredContainerNotFound(containerName) } return container } private func getHiddenContainerTypeInStringRepresentation() throws -> String { if #available(iOS 15, *) { return "_UITextLayoutCanvasView" } if #available(iOS 14, *) { return "_UITextFieldCanvasView" } if #available(iOS 13, *) { return "_UITextFieldCanvasView" } if #available(iOS 12, *) { return "_UITextFieldContentView" } let currentIOSVersion = (UIDevice.current.systemVersion as NSString).floatValue throw Error.unsupportedOSVersion(version: currentIOSVersion) } } How I use it in my Screen let container = ScreenshotPreventingView() override func viewDidLoad() { super.viewDidLoad() container.preventScreenCapture = true container.setup(contentView: viewContainer) //viewContainer is UIView in storyboard, in which all other UI elements are placed in e.g. UITableView self.view.addSubview(container) container.translatesAutoresizingMaskIntoConstraints = false NSLayoutConstraint.activate([ container.topAnchor.constraint(equalTo: self.view.topAnchor), container.bottomAnchor.constraint(equalTo: self.view.bottomAnchor), container.leadingAnchor.constraint(equalTo: self.view.leadingAnchor), container.trailingAnchor.constraint(equalTo: self.view.trailingAnchor) ]) } What I’d Like to Confirm Is this approach acceptable for App Store submission? Is there a more Apple-recommended approach to prevent screen capture of arbitrary UI? Thank you for your help in ensuring compliance.