I have impemented NSFilePresenter presentedSubitem:at oldURL:didMoveTo newURL protocol method in a Mac app (Catalina 10.15.3 and Xcode 11.4.1) on a local drive without sandboxing. The method gets called correctly when a file within the presented directory gets moved.However, the two urls passed are formatted differently. OldURL "file:///System/Volumes/Data/...", while newURL is "file:///Users/...".func presentedSubitem(at oldURL: URL, didMoveTo newURL: URL) {
print(oldURL) // file:///System/Volumes/Data/Users/...
print(newURL) // file:///Users/...
}This creates the following issue: I keep a tree of nodes with file information and traverse the tree to search for the node of the oldURL. The URL's in the node is stored in a "file://Users/..." format and the url's aren't considered euqal.I've tried to compare the File Resource Identifier. However, oldURL's file resource identifier is nil.extension URL {
var identifier: NSObjectProtocol? {
return (try? resourceValues(forKeys: [.fileResourceIdentifierKey]))?.fileResourceIdentifier
}
static func &=(lhs: URL, rhs: URL) -> Bool {
guard let idl = lhs.identifier, let idr = rhs.identifier else {
assertionFailure("volume does not support resource identifiers") // oldURL.identifier = nil
return lhs == rhs
}
return idl.isEqual(idr)
}
}How do I compare two URLs where one has the prefix "file:///File/Volumes/Data/" and one has not in a fool proof way?
Post
Replies
Boosts
Views
Activity
I've implemented the NSFilePresenter protocol in a Mac app (Catalina 10.15.3 Xcode 10.15.3) to watch a directory.Most protocol methods get called correctly, but some don't get called at all. For some there are (cumbersome) alternatives, but if, for example a file is immediately deleted in Finder using option+command+del, the NSFilePresenter delegate never receives any callback. Is there a workaround to trigger the callbacks?final class FileController: NSObject, NSFilePresenter {
...
init() {
presentedItemURL = // Some directory
NSFileCoordinator.addFilePresenter(self)
}
func accommodatePresentedItemDeletion(completionHandler: @escaping (Error?) -> Void) {
// Never gets called
completionHandler(nil)
}
func presentedSubitemDidAppear(at url: URL) {
// Never gets called
}
func presentedSubitemDidChange(at url: URL) {
// Does get called
}
}
I've added an SVG image to the asset catalogue of a SwiftUI project in Xcode 12 beta 3, and set 'Render as' to 'original'.
The gradient background in the SVG image gets rendered in different ways depending on the platform.
In the Xcode's asset catalogue's preview, the gradient is rendered as a solid color
In the MacOS version of the SwiftUI app, the gradient appears as a solid color as well
In the iOS version of the SwiftUI app, the gradient appears as a solid white area.
I understand Xcode is in beta and not everything feature is working and I was wondering if this is an issue (assuming it is a bug) that will be fixed in an upcoming beta version, or if I should switch to a different file format for my images.
In a Xcode 12 beta 5 project on the DTK I see a "My Mac (Designed for iPad)" scheme in my iOS target. I'd like to run the app as an iPhone app on the DTK instead. How do I either add a "My Mac (Designed for iPhone)" scheme or edit the Designed for iPad scheme to iPhone?
My Safari Extension on iOS needs access to a Keychain item (password) that is secured by the userPresence and devicePasscode flag. In other words, FaceID/TouchID or the device PIN is necessary to access the password.
Is there a way for the extension to access the password?
SafariWebExtensionHandler.swift has access to the Keychain, but can't present FaceID/TouchID/device PIN interface to the user. Popup.js has UI access, but can't access the iOS Keychain.
One hack is to set touchIDAuthenticationAllowableReuseDuration of the Keychain item to an arbitrary time and have the user authenticate in the containing app.
However, in case of a time-out, the containing app has be opened by the extension with a custom URL scheme. openURL is not accessible in SafariWebExtensionHandler.swift either (I assume it can be handled by popup.js). This is a user-unfriendly solution. What is the best way to give the Safari extension access to a Keychain item?
It seems that the mail app sets its mail headers after additionalHeaders(for:) is called, overwriting standard headers set by the extension, such as Content-Type.
It also seems the Mail app decides whether an email is of content type text/plain or multipart/alternative; boundary="Apple-Mail=[...]" based on the user input. If the user only inputs plain text (i.e. using no font formatting options or adding an attachment) then Content-Type will always default to text/plain.
This causes an issue in encode(_:, composeContext:) if the signature should be included as an attachment. First of all, it seems impossible to force Mail to set Content-Type to multipart/alternative and even if the message is set to multipart/alternative (e.g. b/c the user made text bold), the ecode method doesn't know the boundary string set by Apple mail (Apple-Mail=[hash]).
Is there a way to create an attachment in encode?