SwiftUI List performance

Upskill in SwiftUI and system design, explore leadership roles, diversify platform expertise strategically.

That's interesting about the difference between NSOperation and NSThread as far as Mach ports go. I watched the # ports in Activity Monitor as I ran a job, and it certainly doesn't climb as each job runs. It goes from initially in the 300s to the low 500s right when the job starts, and stays around there, even after the job ends, and then I run the same job 2 or 3 more times without quitting. Well, that's the joy of Mach port leaks... you never REALLY know what you'll get. So, as some broader background here, the actual issue here isn't really about the thread API itself- ultimately, both APIs are using pthreads and the special pthread GCD uses aren't really different than standard pthreads. The real issue here is that you don't actually own the thread and the assumptions AppleEvents/ScriptingBridge were built around. Both of those APIs predate GCD (by many, many years) and are built around the assumption that they'll be used on a long-running thread that's running its own runloop, as that was basically THE p

Thanks for this awesome post. Yes, low power will trigger the device to go night night if possible. This is a great post for other developers to provide tips and ticks how to keep the device awake on a recording session. https://developer.apple.com/documentation/uikit/uiapplication/isidletimerdisabled Your approach of setting is indeed the standard way to achieve this. However, certain power management features, like Adaptive Power Mode, can override these settings, as you've observed. Ensure that you have an active configured while recording. This typically helps in signaling to the system that media capture is in progress, which should naturally prevent the device from sleeping. Unfortunately, iOS doesn't provide public APIs to directly detect Adaptive Power Mode specifically. However, you can check for Low Power Mode . While this doesn't exactly map to Adaptive Power Mode, it can still be useful for alerting users. Since detecting Adaptive Power Mode isn't directly possible, consider displaying a message w

Thank you for your post. I must admit that I am not entirely clear on your question regarding creating a Live Activity for a remote hosting environment. I believe I may have misunderstood your inquiry. Could you please provide me with additional details to clarify your objectives? As currently, Live Activities are designed primarily for iOS devices, and they appear on the Lock Screen and Control Center. December 16, 2025 Updated guidance for all platforms, and added guidance for macOS and CarPlay. https://developer.apple.com/design/human-interface-guidelines/live-activities/ If you want to bring Live Activities to Apple Watch: https://developer.apple.com/videos/play/wwdc2024/10068/ Including the documentation for the live activities guide. The widget configuration api to position a widget: https://developer.apple.com/documentation/swiftui/widgetconfiguration/disfavoredlocations(_:for:) Thanks, Albert Pascual
  Worldwide Developer Relations.

I am testing my iOS app on iOS 18. I performed 50 tests, and in 43–44 of them, the app successfully detects beacons, relaunches in the background, and continues BLE communication. Testing how? What are the details of the process you're actually using to test this? That is, are you: Artificial Testing” -> Laying the phone on a desk next to the beacon and toggling the beacon (or shielding the phone) on/off to simulate entry and exit. VS. Real World Testing” -> Carrying the phone around in your pocket and seeing what happens. Beyond that, what are the broader parameters of the test itself? How far is the device from the beacon? How long is the device exposed to the beacon? What's the broader use case you're trying to implement? Most importantly, what, if anything, do you know about EXACTLY what was happening when the failure occurred? I want to understand why beacon triggers are inconsistent in iOS. What are the common reasons behind iOS not relaunching the app for beacon events, and what factors

First, please check the document NFC & SE Platform for secure contactless transactions for the requirements and regional availability of NFC support with Secure Element. NFCTagReaderSession cannot be used for payment cards. You will need to use alternate CoreNFC APIs, which are only available via special entitlements and agreements. The document above will also explain the requirements for getting access to those APIs. Eventually, you will need to enter into an agreement with Apple and request the NFC & SE Platform Entitlement, if you satisfy the requirements as listed in the document above. If you are not able to use those APIs, PassKit framework will be your only remaining option, if appropriate. If you have already requested the relevant entitlements, if approved, you will receive further guidance on how to proceed with your development.

Hello @mike sldkcjnsdmhvbsdh I can see the code you submitted and have some insight. However, I am not the engineering team handling this report and would continue to refer to the status and discussion in Feedback Assistant, but I do have some insight. See your line 40 of NestedLazyVStackView .onAppear { // ⚠️ HANG TRIGGER POINT LazyVStacks allocates views as they are needed and here SwiftUI is modifying its content through state changes while that is happening. This creates a race condition. Traversing the accessibility tree will cause unexpected issues in this situation. For more info on the best practices building performant layouts, see: Building layouts with stack views and Creating performant scrollable stacks I hope this helps!  Travis Trotto - DTS Engineer