objcjs-types 0.3.0 → 0.5.0

package/dist/FileProvider/NSFileProviderReplicatedExtension.d.ts

@@ -1,9 +1,9 @@
-import type { NobjcObject } from "objc-js";
 import type { _NSFileProviderDomain } from "./NSFileProviderDomain.js";
 import type { _NSFileProviderEnumerating } from "./NSFileProviderEnumerating.js";
 import type { _NSFileProviderItem } from "./NSFileProviderItem.js";
 import type { _NSFileProviderItemVersion } from "./NSFileProviderItemVersion.js";
 import type { _NSFileProviderRequest } from "./NSFileProviderRequest.js";
+import type { _NSError } from "../Foundation/NSError.js";
 import type { _NSProgress } from "../Foundation/NSProgress.js";
 import type { _NSString } from "../Foundation/NSString.js";
 import type { _NSURL } from "../Foundation/NSURL.js";
@@ -21,33 +21,33 @@ export interface _NSFileProviderReplicatedExtension extends _NSFileProviderEnume
     /**
      * Fetch the metadata for the item with the provider identifier. Error cases: ------------ If the metadata lookup fails because the item is unknown, the call should fail with the NSFileProviderErrorNoSuchItem error. In that case, the system will consider the item has been removed from the domain and will attempt to delete it from disk. In case that deletion fails because there are local changes on this item, the system will re-create the item using createItemBasedOnTemplate. The extension can also report the NSFileProviderErrorNotAuthenticated, NSFileProviderErrorServerUnreachable in case the item cannot be fetched because of the current state of the system / domain. In that case, the system will present an appropriate error message and back off until the next time it is signalled. Any other error, including crashes of the extension process, will be considered to be transient and will cause the lookup to be retried. Errors must be in one of the following domains: NSCocoaErrorDomain, NSFileProviderErrorDomain. For errors which can not be represented using an existing error code in one of these domains, the extension should construct an NSError with domain NSCocoaErrorDomain and code NSXPCConnectionReplyInvalid. The extension should set the NSUnderlyingErrorKey in the NSError's userInfo to the error which could not be represented. Cancellations: ------------ If the NSProgress returned by this method is cancelled, the extension should call the completion handler with (nil, NSUserCancelledError) in the NSProgress cancellation handler. Execution time: --------------- This method is not expected to take more than a few seconds to complete the retrieval of the metadata of the item. If the operation may not complete in a reasonable amount of time because, for instance, of bad network conditions, it is recommended to report an error (for instance NSFileProviderErrorServerUnreachable). The system will call `cancel` on the progress if the operation takes too much time. The extension is then expected to quickly call the completion handler.
      */
-    itemForIdentifier$request$completionHandler$?(identifier: _NSString, request: _NSFileProviderRequest, completionHandler: NobjcObject | null): _NSProgress;
+    itemForIdentifier$request$completionHandler$?(identifier: _NSString, request: _NSFileProviderRequest, completionHandler: ((arg0: _NSFileProviderItem, arg1: _NSError) => void) | null): _NSProgress;
     /**
      * Download the item for the given identifier and return it via the completion handler. The system learns of items through enumerations. Initially, this means that the system is aware that an item (with a specific version) exists on the device. When the user accesses the item, the system makes a request for the contents of the item. The provider can then fulfill the request by providing the item. The system takes ownership of the item and will move it out of the sandbox of the provider. If the provider wishes to force materialization of a given item, the provider should use `-[NSFileProviderManager requestDownloadForItemWithIdentifier:requestedRange:completionHandler:]`, or configure the `-[NSFileProviderItem contentPolicy]`. The requestedVersion parameter specifies which version should be returned. A nil value means that the latest known version should be returned. Except for the error case, the version of the returned item is assumed to be identical to what was requested. requestedVersion is currently always set to nil. Concurrent Downloads: ---------- The system will call fetchContents concurrently if there are multiple outstanding file download requests. The provider can control the concurrency by setting the key NSExtensionFileProviderDownloadPipelineDepth in the Info.plist of the extension to the number of concurrent downloads that the system should create per domain. This number must be between 1 and 128, inclusive. File ownership: --------------- The retrieved content at `fileContents` URL must be a regular file on the same volume as the user-visible URL. A suitable location can be retrieved using -[NSFileProviderManager temporaryDirectoryURLWithError:]. The system clones and unlinks the received fileContents. The extension should not mutate the corresponding file after calling the completion handler. If the extension wishes to keep a copy of the content, it must provide a clone of the that content as the URL passed to the completion handler. In case the extension or the system crashes between the moment the completion handler is called and the moment the system unlinks the file, the file may unexpectedly still be on disk the next time an instance of the extension is created. The extension is then responsible for deleting that file. Disallowing processes from fetching items: --------------- The system automatically downloads files on POSIX accesses. The extension may wish to disallow this class of downloads for specific applications. The extension can set an array of strings into the UserDefault key "NSFileProviderExtensionNonMaterializingProcessNames". A process whose executable's filename on disk is an exact match for an entry in this array will not be allowed to fetch items in the extension's domains. The comparison is case sensitive. In macOS 11.0 and later, this list will be checked when a download is initiated through a POSIX filesystem call. In macOS 11.4 and later, this list will also be checked for downloads initiated through file coordination. Error cases: ------------ If the download fails because the item was deleted on the server, the call should fail with the NSFileProviderErrorNoSuchItem error. In that case, the system will consider the item has been removed from the domain and will attempt to delete it from disk. In case that deletion fails because there are local changes on this item, the system will re-create the item using createItemBasedOnTemplate, passing the NSFileProviderCreateItemDeletionConflicted flag. If the user does not have access to the content of the file, the provider can fail the call with NSCocoaErrorDomain and code NSFileReadNoPermissionError. That error will then be presented to the user. The extension can also report the NSFileProviderErrorNotAuthenticated, NSFileProviderErrorServerUnreachable in case the item cannot be fetched because of the current state of the system / domain. In those cases, the system will present an appropriate error message and back off until the next time it is signalled. Any other error, including crashes of the extension process, will be considered to be transient and will cause the download to be retried. Errors must be in one of the following domains: NSCocoaErrorDomain, NSFileProviderErrorDomain. For errors which can not be represented using an existing error code in one of these domains, the extension should construct an NSError with domain NSCocoaErrorDomain and code NSXPCConnectionReplyInvalid. The extension should set the NSUnderlyingErrorKey in the NSError's userInfo to the error which could not be represented. Cancellations: ------------ If the NSProgress returned by this method is cancelled, the extension should call the completion handler with (nil, nil, NSUserCancelledError) in the NSProgress cancellation handler. The returned NSProgress is used to show progress to the user. If the user cancels the fetch, the extension should stop fetching the item, as it is no longer required. Execution time: --------------- The system will grant enough time to the extension to download the file. The system will interrupt the call if it stops making progress or if download takes an unexpectedly long time. In that case, the system will call `cancel` on the progress. The extension is then expected to quickly call the completion handler.
      */
