Try adding this to your Info.plist: <key>NSAppTransportSecurity</key> <dict> <key>NSAllowsArbitraryLoads</key> <true/> </dict>

Are these resources from an 'arbitrary' url and/or do you allow loads of them?

Thanks for the quick reply; I suspect my storeBookmark() isn't working? I'd appreciate if you could comment specifically but it mimics or identical to other samples I've read.#2 is related to the #1; my sandbox bookmark function is not working: func storeBookmark(url: URL, options: URL.BookmarkCreationOptions = [.withSecurityScope,.securityScopeAllowOnlyReadAccess]) -> Bool { guard isSandboxed() else { return false } // Peek to see if we've seen this key before if let data = bookmarks[url] { if self.fetchBookmark((key: url, value: data)) { Swift.print ("= \(url.absoluteString)") return true } } do { let data = try url.bookmarkData(options: options, includingResourceValuesForKeys: nil, relativeTo: nil) bookmarks[url] = data return self.fetchBookmark((key: url, value: data)) } catch let error { NSApp.presentError(error) Swift.print ("Error storing bookmark: \(url)") return false } }#3, I'm concerned what I get from the pasteboard is currently a string not a URL? so fabricating one I wasn't sure was 'bonafide' as one from open/save? I had read a comment you want to use such dialog urls "as-is". I suspect I need to have such a URL from the pasteboard not my fabrication.I totally agree with your commmentary re: unstructured directories; I want to localize as much as possible where they're going.The best I think of is the reason I took to trying to bookmark the enclosing directory. This however throws a file not found dialog on the diretory - as a file (?), so again I suspect my `storeBookmark()` is at fault as I'm suspecting something should be different when the URL is directory.

Ah, yeah, I fully understand what you're saying; btw I'd fixed (not posted yet) my store issue leaving only this "html" issue to deal with; a current nit, IMHO. <SoapBox> in the current implementation of loadFileURL() the accessReadURL should be dealing with this right out of the api; can't otherwise imagine its use, so this is in essence a temporary workaround (I'd be glad to tear out when possible).Yes, the URLs are coming from open panel or drags; yes they're URL's ready to eat, but as a doc based app whose contents would be sourced by these URLs, how else - other than save/restore would document restoration work? I would rather be cautious than not, but not to the extent of 123 etc dialogs, just a single; if there's content outside of that, that too bad.So, while chasing down each and every bit from an .html is not workable, I wanted to attempt present 1 and one 1 extra iFF html content is found - uti query for the 'accessReadURL'.Hopefully this isn't too much of a hassle, but in presenting the 2nd dialog, is there no way to just have the user confirm the base URL via a new open panel - maybe via an acessory panel if I establish a delegate?if url.isFileURL { var baseURL = url // make them authorize the entire directory if isSandboxed(), url.hasHTMLContent() { let openPanel = NSOpenPanel() openPanel.message = "Authorize access to " + baseURL.lastPathComponent openPanel.prompt = "Authorize" openPanel.allowsMultipleSelection = false openPanel.canChooseFiles = false openPanel.canChooseDirectories = true openPanel.canCreateDirectories = false openPanel.directoryURL = baseURL.deletingLastPathComponent() openPanel.begin() { (result) -> Void in if (result == NSApplication.ModalResponse.OK) { if let authURL = openPanel.url { if self.storeBookmark(url: authURL) { baseuRL = authURL } else { Swift.print("Yoink, unable to sandbox base \(authURL)") } } } } } ///webView.load(URLRequest.init(url: url)) webView.loadFileURL(url, allowingReadAccessTo: baseURL)I've seen apps request this sort of affirmation and I think if similar re: this folder authenication, that might be the way to go; otherwise these html will have to be rendered assetless.

Rather curious to have this slip thru QA

"... How can it be that Apple releases an IDE product where such a basic function..." Not a unit test issue but cross functional testing - Safari ?

I should not that this app is already on the store now, it's just Big Sur execution fails to call my declared handler: func applicationWillFinishLaunching(_ notification: Notification) { 		NSAppleEventManager.shared().setEventHandler( 		self, 		andSelector: #selector(AppDelegate.handleURLEvent(_:withReply:)), 		forEventClass: AEEventClass(kInternetEventClass), 		andEventID: AEEventID(kAEGetURL) 		) }

I have this same problem but macOS (11.1) Xcode 12.0 (17219); which begin on Big Sur in app review, and since I updated and trying to triage what's new / different / required. Trying to launch host app via custom URL.

I got side tracked but with few exceptions, these sub-projects I had exported to GitHub from their origins when they were self contained within their original app I'm now returning to. All was nice and simple. I mused just putting them back, within the app, but that seemed like a bad move, backward, just like using an older system / build environment which last worked and just continue there. One sub-project in particular - CocoaAsyncSocket, appears to have made the grade to SPM, so I'm wading towards that path for the others(6). Aside from explicit dependency entry in build settings, the subject of header resolution leads me to think that perhaps I shouldn't have or use such explicit inclusions, as otherwise the SPM and its definitions (headers) should be treated like any framework - black box?

I neglected to mention this is MacOS, where resources re: the new view are pretty sparse, but thanks.