I'm not sure if this will help you or not but I was having this issue and this post helped me out! https://developer.apple.com/forums/thread/13038 I was registering defaults (.register(defaults: ...) but it turns out those are only held in memory and aren't actually in persistent storage. So you just have to .set the defaults to get them to be stored persistently! My extension could read the values after that.

I was able to get in contact with Developer Technical Support. There's no real answer to this problem unfortunately as there is no public API. Here is what DTS said ⤵︎ Thanks for your patience. I am writing to confirm that there is currently no public API to get the metadata for an un-downloaded >iCloud file. If later on you believe that it has a significant negative impact for your app, please feel free to file a feedback >report for the relevant engineering team to evaluate. There is however a way to sort of get a working solution as suggested by DTS. You can automatically download the file from iCloud prior to reading its metadata but I wasn't keen on this solution. ⤵︎ var error: NSError? let fileCoordinator = NSFileCoordinator() // `theULR` should be the URL without the ‘.’ & ‘.icloud’ components. fileCoordinator.coordinate(readingItemAt: theURL, options: .withoutChanges, error: &error) { newURL in    print('\(newURL)') // Try to get the meta data here. } After fiddling with this I think the best solution, for now, is to not attempt to get any metadata that could be incorrect from a non-downloaded iCloud file.

@eskimo I'm afraid that doesn't help. Did you mean to grab it some other way? I tested it un-sandboxed too btw and the file kind appears normally but the size is still incorrect. I went into detail on what I've tried on Stack Overflow var fileResources: URLResourceValues? let keys: Set<URLResourceKey> = [ .localizedTypeDescriptionKey, .fileSizeKey, ] DispatchQueue.global(qos: .background).async { do { guard let resources = try self.url?.resourceValues(forKeys: keys) else { return } self.fileResources = resources } catch {} DispatchQueue.main.asyncAfter(deadline: .now() + 1) { print(self.fileResources?.localizedTypeDescription) print(self.fileResources?.fileSize) } }

For anyone scrolling past this post trying to figure out how to ignore the keyboard but maybe needs to maintain a Textfield's keyboard avoidance I did this ⤵ Scenario I needed to have a Text view sit at the bottom of a page and then have a Textfield in the middle that would be affected by the keyboard's size. Solution What I ended up doing was placing both the Text view and the Textfield into their own VStack's and then placed both VStack's in a ZStack. Then I simply added the .ignoresSafeArea(.keyboard) modifier to the bottom VStack containing the Text view. So it looked something like this ⤵ struct Home: View {   var body: some View { /** Placing all elements in a ZStack allow us to place a layer with the copyright info at the bottom, ignoring the keyboard safe area while still maintaining spacer flexibility on the user input layer. */ ZStack { /** Top content */ VStack(alignment: .center, content: { Spacer() Textfield("Textfield", text: $textObject) Spacer() }) /** Bottom Content */ VStack { Spacer() Text("Some Text") }.ignoresSafeArea(.keyboard) } } } Problems This solution isn't ideal because now the Textfield isn't reacting to the content in the View field. However, this solution will work well for some situations such as a login screen. I hope this helped someone! 😊 Edit You could also change the ZStack to a VStack and then place a Spacer().ignoresSafeArea(.keyboard) above the two inner VStack's. However, I found this creates weird behaviour occasionally as SwiftUI doesn't know what to space out as it'd technically have no where to go, but it some how still makes space. Maybe it's just ramming the stacks together and hoping for the best?