-    fetchContentsForItemWithIdentifier$version$request$completionHandler$?(itemIdentifier: _NSString, requestedVersion: _NSFileProviderItemVersion | null, request: _NSFileProviderRequest, completionHandler: NobjcObject | null): _NSProgress;
+    fetchContentsForItemWithIdentifier$version$request$completionHandler$?(itemIdentifier: _NSString, requestedVersion: _NSFileProviderItemVersion | null, request: _NSFileProviderRequest, completionHandler: ((fileContents: _NSURL, item: _NSFileProviderItem, error: _NSError) => void) | null): _NSProgress;
     /**
      * Create a new item. The itemTemplate object describes the expected state of the newly created item, including its location provided by parentItemIdentifier and filename. The list of fields to conside in that object is defined by the fields parameter. Fields not listed should be considered as not being defined. The url is used to transfer the content of the file from the system to the extension. It can be nil if the item has no content. This will be the case if the item is a folder or if the item is being reimported (flag NSFileProviderCreateItemMayAlreadyExist set) and the file is dataless on disk. If the item is a symbolic link, the target path is provided by the symlinkTargetPath of the itemTemplate. The system is setting the itemIdentifier of the itemTemplate to a unique value that is guaranteed to stay the same for a given item in case the creation is replayed after a crash. That itemIdentifier is not intended to be the identifier assigned to the item by the provider. In the completion block, the createdItem is expected to reflect the properties of the newly created item, which usually means matching the properties passed in by the template. An exception is the itemIdentifier which should be the identifier assigned to that item by the provider rather than the identifier passed in through the template. If the provider reuses an existing identifier, the item that used that identifier will be removed from disk, replaced by the createdItem. If the item is a directory, the two directories will be merged and the items from the existing one will be modified with the NSFileProviderModifyItemMayAlreadyExist option set. If the provider is not able to apply all the fields at once, it should return a set of stillPendingFields in its completion handler. In that case, the system will attempt to modify the item later by calling modifyItem with those fields. The filename and contents fields should be synced together. If synced independently, files may appear corrupted on other devices, due to a mismatch between the file extension and the actual file data. If a field in the returned createdItem does not match the itemTemplate, and is not in the list of stillPendingFields, the value from the createdItem will be propagated to the disk. If the content of the item as described by createdItem does not match the content from url, the provider should set shouldFetchContent in the completion handler. The content from the provider will then be fetched and propagated to disk. In case the deletion of an item from the working set could not be applied to the disk by the system because it conflicted with a local edit of the file, the system will attempt to create the edited item. In that case the creation call will receive the NSFileProviderCreateItemDeletionConflicted option and the itemIdentifier in the template will be set to the itemIdentifier of the item deleted from the working set. The itemVersion will also be set to the last itemVersion of the item that was made available on disk before the item was edited locally. If such a conflict happens on a dataless item on disk, the item will be immediately deleted from the disk instead of issuing a new creation. In case the NSFileProviderCreateItemMayAlreadyExist option is passed, the content may be nil if the item is found by the system without any associated content. In that case, you should return a nil item if you are not able to match the created item with an existing item from the provider. In case of path collision with an already existing item, the provider can either fail using -[NSError (NSFileProviderError) fileProviderErrorForCollisionWithItem:] or resolve the collision by itself (e.g. by returning an item with a different name). If the error is returned, the system will try to resolve the collision by itself by bouncing away one of the items (renaming the item). If the imported item is refused by the extension, it should return nil for the createdItem without any error. In that case, the source item will be deleted from disk. In case the item represents a directory, the content will be deleted recursively. If the extension does not wish to sync the item, while still keeping the item on disk, on macOS 13.0, iOS 16.0, and later, it should return `NSFileProviderErrorExcludedFromSync` on the completion handler. For more details, see the header comment for that error code. On earlier versions of macOS, where `NSFileProviderErrorExcludedFromSync` is unavailable, the extension could choose to respond to FileProvider API calls as if the item is synced to it's server, but the extension only tracks the item in it's own local database on the device. The extension must be careful to respond to all FileProvider API calls as if the file is really synced to it's server, including enumerations of the parent directory of that item, itemForIdentifier calls, etc. The progress returned by createItemBasedOnTemplate is expected to include the upload progress of the item and will be presented in the user interface until the completion handler is called. Creation is gated by the NSFileProviderItemCapabilitiesAllowsAddingSubItems capability on the parent folder on a UI level, but direct file system changes (e.g. from Terminal) can still result in changes that must be handled. Structural consistency: ----------------------- The system guarantees that the creation is called after the creation of the parent completed. File ownership: --------------- The file at `url` is owned by the system and is unlinked after the completion handler is called. If the extension wishes to keep access to the content of file after calling the completion handler, it should clone the file in its container. Atomicity: ---------- By default, the system assumes all the changes are applied non-atomically, which means that the change or an intermediary state from the change can be observed (for instance while enumerating the working set) while the call is in progress (before the completion handler is called). The provider can indicate to the system that it applies changes atomically (that is, the change cannot be observed before the completion handler is called) by setting the key NSExtensionFileProviderAppliesChangesAtomically in the Info.plist of the extension to YES. The atomicity declaration only describes the visibility of the changes, not the ability of the provider to apply all the fields at once: a provider that applies changes atomically might still apply a subset of the changedFields communicated by the system and defer the remaining fields by setting the stillPendingFields parameter in the completion handler. Error cases: ------------ If the creation fails because the target directory does not exist, the extension must fail the creation using the NSFileProviderErrorNoSuchItem error code. In that case, the system will attempt the re-create the parent directory. In case the location of the new item is already in use by another item, the extension can chose to either resolve the collision by moving one of the items away, or reject the creation with the NSFileProviderErrorFilenameCollision error code. In that error case, the system will be responsible for resolving the collision, by renaming one of the colliding items. When the collision is resolved, the system will call createItemBasedOnTemplate again. The extension can also report NSFileProviderErrorNotAuthenticated, NSFileProviderErrorCannotSynchronize, or NSFileProviderErrorExcludedFromSync, in case the modification cannot be applied because of the current state of the system / domain. In that case, the system will present an appropriate error message and back off until the next time it is signalled. The provider can signal the error resolution by calling signalErrorResolved:completionHandler:. Any other error, including crashes of the extension process, will be considered to be transient and will cause the creation to be retried. Errors must be in one of the following domains: NSCocoaErrorDomain, NSFileProviderErrorDomain. For errors which can not be represented using an existing error code in one of these domains, the extension should construct an NSError with domain NSCocoaErrorDomain and code NSXPCConnectionReplyInvalid. The extension should set the NSUnderlyingErrorKey in the NSError's userInfo to the error which could not be represented. Cancellations: ------------ If the NSProgress returned by this method is cancelled, the extension should call the completion handler with (nil, [], NO, NSUserCancelledError) in the NSProgress cancellation handler. Execution time: --------------- The system will grant enough time to the extension to upload the file if content is passed to the call, otherwise the call is expected to completed within a few seconds. The system will interrupt the call if it stops making progress or if upload takes an unexpectedly long time. In that case, the system will call `cancel` on the progress. The extension is then expected to quickly call the completion handler.
      */
-    createItemBasedOnTemplate$fields$contents$options$request$completionHandler$?(itemTemplate: _NSFileProviderItem, fields: NSFileProviderItemFields, url: _NSURL | null, options: NSFileProviderCreateItemOptions, request: _NSFileProviderRequest, completionHandler: NobjcObject | null): _NSProgress;
+    createItemBasedOnTemplate$fields$contents$options$request$completionHandler$?(itemTemplate: _NSFileProviderItem, fields: NSFileProviderItemFields, url: _NSURL | null, options: NSFileProviderCreateItemOptions, request: _NSFileProviderRequest, completionHandler: ((createdItem: _NSFileProviderItem, stillPendingFields: NSFileProviderItemFields, shouldFetchContent: boolean, error: _NSError) => void) | null): _NSProgress;
     /**
      * Informs the provider that an item or its metadata have changed. More than one property may have changed, e.g. an item may have been renamed, moved and also changed contents, in which case changedFields might contain [.contents, .filename, .parentItemIdentifier, .contentModificationDate]. If the provider is not able to apply all the fields at once, it should return a set of stillPendingFields in its completion handler. In that case, the system will attempt to modify the item later by calling modifyItem with those fields. The filename and contents fields should be synced together. If synced independently, files may appear corrupted on other devices, due to a mismatch between the file extension and the actual file data. Starting in macOS 12.0, if the set of stillPendingFields returned by the provider is identical to the set of fields passed to modifyItem, then the system will consider that these fields are not supported by the provider. The system will not send these fields to the provider again, until the item is modified. If a field in the returned item does not match the itemTemplate, and is not in the list of stillPendingFields, the value from the item will be propagated to the disk. In case there is a content change and the content of the returned item as described by item does not match the content from url, the provider should set shouldFetchContent in the completion handler. The content from the provider will then be fetched and propagated to disk. If the item modification results from the parent directory being merged into another directory, the NSFileProviderModifyItemMayAlreadyExist flag will be passed to the call. The provider can chose to merge two existing items when receiving modifyItem. In that case, the item returned should carry the itemIdentifier of the item with which the item will be merged and well as the resulting state of that item. The system will then keep one of the items (the one whose itemIdentifier was returned) and remove the other one from disk. In case of directories, the content of the two directories is merged and sub-items will be modified with the NSFileProviderModifyItemMayAlreadyExist flag set. If the extension wishes the modify item to cause the deletion of the item on disk, it can call the completion handler with nil in place of the resulting item. If the item is directory, the item will be kept on disk until all its children has been deleted from the working set. The system will only apply the deletion on the disk if this does not conflict with local edits. Otherwise, the system will attempt to re-create the item with the NSFileProviderCreateItemDeletionConflicted option set. The progress returned by modifyItem is expected to include the upload progress if any, even if the provider chose to call the completion handler before the upload finishes. For example, the provider might decide to call the completion handler as soon as the metadata have been stored in a local database. Modifications are gated by the corresponding capabilities of the item on a UI level, but direct file system changes (e.g. from Terminal) can still result in changes that must be handled. Conflict resolution: ------------------- The system passes a `baseVersion` parameter to the modifyItem call. This baseVersion describes the latest version of the file which was reflected on disk. This parameter can be used to detect conflicts with remote edits. For instance, if content version A of the file was downloaded to the local system, and the content was modified locally, the modifyItem call will receive baseVersion of A. If the server has in the meantime received another content edit of the same file, the server may have content version C. In this case, the extension can detect the mismatching baseVersion, and decide how to resolve the conflict. The extension informs the system of how it wishes to resolve the conflict by returning the resolved metadata on the completion handler. As an example resolution, if the extension informs that it wishes for the remote version of the item to be on disk (and to ignore the local edits), it should return the new contentVersion in the completion handler's item. The system will subsequently call fetchContents to retrieve the new contents and replace them on disk. The `baseVersion` might contain one or both component set to `+[NSFileProviderItemVersion beforeFirstSyncComponent]`, in case there has never been a version for which the item on disk and the item in the provider were known to be in sync. Structural consistency and Cycle handling: ------------------------------------------ In case the parentItemIdentifier is modified, the system guarantees that the new parent has been created and the creation completed before the call to modifyItem is issued. The system guarantees that modifyItem called after local changes from the user will never create a cycle: that is all items will always be a descendent of either the root item or the trash item. However, cycles that are caused by concurrent local changes by the user and changes on the remote server can also create cycles. This is handled by the system as a conflict. This means the provider must validate that the call of modifyItem is not creating a cycle with a change it observed from the server. If such a cycle is detected, the provider must fix the conflict by breaking the cycle, and return the state of the item after resolving that conflict. If the resolution affects other items as well, updates for those other items must be published on the working set. File ownership: --------------- The file at `url` is owned by the system and is unlinked after the completion handler is called. If the extension wishes to keep access to the content of file after calling the completion handler, it should clone the file in its container. Atomicity: ---------- By default, the system assumes all the changes are applied non-atomically, which means that the change or an intermediary state from the change can be observed (for instance while enumerating the working set) while the call is in progress (before the completion handler is called). The provider can indicate to the system that it applies changes atomically (that is, the change cannot be observed before the completion handler is called) by setting the key NSExtensionFileProviderAppliesChangesAtomically in the Info.plist of the extension to YES. The atomicity declaration only describes the visibility of the changes, not the ability of the provider to apply all the fields at once: a provider that applies changes atomically might still apply a subset of the changedFields communicated by the system and defer the remaining fields by setting the stillPendingFields parameter in the completion handler. Error cases: ------------ The extension may fail the modification if the modified item does not exist anymore. In that case, the extension should fail the call the NSFileProviderErrorNoSuchItem error code. The system will attempt to delete the item on disk. If the item on disk actually has changes since this call to modifyItem, then it will be re-created by a call to createItemBasedOnTemplate. Likewise, if the item is reparented to a parent that no longer exists, the extension may return a NSFileProviderErrorNoSuchItem error with the parent item. In case the modification updates the location of the item and another item is already known at this location, the extension can chose to either resolve the collision by moving one of the items away, or reject the modification with the NSFileProviderErrorFilenameCollision error code. In that error case, the system will be responsible for resolving the collision, by renaming one of the colliding items. When the collision is resolved, the system will call modifyItem again. In case the NSFileProviderModifyItemFailOnConflict option is passed, the provider should fail the modification if the baseVersion does not match the version on the server. It will be up to the system to merge the conflict and call modifyItem again with an updated baseVersion. The extension can also report NSFileProviderErrorNotAuthenticated, NSFileProviderErrorCannotSynchronize, or NSFileProviderErrorExcludedFromSync, in case the modification cannot be applied because of the current state of the system / domain. In that case, the system will present an appropriate error message and back off until the next time it is signalled. The provider can signal the error resolution by calling signalErrorResolved:completionHandler:. Any other error, including crashes of the extension process, will be considered to be transient and will cause the modification to be retried. Errors must be in one of the following domains: NSCocoaErrorDomain, NSFileProviderErrorDomain. For errors which can not be represented using an existing error code in one of these domains, the extension should construct an NSError with domain NSCocoaErrorDomain and code NSXPCConnectionReplyInvalid. The extension should set the NSUnderlyingErrorKey in the NSError's userInfo to the error which could not be represented. Cancellations: ------------ If the NSProgress returned by this method is cancelled, the extension should call the completion handler with (nil, [], NO, NSUserCancelledError) in the NSProgress cancellation handler. Execution time: --------------- The system will grant enough time to the extension to upload the file if content is passed to the call, otherwise the call is expected to completed within a few seconds. The system will interrupt the call if it stops making progress or if upload takes an unexpectedly long time. In that case, the system will call `cancel` on the progress. The extension is then expected to quickly call the completion handler.
      */
