I'm trying to understand how to best position my iOS apps in the event that—for whatever reason—I'm unable to release another version after submitting a version built with Xcode 26 that uses UIDesignRequiresCompatibility = YES.
For the sake of this discussion, assume that my apps require updates for proper UI presentation with the Liquid Glass UI, and that I'm submitting an initial version with UIDesignRequiresCompatibility = YES.
I need to make an initial update for iOS 26 right away, because running the app linked with the iOS 18.x SDK (as currently shipping on the App Store) on iOS 26 introduces UI usability problems.
Now, I have actually revised the UI for Liquid Glass and this requires slightly different behaviors for the legacy UI path (iOS 18.6 or iOS 26.0 with UIDesignRequiresCompatibility = YES) versus Liquid Glass UI path.
My Liquid Glass adoption UI may be "good enough," and it's certainly better than the results obtained when rebuilding with Xcode 26 and running without any updates at all (which produces a very poor, if not unusable, user experience), but I am not satisfied with these updates at present and I hope to make additional improvements before enabling the revised UI for users.
However, in the event that I cannot make another update for whatever reason, I need to ensure that users will never be exposed to the UI behavior that results from running with UIDesignRequiresCompatibility = NO with the code supporting Liquid Glass adoption disabled.
As long as Apple will guarantee going forward that an app built with Xcode/iOS 26.0 SDK including UIDesignRequiresCompatibility = YES in its plist will always use the old rendering mode in any future OS, then perhaps everything is fine.
However, if that's not the case, then I think I need some way to detect the enablement state of the new Liquid Glass UI at runtime (which goes beyond a simple @available check, e.g. iOS 26+ with "compatibility mode" disabled) so that I can provision to have my code supporting Liquid Glass adoption be automatically enabled in the event that my app never receives another update and a future OS ignores the UIDesignRequiresCompatibility key in its plist. I'm assuming that testing the value of the key in the plist at runtime would be insufficient, since it would still be present but ignored.
This sort of continuity planning seems like something that many developers would be concerned about.
What is Apple's guidance on this? So far I haven't found any clear discussion of this concern.
Note: My app is UIKit-based, mostly Objective-C with a bit of Swift only for TipKit.
Explore the various UI frameworks available for building app interfaces. Discuss the use cases for different frameworks, share best practices, and get help with specific framework-related questions.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
When UIStatusBarHidden is set to YES, the navigation bar is displayed in the wrong vertical position immediately after app launch. The layout only corrects itself after the device orientation changes (e.g., rotation).
Steps to Reproduce:
Create a new app with a navigation controller.
Set UIStatusBarHidden = YES in Info.plist.
Launch the app.
Expected Result:
The navigation bar should appear in the correct position immediately after launch.
Actual Result:
The navigation bar is misaligned on first launch, and only moves to the correct position after rotating the device.
I’m using SwiftUI’s Text(_:style:) with the .relative style to show how long ago a date occurred. According to the docs:
A style displaying a date as relative to now.
I expected it to show the precise difference between a past date and the current date. However, I noticed that two dates that are 3 days apart both display the same relative string under certain conditions.
Code snippet to reproduce- (using GMT time zone and the system calendar)
IMPORTANT: To reproduce this, set your Mac’s system clock to 8 September 2025, 3:00 AM. SwiftUI’s relative style uses the current system time as its reference point, so changing the clock is necessary to see the behavior.
Settings
Mac is set to Central European Time zone (but this behaviour was also reproduced by one of my app's users in the US.)
Mac OS Sequoia 15.5
XCode 16.4
tested on an iOS Simulator and a real iPhone both running iOS 18.5
struct TestDateView: View {
var body: some View {
// 8. July 10AM to 8. September 3AM = Shows 2 months 2 days
let startDate1: Date = Calendar.current.date(from: .init(calendar: .current, timeZone: .gmt,
year: 2025, month: 7, day: 8, hour: 10, minute: 0, second: 0))!
// 5. July 10AM to 8. September 3AM = Shows 2 months 2 days
let startDate2: Date = Calendar.current.date(from: .init(calendar: .current, timeZone: .gmt,
year: 2025, month: 7, day: 5, hour: 10, minute: 0, second: 0))!
// IMPORTANT!: Need to set MAC's clock to 8. September 3:00 AM to reproduce this bug
VStack {
Text(startDate1, style: .relative)
Text(startDate2, style: .relative)
}
}
}
How exactly does the .relative style work internally?
Is it expected that different dates can collapse into the same result like this, or is there a better way to use .relative to get more precise results?
PS: I know about DateComponents and DateFormatter for exact calculations, but I’d like to understand this approach since it auto-updates natively with no timers or publishers.
Hi,
Is there any equivalent of glassEffectUnion in UIKit ?
I would like to achieve the same effect as described here :
https://developer.apple.com/documentation/SwiftUI/Applying-Liquid-Glass-to-custom-views
Topic:
UI Frameworks
SubTopic:
UIKit
When I create a SwiftUI toolbar item with placement of .keyboard on iOS 26, the item appears directly on top of and in contact with the keyboard. This does not look good visually nor does it match the behavior seen in Apple's apps, such as Reminders. Adding padding to the contents of the toolbar item only expands the size of the item but does not separate the capsule background of the item from the keyboard. How can I add vertical padding or spacing to separate the toolbar item capsule from the keyboard?
Topic:
UI Frameworks
SubTopic:
SwiftUI
I need more time to adapt to the new iOS 26 UI, so I set the "UIDesignRequiresCompatibility" attribute to "Yes."
This works, but now all large titles are not aligned with the content.
Below you can see an example, but I have the issue with all large titles.
All good on iOS 18.
Does anyone have an idea why and how can i fix it?
The "Cancel" button for VNDocumentCameraViewController is not displayed on iPadOS 26. This issue appears to be specific to iPad, as the button appears correctly on iPhone.
Experiencing 100% CPU usage in SwiftUI app using UIHostingController, only on iOS 26 beta and Xcode beta. Issue involves excessive view updates in AttributeGraph propagation.
Stack trace (main thread):
thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
frame #0: 0x00000001c38b9aa4 AttributeGraph`AG::Graph::propagate_dirty(AG::AttributeID) + 416
frame #1: 0x00000001d9a743ec SwiftUICore`SwiftUI.ObservationGraphMutation.apply() -> () + 656
frame #2: 0x00000001d97c0d4c SwiftUICore`function signature specialization <Arg[2] = [Closure Propagated : closure #1 () -> () in SwiftUI.(AsyncTransaction in _F9F204BD2F8DB167A76F17F3FB1B3335).apply() -> (), Argument Types : [SwiftUI.AsyncTransaction]> of generic specialization <()> of closure #1 () throws -> τ_0_0 in SwiftUI.withTransaction<τ_0_0>(SwiftUI.Transaction, () throws -> τ_0_0) throws -> τ_0_0 + 336
frame #3: 0x00000001d9a6ac80 SwiftUICore`merged function signature specialization <Arg[3] = Owned To Guaranteed> of function signature specialization <Arg[1] = [Closure Propagated : implicit closure #2 () -> () in implicit closure #1 @Sendable (SwiftUI.(AsyncTransaction in _F9F204BD2F8DB167A76F17F3FB1B3335)) -> () -> () in SwiftUI.GraphHost.flushTransactions() -> (), Argument Types : [SwiftUI.AsyncTransaction]> of SwiftUI.GraphHost.runTransaction(_: Swift.Optional<SwiftUI.Transaction>, do: () -> (), id: Swift.Optional<Swift.UInt32>) -> () + 196
frame #4: 0x00000001d9a52ab0 SwiftUICore`SwiftUI.GraphHost.flushTransactions() -> () + 176
frame #5: 0x00000001d8461aac SwiftUI`closure #1 (SwiftUI.GraphHost) -> () in SwiftUI._UIHostingView._renderForTest(interval: Swift.Double) -> () + 20
frame #6: 0x00000001d9bf3b38 SwiftUICore`partial apply forwarder for closure #1 (SwiftUI.ViewGraph) -> τ_1_0 in SwiftUI.ViewGraphRootValueUpdater.updateGraph<τ_0_0>(body: (SwiftUI.GraphHost) -> τ_1_0) -> τ_1_0 + 20
frame #7: 0x00000001d9e16dc4 SwiftUICore`SwiftUI.ViewGraphRootValueUpdater._updateViewGraph<τ_0_0>(body: (SwiftUI.ViewGraph) -> τ_1_0) -> Swift.Optional<τ_1_0> + 200
frame #8: 0x00000001d9e1546c SwiftUICore`SwiftUI.ViewGraphRootValueUpdater.updateGraph<τ_0_0>(body: (SwiftUI.GraphHost) -> τ_1_0) -> τ_1_0 + 136
frame #9: 0x00000001d8461a7c SwiftUI`closure #1 () -> () in closure #1 () -> () in closure #1 () -> () in SwiftUI._UIHostingView.beginTransaction() -> () + 144
frame #10: 0x00000001d846aed0 SwiftUI`partial apply forwarder for closure #1 () -> () in closure #1 () -> () in closure #1 () -> () in SwiftUI._UIHostingView.beginTransaction() -> () + 20
frame #11: 0x00000001d984f814 SwiftUICore`closure #1 () throws -> τ_0_0 in static SwiftUI.Update.ensure<τ_0_0>(() throws -> τ_0_0) throws -> τ_0_0 + 48
frame #12: 0x00000001d984e114 SwiftUICore`static SwiftUI.Update.ensure<τ_0_0>(() throws -> τ_0_0) throws -> τ_0_0 + 96
frame #13: 0x00000001d846aeac SwiftUI`partial apply forwarder for closure #1 () -> () in closure #1 () -> () in SwiftUI._UIHostingView.beginTransaction() -> () + 64
frame #14: 0x00000001851eab1c UIKitCore`___lldb_unnamed_symbol311742 + 20
* frame #15: 0x00000001852b56a8 UIKitCore`___lldb_unnamed_symbol315200 + 44
frame #16: 0x0000000185175120 UIKitCore`___lldb_unnamed_symbol308851 + 20
frame #17: 0x00000001d984e920 SwiftUICore`static SwiftUI.Update.dispatchImmediately<τ_0_0>(reason: Swift.Optional<SwiftUI.CustomEventTrace.ActionEventType.Reason>, _: () -> τ_0_0) -> τ_0_0 + 300
frame #18: 0x00000001d95a7428 SwiftUICore`static SwiftUI.ViewGraphHostUpdate.dispatchImmediately<τ_0_0>(() -> τ_0_0) -> τ_0_0 + 40
frame #19: 0x00000001852b59dc UIKitCore`___lldb_unnamed_symbol315204 + 192
frame #20: 0x00000001852b54a4 UIKitCore`___lldb_unnamed_symbol315199 + 64
frame #21: 0x0000000185745dd4 UIKitCore`_UIUpdateSequenceRunNext + 120
frame #22: 0x0000000186144fac UIKitCore`schedulerStepScheduledMainSectionContinue + 56
frame #23: 0x00000002505ad150 UpdateCycle`UC::DriverCore::continueProcessing() + 36
frame #24: 0x0000000180445b20 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24
frame #25: 0x0000000180445a68 CoreFoundation`__CFRunLoopDoSource0 + 168
frame #26: 0x00000001804451f4 CoreFoundation`__CFRunLoopDoSources0 + 220
frame #27: 0x00000001804443a8 CoreFoundation`__CFRunLoopRun + 756
frame #28: 0x000000018043f458 CoreFoundation`_CFRunLoopRunSpecificWithOptions + 496
frame #29: 0x00000001928d19bc GraphicsServices`GSEventRunModal + 116
frame #30: 0x0000000186224480 UIKitCore`-[UIApplication _run] + 772
frame #31: 0x0000000186228650 UIKitCore`UIApplicationMain + 124
frame #32: 0x000000010bb1b504 MyApp.debug.dylib`main at main.swift:13:1
frame #33: 0x00000001043813d0 dyld_sim`start_sim + 20
frame #34: 0x000000010468ab98 dyld`start + 6076
Used let _ = Self.printChanges() in my SwiftUI View and got infinite changes of \_UICornerProvider.<computed 0x000000018527ffd8 (Optional<UICoordinateSpace>)> changed.
Reproduces only on beta; works on stable iOS. Likely beta-specific bug in SwiftUI rendering.
When I display 2/3 of the poster on tvos, after setting it according to the code, some semi-transparent background can be seen in the upper left and right corners of the image when it is in focus. How can I eliminate it?
struct HighPosterView: View {
let media: MediaDetail
@State private var isShowingDetails = false
@Environment(\.isFocused) private var isFocused: Bool
var body: some View {
Button {
isShowingDetails.toggle()
} label: {
HighShelfImageView(imageURL: media.posterURL)
.contentShape(RoundedRectangle(cornerRadius: 24, style: .continuous))
.hoverEffect(.highlight)
Text(media.displayTitle)
.lineLimit(1)
.font(.subheadline)
.frame(maxWidth: 300)
}
.buttonStyle(.borderless)
.animation(.smooth)
}
}
struct HighShelfImageView: View {
let imageURL: URL?
var body: some View {
KFImage.url(imageURL)
.targetCache(ImageCacheManager.shelfCache)
.setProcessor(ImageCacheManager.mediaListShelfProcessor)
.placeholder {
Color.primary.opacity(0.1)
.cornerRadius(Constants.cornerRadius)
}
.cancelOnDisappear(true)
.cacheMemoryOnly(false)
.fade(duration: 0.1)
.cacheOriginalImage(true)
.resizable()
.aspectRatio(2/3, contentMode: .fill)
.clipShape(RoundedRectangle(cornerRadius: Constants.cornerRadius))
}
}
I need to keep the image and text distributed vertically, keep customize corner, with the text pushed aside when the image is in focus.
If the NavigationSplitView on iPadOS 26 is combined with a .inspector column, the sidebarToggle is always hidden, when the sidebar is collapsed. If you remove the .inspector modifier, the sidebarToggle stays visible throughout the collapsed or expanded state.
Has maybe someone a workaround for this issue?
The problem does not exist in iOS 18.
The bug is reported as FB20061260
Steps to reproduce:
Create a default document-based app for iOS using SwiftUI or UIKit with UIDocumentViewController.
In the document loading method, simulate an error by throwing an exception, for example: throw CocoaError(.coderValueNotFound)
Open the app on device/simulator running iOS 18 and attempt to open or create a new document.
Expected behavior:
An appropriate error message should be displayed to the user.
Actual behavior:
No error message is shown to the user
The "Create Document" button becomes permanently disabled
The app appears to hang or become unresponsive
Environment:
iOS 18, 26 beta 9
Both UIKit and SwiftUI implementations affected
Has anyone encountered this issue or found a workaround?
This seems like a regression in iOS 18's document handling.
FB20189617, FB20189669
Hello,
I am building a UIKit application where I need to handle key events in a UITextField with the following requirements:
Normal key presses (e.g. A, B, etc.) should insert characters into the text field.
A hotkey combination (Ctrl+K) should trigger a custom computation that runs on a background thread, and once completed, its result (e.g. $) should be inserted into the text field.
All events (normal keys and hotkeys) must appear in the exact order they were pressed by the user. For example:
If the user types A, B, then Ctrl+K, the field should show AB$.
If the user types A, Ctrl+K, C, the field should show A$C, even if the computation for $ takes longer.
I want strict sequential processing: no later keystroke should be inserted until an earlier hotkey computation finishes.
I have tried overriding pressesBegan(_:with:) in a custom UITextField subclass, and I can detect both normal keys and Ctrl+K.
Questions:
Is there a recommended UIKit API or pattern for handling this kind of ordered key event processing with hotkeys?
Are there best practices for mixing UI updates with background computations in this context, while preserving event order?
Thanks!
Hi,
I came across the following API:
@MainActor
func placeCursor(at position: UITextPosition!, animated: Bool)
From the signature, it seems intended to move the insertion point (caret) to a given UITextPosition, with an option for animation.
However, UITextView and UITextField don’t seem to expose this method as a public member — calling it gives the error:
Value of type 'UITextView' has no member 'placeCursor'
My questions are:
Is placeCursor(at:animated:) a public, supported API that we can safely use in apps?
If not, what is the Apple-recommended way to programmatically move the cursor without animation?
Right now, I only know of updating selectedTextRange, which works but doesn’t involve this placeCursor method. I want to confirm if placeCursor is meant for developer use or is an internal/private API.
Thanks!
Since iOS 26, when using toolbar items with .keyboard placement, the view inside the hierarchy which is pushed, does not directly stick to the toolbar anymore when a text field is focused, creating a gap, or moving the view below the toolbar. Focusing another field pushes the layout below the toolbar.
Minimal example to reproduce the issue.
import SwiftUI
import Foundation
@main
struct testfocusApp: App {
@State var showSheet = false
var body: some Scene {
WindowGroup {
ContentView()
}
}
}
struct ContentView: View {
enum Field: Hashable {
case body
case title
}
@State var titleText = ""
@State var bodyText = ""
@FocusState private var focusedField: Field?
var body: some View {
NavigationView {
VStack(spacing: 0) {
ScrollView {
VStack(spacing: 16) {
TextField("", text: $titleText)
.onSubmit {
focusedField = .body
}
.background(Color.red)
.focused($focusedField, equals: .title)
VStack(spacing: 0) {
VStack {
Text(bodyText)
.padding(.vertical, 9)
.padding(.horizontal, 5)
.hidden()
TextEditor(
text: $bodyText
)
.focused($focusedField, equals: .body)
}
}
}
.padding(20)
}
Spacer()
VStack(spacing: 16) {
Text("message")
Button {
} label: {
Text("Save")
.frame(maxWidth: .infinity)
}
}
.border(Color.red)
.background(Color.green)
}
.background(Color.yellow)
.border(Color.purple)
.toolbar {
ToolbarItem(placement: .keyboard) {
Button("Done") {
}
.border(Color.purple)
}
}
}
}
}
The following shows minimal example to reproduce the issue:
Menu {
Button("Test"){}
} label: {
Text("Menu")
} primaryAction: {
// Some action
}
primaryAction modifier will not be called when pressing the menu button/view on iOS 26 beta, long pressing it will open the menu.
Was tested on latest iOS 26 beta 8
Topic:
UI Frameworks
SubTopic:
SwiftUI
Anyone else seeing this? I reported the regression back in March 2025 and have no reply from Apple. My apps are Obj-C, in case it matters.
DESCRIPTION
After updating to iOS 18.3.x, | noticed a regression in the title menu behavior of my UlDocumentViewController-based shipping apps on the App Store [1]: Instead of displaying the document icon supplied by the app, the share menu item displays a placeholder icon instead, and iconservicesagent error messages are emitted in the log stream [2].
STEPS TO REPRODUCE
Install one of the apps from note [1] below.
Launch the app, tap the document/title menu at top center of the screen, and observe first menu item.
RESULTS
Expected:
App-provided document icon displayed to left of first menu item ("W-1" or "W68" document icon).
Actual:
Placeholder icon displayed.
REGRESSION
Occurs:
iOS 18.3 (iPad)
iOS 18.3.1 (iPhone)
iOS 18.3.2 (iPhone)
Does Not Occur:
iOS 18.2,18.3 Simulator
iOS 18.0-18.2? [| no longer have a device with < 18.3 to confirm regression point]
NOTES:
[1] WOZNIAC-1 <https://apps.apple.com/us/ app/wozniac-1/id6474085354> and
WOZNIAC-68 <https://apps.apple.com/us/app/ wozniac-68/id6736677781>.
[2] When the problem occurs, the following log messages are omitted:
Error returned from iconservicesagent image request: <|STagIcon: 0x30299c040> Tag: alvm, Class: public.filename-extension, Base type: public.item - <|SImageDescriptor:
Ox300dd5860> - (37.00, 48.00)@3x v:40000 1:5 a: 0:0:0:0 t:() b:0 s:2 ps:0 digest:
0D3223D0-9AЕ3-3B19-A081-ACACE55691B7
error: Error Domain=NSOSStatusErrorDomain Code=-609 "Client is disallowed from making such an icon request"
UserInfo={NSLocalizedDescription=Client is disallowed from making such an icon request}
Topic:
UI Frameworks
SubTopic:
UIKit
I have a PDF which contains geocoordinates. I'm extracting out that image with the following code (this is for an iOS application):
guard let cgDocument = CGPDFDocument(overlay.pdfUrl as CFURL) else { return }
guard let cgPage = cgDocument.page(at: 1) else { return }
var boundingRect = self.rect(for: overlay.boundingMapRect)
let pdfPageRect = cgPage.getBoxRect(.mediaBox)
let renderer = UIGraphicsImageRenderer(size: pdfPageRect.size)
var img = renderer.image { ctx in
UIColor.white.set()
ctx.fill(pdfPageRect)
ctx.cgContext.translateBy(x: 0.0, y: pdfPageRect.size.height)
ctx.cgContext.scaleBy(x: 1.0, y: -1.0)
ctx.cgContext.drawPDFPage(cgPage)
}
Once I have that image, I then need to adjust it to fit the specific coordinate corners. For that, I'm doing the following using a perspectiveTransform:
let ciImg = CIImage(image: img)!
let perspectiveTransformFilter = CIFilter.perspectiveTransform()
perspectiveTransformFilter.inputImage = ciImg
perspectiveTransformFilter.topRight = cartesianForPoint(point: ur, extent: boundingRect)
perspectiveTransformFilter.topLeft = cartesianForPoint(point: ul, extent: boundingRect)
perspectiveTransformFilter.bottomRight = cartesianForPoint(point: lr, extent: boundingRect)
perspectiveTransformFilter.bottomLeft = cartesianForPoint(point: ll, extent: boundingRect)
let txImg = perspectiveTransformFilter.outputImage!
img = UIImage(ciImage: txImg)
The original image is 792 x 612 (a landscape PDF) but the boundingRect covering the coordinates is 25625 x 20030. Obviously when I try to draw the image into that bounding box the app runs out of memory (25625 x 20030 x 4 is around 2GB of memory).
What I'm struggling with is - how do I correctly scale this image to fit into the bounding box even though the bounding box is, oh, 10x the resolution of the actual device? There's some key CoreGraphics thing I'm sure I'm missing here.
I've been trying to update my apps for iOS 26, and all summer I kept hitting this issue with the navigation bar title. I was hoping Apple would eventually fix it, but it still seems to be broken in beta 9, so now I'm wondering if I'm doing something wrong.
Here's a minimal working example:
struct ContentView: View {
@State private var path = NavigationPath()
var body: some View {
NavigationStack(path: $path) {
List {
Text("Item 1")
Text("Item 2")
Text("Item 3")
}
.navigationTitle("Title")
.toolbarBackground(Color(red: 0.5, green: 0.5, blue: 0.5), for: .navigationBar)
.toolbarBackgroundVisibility(.visible, for: .navigationBar)
}
}
}
Expected result: The title should be rendered on a gray background.
Actual result: The title is invisible because it is rendered below the gray background.
If I modify the gray color with .opacity(0.5), then it becomes clear that the title is indeed present, but it's behind the background.
This example works correctly in iOS 18.
Is this an iOS 26 bug or is this a forbidden design now because everything has to be translucent?
Topic:
UI Frameworks
SubTopic:
SwiftUI
Hi guys!
I wanted to study this new ManipulationComponent(), but I keep getting a warning that I don’t understand, even in a very simple scenario.
i don't have any collisions just binding the Manipulation
the warning message is :
** Entity returned from EntityWrapper.makeEntity(context:) was already parented to another entity. This is not supported and may lead to unexpected behavior. SwiftUI adds entities to internally-managed entity hierarchies.**
RealityView { content, attachments in
if let loadedModel = try? await Entity(named: "cloud_glb", in: realityKitContentBundle) {
content.add(loadedModel)
loadedModel.components.set(ManipulationComponent())
}
Thanks !
One screen in my app uses a navigation bar with some buttons added to the titleView and some buttons added as a customView of a single rightBarButtonItem.
In iOS 26 (beta 9), if I switch to the home screen and back again, the titleView and rightBarButtonItem disappear and an overflow button (three dots) appears instead. Nothing happens when I click the overflow button. Here's a screen capture:
https://youtu.be/tthRnMz98kA
This also happens when I switch to another app, when I rotate the device or when I resize the app window. In all cases, there is enough room to show all the buttons, but they still disappear.
I overrode the viewWillTransition function in my view controller and logged when that runs. I can see that if I switch to the home screen and back again before that runs (within one or two seconds), there's no problem. But once that runs, the navigation bar items disappear and the overflow button appears.
I have not done anything to set up the overflow button and don't have any need to use it. The documentation about it isn't very detailed, but it seems like it shouldn't be used unless I add it. This wasn't a problem in iOS 18 or earlier iOS versions.
Does anyone know how to stop this?
BTW, I'm using Swift, but not SwiftUI.
Topic:
UI Frameworks
SubTopic:
UIKit