After more than a year of usage, I can heuristically answer my own question Does geo-tracking always provide greater than or equal to the accuracy of world tracking, for a GPS outdoor AR experience? No. Especially indoors, world tracking is more suitable.

Same here. Anything in SwiftUI with a Slider will crash on macOS Mac Catalyst 26. Following this thread… FB20614181 also filed.

For anyone else with similar situation - Our local Swift Package has a bundle identifier "FooBAR" in the past, and now it becomes "foobar.FooBAR".

This is bothering. We had the same issue for our recent (initial) macOS release and dang, now we are stuck with a huge CFBundleVersion number for macOS: https://developer.apple.com/forums/thread/759988 😩

After more reading, I realized the following fact: iOS has different version number strategy than macOS. Specifically, an iOS app's version number typically looks like major.minor.patch (build), whereas for macOS app it looks like major.minor.patch. No build number for macOS app due to historical reasons. On iOS, major.minor.patch = CFBundleShortVersionString, and build = CFBundleVersion on macOS, major.minor.patch = CFBundleVersion Which causes problem for a cross platform app that used to be iOS only, but recently start to support macOS via Mac Catalyst (exactly our case. =_=!) The app versioning used to work well with iOS versioning pattern major.minor.patch (build) where the "must contain a higher version" requirement only applies to the build part when the version number is the same. If the version is different, no need to compare build at all. But on macOS, because there is no build number, it directly compares the major.minor.patch version number, which unfortunately uses the same dict key CFBundleVersion as on iOS. Thus, the single component build number on iOS, becomes the sole number for macOS version comparison. That doesn't pose a problem if your app's build increases daily. But it causes huge problem if you assign the build manually when you do the App Store upload, like us. How to solve it? Well, I hope App Store Connect can add some special handling for cross-platform app that originated from iOS, to first compare the version number via CFBundleShortVersionString, so that CFBundleVersion can be treated as a build number to be used for further comparison. Otherwise, we have to discard the 20-million integers (20240801 to be exact) we've inadvertently wasted for the macOS version number. 😩

Today we meet this problem again. The Mac App Store published version 200.5.0 (20240801) causes the daily build 200.6.0 (4318) to fail to upload. Which doesn't make sense in several ways: The version number of the daily build is greater, so the build number shouldn't even be compared! After submission got published, I have expired the TestFlight build for 20240801, so it shouldn't play a role in version comparison at all! Why does an approved and published app build should affect anything in TestFlight? Why iOS TestFlight doesn't have this problem, only MacOS does?? In case someone find this thread with the same problem, I'll try Feedback Assistant and see what Apple says. Likely that we need to adjust our build number pattern to cater them. 🥀

I have a follow up question - I see many Apple APIs have auto-generated async counterparts of their old completion block/escaping closure version. Aside from the "sequential" vs "pyramid" styling differences, are there any other underlying differences, such as async/await is based upon Swift Concurrency vs escaping closure is using GCD/Dispatch? The reason I ask is that sometimes in our codebase people accidentally use the escaping closure version of the API in synchronous context, such as onAppear modifier of a view, while ideally the async version should really be used in a task modifier. Does using completion-block based API cause performance degradation or mess up the Swift Concurrency model? Are all the APIs with async wrappers have been bridged using continuation? Thanks.

We are actually using this pattern quite a lot in our framework and demo apps. As you may find, computing resource-intensive mapping related objects is time consuming! We have even written a doc - "Working with Geo Views | ArcGIS Documentation" (albeit concise) to explain the right pattern for using our framework. 😄 And your assessment is correct - State property wrapper and its initializer should not be used with an injected variable - it should only be used with a constant or created within the view. StateObject's initializer can be used, but with caution.

See What’s new in SwiftUI - WWDC 2024 around 17:30. Instead of annotating the View.body with MainActor, now the View protocol is on main actor.

If you are open to change the $(PRODUCT_NAME), it will change the app name. Otherwise, set specific values for CFBundleName (for macOS menu and app bundle name), and CFBundleDisplayName (the text displayed in the app's nav bar). You can also set localized app names for these 2 values in a strings file.

To anyone who find this question after iOS 17, here is a new modifier that solves exactly this problem: onChange(of:initial:_:)

I have seen similar log for ARKitCore. It seems to be an ARKit internal issue. Thread Performance Checker: Thread running at User-initiated quality-of-service class waiting on a lower QoS thread running at Default quality-of-service class. Investigate ways to avoid priority inversions PID: 14603, TID: 6216861 Backtrace ================================================================= 3 ARKitCore 0x00000001cb1bfd68 531C4275-B554-3D3A-88B7-3C9CE4D952C3 + 441704 4 libdispatch.dylib 0x0000000101f88f50 _dispatch_call_block_and_release + 32 5 libdispatch.dylib 0x0000000101f8ab34 _dispatch_client_callout + 20 6 libdispatch.dylib 0x0000000101f9298c _dispatch_lane_serial_drain + 832 7 libdispatch.dylib 0x0000000101f9375c _dispatch_lane_invoke + 460 8 libdispatch.dylib 0x0000000101f94d6c _dispatch_workloop_invoke + 2336 9 libdispatch.dylib 0x0000000101fa05f8 _dispatch_root_queue_drain_deferred_wlh + 328 10 libdispatch.dylib 0x0000000101f9fc2c _dispatch_workloop_worker_thread + 444 11 libsystem_pthread.dylib 0x0000000205f2f964 _pthread_wqthread + 288 12 libsystem_pthread.dylib 0x0000000205f2fa04 start_wqthread + 8

I have a similar problem. The root cause is not the custom binding, but is related to observation mechanism. While my understanding is the same as the accepted reply above - non-observable object won't trigger UI updates correctly, the behavior is unexpected on iOS vs Mac Catalyst. Consider the code snippet below import SwiftUI class BoolWrapper { var value = false { didSet { print("Value changed to \(value)") } } } struct ContentView: View { @State private var wrapper = BoolWrapper() var body: some View { Toggle("Toggle example", isOn: $wrapper.value) } } #Preview { ContentView() } The expected behavior for this snippet is not to change the UI when the toggle is turned on/off, because the BoolWrapper object is not observable. However… On iOS, the toggle work normally. When it turns on, the UI correctly shows the tinted control, and the value is set to true On Mac Catalyst, the toggle checkbox's UI doesn't update, whereas the value still changes between true/false when I click the checkbox. My question is: Is the behavior on iOS unexpected, or "by accident"? It shouldn't work on iOS, but somehow it works. FB13698944 is logged for this issue. The code with correct behavior is like below, where the ObservableObject protocol is used. import SwiftUI class BoolWrapper: ObservableObject { @Published var value = false { didSet { print("Value changed to \(value)") } } } struct ContentView: View { @StateObject private var wrapper = BoolWrapper() var body: some View { Toggle("Toggle example", isOn: $wrapper.value) } } #Preview { ContentView() }

Another finding during our test is that, regardless of geo-tracking or world-tracking configuration, when I first manually adjust the heading of our custom view to be aligned with the AR view, then start to turn quickly around 360 degrees, or several circles consecutively, the custom view's heading alignment will drift drastically. In order to restore the alignment, I had to reset the session and re-localize, or manually calibrate the heading according to some visual reference POIs. Is it due to the device electronic compass' intrinsical limitation? Also, if there isn't a good answer to the original question, we might just end up presenting a toast to guide the user to manually adjust the heading, whenever it is mis-aligned with the AR view. Thanks.

Just make the "Builds" section a list with checkboxes, allow us to edit then select builds from the list, and provide an "expire selected builds" or "delete selected builds" button at the top of the list. How difficult is that? 🧐