-    modifyItem$baseVersion$changedFields$contents$options$request$completionHandler$?(item: _NSFileProviderItem, version: _NSFileProviderItemVersion, changedFields: NSFileProviderItemFields, newContents: _NSURL | null, options: NSFileProviderModifyItemOptions, request: _NSFileProviderRequest, completionHandler: NobjcObject | null): _NSProgress;
+    modifyItem$baseVersion$changedFields$contents$options$request$completionHandler$?(item: _NSFileProviderItem, version: _NSFileProviderItemVersion, changedFields: NSFileProviderItemFields, newContents: _NSURL | null, options: NSFileProviderModifyItemOptions, request: _NSFileProviderRequest, completionHandler: ((item: _NSFileProviderItem, stillPendingFields: NSFileProviderItemFields, shouldFetchContent: boolean, error: _NSError) => void) | null): _NSProgress;
     /**
      * Delete an item forever. This is called when the user deletes an item that was already in the Trash and the item should no longer appear there after this call. This call should remove the item from the working set. This call receives an optional baseVersion which represent the version of the item we are trying to delete. Unless the NSFileProviderDeleteItemRecursive options is passed, the deletion of a directory should be non-recursive. If the deletion is recursive the provider should take care of reporting the deletion of all the deleted items through the working set. Delete is gated by the capabilities of the removed item with NSFileProviderItemCapabilitiesAllowsDeleting. Modifications are gated by NSFileProviderItemCapabilitiesAllowsDeleting of the item on a UI level, but direct file system changes (e.g. from Terminal) can still result in changes that must be handled. Atomicity: ---------- By default, the system assumes all the changes are applied non-atomically, which means that the change or an intermediary state from the change can be observed (for instance while enumerating the working set) while the call is in progress (before the completion handler is called). The provider can indicate to the system that it applies changes atomically (that is, the change cannot be observed before the completion handler is called) by setting the key NSExtensionFileProviderAppliesChangesAtomically in the Info.plist of the extension to YES. Error cases: ------------ The extension may fail the deletion in different scenarios, for instance because the baseVersion is out of date or because the user does not have permissions to delete the item. In that case the extension should fail the call with the NSFileProviderErrorDeletionRejected error code which will cause the system to re-create the deleted item on disk based on the latest metadata available from the extension. If the options don't include NSFileProviderDeleteItemRecursive and the deletion targets a non-empty directory, the extension must reject the deletion with the NSFileProviderErrorDirectoryNotEmpty error code. This error can also be reported in case some children of the directory cannot be deleted when receiving the NSFileProviderDeleteItemRecursive option. In both cases, the system will re-create the deleted item on disk based on the latest metadata available from the extension. If the deletion targets an item that is unknown from the extension because that item may have already been deleted remotely, then the extension should report a success. The extension can also report the NSFileProviderErrorNotAuthenticated, NSFileProviderErrorServerUnreachable, or NSFileProviderErrorCannotSynchronize in case the deletion cannot be applied because of the current state of the system / domain. In that case, the system will present an appropriate error message and back off until the next time it is signalled. Any other error, including crashes of the extension process, will be considered to be transient and will cause the deletion to be retried. Errors must be in one of the following domains: NSCocoaErrorDomain, NSFileProviderErrorDomain. For errors which can not be represented using an existing error code in one of these domains, the extension should construct an NSError with domain NSCocoaErrorDomain and code NSXPCConnectionReplyInvalid. The extension should set the NSUnderlyingErrorKey in the NSError's userInfo to the error which could not be represented. Cancellations: ------------ If the NSProgress returned by this method is cancelled, the extension should call the completion handler with (NSUserCancelledError) in the NSProgress cancellation handler. Execution time: --------------- This call is not expected to take more than a few seconds to complete. The system will interrupt the call if it stops making progress or if the deletion takes an unexpectedly long time. In that case,the system will call `cancel` on the progress. The extension is then expected to quickly call the completion handler.
      */
-    deleteItemWithIdentifier$baseVersion$options$request$completionHandler$?(identifier: _NSString, version: _NSFileProviderItemVersion, options: NSFileProviderDeleteItemOptions, request: _NSFileProviderRequest, completionHandler: NobjcObject | null): _NSProgress;
+    deleteItemWithIdentifier$baseVersion$options$request$completionHandler$?(identifier: _NSString, version: _NSFileProviderItemVersion, options: NSFileProviderDeleteItemOptions, request: _NSFileProviderRequest, completionHandler: ((arg0: _NSError) => void) | null): _NSProgress;
     /**
      * Signal the end of import of on-disk items. This is called after a reimport of on-disk items has been triggered by either `-[NSFileProviderManager reimportItemsBelowItemWithIdentifier:completionHandler:]` or after a new domain is created using `+[NSFileProviderManager importDomain:fromDirectoryAtURL:completionHandler:]` or `+[NSFileProviderManager addDomain:completionHandler:]`. `reimport` can also be started by the system independently from any request by the provider. The provider can detect those events by monitoring `-[NSFileProviderDomain backingStoreIdentity]`. During import, found items will be created via the -[NSFileProviderExtension createItemBasedOnTemplate:fields:contents:options:completionHandler:] call with the NSFileProviderCreateItemMayAlreadyExist flag set. At the end of an import the -[NSFileProviderExtension importDidFinishWithCompletionHandler:] is called. The system will attempt to import items as they are accessed by the user or applications. Import of the other items is scheduled by the system as a background task. That task may be delayed, for instance in low-power situations, or when the system is under heavy load. The provider can force the system to process a folder and its direct children by issuing a coordination request on that folder. Execution time: --------------- This call is not expected to take more than a few seconds to complete.
      */
-    importDidFinishWithCompletionHandler$?(completionHandler: NobjcObject): void;
+    importDidFinishWithCompletionHandler$?(completionHandler: () => void): void;
     /**
      * Called by the system if the set of materialized items changes. Materialized items are items that have synced to disk and are not dataless. They may contain a mix of dataless and materialized files and directories, but in any case, all their children are represented on disk. Traversals of dataless directories by applications trigger an enumeration against the file provider extension; traversals of materialized directories do not. It is the responsability of the file provider extension to notify the system on remote changes of these files: there is no alternative cache invalidation mechanism. If the extension doesn't keep track of the materialized set, it will have to notify the system of all remote changes. In that case the working set is the entire dataset. The system may drop items whose parent isn't materialized, to avoid unnecessary disk usage. This saves some I/O, but isn't optimal. The filtering by parentItemIdentifier is better done in the extension; ideally, it would even be done server-side. A hybrid model is possible, where some filtering is done server-side, and some finer filtering is done client-side. The file provider extension should therefore keep a list of the identifiers of the materialized directories. This method is called when a new directory is materialized or when a materialized directory is rendered dataless. To enumerate the set of materialized containers, - Call -enumeratorForMaterializedItems on the instance of NSFileProviderManager corresponding to your domain; - Implement the NSFileProviderEnumerationObserver and NSFileProviderChangeObserver on an object; - Pass that object to the enumerator; - Use the identifiers of items or changes you receive to note the materialization status in your database. When an item is created, modified or deleted remotely, the file provider extension should check whether its parentItemIdentifier is in the materialized set. If it is, the extension needs to inform the system so the system may create, modify or delete the file or directory (initially dataless) on disk. In the case when an item is reparented, the test should be that either the new or the old parentItemIdentifier is in the materialized set. No need to pretend that the iten was deleted if the new parentItemIdentifier is no longer in the materialized set: the system will know what to do with an unknown parent identifier. To notify the system of this created, modified or deleted item, - Call -signalEnumeratorForContainerItemIdentifier: on the working set, i.e the container identified by NSFileProviderWorkingSetContainerItemIdentifier; - Include this item in the next enumeration of the working set. Since this method is called on every change of the set of materialized items, it is advisable to use it to set a flag and perform any resulting work as a timed task rather than performing any work directly. Execution time: --------------- This call is not expected to take more than a few seconds to complete.
      */
