We still need the answer to this question. Our usecase in short: ❓ For ARGeoTrackingConfiguration, we want to set a custom view to have the same heading as the AR camera, so it can provide geo-referenced symbol with correct heading in real world. However, we couldn't find the right way to access AR camera's heading. ✅ For ARWorldTrackingConfiguration, setting the custom view heading to zero and AR config worldAlignment = gravityAndHeading makes their headings aligned. More details: I tried many approaches for the custom view's heading. Euler Angle seems to be the most promising, but we don't know how to exactly interpret that vector. i) setting heading to zero, ii) setting heading to the most recent compass heading, iii) using AR camera’s eulerAngles, iv) tinkering with the transformation matrix. When I used the recorded data following Recording and Replaying AR Session Data tutorial, I found that the initial heading deflection is almost always the same value, no matter when the AR session becomes localized. My assumption is that - when the geo-tracking gets localized, it provides additional tracking information so the AR frame is somehow geo-referenced. In contrast, the world tracking doesn’t have anchors, thus using zero as initial heading is fine. Apple's WWDC demo in San Francisco seems to have hardcoded the orientation of the 3D text? From the public demo projects in the documentation, I didn't find a way to get the heading for ARGeoTrackingConfiguration.

FB13464160 Apple responded that this error is log noice, and will be removed in a future update.

Thanks for your response. That doesn't quite answer my question though. Before ARGeoTrackingConfiguration was available in ARKit 4, we used to use ARWorldTrackingConfiguration and a custom method to periodically calibrate/sync the location between the AR view and our 3D-map scene view, so our scene doesn't drift too much in regards to the AR camera feed, as the device move around 10+ meters. With the addition of ARGeoTrackingConfiguration and when street imagery/geo-anchors are available on the main streets, we now find the accuracy of ARFrame camera really good, resulting in smooth experience and much less calibration needed. 👍 However, when street imagery aren't available, say we move from a main street into a neighborhood, so the geo-tracking accuracy drops from medium to low or even undetermined, we need to fallback to something. The question is: should we fallback to a new session with ARWorldTrackingConfiguration and use our old periodic calibration approach, or should we keep using ARGeoTrackingConfiguration and add some custom calibration logic to compensate for the low/undetermined accuracy? It largely depends on if the session(_:didUpdate:) method in geo-tracking configuration always provides the accuracy as good as or better than world tracking. In other words, is geo-tracking a superset of features of world tracking in this regard? From our own ad-hoc testing, we cannot tell for sure. 🫤 It almost seems like when street imagery isn't available, geo-tracking's accuracy sometimes is worse than world tracking, though only by a small margin. Also we found that when geo-tracking is trying to re-localize using street imagery, the ARFrame's camera might be unstable for a short period. To sum up, we want to smoothly handle the case when geo-tracking starts to become unstable, or street imagery based geo-tracking is completely unavailable, to use custom logics to keep our scene aligned with the AR view. Is it possible to achieve it solely with a session configure with ARGeoTrackingConfiguration?

If you knows someone in a supported city listed here: https://developer.apple.com/documentation/arkit/argeotrackingconfiguration, refer to this article to get a recorded session data for testing: https://developer.apple.com/documentation/arkit/arsession/recording_and_replaying_ar_session_data

