User Profile

We have been using the BGTask (specifically a BGProcessingTask) reliably for the last couple of years for our app. Up until now they wake up automatically while the screen is off, the iPad is plugged in, and the app is running (that is, in the background), but never while the screen is on (that is, never when the scenePhase == .active). For the last month or so, I've noticed that they are triggering now while the screen is displayed. How is this possible??? Did something change with a recent version of iOS? It's violating Apple's own documentation, which describes the BGProcessingTask as: "A time-consuming processing task that runs while the app is in the background."

We have a NavigationView embedded within a TabView, like this: TabView(selection: $tabSelection) { NavigationView { When a view gets pushed onto the stack in the NavigationView, the NavigationBar appears too high, almost under the StatusBar, as shown in the attached picture. If you touch the StatusBar, somehow it alerts the NavigationBar to scoot downward into its correct position. I discovered a hack where I quickly toggle the StatusBar off, then back on, which accomplishes the same thing. My question, though, is why is this necessary? Why isn't the NavigationBar in the correct place to begin with? Here's the hack that fixes it: .onAppear { withAnimation(.linear(duration: 0.3)) { appViewModel.hideStatusBar.toggle() } DispatchQueue.main.asyncAfter(deadline: .now() + 0.3) { withAnimation(.easeInOut(duration: 0.3)) { appViewModel.hideStatusBar.toggle() } } }

This example is pretty contrived, but it illustrates the behavior. I know you can use .accessibilityIdentifier to uniquely identify a control, but I'm just trying to better understand the interplay between XCUIElement and XCUIElementQuery. Let's say you have an app like this: import SwiftUI struct ContentView: View { @State var showRedButton = true var body: some View { VStack { if showRedButton { Button("Click me") { showRedButton = false } .background(.red) } else { HStack { Button("Click me") { showRedButton = true } .background(.blue) Spacer() } } } } } And you are UI testing like this: import XCTest final class MyAppUITests: XCTestCase { func testExample() throws { let app = XCUIApplication() app.launch() print(app.debugDescription) // At this point, the Element subtree shows // a single Button: // Button, 0x14e40d290, // {{162.3, 418.3}, {65.3, 20.3}}, label: 'Click me' let btn = app.buttons["Click me"] // This tap makes the red button disappear // and shows the blue button btn.tap() print(app.debugDescription) // Now, the Element subtree shows a single Button // that has a different ID // and different x-y coordinates: // Button, 0x15dc12e50, // {{0.0, 418.3}, {65.3, 20.3}}, label: 'Click me' // This tap now works on the blue button?? // Without requerying? btn.tap() print(app.debugDescription) // The red button reappears, // but with a different ID (which makes sense). } } Why does the second tap work, even though it's a different control? This must mean that SwiftUI is automatically re-running the XCUIElementQuery to find the button that matches "Click me". Apparently the variable btn isn't linked to the control with the ID 0x14e40d290. Does this mean XCUIElement actually represents an XCUIElementQuery? I expected it to require me to explicitly re-run the query like this, btn = app.buttons["Click me"] prior to running the 2nd tap, or the tap would've said that btn was no longer available. The final print of the Element subtree shows that the red button has a different ID now. This makes sense, because when SwiftUI redraws the red button, it's not the same instance as the last time. This is explained well in the WWDC videos. Nevertheless, at the moment I connected the variable "btn" to the control, I thought there was a tighter affiliation. Maybe UI testing has to behave this way because SwiftUI redraws controls so frequently?

To me this is a clear bug (and I submitted it as one: FB11813464), unless there's something I'm missing? When the confirmationDialog is showing on an iPad, and you click outside it, the confirmationDialog disappears, as it should. This is the same behavior as the popover in UIKit; the outside-click acts in lieu of a Cancel button when you're on an iPad. HOWEVER, the outside-click also triggers behaviors elsewhere on the screen, for ex if the place you click has a Button, or an onTapGesture listener. As demonstrated in this picture, when the confirmationDialog is showing, and you click on this button, the confirmationDialog disappears, which is correct, but the print action also runs, which shouldn't. I’m running Xcode 14.1, targeting iOS 16.1, and running on an iPad 10th gen simulator.