-    materializedItemsDidChangeWithCompletionHandler$?(completionHandler: NobjcObject): void;
+    materializedItemsDidChangeWithCompletionHandler$?(completionHandler: () => void): void;
     /**
      * Called by the system when the set of pending items is refreshed. The pending enumerator lists all the items for which a change has been observed either on the disk or in the working set more than one second ago and that change hasn't been applied on the other side yet. An item can appear in the pending set for various reasons: - the system is under load and cannot process all the events in a timely fashion - a long running operation is scheduled or running for the item to be in sync (for instance, the download or the upload of a new content) - an error occurred, in which case the error will be set on the item as `downloadError` if it occurred when applying a change to the disk, or `uploadError` in the other way around. The pending set will only include items that comply to the following rules: - They have been queued for changes for more time than the refresh interval; - The items are already known by the provider. These constraints imply that initial transfer of a file from the disk to the provider will not be listed in the pending set, even though the transfer could take several minutes to complete Furthermore, the pending set can only contain a limited number of items. The pending set provides an easy way to design an "in progress" UI containing a few items and to detect whether there's any activity pending on the system. In case the pending set reached its maximum size items, newly pending items won't be included in it. Already present items in the pending set will remain until they no longer are pending. The pending set is refreshed regurlary but only if there are meaningful changes: new pending items, items that were pending but are not anymore (deletions from the set), or domain version changed and set is not empty To enumerate the set of pending items, - Call -enumeratorForPendingItems on the instance of NSFileProviderManager corresponding to your domain; - Implement the NSFileProviderEnumerationObserver and NSFileProviderChangeObserver on an object; - Pass that object to the enumerator; - It will get called upon change to the set. This method is regularly called when changes happen to the pending set. implementeers are advised that this call will not happen as soon as an item is pending. Thus, implementeers should not use the pending set to detect when a change happens. The pending set will only contain items that were pending for a least one second before the last refresh date. Execution time: --------------- This call is not expected to take more than a few seconds to complete.
      */
-    pendingItemsDidChangeWithCompletionHandler$?(completionHandler: NobjcObject): void;
+    pendingItemsDidChangeWithCompletionHandler$?(completionHandler: () => void): void;
 }

package/dist/FileProvider/NSFileProviderServicing.d.ts

@@ -1,9 +1,10 @@
-import type { NobjcObject } from "objc-js";
+import type { _NSArray } from "../Foundation/NSArray.js";
+import type { _NSError } from "../Foundation/NSError.js";
 import type { _NSProgress } from "../Foundation/NSProgress.js";
 import type { _NSString } from "../Foundation/NSString.js";
 export interface _NSFileProviderServicing {
     /**
      * A file provider can implemement this method to return service sources that provide custom communication channels to client applications. The service sources must be tied to the item identified by Client applications can retrieve the list of supported services by calling getFileProviderServicesForItemAtURL:] for a specific item URL. Cancellations: ------------ If the NSProgress returned by this method is cancelled, the extension should call the completion handler with (nil, NSUserCancelledError) in the NSProgress cancellation handler. Execution time: --------------- This method is not expected to take more than a few seconds to complete the retrieval of the thumbnails. The system will call `cancel` on the progress if the operation takes too much time. The extension is then expected to quickly call the completion handler.
      */
-    supportedServiceSourcesForItemIdentifier$completionHandler$?(itemIdentifier: _NSString, completionHandler: NobjcObject | null): _NSProgress;
+    supportedServiceSourcesForItemIdentifier$completionHandler$?(itemIdentifier: _NSString, completionHandler: ((arg0: _NSArray, arg1: _NSError) => void) | null): _NSProgress;
 }

package/dist/FileProvider/NSFileProviderThumbnailing.d.ts

@@ -1,10 +1,12 @@
-import type { NobjcObject } from "objc-js";
 import type { _NSArray } from "../Foundation/NSArray.js";
+import type { _NSData } from "../Foundation/NSData.js";
+import type { _NSError } from "../Foundation/NSError.js";
 import type { _NSProgress } from "../Foundation/NSProgress.js";
+import type { _NSString } from "../Foundation/NSString.js";
 import type { CGSize } from "../structs/CGSize.js";
 export interface _NSFileProviderThumbnailing {
     /**
      * The system calls this method to fetch thumbnails. The should be called for each thumbnail, and only after all the per thumbnail completion blocks. In the event of a global error, the implementation is allowed to skip calling the for individual thumbnails. In that case, the error parameter would apply to all item identifiers for which had not been called. If there is no thumbnail for a given item, the should be called with its and parameters both set to nil. If the system decides that an in-flight thumbnail request is not needed anymore, it will call the returned object's method, at which time the implementation should clean up any held resources. The system will cache the thumbnail for the item, and the cache will be invalidated when itemVersion.contentVersion changes. Thread safety: ------------ The may be called from multiple threads concurrently. Cancellations: ------------ If the NSProgress returned by this method is cancelled, the extension should call the completion handler with (NSUserCancelledError) in the NSProgress cancellation handler. Execution time: --------------- This method is not expected to take more than a few tens seconds to complete the retrieval of the services exposed on the item. The system will call `cancel` on the progress if the operation takes too much time. The extension is then expected to quickly call the completion handler.
      */
-    fetchThumbnailsForItemIdentifiers$requestedSize$perThumbnailCompletionHandler$completionHandler$?(itemIdentifiers: _NSArray, size: CGSize, perThumbnailCompletionHandler: NobjcObject | null, completionHandler: NobjcObject | null): _NSProgress;
+    fetchThumbnailsForItemIdentifiers$requestedSize$perThumbnailCompletionHandler$completionHandler$?(itemIdentifiers: _NSArray, size: CGSize, perThumbnailCompletionHandler: ((identifier: _NSString, imageData: _NSData, error: _NSError) => void) | null, completionHandler: ((error: _NSError) => void) | null): _NSProgress;
 }

package/dist/FileProvider/index.d.ts

@@ -94,6 +94,7 @@ export { NSFileProviderCreateItemOptions } from "./NSFileProviderCreateItemOptio
 export { NSFileProviderDeleteItemOptions } from "./NSFileProviderDeleteItemOptions.js";
 export { NSFileProviderDomainRemovalMode } from "./NSFileProviderDomainRemovalMode.js";
 export { NSFileProviderDomainTestingModes } from "./NSFileProviderDomainTestingModes.js";
+export { NSFileProviderErrorCode } from "./NSFileProviderErrorCode.js";
 export { NSFileProviderFetchContentsOptions } from "./NSFileProviderFetchContentsOptions.js";
 export { NSFileProviderFileSystemFlags } from "./NSFileProviderFileSystemFlags.js";
 export { NSFileProviderItemCapabilities } from "./NSFileProviderItemCapabilities.js";

package/dist/FileProvider/index.js

@@ -16,6 +16,7 @@ export { NSFileProviderCreateItemOptions } from "./NSFileProviderCreateItemOptio
 export { NSFileProviderDeleteItemOptions } from "./NSFileProviderDeleteItemOptions.js";
 export { NSFileProviderDomainRemovalMode } from "./NSFileProviderDomainRemovalMode.js";
 export { NSFileProviderDomainTestingModes } from "./NSFileProviderDomainTestingModes.js";
+export { NSFileProviderErrorCode } from "./NSFileProviderErrorCode.js";
 export { NSFileProviderFetchContentsOptions } from "./NSFileProviderFetchContentsOptions.js";
 export { NSFileProviderFileSystemFlags } from "./NSFileProviderFileSystemFlags.js";
 export { NSFileProviderItemCapabilities } from "./NSFileProviderItemCapabilities.js";

package/dist/FinderSync/FIFinderSync.d.ts

@@ -1,5 +1,7 @@
 import type { NobjcObject } from "objc-js";
 import type { _NSArray } from "../Foundation/NSArray.js";
+import type { _NSDictionary } from "../Foundation/NSDictionary.js";
+import type { _NSError } from "../Foundation/NSError.js";
 import type { _NSExtensionRequestHandling } from "../Foundation/NSExtensionRequestHandling.js";
 import type { _NSObject } from "../Foundation/NSObject.js";
 import type { _NSString } from "../Foundation/NSString.js";