To add to the good summary by Brandon, here is a post on StackOverflow that further explains some advantages that ARCore (Google's equivalent of ARKit) have in terms of imagery anchors in real world: https://stackoverflow.com/questions/52893075/what-is-aranchor-exactly/52899502#52899502

I'm seeing this issue as well and I logged another post here.

The example code above shows our real workflow. It can be strip down to the version below. Dismiss the sheet by dragging down the page. import SwiftUI import WebKit struct ContentView: View { @State private var isInfoViewPresented = false var body: some View { Button { isInfoViewPresented = true } label: { Image(systemName: "info.circle") } .sheet(isPresented: $isInfoViewPresented) { ZStack { WebView(htmlString: "Hello World") WebView(htmlString: "Foo Bar") } } } } struct WebView: UIViewRepresentable { let htmlString: String func makeUIView(context: Context) -> WKWebView { return WKWebView(frame: .zero) } func updateUIView(_ webView: WKWebView, context: Context) { webView.loadHTMLString(htmlString, baseURL: nil) } }

This post may be helpful: https://stackoverflow.com/questions/63581114/mac-catalyst-version Think Mac Catalyst version as iOS version. https://developer.apple.com/support/xcode/ gives the deployment target version range for both iOS and macOS. You can map the Mac Catalyst versions back to macOS, or simply use the iOS version counterpart as a guesstimate.

You should be able to use: https://developer.apple.com/documentation/swiftui/view/fixedsize(horizontal:vertical:) with the horizontal parameter set to false. @Polyphonic Before I made this post, I've tried the fixedSize(horizontal:vertical:) modifier out on Xcode 15.0 beta 6 (15A5219j), and it has no effect, which was kind of unexpected. The segmented control is still tight on iOS 17 after it is applied. Here is the snippet where I want the segmented control to behave consistently among iOS 15, 16 and 17. .toolbar { ToolbarItem(placement: .principal) { Picker("Information Mode", selection: $informationMode) { ForEach(InformationMode.allCases, id: \.self) { mode in Text(mode.label) } } .pickerStyle(.segmented) // .fixedSize(horizontal: true, vertical: false) // has no effect on iOS 17 } }

Kevin, thanks for your response. That clears things up quite a bit. I'll try to summarize what I've learned here, as well as some lingering questions - feel free to correct. Learned My question in the original post was caused by the File system changes introduced in iOS 17 - iOS 17 will put the app bundle and its data container on different volumes. When url(for:in:appropriateFor:create:) creates an itemReplacementDirectory, it uses the volume from the appropriateFor url: parameter. Since the app bundle is on a different volume now, the method throws a file permission error. There are 2 kinds of temporary files - a) those will eventually end up in another destination, and b) those don't need to be kept around and will be purged with the temporary directory. in case a), the temporary file is intended to replace another file, say we want to modify the temporary copy and overwrite the original file, itemReplacementDirectory with url(for:in:appropriateFor:create:) is the most suitable API. in case b), the temporary file may be just an transitory output that we may read from, then throw away. NSTemporaryDirectory() and its equivalents are the most suitable. The itemReplacementDirectory has no guarantee to be under the tmp directory, and we should not rely on any folder structure of its parent directories, to recursively remove items, or whatever. Questions There are a couple of doc pages talking about temporary directories on Apple Developer Documentation. https://developer.apple.com/documentation/foundation/1409211-nstemporarydirectory https://developer.apple.com/documentation/foundation/filemanager/1642996-temporarydirectory https://developer.apple.com/documentation/foundation/filemanager/1407693-url https://developer.apple.com/documentation/foundation/filemanager/searchpathdirectory/itemreplacementdirectory On the 1st page, it says "see url(for:in:appropriateFor:create:) for the preferred means of finding the correct temporary directory". On the 3rd page discussion section, it says "You can use this method to create a new temporary directory." On the 4th page, it says "Pass this constant … to create a temporary directory." These docs were where the confusion really came from. It pushed us to use url(for:in:appropriateFor:create:) API in the first place, only later did we find out that API best suits a edit-and-move temp file (case a above), not for a use-and-throw temp file. Hope some distinction between these 2 usecases can be added to the doc's discussion. Two luxuries come with using url(for:in:appropriateFor:create:) with itemReplacementDirectory API are… a) it helps create the directory instead of us calling createDirectory manually, and b) it creates a subdirectory that is app-specific. This doesn't mean much on iOS, but as we are doing cross-platform apps/frameworks, this make macOS development easier. Besides, the item replacement directory always has the bundle name in part of its path components, which makes debugging easier. i.e., # NSTemporaryDirectory() file:///var/folders/09/qv7t964n5nv1zh6bqvzthlvc0000gp/T/ # itemReplacementDirectory file:///var/folders/09/qv7t964n5nv1zh6bqvzthlvc0000gp/T/TemporaryItems/NSIRD_MyProject_dNMkNh/ Indeed, we can easily create our own method to provide these capabilities, but it's always hard to say no to a native one-liner API that behaves almost exactly as we wanted. 😉

Edit: it seems for iOS 16+ there would be a different solution such as URL.temporaryDirectory. At the mean time, I'll apply what Quinn suggested. try! FileManager.default.url( for: .itemReplacementDirectory, in: .userDomainMask, appropriateFor: FileManager.default.urls(for: .documentDirectory, in: .userDomainMask).first, create: true )

Thank you Eskimo! Where do you ultimately plan to save your files? As the API semantically indicates, we want to create a temporary directory specific for the current user, for our own app, preferably with the app's display name in the path component so it is easier to look up when debugging. We don't really mind where the temporary directory is located; just want to be a good citizen, limit the files within our own subdirectory, and not to pollute the wider tmp folder, i.e., FileManager.default.temporaryDirectory. And we want to clean up the subfolder at a certain point. I have to apologize that I didn't scrutinize the doc (or fully understand its intricacy) of the url(for:in:appropriateFor:create:) API, and missed the "Only the volume of this parameter is used." part in the doc. Took it for granted for too long that iOS/macOS only uses 1 volume for user data storage. What is the recommended approach for creating a temporary directory? I think the url(for:in:appropriateFor:create:) is still the recommended API to use. Should I… Pass nil to the appropriateFor URL, and manually create a subdirectory using an UUID Use cachesDirectory instead of itemReplacementDirectory Use the system temp directory at FileManager.default.temporaryDirectory, and manually create a subdirectory using an UUID

As mentioned below, one workaround would be 1. close the project 2. use CLI or other tools to switch branch 3. open the project. In this way Xcode won't resolve the Swift packages again. But that doesn't help when someone uses Xcode's built-in Git client. Hope Xcode can add an option to allow manually resolve the packages when needed, just like the recent additions of "Clear All Issues" and "Clean Test Results".

We also experienced similar issue with Xcode 14.2. The screenshot below is directly captured from an iOS 16.2 iPhone 14 Pro Max Simulator. Cannot repro on other co-workers' environment. Additionally, the simctl status_bar command doesn't work since iOS 16.0 sims. Link to the screenshot: https://raw.githubusercontent.com/Esri/arcgis-maps-sdk-swift-samples/72f9a8fdbf859ca4c0dc5dd75119c4c2de2632ff/Shared/Samples/Sketch%20on%20the%20map/sketch-on-map-2.png

I have the same problem. It seems the sheet modifier gets stuck to the initial value of a state property and gets rendered with it. Unless the parent view redraws, the sheet will stay stagnant no matter how the state property changes.