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.

In case anyone found this thread, here is an issue we found in Xcode 14.1. In the past we can add a local Swift package by dragging in the enclosing folder of the package manifest, and then add it to the "Frameworks, Libraries, and Embedded Content" section. The local package will appear under "Workspace" section. We found that it works fine in Xcode 14.0.1, but in Xcode 14.1, the "Workspace" section disappears. Projects created prior to Xcode 14.1 still works and the framework shows up just fine in "Frameworks, Libraries, and Embedded Content". But if I remove the package from it and try to add it back, it doesn't show up. This might be a bug in Xcode, or something has changed in the requirement of a local Swift package, we are still looking into it.

Will keep an eye on this thread. It would be helpful to allow specifying custom sub path other than /documentation/ render correctly without --hosting-base-path being set to a specific sub path

In my case I got the local package open in another window. In the past it will give a more specific error saying the package is open, but now it doesn't.