@@ -32,7 +34,7 @@ export declare class _FIFinderSync extends _NSObject {
     /** Collaboration, starting in macOS 10.13. */
     supportedServiceNamesForItemWithURL$(itemURL: _NSURL): _NSArray;
     makeListenerEndpointForServiceName$itemURL$andReturnError$(serviceName: NSFileProviderServiceName, itemURL: _NSURL, error: NobjcObject | null): _NSXPCListenerEndpoint | null;
-    valuesForAttributes$forItemWithURL$completion$(attributes: _NSArray, itemURL: _NSURL, completion: NobjcObject | null): void;
+    valuesForAttributes$forItemWithURL$completion$(attributes: _NSArray, itemURL: _NSURL, completion: ((arg0: _NSDictionary, arg1: _NSError) => void) | null): void;
     /**
      * The name of the extension’s toolbar button. To add a toolbar item to the Finder, override the getter method for the toolbar image, name, and tooltip properties.
      */

package/dist/FinderSync/FIFinderSyncController.d.ts

@@ -1,7 +1,7 @@
-import type { NobjcObject } from "objc-js";
 import type { _NSArray } from "../Foundation/NSArray.js";
 import type { _NSData } from "../Foundation/NSData.js";
 import type { _NSDate } from "../Foundation/NSDate.js";
+import type { _NSError } from "../Foundation/NSError.js";
 import type { _NSExtensionContext } from "../Foundation/NSExtensionContext.js";
 import type { _NSSet } from "../Foundation/NSSet.js";
 import type { _NSString } from "../Foundation/NSString.js";
@@ -38,9 +38,9 @@ export declare class _FIFinderSyncController extends _NSExtensionContext {
     selectedItemURLs(): _NSArray | null;
     /** Collaboration, starting in macOS 10.13. */
     lastUsedDateForItemWithURL$(itemURL: _NSURL): _NSDate | null;
-    setLastUsedDate$forItemWithURL$completion$(lastUsedDate: _NSDate, itemURL: _NSURL, completion: NobjcObject): void;
+    setLastUsedDate$forItemWithURL$completion$(lastUsedDate: _NSDate, itemURL: _NSURL, completion: (error: _NSError) => void): void;
     tagDataForItemWithURL$(itemURL: _NSURL): _NSData | null;
-    setTagData$forItemWithURL$completion$(tagData: _NSData | null, itemURL: _NSURL, completion: NobjcObject): void;
+    setTagData$forItemWithURL$completion$(tagData: _NSData | null, itemURL: _NSURL, completion: (error: _NSError) => void): void;
     /**
      * The directories managed by this extension. The extension receives ``FIFinderSync/beginObservingDirectoryAtURL:`` and ``FIFinderSync/endObservingDirectoryAtURL:`` messages for every directory in this set and for all of their subdirectories. Always set `directoryURLs` when the extension starts. If there are no directories to watch, set `directoryURLs` to an empty set.
      */

package/dist/Foundation/NSArray.d.ts

@@ -65,25 +65,25 @@ export declare class _NSArray extends _NSObject {
     makeObjectsPerformSelector$withObject$(aSelector: string, argument: NobjcObject | null): void;
     objectsAtIndexes$(indexes: _NSIndexSet): _NSArray;
     objectAtIndexedSubscript$(idx: number): NobjcObject;
-    enumerateObjectsUsingBlock$(block: NobjcObject): void;
-    enumerateObjectsWithOptions$usingBlock$(opts: NSEnumerationOptions, block: NobjcObject): void;
-    enumerateObjectsAtIndexes$options$usingBlock$(s: _NSIndexSet, opts: NSEnumerationOptions, block: NobjcObject): void;
-    indexOfObjectPassingTest$(predicate: NobjcObject): number;
-    indexOfObjectWithOptions$passingTest$(opts: NSEnumerationOptions, predicate: NobjcObject): number;
-    indexOfObjectAtIndexes$options$passingTest$(s: _NSIndexSet, opts: NSEnumerationOptions, predicate: NobjcObject): number;
-    indexesOfObjectsPassingTest$(predicate: NobjcObject): _NSIndexSet;
-    indexesOfObjectsWithOptions$passingTest$(opts: NSEnumerationOptions, predicate: NobjcObject): _NSIndexSet;
-    indexesOfObjectsAtIndexes$options$passingTest$(s: _NSIndexSet, opts: NSEnumerationOptions, predicate: NobjcObject): _NSIndexSet;
-    sortedArrayUsingComparator$(cmptr: NobjcObject): _NSArray;
-    sortedArrayWithOptions$usingComparator$(opts: NSSortOptions, cmptr: NobjcObject): _NSArray;
+    enumerateObjectsUsingBlock$(block: (obj: NobjcObject, idx: number, stop: NobjcObject) => void): void;
+    enumerateObjectsWithOptions$usingBlock$(opts: NSEnumerationOptions, block: (obj: NobjcObject, idx: number, stop: NobjcObject) => void): void;
+    enumerateObjectsAtIndexes$options$usingBlock$(s: _NSIndexSet, opts: NSEnumerationOptions, block: (obj: NobjcObject, idx: number, stop: NobjcObject) => void): void;
+    indexOfObjectPassingTest$(predicate: (obj: NobjcObject, idx: number, stop: NobjcObject) => boolean): number;
+    indexOfObjectWithOptions$passingTest$(opts: NSEnumerationOptions, predicate: (obj: NobjcObject, idx: number, stop: NobjcObject) => boolean): number;
+    indexOfObjectAtIndexes$options$passingTest$(s: _NSIndexSet, opts: NSEnumerationOptions, predicate: (obj: NobjcObject, idx: number, stop: NobjcObject) => boolean): number;
+    indexesOfObjectsPassingTest$(predicate: (obj: NobjcObject, idx: number, stop: NobjcObject) => boolean): _NSIndexSet;
+    indexesOfObjectsWithOptions$passingTest$(opts: NSEnumerationOptions, predicate: (obj: NobjcObject, idx: number, stop: NobjcObject) => boolean): _NSIndexSet;
+    indexesOfObjectsAtIndexes$options$passingTest$(s: _NSIndexSet, opts: NSEnumerationOptions, predicate: (obj: NobjcObject, idx: number, stop: NobjcObject) => boolean): _NSIndexSet;
+    sortedArrayUsingComparator$(cmptr: (arg0: NobjcObject, arg1: NobjcObject) => number): _NSArray;
+    sortedArrayWithOptions$usingComparator$(opts: NSSortOptions, cmptr: (arg0: NobjcObject, arg1: NobjcObject) => number): _NSArray;
     /** binary search */
-    indexOfObject$inSortedRange$options$usingComparator$(obj: NobjcObject, r: NSRange, opts: NSBinarySearchingOptions, cmp: NobjcObject): number;
+    indexOfObject$inSortedRange$options$usingComparator$(obj: NobjcObject, r: NSRange, opts: NSBinarySearchingOptions, cmp: (arg0: NobjcObject, arg1: NobjcObject) => number): number;
     initWithObjects$(firstObj: NobjcObject): _NSArray;
     initWithArray$(array: _NSArray): _NSArray;
     initWithArray$copyItems$(array: _NSArray, flag: boolean): _NSArray;
     /** Reads array stored in NSPropertyList format from the specified url. */
     initWithContentsOfURL$error$(url: _NSURL, error: NobjcObject | null): _NSArray | null;
-    differenceFromArray$withOptions$usingEquivalenceTest$(other: _NSArray, options: NSOrderedCollectionDifferenceCalculationOptions, block: NobjcObject): _NSOrderedCollectionDifference;
+    differenceFromArray$withOptions$usingEquivalenceTest$(other: _NSArray, options: NSOrderedCollectionDifferenceCalculationOptions, block: (obj1: NobjcObject, obj2: NobjcObject) => boolean): _NSOrderedCollectionDifference;
     differenceFromArray$withOptions$(other: _NSArray, options: NSOrderedCollectionDifferenceCalculationOptions): _NSOrderedCollectionDifference;
     /**
      * Uses isEqual: to determine the difference between the parameter and the receiver

package/dist/Foundation/NSAttributedString.d.ts

@@ -33,8 +33,8 @@ export declare class _NSAttributedString extends _NSObject {
     initWithString$(str: _NSString): _NSAttributedString;
     initWithString$attributes$(str: _NSString, attrs: _NSDictionary | null): _NSAttributedString;
     initWithAttributedString$(attrStr: _NSAttributedString): _NSAttributedString;
-    enumerateAttributesInRange$options$usingBlock$(enumerationRange: NSRange, opts: NSAttributedStringEnumerationOptions, block: NobjcObject): void;
-    enumerateAttribute$inRange$options$usingBlock$(attrName: _NSString, enumerationRange: NSRange, opts: NSAttributedStringEnumerationOptions, block: NobjcObject | null): void;
+    enumerateAttributesInRange$options$usingBlock$(enumerationRange: NSRange, opts: NSAttributedStringEnumerationOptions, block: (attrs: _NSDictionary, range: NSRange, stop: NobjcObject) => void): void;
+    enumerateAttribute$inRange$options$usingBlock$(attrName: _NSString, enumerationRange: NSRange, opts: NSAttributedStringEnumerationOptions, block: ((value: NobjcObject, range: NSRange, stop: NobjcObject) => void) | null): void;
     /**
      * These constructors have a 'baseURL' parameter. If specified, links in the document will be relative to this URL, and images in the document will be looked for relative to this URL (if the other options allow image loading). Defaults to nil. If set to nil, paths will not be resolved.
      */

package/dist/Foundation/NSBackgroundActivityScheduler.d.ts

@@ -1,6 +1,6 @@
-import type { NobjcObject } from "objc-js";
 import type { _NSObject } from "./NSObject.js";
 import type { _NSString } from "./NSString.js";
+import type { NSBackgroundActivityResult } from "./NSBackgroundActivityResult.js";
 import type { NSQualityOfService } from "./NSQualityOfService.js";
 export declare class _NSBackgroundActivityScheduler extends _NSObject {
     static alloc(): _NSBackgroundActivityScheduler;
@@ -13,7 +13,7 @@ export declare class _NSBackgroundActivityScheduler extends _NSObject {
     /**
      * Begin scheduling the activity. All properties should be setup by this point. The block will be called on a serial background queue appropriate for the level of quality of service specified. The system will automatically use NSProcessInfo's -beginActivityWithOptions:reason: API while invoking the block, choosing options appropriate for the desired quality of service. When you are done with the work, be sure to invoke the completionHandler block given to you as an argument to your block. You can pass in a kind of NSBackgroundActivityResult to indicate if the work has been finished or if you are deferring the rest of the work (see -shouldDefer). If you fail to invoke the completionHandler then your activity will never be rescheduled. When invoking the completionHandler, the system will set the schedule the next invocation. If you want to adjust the properties of your scheduler (e.g., the interval or tolerance), do this before invoking the completion block.
      */
-    scheduleWithBlock$(block: NobjcObject): void;
+    scheduleWithBlock$(block: (completionHandler: (arg0: NSBackgroundActivityResult) => void) => void): void;
     /**
      * Stop scheduling the activity. Any currently executing block will still complete.
      */

package/dist/Foundation/NSBlockOperation.d.ts

@@ -4,7 +4,7 @@ export declare class _NSBlockOperation extends _NSOperation {
     static alloc(): _NSBlockOperation;
     static new(): _NSBlockOperation;
     init(): _NSBlockOperation;
-    static blockOperationWithBlock$(block: NobjcObject): _NSBlockOperation;
-    addExecutionBlock$(block: NobjcObject): void;
-    executionBlocks(): NobjcObject;
+    static blockOperationWithBlock$(block: () => void): _NSBlockOperation;
+    addExecutionBlock$(block: () => void): void;
+    executionBlocks(): () => NobjcObject;
 }

package/dist/Foundation/NSBundleResourceRequest.d.ts

@@ -1,5 +1,5 @@
-import type { NobjcObject } from "objc-js";
 import type { _NSBundle } from "./NSBundle.js";
+import type { _NSError } from "./NSError.js";
 import type { _NSObject } from "./NSObject.js";
 import type { _NSProgress } from "./NSProgress.js";
 import type { _NSSet } from "./NSSet.js";
@@ -15,11 +15,11 @@ export declare class _NSBundleResourceRequest extends _NSObject {
     /**
      * Ask the system to fetch the resources that were part of the tag set in this request. Resources will not be purged while in use by the application (as indicated by the application using this begin API paired with a call to -endAccessingResources). If an application has too many fetched resources and the system is unable to reserve enough space for newly requested tags, the request may return an error. When you are finished with the resources and they may be purged off the disk, invoke -endAccessingResources. If the request object is deallocated, it will also inform the system that the resources are no longer in use. The completion block will be invoked on a non-main serial queue when the resources are available or an error has occurred. An example of a possible error that may be reported is the lack of a network connection or a problem connecting to the on-demand servers. Fetch requests are reference counted across the application. So if you have two requests outstanding with the same set of tags, each may be used independently without having to know about any global state. However, each NSBundleResourceRequest object may only be used once. If you cancel an outstanding request (via the cancel method on the NSProgress object, or cancelling a parent progress object you have created) the completion handler argument to this method will be called back with an NSUserCancelledError in the NSCocoaErrorDomain. Be sure to always invoke the -endAccessingResources method to balance a call to the begin method, even in the case of an error in the completion handler. If you want to access the resources again, create a new NSBundleResourceRequest object.
      */
-    beginAccessingResourcesWithCompletionHandler$(completionHandler: NobjcObject | null): void;
+    beginAccessingResourcesWithCompletionHandler$(completionHandler: ((error: _NSError) => void) | null): void;
     /**
      * Inform the system that you wish to begin accessing the resources that are part of this request, but do not attempt to download any content over the network. The completion handler will be invoked with a YES argument if the resources are available. If the resources were available, then you must invoke the -endAccessingResources method once you are done accessing them. If the resources were not available, then you may invoke the -beginAccessingResourcesWithCompletionHandler: method to initiate a download of the resources.
      */
-    conditionallyBeginAccessingResourcesWithCompletionHandler$(completionHandler: NobjcObject): void;
+    conditionallyBeginAccessingResourcesWithCompletionHandler$(completionHandler: (resourcesAvailable: boolean) => void): void;
     /**
      * Informs the system that you are finished with the resources that were part of the tag set in this request. Call this after you no longer need the resources to be available on disk. It is important to invoke this method to make room for newly requested resources. This method may only be invoked if you have received a callback from -beginAccessingResourcesWithCompletionHandler:. To cancel an in-progress request, invoke cancel on the -progress property.
      */

package/dist/Foundation/NSCalendar.d.ts

@@ -102,7 +102,7 @@ export declare class _NSCalendar extends _NSObject {
     /**
      * This method computes the dates which match (or most closely match) a given set of components, and calls the block once for each of them, until the enumeration is stopped. There will be at least one intervening date which does not match all the components (or the given date itself must not match) between the given date and any result. If the NSCalendarSearchBackwards option is used, this method finds the previous match before the given date. The intent is that the same matches as for a forwards search will be found (that is, if you are enumerating forwards or backwards for each hour with minute "27", the seconds in the date you will get in forwards search would obviously be 00, and the same will be true in a backwards search in order to implement this rule. Similarly for DST backwards jumps which repeats times, you'll get the first match by default, where "first" is defined from the point of view of searching forwards. So, when searching backwards looking for a particular hour, with no minute and second specified, you don't get a minute and second of 59:59 for the matching hour (which would be the nominal first match within a given hour, given the other rules here, when searching backwards). If the NSCalendarMatchStrictly option is used, the algorithm travels as far forward or backward as necessary looking for a match, but there are ultimately implementation-defined limits in how far distant the search will go. If the NSCalendarMatchStrictly option is not specified, the algorithm searches up to the end of the next instance of the next higher unit to the highest specified unit in the NSDateComponents argument. If you want to find the next Feb 29 in the Gregorian calendar, for example, you have to specify the NSCalendarMatchStrictly option to guarantee finding it. If an exact match is not possible, and requested with the NSCalendarMatchStrictly option, nil is passed to the block and the enumeration ends. (Logically, since an exact match searches indefinitely into the future, if no match is found there's no point in continuing the enumeration.) If the NSCalendarMatchStrictly option is NOT used, exactly one option from the set {NSCalendarMatchPreviousTimePreservingSmallerUnits, NSCalendarMatchNextTimePreservingSmallerUnits, NSCalendarMatchNextTime} must be specified, or an illegal argument exception will be thrown. If the NSCalendarMatchPreviousTimePreservingSmallerUnits option is specified, and there is no matching time before the end of the next instance of the next higher unit to the highest specified unit in the NSDateComponents argument, the method will return the previous existing value of the missing unit and preserves the lower units' values (e.g., no 2:37am results in 1:37am, if that exists). If the NSCalendarMatchNextTimePreservingSmallerUnits option is specified, and there is no matching time before the end of the next instance of the next higher unit to the highest specified unit in the NSDateComponents argument, the method will return the next existing value of the missing unit and preserves the lower units' values (e.g., no 2:37am results in 3:37am, if that exists). If the NSCalendarMatchNextTime option is specified, and there is no matching time before the end of the next instance of the next higher unit to the highest specified unit in the NSDateComponents argument, the method will return the next existing time which exists (e.g., no 2:37am results in 3:00am, if that exists). If the NSCalendarMatchFirst option is specified, and there are two or more matching times (all the components are the same, including isLeapMonth) before the end of the next instance of the next higher unit to the highest specified unit in the NSDateComponents argument, the method will return the first occurrence. If the NSCalendarMatchLast option is specified, and there are two or more matching times (all the components are the same, including isLeapMonth) before the end of the next instance of the next higher unit to the highest specified unit in the NSDateComponents argument, the method will return the last occurrence. If neither the NSCalendarMatchFirst or NSCalendarMatchLast option is specified, the default behavior is to act as if NSCalendarMatchFirst was specified. There is no option to return middle occurrences of more than two occurrences of a matching time, if such exist. Result dates have an integer number of seconds (as if 0 was specified for the nanoseconds property of the NSDateComponents matching parameter), unless a value was set in the nanoseconds property, in which case the result date will have that number of nanoseconds (or as close as possible with floating point numbers). The enumeration is stopped by setting *stop = YES in the block and return. It is not necessary to set *stop to NO to keep the enumeration going.
      */
-    enumerateDatesStartingAfterDate$matchingComponents$options$usingBlock$(start: _NSDate, comps: _NSDateComponents, opts: NSCalendarOptions, block: NobjcObject | null): void;
+    enumerateDatesStartingAfterDate$matchingComponents$options$usingBlock$(start: _NSDate, comps: _NSDateComponents, opts: NSCalendarOptions, block: ((date: _NSDate, exactMatch: boolean, stop: NobjcObject) => void) | null): void;
     /**
      * This method computes the next date which matches (or most closely matches) a given set of components. The general semantics follow those of the -enumerateDatesStartingAfterDate:... method above. To compute a sequence of results, use the -enumerateDatesStartingAfterDate:... method above, rather than looping and calling this method with the previous loop iteration's result.
      */

package/dist/Foundation/NSData.d.ts

@@ -44,11 +44,11 @@ export declare class _NSData extends _NSObject {
     /**
      * 'block' is called once for each contiguous region of memory in the receiver (once total for contiguous NSDatas), until either all bytes have been enumerated, or the 'stop' parameter is set to YES.
      */
-    enumerateByteRangesUsingBlock$(block: NobjcObject): void;
+    enumerateByteRangesUsingBlock$(block: (bytes: NobjcObject, byteRange: NSRange, stop: NobjcObject) => void): void;
     initWithBytes$length$(bytes: Uint8Array | null, length: number): _NSData;
     initWithBytesNoCopy$length$(bytes: Uint8Array, length: number): _NSData;
     initWithBytesNoCopy$length$freeWhenDone$(bytes: Uint8Array, length: number, b: boolean): _NSData;
-    initWithBytesNoCopy$length$deallocator$(bytes: Uint8Array, length: number, deallocator: NobjcObject | null): _NSData;
+    initWithBytesNoCopy$length$deallocator$(bytes: Uint8Array, length: number, deallocator: ((bytes: NobjcObject, length: number) => void) | null): _NSData;
     initWithContentsOfFile$options$error$(path: _NSString, readOptionsMask: NSDataReadingOptions, errorPtr: NobjcObject | null): _NSData | null;
     initWithContentsOfURL$options$error$(url: _NSURL, readOptionsMask: NSDataReadingOptions, errorPtr: NobjcObject | null): _NSData | null;
     initWithContentsOfFile$(path: _NSString): _NSData | null;

package/dist/Foundation/NSDictionary.d.ts

@@ -53,12 +53,12 @@ export declare class _NSDictionary extends _NSObject {
     /** count refers to the number of elements in the dictionary */
     getObjects$andKeys$count$(objects: NobjcObject | null, keys: NobjcObject | null, count: number): void;
     objectForKeyedSubscript$(key: NobjcObject): NobjcObject | null;
-    enumerateKeysAndObjectsUsingBlock$(block: NobjcObject): void;
-    enumerateKeysAndObjectsWithOptions$usingBlock$(opts: NSEnumerationOptions, block: NobjcObject): void;
-    keysSortedByValueUsingComparator$(cmptr: NobjcObject): _NSArray;
-    keysSortedByValueWithOptions$usingComparator$(opts: NSSortOptions, cmptr: NobjcObject): _NSArray;
-    keysOfEntriesPassingTest$(predicate: NobjcObject): _NSSet;
-    keysOfEntriesWithOptions$passingTest$(opts: NSEnumerationOptions, predicate: NobjcObject): _NSSet;
+    enumerateKeysAndObjectsUsingBlock$(block: (key: NobjcObject, obj: NobjcObject, stop: NobjcObject) => void): void;
+    enumerateKeysAndObjectsWithOptions$usingBlock$(opts: NSEnumerationOptions, block: (key: NobjcObject, obj: NobjcObject, stop: NobjcObject) => void): void;
+    keysSortedByValueUsingComparator$(cmptr: (arg0: NobjcObject, arg1: NobjcObject) => number): _NSArray;
+    keysSortedByValueWithOptions$usingComparator$(opts: NSSortOptions, cmptr: (arg0: NobjcObject, arg1: NobjcObject) => number): _NSArray;
+    keysOfEntriesPassingTest$(predicate: (key: NobjcObject, obj: NobjcObject, stop: NobjcObject) => boolean): _NSSet;
+    keysOfEntriesWithOptions$passingTest$(opts: NSEnumerationOptions, predicate: (key: NobjcObject, obj: NobjcObject, stop: NobjcObject) => boolean): _NSSet;
     /**
      * This method is unsafe because it could potentially cause buffer overruns. You should use -getObjects:andKeys:count:
      * @deprecated Use -getObjects:andKeys:count: instead

package/dist/Foundation/NSError.d.ts

@@ -13,8 +13,8 @@ export declare class _NSError extends _NSObject {
     /**
      * Specify a block which will be called from the implementations of localizedDescription, localizedFailureReason, localizedRecoverySuggestion, localizedRecoveryOptions, recoveryAttempter, helpAnchor, and debugDescription when the underlying value for these is not present in the userInfo dictionary of NSError instances with the specified domain. The provider will be called with the userInfo key corresponding to the queried property: For instance, NSLocalizedDescriptionKey for localizedDescription. The provider should return nil for any keys it is not able to provide and, very importantly, any keys it does not recognize (since we may extend the list of keys in future releases). The specified block will be called synchronously at the time when the above properties are queried. The results are not cached. This provider is optional. It enables localization and formatting of error messages to be done lazily; rather than populating the userInfo at NSError creation time, these keys will be fetched on-demand when asked for. It is expected that only the “owner” of an NSError domain specifies the provider for the domain, and this is done once. This facility is not meant for consumers of errors to customize the userInfo entries. This facility should not be used to customize the behaviors of error domains provided by the system. If an appropriate result for the requested key cannot be provided, return nil rather than choosing to manufacture a generic fallback response such as "Operation could not be completed, error 42." NSError will take care of the fallback cases.
      */
-    static setUserInfoValueProviderForDomain$provider$(errorDomain: _NSString, provider: NobjcObject | null): void;
-    static userInfoValueProviderForDomain$(errorDomain: _NSString): NobjcObject | null;
+    static setUserInfoValueProviderForDomain$provider$(errorDomain: _NSString, provider: ((err: _NSError, userInfoKey: _NSString) => NobjcObject) | null): void;
+    static userInfoValueProviderForDomain$(errorDomain: _NSString): ((arg0: _NSError, arg1: _NSString) => NobjcObject) | null;
     /** Domain cannot be nil; dict may be nil if no userInfo desired. */
     initWithDomain$code$userInfo$(domain: _NSString, code: number, dict: _NSDictionary | null): _NSError;
     /**

package/dist/Foundation/NSExpression.d.ts

@@ -54,7 +54,7 @@ export declare class _NSExpression extends _NSObject {
     /**
      * Expression that invokes the block with the parameters; note that block expressions are not encodable or representable as parseable strings.
      */
-    static expressionForBlock$arguments$(block: NobjcObject | null, arguments_: _NSArray | null): _NSExpression;
+    static expressionForBlock$arguments$(block: ((evaluatedObject: NobjcObject, expressions: _NSArray, context: _NSMutableDictionary) => NobjcObject) | null, arguments_: _NSArray | null): _NSExpression;
     /**
      * Expression that will return the result of trueExpression or falseExpression depending on the value of predicate
      */
@@ -95,7 +95,7 @@ export declare class _NSExpression extends _NSObject {
      * expression which will be evaluated if a conditional expression's predicate evaluates to false
      */
     falseExpression(): _NSExpression;
-    expressionBlock(): NobjcObject | null;
+    expressionBlock(): ((arg0: NobjcObject, arg1: _NSArray, arg2: _NSMutableDictionary) => NobjcObject) | null;
 }
 export interface _NSExpression extends _NSCopying {
 }

package/dist/Foundation/NSExtensionContext.d.ts

@@ -1,4 +1,3 @@
-import type { NobjcObject } from "objc-js";
 import type { _NSArray } from "./NSArray.js";
 import type { _NSError } from "./NSError.js";
 import type { _NSObject } from "./NSObject.js";
@@ -10,13 +9,13 @@ export declare class _NSExtensionContext extends _NSObject {
     /**
      * Signals the host to complete the app extension request with the supplied result items. The completion handler optionally contains any work which the extension may need to perform after the request has been completed, as a background-priority task. The `expired` parameter will be YES if the system decides to prematurely terminate a previous non-expiration invocation of the completionHandler. Note: calling this method will eventually dismiss the associated view controller.
      */
-    completeRequestReturningItems$completionHandler$(items: _NSArray | null, completionHandler: NobjcObject | null): void;
+    completeRequestReturningItems$completionHandler$(items: _NSArray | null, completionHandler: ((expired: boolean) => void) | null): void;
     /**
      * Signals the host to cancel the app extension request, with the supplied error, which should be non-nil. The userInfo of the NSError will contain a key NSExtensionItemsAndErrorsKey which will have as its value a dictionary of NSExtensionItems and associated NSError instances.
      */
     cancelRequestWithError$(error: _NSError): void;
     /** Asks the host to open a URL on the extension's behalf */
-    openURL$completionHandler$(URL: _NSURL, completionHandler: NobjcObject | null): void;
+    openURL$completionHandler$(URL: _NSURL, completionHandler: ((success: boolean) => void) | null): void;
     /**
      * The list of input NSExtensionItems associated with the context. If the context has no input items, this array will be empty.
      */

package/dist/Foundation/NSFileCoordinator.d.ts

@@ -1,5 +1,6 @@
 import type { NobjcObject } from "objc-js";
 import type { _NSArray } from "./NSArray.js";
+import type { _NSError } from "./NSError.js";
 import type { _NSFilePresenter } from "./NSFilePresenter.js";
 import type { _NSObject } from "./NSObject.js";
 import type { _NSOperationQueue } from "./NSOperationQueue.js";
@@ -25,18 +26,18 @@ export declare class _NSFileCoordinator extends _NSObject {
     /**
      * Given an array of one or more NSFileAccessIntent objects that specify reading and/or writing items located by the corresponding URLs, wait asynchronously for certain other readers and writers and then invoke the passed-in block on the given queue, which must not be nil. If an error occurs, file access is not granted and a non-nil error will be passed to the accessor block. If file access is successfully granted, then 'error' will be nil and you may perform the intended file access inside the accessor block. You must use the URL property on the NSFileAccessIntent objects when performing file access in the accessor block. Within the block, the NSFileAccessIntent objects' URLs may differ from their original values to account for items that have been moved or renamed while waiting for access to be granted. When access to the intended files is granted, certain other readers and writers are made to wait until the given block returns, which defines the end of that file access. Do not allow file access to continue after the accessor block returns by dispatching work to other threads or queues. You can invoke this method to serialize your process's access of files and directories with other processes' access of the same files and directories so that inconsistencies due to overlapping reading and writing don't occur. It also causes messages to be sent to NSFilePresenters, and wait for NSFilePresenters to react, as described below. The fact that file system items can be moved or renamed while this method is waiting to invoke the block you passed when invoking it is why it's critical to use the URL property on the NSFileAccessIntent objects, not the URLs you used when initializing them. In general a coordinated reader waits for a coordinated writer of the same item, and a coordinated writer waits for coordinated readers and other coordinated writers of the same item. Coordinated readers do not wait for each other. Coordinated reading or writing of items in a file package is treated as coordinated reading or writing of the file package as a whole. A coordinated reader of a directory that is not a file package does not wait for coordinated writers of contained items, or cause such writers to wait. With one exception, a coordinated writer of a directory that is not a file package does not wait for coordinated readers and writers of contained items, or cause such readers and writers to wait. The exception is when you use NSFileCoordinatorWritingForDeleting, NSFileCoordinatorWritingForMoving, or NSFileCoordinatorWritingForReplacing. They make your coordinated writer wait for previously scheduled coordinated readers and writers of contained items, and causes subsequently scheduled coordinated readers and writers of contained items to wait. None of those rules apply to coordinated readers and writers that are using the exact same instance of NSFileCoordinator, including arrays of multiple NSFileAccessIntent objects. Instances of NSFileCoordinator never block themselves. You can take advantage of that in a couple of ways when invoking -coordinateAccessWithIntents:queue:byAccessor: multiple times on the same NSFileCoordinator instance, but take care because doing so raises the possibility of deadlocking with other processes that are doing the same sort of thing. If you can, you should invoke -coordinateAccessWithIntents:queue:byAccessor: a single time with multiple NSFileAccessIntent objects instead of invoking it multiple times with a single NSFileAccssIntent object. In addition to waiting for writers, readers wait for NSFilePresenters that are messaged as part of the coordinated reading. Coordinated reading of an item triggers the sending of messages to NSFilePresenters that implement the corresponding optional methods, even those in other processes, except the one specified when -initWithFilePresenter: was invoked: - -relinquishPresentedItemToReader: is sent to NSFilePresenters of the item and, if the item is in a file package, NSFilePresenters of the file package. If there are nested file packages then the message is sent to NSFilePresenters of all of them. - If NSFileCoordinatorReadingWithoutChanges is not used then -savePresentedItemChangesWithCompletionHandler: is also sent to the same NSFilePresenters. In addition to waiting for readers and other writers, writers wait for NSFilePresenters that are messaged as part of the coordinated writing. Coordinated writing of an item triggers the sending of messages to NSFilePresenters that implement the corresponding optional methods, even those in other processes, except the one specified when -initWithFilePresenter: was invoked: - -relinquishPresentedItemToWriter: is sent to NSFilePresenters of the item and, if the item is in a file package, NSFilePresenters of the file package. If there are nested file packages then the message is sent to NSFilePresenters of all of them. - If NSFileCoordinatorWritingForDeleting, NSFileCoordinatorWritingForMoving, or NSFileCoordinatorWritingForReplacing is used and the item is a directory then -relinquishPresentedItemToWriter: is also sent to NSFilePresenters of each item contained by it. - If NSFileCoordinatorWritingForDeleting or NSFileCoordinatorWritingForReplacing is used then -accommodatePresentedItemDeletionWithCompletionHandler: is sent to NSFilePresenters of the item and, if the item is a directory, NSFilePresenters of each item contained by it. -accommodatePresentedSubitemDeletionAtURL:completionHandler: is sent to NSFilePresenters of each file package that contains the item. - When NSFileCoordinatorWritingForReplacing is used the the definition of "the item" depends on what happened while waiting for other writers. See the description of it above. - If NSFileCoordinatorWritingForMerging is used then -savePresentedItemChangesWithCompletionHandler: is sent to NSFilePresenters of the item and, if the item is in a file package, NSFilePresenters of the file package. If there are nested file packages then the message is sent to NSFilePresenters of all of them. For both coordinated reading and writing, if there are multiple NSFilePresenters involved then the order in which they are messaged is undefined. If an NSFilePresenter signals failure then waiting will fail and *outError will be set to an NSError describing the failure.
      */
-    coordinateAccessWithIntents$queue$byAccessor$(intents: _NSArray, queue: _NSOperationQueue, accessor: NobjcObject | null): void;
+    coordinateAccessWithIntents$queue$byAccessor$(intents: _NSArray, queue: _NSOperationQueue, accessor: ((error: _NSError) => void) | null): void;
     /**
      * The next four methods behave similarly to -coordinateAccessWithIntents:queue:byAccessor: with one or two NSFileAccessIntent objects with the following exceptions: Each of these methods wait synchronously on the same thread they were invoked on before invoking the passed-in accessor block on the same thread, instead of waiting asynchronously and scheduling invocation of the block on a specific queue. The accessor block of each of these methods is passed one or more URLs that locate the intended items, perhaps changed from the original URLs to take into account the fact that the item might have been moved or renamed during the waiting. Each of these methods returns an NSError by reference instead of passing it to the accessory block. However, these methods are uncommon among Cocoa framework methods in that they don't also return a result indicating success or failure. The success of the waiting that they do is typically not interesting to invokers. Only the success of file system access done by the passed-in block is interesting. (The failure of either is of course interesting.) When invoking these methods it's cleanest to just declare a __block variable outside of the block and initialize it to a value that signals failure, and then inside the block set it to a value that signals success. If the waiting fails then the invoked method sets the error reference to an NSError that describes what went wrong, your block will not be invoked, your __block variable will not be set to a value that signals success, and all will be as it should be, with failure signaled and an NSError that describes the failure.
      */
-    coordinateReadingItemAtURL$options$error$byAccessor$(url: _NSURL, options: NSFileCoordinatorReadingOptions, outError: NobjcObject | null, reader: NobjcObject): void;
-    coordinateWritingItemAtURL$options$error$byAccessor$(url: _NSURL, options: NSFileCoordinatorWritingOptions, outError: NobjcObject | null, writer: NobjcObject): void;
-    coordinateReadingItemAtURL$options$writingItemAtURL$options$error$byAccessor$(readingURL: _NSURL, readingOptions: NSFileCoordinatorReadingOptions, writingURL: _NSURL, writingOptions: NSFileCoordinatorWritingOptions, outError: NobjcObject | null, readerWriter: NobjcObject): void;
-    coordinateWritingItemAtURL$options$writingItemAtURL$options$error$byAccessor$(url1: _NSURL, options1: NSFileCoordinatorWritingOptions, url2: _NSURL, options2: NSFileCoordinatorWritingOptions, outError: NobjcObject | null, writer: NobjcObject): void;
+    coordinateReadingItemAtURL$options$error$byAccessor$(url: _NSURL, options: NSFileCoordinatorReadingOptions, outError: NobjcObject | null, reader: (newURL: _NSURL) => void): void;
+    coordinateWritingItemAtURL$options$error$byAccessor$(url: _NSURL, options: NSFileCoordinatorWritingOptions, outError: NobjcObject | null, writer: (newURL: _NSURL) => void): void;
+    coordinateReadingItemAtURL$options$writingItemAtURL$options$error$byAccessor$(readingURL: _NSURL, readingOptions: NSFileCoordinatorReadingOptions, writingURL: _NSURL, writingOptions: NSFileCoordinatorWritingOptions, outError: NobjcObject | null, readerWriter: (newReadingURL: _NSURL, newWritingURL: _NSURL) => void): void;
+    coordinateWritingItemAtURL$options$writingItemAtURL$options$error$byAccessor$(url1: _NSURL, options1: NSFileCoordinatorWritingOptions, url2: _NSURL, options2: NSFileCoordinatorWritingOptions, outError: NobjcObject | null, writer: (newURL1: _NSURL, newURL2: _NSURL) => void): void;
     /**
      * Prepare to more efficiently do a large number of invocations of -coordinate... methods, first synchronously messaging and waiting for NSFilePresenters in a variation of what individual invocations of the -coordinate... methods would do, and then, if no error occurs, invoke the passed-in block. The passed-in block must invoke the completion handler passed to it when all of the coordinated reading and writing it does is done. The completion handler block can be invoked on any thread (or from any dispatch queue, if that's how you think of it). This method returns errors in the same manner as the -coordinate... methods. The -coordinate... methods must use interprocess communication to message instances of NSFileCoordinator and NSFilePresenter in other processes in the system. That is an expense best avoided when reading or writing many files in one operation. Using this method can greatly reduce the amount of interprocess communication required by, for example, a large batched copying or moving of files. You use it by moving all of the invocations of the -coordinate... methods your application will do during a batch operation, or the scheduling of them if the operation's work is done in a multithreaded fashion, into a block and passing that block to an invocation of this method, remembering that the completion handler passed to that block must be invoked when the operation is done. You don't simply pass all URLs that will be passed into invocations of the -coordinate... methods when invoking this method. Instead you pass the top-level files and directories involved in the operation. This method triggers messages to not just NSFilePresenters of those items, but also NSFilePresenters of items contained by those items. For example, when Finder uses this method during a copy operation readingURLs is an array of the URLs of the exact files and folders that the user has selected, even though those folders may contain many files and subfolders for which Finder is going to do coordinated reading, and writingURLs is an array that contains just the URL of the destination folder. In most cases it is redundant to pass the same reading or writing options in an invocation of this method as are passed to individual invocations of the -coordinate... methods invoked by the block passed to an invocation of this method. For example, when Finder invokes this method during a copy operation it does not pass NSFileCoordinatorReadingWithoutChanges because it is appropriate to trigger the saving of document changes right away, but it does pass it when doing the nested invocations of -coordinate... methods because it is not necessary to trigger saving again, even if the user changes the document before the Finder proceeds far enough to actually copy that document's file.
      */
-    prepareForReadingItemsAtURLs$options$writingItemsAtURLs$options$error$byAccessor$(readingURLs: _NSArray, readingOptions: NSFileCoordinatorReadingOptions, writingURLs: _NSArray, writingOptions: NSFileCoordinatorWritingOptions, outError: NobjcObject | null, batchAccessor: NobjcObject): void;
+    prepareForReadingItemsAtURLs$options$writingItemsAtURLs$options$error$byAccessor$(readingURLs: _NSArray, readingOptions: NSFileCoordinatorReadingOptions, writingURLs: _NSArray, writingOptions: NSFileCoordinatorWritingOptions, outError: NobjcObject | null, batchAccessor: (arg0: () => void) => void): void;
     /**
      * Announce that the item located by a URL is going to be located by another URL. Support for App Sandbox on OS X. Some applications can rename files while saving them. For example, when a user adds attachments to a rich text document, TextEdit changes the document's extension from .rtf to .rtfd. A sandboxed application like TextEdit must ordinarily prompt the user for approval before renaming a document. You can invoke this method to make your process declare its intent to rename a document without user approval. After the renaming succeeds you must invoke -itemAtURL:didMoveToURL:, with the same arguments, for the process to keep access to the file with its new name and to give up access to any file that appears with the old name. If the renaming fails you should probably not invoke -itemAtURL:didMoveToURL:. There is no reason to invoke this method from applications that do not use App Sandbox. Invoking it does nothing on iOS.
      */

package/dist/Foundation/NSFileHandle.d.ts

@@ -59,10 +59,10 @@ export declare class _NSFileHandle extends _NSObject {
     /** @deprecated closeAndReturnError: */
     closeFile(): void;
     availableData(): _NSData;
-    readabilityHandler(): NobjcObject | null;
-    setReadabilityHandler$(value: NobjcObject | null): void;
-    writeabilityHandler(): NobjcObject | null;
-    setWriteabilityHandler$(value: NobjcObject | null): void;
+    readabilityHandler(): ((arg0: _NSFileHandle) => void) | null;
+    setReadabilityHandler$(value: ((arg0: _NSFileHandle) => void) | null): void;
+    writeabilityHandler(): ((arg0: _NSFileHandle) => void) | null;
+    setWriteabilityHandler$(value: ((arg0: _NSFileHandle) => void) | null): void;
     fileDescriptor(): number;
     /** @deprecated getOffset:error: */
     offsetInFile(): number;