objcjs-types 0.1.0 → 0.2.1

package/dist/Foundation/NSException.d.ts

@@ -1,7 +1,9 @@
 import type { NobjcObject } from "objc-js";
 import type { _NSArray } from "./NSArray.js";
+import type { _NSCopying } from "./NSCopying.js";
 import type { _NSDictionary } from "./NSDictionary.js";
 import type { _NSObject } from "./NSObject.js";
+import type { _NSSecureCoding } from "./NSSecureCoding.js";
 import type { _NSString } from "./NSString.js";
 import type { NSExceptionName } from "./NSExceptionName.js";
 export declare class _NSException extends _NSObject {
@@ -19,3 +21,5 @@ export declare class _NSException extends _NSObject {
     callStackReturnAddresses(): _NSArray;
     callStackSymbols(): _NSArray;
 }
+export interface _NSException extends _NSCopying, _NSSecureCoding {
+}

package/dist/Foundation/NSExpression.d.ts

@@ -1,6 +1,7 @@
 import type { NobjcObject } from "objc-js";
 import type { _NSArray } from "./NSArray.js";
 import type { _NSCoder } from "./NSCoder.js";
+import type { _NSCopying } from "./NSCopying.js";
 import type { _NSMutableDictionary } from "./NSMutableDictionary.js";
 import type { _NSObject } from "./NSObject.js";
 import type { _NSPredicate } from "./NSPredicate.js";
@@ -14,7 +15,7 @@ export declare class _NSExpression extends _NSObject {
     static expressionWithFormat$(expressionFormat: _NSString): _NSExpression;
     static expressionWithFormat$arguments$(expressionFormat: _NSString, argList: NobjcObject): _NSExpression;
     /** Expression that returns a constant value */
-    static expressionForConstantValue$(obj: NobjcObject): _NSExpression;
+    static expressionForConstantValue$(obj: NobjcObject | null): _NSExpression;
     /** Expression that returns the object being evaluated */
     static expressionForEvaluatedObject(): _NSExpression;
     /** Expression that pulls a value from the variable bindings dictionary */
@@ -53,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, arguments_: _NSArray | null): _NSExpression;
+    static expressionForBlock$arguments$(block: NobjcObject | null, arguments_: _NSArray | null): _NSExpression;
     /**
      * Expression that will return the result of trueExpression or falseExpression depending on the value of predicate
      */
@@ -63,12 +64,12 @@ export declare class _NSExpression extends _NSObject {
     /**
      * evaluate the expression using the object and bindings- note that context is mutable here and can be used by expressions to store temporary state for one predicate evaluation
      */
-    expressionValueWithObject$context$(object_: NobjcObject, context: _NSMutableDictionary | null): NobjcObject;
+    expressionValueWithObject$context$(object_: NobjcObject | null, context: _NSMutableDictionary | null): NobjcObject | null;
     /** Force an expression which was securely decoded to allow evaluation */
     allowEvaluation(): void;
     /** accessors for individual parameters - raise if not applicable */
     expressionType(): NSExpressionType;
-    constantValue(): NobjcObject;
+    constantValue(): NobjcObject | null;
     keyPath(): _NSString;
     function(): _NSString;
     variable(): _NSString;
@@ -94,5 +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;
+    expressionBlock(): NobjcObject | null;
+}
+export interface _NSExpression extends _NSCopying {
 }

package/dist/Foundation/NSExtensionContext.d.ts

@@ -10,13 +10,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): void;
+    completeRequestReturningItems$completionHandler$(items: _NSArray | null, completionHandler: NobjcObject | 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): void;
+    openURL$completionHandler$(URL: _NSURL, completionHandler: NobjcObject | 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/NSExtensionItem.d.ts

@@ -1,7 +1,9 @@
 import type { _NSArray } from "./NSArray.js";
 import type { _NSAttributedString } from "./NSAttributedString.js";
+import type { _NSCopying } from "./NSCopying.js";
 import type { _NSDictionary } from "./NSDictionary.js";
 import type { _NSObject } from "./NSObject.js";
+import type { _NSSecureCoding } from "./NSSecureCoding.js";
 export declare class _NSExtensionItem extends _NSObject {
     static alloc(): _NSExtensionItem;
     static new(): _NSExtensionItem;
@@ -23,3 +25,5 @@ export declare class _NSExtensionItem extends _NSObject {
     userInfo(): _NSDictionary | null;
     setUserInfo$(value: _NSDictionary | null): void;
 }
+export interface _NSExtensionItem extends _NSCopying, _NSSecureCoding {
+}

package/dist/Foundation/NSFastEnumeration.d.ts

@@ -1,4 +1,4 @@
 import type { NobjcObject } from "objc-js";
 export interface _NSFastEnumeration {
-    countByEnumeratingWithState$objects$count$?(state: NobjcObject, buffer: NobjcObject, len: number): number;
+    countByEnumeratingWithState$objects$count$?(state: NobjcObject, buffer: NobjcObject | null, len: number): number;
 }

package/dist/Foundation/NSFileCoordinator.d.ts

@@ -17,7 +17,7 @@ export declare class _NSFileCoordinator extends _NSObject {
      */
     static addFilePresenter$(filePresenter: _NSFilePresenter): void;
     static removeFilePresenter$(filePresenter: _NSFilePresenter): void;
-    static filePresenters(): NobjcObject;
+    static filePresenters(): _NSArray;
     /**
      * The designated initializer. If an NSFilePresenter is provided then the receiver is considered to have been created by that NSFilePresenter, or on its behalf. NSFileCoordinator is meant to be instantiated on a per-file-operation basis, where a file operation is something like the opening or saving of a document, or the copying or moving of a batch of folders and files. There is no benefit to keeping an instance of it alive in your application for much more time than it takes to actually perform the file operation. Doing so can be harmful, or at least wasteful of memory, because NSFileCoordinators may retain NSFilePresenters. You pass an NSFilePresenter to this initializer when the operation whose file access is to be coordinated is being performed by that NSFilePresenter. Associating an NSFileCoordinator with an NSFilePresenter accomplishes a few important things: - It prevents the NSFileCoordinator from sending messages to that NSFilePresenter, so the NSFilePresenter does not have to somehow filter out messages about its own file operations. The exception to this rule is that messages about versions of the presented item being added, remove, or resolved during coordinated writing are sent to every relevant NSFilePresenter, even the one passed to -initWithFilePresenter:. - It allows the file coordination mechanism to determine when coordinated writing is being done in response to an NSFilePresenter receiving a -savePresentedItemChangesWithCompletionHandler: message, and not deadlock. Usually coordinated writing done by one NSFileCoordinator must wait for coordinated reading of the same file or directory done by another NSFileCoordinator. But, for example, when coordinated reading is begun with one NSFileCoordinator, and that causes an NSFilePresenter to do coordinated writing using another NSFileCoordinator, the writing done with the second NSFileCoordinator should not wait for the completion of the first NSFileCoordinator's reading, it should instead happen while the first NSFileCoordinator is waiting to read. - It allows the file coordination mechanism to handle a race condition that can occur when it has sent an NSFilePresenter a -presentedItemDidMoveToURL: message in the NSFilePresenter's operation queue but before that message is dequeued the NSFilePresenter enqueues, on a different queue, an operation using the old URL. For this to be effective however the NSFileCoordinator must be initialized in the same operation queue in which NSFilePresenter messages are received. - It allows the file coordination mechanism to gracefully handle your application's registration of an NSFilePresenter that at first returns nil when sent -presentedItemURL but can later return non-nil at the end of doing a coordinated write that creates the presented item in the file system for the very first time. AppKit for example takes advantage of this by registering brand new untitled NSDocuments as NSFilePresenters immediately, instead of waiting until after the first time the user causes the document to be saved to a file, which would be more complicated. For example, NSDocument creates a single NSFileCoordinator for all of the coordinated reading and writing it does during the saving of a document. It always creates the NSFileCoordinator in the main queue even when it is doing the actual coordinated reading and writing in a background queue to implement asynchronous saving.
      */
@@ -25,18 +25,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): void;
+    coordinateAccessWithIntents$queue$byAccessor$(intents: _NSArray, queue: _NSOperationQueue, accessor: NobjcObject | 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, reader: NobjcObject): void;
-    coordinateWritingItemAtURL$options$error$byAccessor$(url: _NSURL, options: NSFileCoordinatorWritingOptions, outError: NobjcObject, writer: NobjcObject): void;
-    coordinateReadingItemAtURL$options$writingItemAtURL$options$error$byAccessor$(readingURL: _NSURL, readingOptions: NSFileCoordinatorReadingOptions, writingURL: _NSURL, writingOptions: NSFileCoordinatorWritingOptions, outError: NobjcObject, readerWriter: NobjcObject): void;
-    coordinateWritingItemAtURL$options$writingItemAtURL$options$error$byAccessor$(url1: _NSURL, options1: NSFileCoordinatorWritingOptions, url2: _NSURL, options2: NSFileCoordinatorWritingOptions, outError: NobjcObject, writer: NobjcObject): void;
+    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;
     /**
      * 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, batchAccessor: NobjcObject): void;
+    prepareForReadingItemsAtURLs$options$writingItemsAtURLs$options$error$byAccessor$(readingURLs: _NSArray, readingOptions: NSFileCoordinatorReadingOptions, writingURLs: _NSArray, writingOptions: NSFileCoordinatorWritingOptions, outError: NobjcObject | null, batchAccessor: NobjcObject): 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

@@ -12,24 +12,24 @@ export declare class _NSFileHandle extends _NSObject {
     static fileHandleForReadingAtPath$(path: _NSString): _NSFileHandle | null;
     static fileHandleForWritingAtPath$(path: _NSString): _NSFileHandle | null;
     static fileHandleForUpdatingAtPath$(path: _NSString): _NSFileHandle | null;
-    static fileHandleForReadingFromURL$error$(url: _NSURL, error: NobjcObject): _NSFileHandle | null;
-    static fileHandleForWritingToURL$error$(url: _NSURL, error: NobjcObject): _NSFileHandle | null;
-    static fileHandleForUpdatingURL$error$(url: _NSURL, error: NobjcObject): _NSFileHandle | null;
+    static fileHandleForReadingFromURL$error$(url: _NSURL, error: NobjcObject | null): _NSFileHandle | null;
+    static fileHandleForWritingToURL$error$(url: _NSURL, error: NobjcObject | null): _NSFileHandle | null;
+    static fileHandleForUpdatingURL$error$(url: _NSURL, error: NobjcObject | null): _NSFileHandle | null;
     static fileHandleWithStandardInput(): _NSFileHandle;
     static fileHandleWithStandardOutput(): _NSFileHandle;
     static fileHandleWithStandardError(): _NSFileHandle;
     static fileHandleWithNullDevice(): _NSFileHandle;
     initWithFileDescriptor$closeOnDealloc$(fd: number, closeopt: boolean): _NSFileHandle;
     initWithCoder$(coder: _NSCoder): _NSFileHandle | null;
-    readDataToEndOfFileAndReturnError$(error: NobjcObject): _NSData | null;
-    readDataUpToLength$error$(length: number, error: NobjcObject): _NSData | null;
-    writeData$error$(data: _NSData, error: NobjcObject): boolean;
-    getOffset$error$(offsetInFile: NobjcObject, error: NobjcObject): boolean;
-    seekToEndReturningOffset$error$(offsetInFile: NobjcObject, error: NobjcObject): boolean;
-    seekToOffset$error$(offset: number, error: NobjcObject): boolean;
-    truncateAtOffset$error$(offset: number, error: NobjcObject): boolean;
-    synchronizeAndReturnError$(error: NobjcObject): boolean;
-    closeAndReturnError$(error: NobjcObject): boolean;
+    readDataToEndOfFileAndReturnError$(error: NobjcObject | null): _NSData | null;
+    readDataUpToLength$error$(length: number, error: NobjcObject | null): _NSData | null;
+    writeData$error$(data: _NSData, error: NobjcObject | null): boolean;
+    getOffset$error$(offsetInFile: NobjcObject, error: NobjcObject | null): boolean;
+    seekToEndReturningOffset$error$(offsetInFile: NobjcObject | null, error: NobjcObject | null): boolean;
+    seekToOffset$error$(offset: number, error: NobjcObject | null): boolean;
+    truncateAtOffset$error$(offset: number, error: NobjcObject | null): boolean;
+    synchronizeAndReturnError$(error: NobjcObject | null): boolean;
+    closeAndReturnError$(error: NobjcObject | null): boolean;
     readInBackgroundAndNotifyForModes$(modes: _NSArray | null): void;
     readInBackgroundAndNotify(): void;
     readToEndOfFileInBackgroundAndNotifyForModes$(modes: _NSArray | null): void;
@@ -59,10 +59,10 @@ export declare class _NSFileHandle extends _NSObject {
     /** @deprecated closeAndReturnError: */
     closeFile(): void;
     availableData(): _NSData;
-    readabilityHandler(): NobjcObject;
-    setReadabilityHandler$(value: NobjcObject): void;
-    writeabilityHandler(): NobjcObject;
-    setWriteabilityHandler$(value: NobjcObject): void;
+    readabilityHandler(): NobjcObject | null;
+    setReadabilityHandler$(value: NobjcObject | null): void;
+    writeabilityHandler(): NobjcObject | null;
+    setWriteabilityHandler$(value: NobjcObject | null): void;
     fileDescriptor(): number;
     /** @deprecated getOffset:error: */
     offsetInFile(): number;

package/dist/Foundation/NSFileManager.d.ts

@@ -30,11 +30,11 @@ export declare class _NSFileManager extends _NSObject {
     /**
      * This method starts the process of unmounting the volume specified by url. If the volume is encrypted, it is re-locked after being unmounted. The completionHandler will be executed when the operation is complete. If the operation was successful, the block’s errorOrNil argument will be nil; otherwise, errorOrNil will be an error object indicating why the unmount operation failed.
      */
-    unmountVolumeAtURL$options$completionHandler$(url: _NSURL, mask: NSFileManagerUnmountOptions, completionHandler: NobjcObject): void;
+    unmountVolumeAtURL$options$completionHandler$(url: _NSURL, mask: NSFileManagerUnmountOptions, completionHandler: NobjcObject | null): void;
     /**
      * -contentsOfDirectoryAtURL:includingPropertiesForKeys:options:error: returns an NSArray of NSURLs identifying the the directory entries. If this method returns nil, an NSError will be returned by reference in the 'error' parameter. If the directory contains no entries, this method will return the empty array. When an array is specified for the 'keys' parameter, the specified property values will be pre-fetched and cached with each enumerated URL. This method always does a shallow enumeration of the specified directory (i.e. it always acts as if NSDirectoryEnumerationSkipsSubdirectoryDescendants has been specified). If you need to perform a deep enumeration, use -[NSFileManager enumeratorAtURL:includingPropertiesForKeys:options:errorHandler:]. If you wish to only receive the URLs and no other attributes, then pass '0' for 'options' and an empty NSArray ('[NSArray array]') for 'keys'. If you wish to have the property caches of the vended URLs pre-populated with a default set of attributes, then pass '0' for 'options' and 'nil' for 'keys'.
      */
-    contentsOfDirectoryAtURL$includingPropertiesForKeys$options$error$(url: _NSURL, keys: _NSArray | null, mask: NSDirectoryEnumerationOptions, error: NobjcObject): _NSArray | null;
+    contentsOfDirectoryAtURL$includingPropertiesForKeys$options$error$(url: _NSURL, keys: _NSArray | null, mask: NSDirectoryEnumerationOptions, error: NobjcObject | null): _NSArray | null;
     /**
      * -URLsForDirectory:inDomains: is analogous to NSSearchPathForDirectoriesInDomains(), but returns an array of NSURL instances for use with URL-taking APIs. This API is suitable when you need to search for a file or files which may live in one of a variety of locations in the domains specified.
      */
@@ -42,74 +42,74 @@ export declare class _NSFileManager extends _NSObject {
     /**
      * -URLForDirectory:inDomain:appropriateForURL:create:error: is a URL-based replacement for FSFindFolder(). It allows for the specification and (optional) creation of a specific directory for a particular purpose (e.g. the replacement of a particular item on disk, or a particular Library directory. You may pass only one of the values from the NSSearchPathDomainMask enumeration, and you may not pass NSAllDomainsMask.
      */
-    URLForDirectory$inDomain$appropriateForURL$create$error$(directory: NSSearchPathDirectory, domain: NSSearchPathDomainMask, url: _NSURL | null, shouldCreate: boolean, error: NobjcObject): _NSURL | null;
+    URLForDirectory$inDomain$appropriateForURL$create$error$(directory: NSSearchPathDirectory, domain: NSSearchPathDomainMask, url: _NSURL | null, shouldCreate: boolean, error: NobjcObject | null): _NSURL | null;
     /**
      * Sets 'outRelationship' to NSURLRelationshipContains if the directory at 'directoryURL' directly or indirectly contains the item at 'otherURL', meaning 'directoryURL' is found while enumerating parent URLs starting from 'otherURL'. Sets 'outRelationship' to NSURLRelationshipSame if 'directoryURL' and 'otherURL' locate the same item, meaning they have the same NSURLFileResourceIdentifierKey value. If 'directoryURL' is not a directory, or does not contain 'otherURL' and they do not locate the same file, then sets 'outRelationship' to NSURLRelationshipOther. If an error occurs, returns NO and sets 'error'.
      */
-    getRelationship$ofDirectoryAtURL$toItemAtURL$error$(outRelationship: NobjcObject, directoryURL: _NSURL, otherURL: _NSURL, error: NobjcObject): boolean;
+    getRelationship$ofDirectoryAtURL$toItemAtURL$error$(outRelationship: NobjcObject, directoryURL: _NSURL, otherURL: _NSURL, error: NobjcObject | null): boolean;
     /**
      * Similar to -[NSFileManager getRelationship:ofDirectoryAtURL:toItemAtURL:error:], except that the directory is instead defined by an NSSearchPathDirectory and NSSearchPathDomainMask. Pass 0 for domainMask to instruct the method to automatically choose the domain appropriate for 'url'. For example, to discover if a file is contained by a Trash directory, call [fileManager getRelationship:&result ofDirectory:NSTrashDirectory inDomain:0 toItemAtURL:url error:&error].
      */
-    getRelationship$ofDirectory$inDomain$toItemAtURL$error$(outRelationship: NobjcObject, directory: NSSearchPathDirectory, domainMask: NSSearchPathDomainMask, url: _NSURL, error: NobjcObject): boolean;
+    getRelationship$ofDirectory$inDomain$toItemAtURL$error$(outRelationship: NobjcObject, directory: NSSearchPathDirectory, domainMask: NSSearchPathDomainMask, url: _NSURL, error: NobjcObject | null): boolean;
     /**
      * createDirectoryAtURL:withIntermediateDirectories:attributes:error: creates a directory at the specified URL. If you pass 'NO' for withIntermediateDirectories, the directory must not exist at the time this call is made. Passing 'YES' for withIntermediateDirectories will create any necessary intermediate directories. This method returns YES if all directories specified in 'url' were created and attributes were set. Directories are created with attributes specified by the dictionary passed to 'attributes'. If no dictionary is supplied, directories are created according to the umask of the process. This method returns NO if a failure occurs at any stage of the operation. If an error parameter was provided, a presentable NSError will be returned by reference.
      */
-    createDirectoryAtURL$withIntermediateDirectories$attributes$error$(url: _NSURL, createIntermediates: boolean, attributes: _NSDictionary | null, error: NobjcObject): boolean;
+    createDirectoryAtURL$withIntermediateDirectories$attributes$error$(url: _NSURL, createIntermediates: boolean, attributes: _NSDictionary | null, error: NobjcObject | null): boolean;
     /**
      * createSymbolicLinkAtURL:withDestinationURL:error: returns YES if the symbolic link that point at 'destURL' was able to be created at the location specified by 'url'. 'destURL' is always resolved against its base URL, if it has one. If 'destURL' has no base URL and it's 'relativePath' is indeed a relative path, then a relative symlink will be created. If this method returns NO, the link was unable to be created and an NSError will be returned by reference in the 'error' parameter. This method does not traverse a terminal symlink.
      */
-    createSymbolicLinkAtURL$withDestinationURL$error$(url: _NSURL, destURL: _NSURL, error: NobjcObject): boolean;
+    createSymbolicLinkAtURL$withDestinationURL$error$(url: _NSURL, destURL: _NSURL, error: NobjcObject | null): boolean;
     /**
      * setAttributes:ofItemAtPath:error: returns YES when the attributes specified in the 'attributes' dictionary are set successfully on the item specified by 'path'. If this method returns NO, a presentable NSError will be provided by-reference in the 'error' parameter. If no error is required, you may pass 'nil' for the error. This method replaces changeFileAttributes:atPath:.
      */
-    setAttributes$ofItemAtPath$error$(attributes: _NSDictionary, path: _NSString, error: NobjcObject): boolean;
+    setAttributes$ofItemAtPath$error$(attributes: _NSDictionary, path: _NSString, error: NobjcObject | null): boolean;
     /**
      * createDirectoryAtPath:withIntermediateDirectories:attributes:error: creates a directory at the specified path. If you pass 'NO' for createIntermediates, the directory must not exist at the time this call is made. Passing 'YES' for 'createIntermediates' will create any necessary intermediate directories. This method returns YES if all directories specified in 'path' were created and attributes were set. Directories are created with attributes specified by the dictionary passed to 'attributes'. If no dictionary is supplied, directories are created according to the umask of the process. This method returns NO if a failure occurs at any stage of the operation. If an error parameter was provided, a presentable NSError will be returned by reference. This method replaces createDirectoryAtPath:attributes:
      */
-    createDirectoryAtPath$withIntermediateDirectories$attributes$error$(path: _NSString, createIntermediates: boolean, attributes: _NSDictionary | null, error: NobjcObject): boolean;
+    createDirectoryAtPath$withIntermediateDirectories$attributes$error$(path: _NSString, createIntermediates: boolean, attributes: _NSDictionary | null, error: NobjcObject | null): boolean;
     /**
      * contentsOfDirectoryAtPath:error: returns an NSArray of NSStrings representing the filenames of the items in the directory. If this method returns 'nil', an NSError will be returned by reference in the 'error' parameter. If the directory contains no items, this method will return the empty array. This method replaces directoryContentsAtPath:
      */
-    contentsOfDirectoryAtPath$error$(path: _NSString, error: NobjcObject): _NSArray | null;
+    contentsOfDirectoryAtPath$error$(path: _NSString, error: NobjcObject | null): _NSArray | null;
     /**
      * subpathsOfDirectoryAtPath:error: returns an NSArray of NSStrings representing the filenames of the items in the specified directory and all its subdirectories recursively. If this method returns 'nil', an NSError will be returned by reference in the 'error' parameter. If the directory contains no items, this method will return the empty array. This method replaces subpathsAtPath:
      */
-    subpathsOfDirectoryAtPath$error$(path: _NSString, error: NobjcObject): _NSArray | null;
+    subpathsOfDirectoryAtPath$error$(path: _NSString, error: NobjcObject | null): _NSArray | null;
     /**
      * attributesOfItemAtPath:error: returns an NSDictionary of key/value pairs containing the attributes of the item (file, directory, symlink, etc.) at the path in question. If this method returns 'nil', an NSError will be returned by reference in the 'error' parameter. This method does not traverse a terminal symlink. This method replaces fileAttributesAtPath:traverseLink:.
      */
-    attributesOfItemAtPath$error$(path: _NSString, error: NobjcObject): _NSDictionary | null;
+    attributesOfItemAtPath$error$(path: _NSString, error: NobjcObject | null): _NSDictionary | null;
     /**
      * attributesOfFileSystemForPath:error: returns an NSDictionary of key/value pairs containing the attributes of the filesystem containing the provided path. If this method returns 'nil', an NSError will be returned by reference in the 'error' parameter. This method does not traverse a terminal symlink. This method replaces fileSystemAttributesAtPath:.
      */
-    attributesOfFileSystemForPath$error$(path: _NSString, error: NobjcObject): _NSDictionary | null;
+    attributesOfFileSystemForPath$error$(path: _NSString, error: NobjcObject | null): _NSDictionary | null;
     /**
      * createSymbolicLinkAtPath:withDestination:error: returns YES if the symbolic link that point at 'destPath' was able to be created at the location specified by 'path'. If this method returns NO, the link was unable to be created and an NSError will be returned by reference in the 'error' parameter. This method does not traverse a terminal symlink. This method replaces createSymbolicLinkAtPath:pathContent:
      */
-    createSymbolicLinkAtPath$withDestinationPath$error$(path: _NSString, destPath: _NSString, error: NobjcObject): boolean;
+    createSymbolicLinkAtPath$withDestinationPath$error$(path: _NSString, destPath: _NSString, error: NobjcObject | null): boolean;
     /**
      * destinationOfSymbolicLinkAtPath:error: returns an NSString containing the path of the item pointed at by the symlink specified by 'path'. If this method returns 'nil', an NSError will be returned by reference in the 'error' parameter. This method replaces pathContentOfSymbolicLinkAtPath:
      */
-    destinationOfSymbolicLinkAtPath$error$(path: _NSString, error: NobjcObject): _NSString | null;
+    destinationOfSymbolicLinkAtPath$error$(path: _NSString, error: NobjcObject | null): _NSString | null;
     /**
      * These methods replace their non-error returning counterparts below. See the NSFileManagerDelegate protocol below for methods that are dispatched to the NSFileManager instance's delegate.
      */
-    copyItemAtPath$toPath$error$(srcPath: _NSString, dstPath: _NSString, error: NobjcObject): boolean;
-    moveItemAtPath$toPath$error$(srcPath: _NSString, dstPath: _NSString, error: NobjcObject): boolean;
-    linkItemAtPath$toPath$error$(srcPath: _NSString, dstPath: _NSString, error: NobjcObject): boolean;
-    removeItemAtPath$error$(path: _NSString, error: NobjcObject): boolean;
+    copyItemAtPath$toPath$error$(srcPath: _NSString, dstPath: _NSString, error: NobjcObject | null): boolean;
+    moveItemAtPath$toPath$error$(srcPath: _NSString, dstPath: _NSString, error: NobjcObject | null): boolean;
+    linkItemAtPath$toPath$error$(srcPath: _NSString, dstPath: _NSString, error: NobjcObject | null): boolean;
+    removeItemAtPath$error$(path: _NSString, error: NobjcObject | null): boolean;
     /**
      * These methods are URL-taking equivalents of the four methods above. Their delegate methods are defined in the NSFileManagerDelegate protocol below.
      */
-    copyItemAtURL$toURL$error$(srcURL: _NSURL, dstURL: _NSURL, error: NobjcObject): boolean;
-    moveItemAtURL$toURL$error$(srcURL: _NSURL, dstURL: _NSURL, error: NobjcObject): boolean;
-    linkItemAtURL$toURL$error$(srcURL: _NSURL, dstURL: _NSURL, error: NobjcObject): boolean;
-    removeItemAtURL$error$(URL: _NSURL, error: NobjcObject): boolean;
+    copyItemAtURL$toURL$error$(srcURL: _NSURL, dstURL: _NSURL, error: NobjcObject | null): boolean;
+    moveItemAtURL$toURL$error$(srcURL: _NSURL, dstURL: _NSURL, error: NobjcObject | null): boolean;
+    linkItemAtURL$toURL$error$(srcURL: _NSURL, dstURL: _NSURL, error: NobjcObject | null): boolean;
+    removeItemAtURL$error$(URL: _NSURL, error: NobjcObject | null): boolean;
     /**
      * trashItemAtURL:resultingItemURL:error: returns YES if the item at 'url' was successfully moved to a Trash. Since the operation may require renaming the file to avoid collisions, it also returns by reference the resulting URL that the item was moved to. If this method returns NO, the item was not moved and an NSError will be returned by reference in the 'error' parameter. To easily discover if an item is in the Trash, you may use [fileManager getRelationship:&result ofDirectory:NSTrashDirectory inDomain:0 toItemAtURL:url error:&error] && result == NSURLRelationshipContains.
      * @deprecated Use -attributesOfItemAtPath:error: instead
      */
-    trashItemAtURL$resultingItemURL$error$(url: _NSURL, outResultingURL: NobjcObject, error: NobjcObject): boolean;
+    trashItemAtURL$resultingItemURL$error$(url: _NSURL, outResultingURL: NobjcObject | null, error: NobjcObject | null): boolean;
     /**
      * The following methods are deprecated on Mac OS X 10.5. Their URL-based and/or error-returning replacements are listed above.
      * @deprecated Use -attributesOfItemAtPath:error: instead
@@ -130,19 +130,19 @@ export declare class _NSFileManager extends _NSObject {
      */
     createDirectoryAtPath$attributes$(path: _NSString, attributes: _NSDictionary): boolean;
     /** @deprecated Not supported */
-    linkPath$toPath$handler$(src: _NSString, dest: _NSString, handler: NobjcObject): boolean;
+    linkPath$toPath$handler$(src: _NSString, dest: _NSString, handler: NobjcObject | null): boolean;
     /** @deprecated Not supported */
-    copyPath$toPath$handler$(src: _NSString, dest: _NSString, handler: NobjcObject): boolean;
+    copyPath$toPath$handler$(src: _NSString, dest: _NSString, handler: NobjcObject | null): boolean;
     /** @deprecated Not supported */
-    movePath$toPath$handler$(src: _NSString, dest: _NSString, handler: NobjcObject): boolean;
+    movePath$toPath$handler$(src: _NSString, dest: _NSString, handler: NobjcObject | null): boolean;
     /** @deprecated Not supported */
-    removeFileAtPath$handler$(path: _NSString, handler: NobjcObject): boolean;
+    removeFileAtPath$handler$(path: _NSString, handler: NobjcObject | null): boolean;
     changeCurrentDirectoryPath$(path: _NSString): boolean;
     /**
      * The following methods are of limited utility. Attempting to predicate behavior based on the current state of the filesystem or a particular file on the filesystem is encouraging odd behavior in the face of filesystem race conditions. It's far better to attempt an operation (like loading a file or creating a directory) and handle the error gracefully than it is to try to figure out ahead of time whether the operation will succeed.
      */
     fileExistsAtPath$(path: _NSString): boolean;
-    fileExistsAtPath$isDirectory$(path: _NSString, isDirectory: NobjcObject): boolean;
+    fileExistsAtPath$isDirectory$(path: _NSString, isDirectory: NobjcObject | null): boolean;
     isReadableFileAtPath$(path: _NSString): boolean;
     isWritableFileAtPath$(path: _NSString): boolean;
     isExecutableFileAtPath$(path: _NSString): boolean;
@@ -166,7 +166,7 @@ export declare class _NSFileManager extends _NSObject {
     /**
      * enumeratorAtURL:includingPropertiesForKeys:options:errorHandler: returns an NSDirectoryEnumerator rooted at the provided directory URL. The NSDirectoryEnumerator returns NSURLs from the -nextObject method. The optional 'includingPropertiesForKeys' parameter indicates which resource properties should be pre-fetched and cached with each enumerated URL. The optional 'errorHandler' block argument is invoked when an error occurs. Parameters to the block are the URL on which an error occurred and the error. When the error handler returns YES, enumeration continues if possible. Enumeration stops immediately when the error handler returns NO. If you wish to only receive the URLs and no other attributes, then pass '0' for 'options' and an empty NSArray ('[NSArray array]') for 'keys'. If you wish to have the property caches of the vended URLs pre-populated with a default set of attributes, then pass '0' for 'options' and 'nil' for 'keys'.
      */
-    enumeratorAtURL$includingPropertiesForKeys$options$errorHandler$(url: _NSURL, keys: _NSArray | null, mask: NSDirectoryEnumerationOptions, handler: NobjcObject): _NSDirectoryEnumerator | null;
+    enumeratorAtURL$includingPropertiesForKeys$options$errorHandler$(url: _NSURL, keys: _NSArray | null, mask: NSDirectoryEnumerationOptions, handler: NobjcObject | null): _NSDirectoryEnumerator | null;
     /**
      * subpathsAtPath: returns an NSArray of all contents and subpaths recursively from the provided path. This may be very expensive to compute for deep filesystem hierarchies, and should probably be avoided.
      */
@@ -187,21 +187,21 @@ export declare class _NSFileManager extends _NSObject {
     /**
      * -replaceItemAtURL:withItemAtURL:backupItemName:options:resultingItemURL:error: is for developers who wish to perform a safe-save without using the full NSDocument machinery that is available in the AppKit. The `originalItemURL` is the item being replaced. `newItemURL` is the item which will replace the original item. This item should be placed in a temporary directory as provided by the OS, or in a uniquely named directory placed in the same directory as the original item if the temporary directory is not available. If `backupItemName` is provided, that name will be used to create a backup of the original item. The backup is placed in the same directory as the original item. If an error occurs during the creation of the backup item, the operation will fail. If there is already an item with the same name as the backup item, that item will be removed. The backup item will be removed in the event of success unless the `NSFileManagerItemReplacementWithoutDeletingBackupItem` option is provided in `options`. For `options`, pass `0` to get the default behavior, which uses only the metadata from the new item while adjusting some properties using values from the original item. Pass `NSFileManagerItemReplacementUsingNewMetadataOnly` in order to use all possible metadata from the new item.
      */
-    replaceItemAtURL$withItemAtURL$backupItemName$options$resultingItemURL$error$(originalItemURL: _NSURL, newItemURL: _NSURL, backupItemName: _NSString | null, options: NSFileManagerItemReplacementOptions, resultingURL: NobjcObject, error: NobjcObject): boolean;
+    replaceItemAtURL$withItemAtURL$backupItemName$options$resultingItemURL$error$(originalItemURL: _NSURL, newItemURL: _NSURL, backupItemName: _NSString | null, options: NSFileManagerItemReplacementOptions, resultingURL: NobjcObject | null, error: NobjcObject | null): boolean;
     /**
      * Changes whether the item for the specified URL is ubiquitous and moves the item to the destination URL. When making an item ubiquitous, the destination URL must be prefixed with a URL from -URLForUbiquityContainerIdentifier:. Returns YES if the change is successful, NO otherwise.
      */
-    setUbiquitous$itemAtURL$destinationURL$error$(flag: boolean, url: _NSURL, destinationURL: _NSURL, error: NobjcObject): boolean;
+    setUbiquitous$itemAtURL$destinationURL$error$(flag: boolean, url: _NSURL, destinationURL: _NSURL, error: NobjcObject | null): boolean;
     /** Returns YES if the item for the specified URL is ubiquitous, NO otherwise. */
     isUbiquitousItemAtURL$(url: _NSURL): boolean;
     /**
      * Start downloading a local instance of the specified ubiquitous item, if necessary. Returns YES if the download started successfully or wasn't necessary, NO otherwise.
      */
-    startDownloadingUbiquitousItemAtURL$error$(url: _NSURL, error: NobjcObject): boolean;
+    startDownloadingUbiquitousItemAtURL$error$(url: _NSURL, error: NobjcObject | null): boolean;
     /**
      * Removes the local instance of the ubiquitous item at the given URL. Returns YES if removal was successful, NO otherwise.
      */
-    evictUbiquitousItemAtURL$error$(url: _NSURL, error: NobjcObject): boolean;
+    evictUbiquitousItemAtURL$error$(url: _NSURL, error: NobjcObject | null): boolean;
     /**
      * Returns a file URL for the root of the ubiquity container directory corresponding to the supplied container ID. Returns nil if the mobile container does not exist or could not be determined.
      */
@@ -209,27 +209,27 @@ export declare class _NSFileManager extends _NSObject {
     /**
      * Returns a URL that can be shared with other users to allow them download a copy of the specified ubiquitous item. Also returns the date after which the item will no longer be accessible at the returned URL. The URL must be prefixed with a URL from -URLForUbiquityContainerIdentifier:.
      */
-    URLForPublishingUbiquitousItemAtURL$expirationDate$error$(url: _NSURL, outDate: NobjcObject, error: NobjcObject): _NSURL | null;
+    URLForPublishingUbiquitousItemAtURL$expirationDate$error$(url: _NSURL, outDate: NobjcObject | null, error: NobjcObject | null): _NSURL | null;
     /**
      * Asynchronously pauses sync of an item at the given URL. Call this when opening an item to prevent sync from altering the contents of the URL. Once paused, the file provider will not upload local changes nor download remote changes. While paused, call ``uploadLocalVersionOfUbiquitousItem(at:withConflictResolutionPolicy:completionHandler:)`` when the document is in a stable state. This action keeps the server version as up-to-date as possible. If the item is already paused, a second call to this method reports success. If the file provider is already applying changes to the item, the pause fails with an ``NSFileWriteUnknownError-enum.case``, with an underlying error that has domain ``NSPOSIXErrorDomain`` and code ``POSIXError/EBUSY``. If the pause fails, wait for the state to stabilize before retrying. Pausing also fails with ``CocoaError/featureUnsupported`` if `url` refers to a regular (non-package) directory. Pausing sync is independent of the calling app's lifecycle; sync doesn't automatically resume if the app closes or crashes and relaunches later. To resume syncing, explicitly call ``resumeSyncForUbiquitousItem(at:with:completionHandler:)``. Always be sure to resume syncing before you close the item. - Parameters: - url: The URL of the item for which to pause sync. - completionHandler: A closure or block that the framework calls when the pause action completes. It receives a single ``NSError`` parameter to indicate an error that prevented pausing; this value is `nil` if the pause succeeded. In Swift, you can omit the completion handler and catch the thrown error instead.
      */
-    pauseSyncForUbiquitousItemAtURL$completionHandler$(url: _NSURL, completionHandler: NobjcObject): void;
+    pauseSyncForUbiquitousItemAtURL$completionHandler$(url: _NSURL, completionHandler: NobjcObject | null): void;
     /**
      * Asynchronously resumes the sync on a paused item using the given resume behavior. Always call this method when your app closes an item to allow the file provider to sync local changes back to the server. In most situations, the ``NSFileManagerResumeSyncBehavior/preserveLocalChanges`` behavior is the best choice to avoid any risk of data loss. The resume call fails with ``CocoaError/featureUnsupported`` if `url` isn't currently paused. If the device isn't connected to the network, the call may fail with ``NSFileWriteUnknownError-enum.case``, with the underlying error of <doc://com.apple.documentation/documentation/FileProvider/NSFileProviderError/serverUnreachable>. - Parameters: - url: The URL of the item for which to resume sync. - behavior: A ``NSFileManagerResumeSyncBehavior`` value that tells the file manager how to handle conflicts between local and remote versions of files. - completionHandler: A closure or block that the framework calls when the resume action completes. It receives a single ``NSError`` parameter to indicate an error that prevented the resume action; the value is `nil` if the resume succeeded. In Swift, you can omit the completion handler and catch the thrown error instead.
      */
-    resumeSyncForUbiquitousItemAtURL$withBehavior$completionHandler$(url: _NSURL, behavior: NSFileManagerResumeSyncBehavior, completionHandler: NobjcObject): void;
+    resumeSyncForUbiquitousItemAtURL$withBehavior$completionHandler$(url: _NSURL, behavior: NSFileManagerResumeSyncBehavior, completionHandler: NobjcObject | null): void;
     /**
      * Asynchronously fetches the latest remote version of a given item from the server. Use this method if uploading fails due to a version conflict and sync is paused. In this case, fetching the latest remote version allows you to inspect the newer item from the server, resolve the conflict, and resume uploading. The version provided by this call depends on several factors: * If there is no newer version of the file on the server, the caller receives the current version of the file. * If the server has a newer version and sync isn't paused, this call replaces the local item and provides the version of the new item. * If the server has a newer version but sync is paused, the returned version points to a side location. In this case, call ``NSFileVersion/replaceItem(at:options:)`` on the provided version object to replace the local item with the newer item from the server. If the device isn't connected to the network, the call may fail with ``NSFileReadUnknownError-enum.case``, with the underlying error of <doc://com.apple.documentation/documentation/FileProvider/NSFileProviderError/serverUnreachable>. - Parameters: - url: The URL of the item for which to check the version. - completionHandler: A closure or block that the framework calls when the fetch action completes. It receives parameters of types ``NSFileVersion`` and ``NSError``. The error is `nil` if fetching the remote version succeeded; otherwise it indicates the error that caused the call to fail. In Swift, you can omit the completion handler, catching any error in a `do`-`catch` block and receiving the version as the return value.
      */
-    fetchLatestRemoteVersionOfItemAtURL$completionHandler$(url: _NSURL, completionHandler: NobjcObject): void;
+    fetchLatestRemoteVersionOfItemAtURL$completionHandler$(url: _NSURL, completionHandler: NobjcObject | null): void;
     /**
      * Asynchronously uploads the local version of the item using the provided conflict resolution policy. Once your app pauses a sync for an item, call this method every time your document is in a stable state. This action keeps the server version as up-to-date as possible. If the server has a newer version than the one to which the app made changes, uploading fails with ``NSFileWriteUnknownError-enum.case``, with an underlying error of <doc://com.apple.documentation/documentation/FileProvider/NSFileProviderError/localVersionConflictingWithServer>. In this case, call ``FileManager/fetchLatestRemoteVersionOfItem(at:completionHandler:)``, rebase local changes on top of that version, and retry the upload. If the device isn't connected to the network, the call may fail with ``NSFileWriteUnknownError-enum.case``, with the underlying error of <doc://com.apple.documentation/documentation/FileProvider/NSFileProviderError/serverUnreachable>. - Parameters: - url: The URL of the item for which to check the version. - conflictResolutionPolicy: The policy the file manager applies if the local and server versions conflict. - completionHandler: A closure or block that the framework calls when the upload completes. It receives parameters of types ``NSFileVersion`` and ``NSError``. The error is `nil` if fetching the remote version succeeded; otherwise it indicates the error that caused the call to fail. In Swift, you can omit the completion handler, catching any error in a `do`-`catch` block and receiving the version as the return value.
      */
-    uploadLocalVersionOfUbiquitousItemAtURL$withConflictResolutionPolicy$completionHandler$(url: _NSURL, conflictResolutionPolicy: NSFileManagerUploadLocalVersionConflictPolicy, completionHandler: NobjcObject): void;
+    uploadLocalVersionOfUbiquitousItemAtURL$withConflictResolutionPolicy$completionHandler$(url: _NSURL, conflictResolutionPolicy: NSFileManagerUploadLocalVersionConflictPolicy, completionHandler: NobjcObject | null): void;
     /**
      * Asynchronously returns a dictionary of zero or more NSFileProviderService instances, which enable your application to instruct the file's provider to take various actions on or with regards to the given URL. To do this, first identify an NSFileProviderService object whose name matches the service you wish to use. Then get an NSXPCConnection from it and set up its NSXPCInterface with the protocol that matches the service's name. You'll need to refer to external documentation or an SDK supplied by the provider to get this information. Once an NSXPCConnection is obtained, you must finish configuring it and send it -resume. Failure to do so will result in leaking system resources.
      */
-    getFileProviderServicesForItemAtURL$completionHandler$(url: _NSURL, completionHandler: NobjcObject): void;
+    getFileProviderServicesForItemAtURL$completionHandler$(url: _NSURL, completionHandler: NobjcObject | null): void;
     /** Available for OS X in 10.8.3. */
     containerURLForSecurityApplicationGroupIdentifier$(groupIdentifier: _NSString): _NSURL | null;
     homeDirectoryForUser$(userName: _NSString): _NSURL | null;

package/dist/Foundation/NSFilePresenter.d.ts

@@ -7,23 +7,23 @@ export interface _NSFilePresenter {
     /**
      * Given that something in the system is waiting to read from the presented file or directory, do whatever it takes to ensure that the application will behave properly while that reading is happening, and then invoke the completion handler. The definition of "properly" depends on what kind of ownership model the application implements. Implementations of this method must always invoke the passed-in reader block because other parts of the system will wait until it is invoked or until the user loses patience and cancels the waiting. When an implementation of this method invokes the passed-in block it can pass that block yet another block, which will be invoked in the receiver's operation queue when reading is complete. A common sequence that your NSFilePresenter must handle is the file coordination mechanism sending this message, then sending -savePresentedItemChangesWithCompletionHandler:, and then, after you have invoked that completion handler, invoking your reacquirer.
      */
-    relinquishPresentedItemToReader$?(reader: NobjcObject): void;
+    relinquishPresentedItemToReader$?(reader: NobjcObject | null): void;
     /**
      * Given that something in the system is waiting to write to the presented file or directory, do whatever it takes to ensure that the application will behave properly while that writing is happening, and then invoke the completion handler. The definition of "properly" depends on what kind of ownership model the application implements. Implementations of this method must always invoke the passed-in writer block because other parts of the system will wait until it is invoked or until the user loses patience and cancels the waiting. When an implementation of this method invokes the passed-in block it can pass that block yet another block, which will be invoked in the receiver's operation queue when writing is complete. A common sequence that your NSFilePresenter must handle is the file coordination mechanism sending this message, then sending -accommodatePresentedItemDeletionWithCompletionHandler: or -savePresentedItemChangesWithCompletionHandler:, and then, after you have invoked that completion handler, invoking your reacquirer. It is also common for your NSFilePresenter to be sent a combination of the -presented... messages listed below in between relinquishing and reacquiring.
      */
-    relinquishPresentedItemToWriter$?(writer: NobjcObject): void;
+    relinquishPresentedItemToWriter$?(writer: NobjcObject | null): void;
     /**
      * Given that something in the system is waiting to read from the presented file or directory, do whatever it takes to ensure that the contents of the presented file or directory is completely up to date, and then invoke the completion handler. If successful (including when there is simply nothing to do) pass nil to the completion handler, or if not successful pass an NSError that encapsulates the reason why saving failed. Implementations of this method must always invoke the completion handler because other parts of the system will wait until it is invoked or the user loses patience and cancels the waiting. If this method is not implemented then the NSFilePresenter is assumed to be one that never lets the user make changes that need to be saved. For example, NSDocument has an implementation of this method that autosaves the document if it has been changed since the last time it was saved or autosaved. That way when another process tries to read the document file it always reads the same version of the document that the user is looking at in your application. (WYSIWGCBF - What You See Is What Gets Copied By Finder.) A shoebox application would also implement this method. The file coordination mechanism does not always send -relinquishPresentedItemToReader: or -relinquishPresentedItemToWriter: to your NSFilePresenter before sending this message. For example, other process' use of -[NSFileCoordinator prepareForReadingItemsAtURLs:options:writingItemsAtURLs:options:error:byAccessor:] can cause this to happen.
      */
-    savePresentedItemChangesWithCompletionHandler$?(completionHandler: NobjcObject): void;
+    savePresentedItemChangesWithCompletionHandler$?(completionHandler: NobjcObject | null): void;
     /**
      * Given that something in the system is waiting to delete the presented file or directory, do whatever it takes to ensure that the deleting will succeed and that the receiver's application will behave properly when the deleting has happened, and then invoke the completion handler. If successful (including when there is simply nothing to do) pass nil to the completion handler, or if not successful pass an NSError that encapsulates the reason why preparation failed. Implementations of this method must always invoke the completion handler because other parts of the system will wait until it is invoked or until the user loses patience and cancels the waiting. For example, NSDocument has an implementation of this method that closes the document. That way if the document is in the trash and the user empties the trash the document is simply closed before its file is deleted. This means that emptying the trash will not fail with an alert about the file being "in use" just because the document's file is memory mapped by the application. It also means that the document won't be left open with no document file underneath it. A shoebox application would only implement this method to be robust against surprising things like the user deleting its data directory while the application is running. The file coordination mechanism does not always send -relinquishPresentedItemToReader: or -relinquishPresentedItemToWriter: to your NSFilePresenter before sending this message. For example, other process' use of -[NSFileCoordinator prepareForReadingItemsAtURLs:options:writingItemsAtURLs:options:error:byAccessor:] can cause this to happen.
      */
-    accommodatePresentedItemDeletionWithCompletionHandler$?(completionHandler: NobjcObject): void;
+    accommodatePresentedItemDeletionWithCompletionHandler$?(completionHandler: NobjcObject | null): void;
     /**
      * Given that something in the system is waiting to evict the presented file or directory, do whatever it takes to ensure that the eviction will succeed and that the receiver's application will behave properly when the eviction has happened, and then invoke the completion handler. This must include calling `+[NSFileCoordinator removeFilePresenter:]`. If successful, pass nil to the completion handler. If not successful, or to prevent the eviction of the file, throw an error that encapsulates the reason. Implementations of this method must always invoke the completion handler because other parts of the system will wait until it is invoked or until the user loses patience and cancels the waiting. If this method is not implemented, eviction will fail.
      */
-    accommodatePresentedItemEvictionWithCompletionHandler$?(completionHandler: NobjcObject): void;
+    accommodatePresentedItemEvictionWithCompletionHandler$?(completionHandler: NobjcObject | null): void;
     /**
      * Be notified that the file or directory has been moved or renamed, or a directory containing it has been moved or renamed. A typical implementation of this method will cause subsequent invocations of -presentedItemURL to return the new URL. The new URL may have a different file name extension than the current value of the presentedItemURL property. For example, NSDocument implements this method to handle document file moving and renaming. A shoebox application would only implement this method to be robust against surprising things like the user moving its data directory while the application is running. Not all programs use file coordination. Your NSFileProvider may be sent this message without being sent -relinquishPresentedItemToWriter: first. Make your application do the best it can in that case.
      */
@@ -45,7 +45,7 @@ export interface _NSFilePresenter {
     /**
      * Given that something in the system is waiting to delete a file or directory contained by the directory, do whatever it takes to ensure that the deleting will succeed and that the receiver's application will behave properly when the deleting has happened, and then invoke the completion handler. If successful (including when there is simply nothing to do) pass nil to the completion handler, or if not successful pass an NSError that encapsulates the reason why preparation failed. Implementations of this method must always invoke the completion handler because other parts of the system will wait until it is invoked or until the user loses patience and cancels the waiting. The file coordination mechanism does not always send -relinquishPresentedItemToReader: or -relinquishPresentedItemToWriter: to your NSFilePresenter before sending this message. For example, other process' use of -[NSFileCoordinator prepareForReadingItemsAtURLs:options:writingItemsAtURLs:options:error:byAccessor:] can cause this to happen.
      */
-    accommodatePresentedSubitemDeletionAtURL$completionHandler$?(url: _NSURL, completionHandler: NobjcObject): void;
+    accommodatePresentedSubitemDeletionAtURL$completionHandler$?(url: _NSURL, completionHandler: NobjcObject | null): void;
     /**
      * Be notified that a file or directory contained by the directory has been added. If this method is not implemented but -presentedItemDidChange is, and the directory is actually a file package, then the file coordination machinery will invoke -presentedItemDidChange instead. Not all programs use file coordination. Your NSFileProvider may be sent this message without being sent -relinquishPresentedItemToWriter: first. Make your application do the best it can in that case.
      */

package/dist/Foundation/NSFileProviderService.d.ts

@@ -5,6 +5,6 @@ export declare class _NSFileProviderService extends _NSObject {
     static alloc(): _NSFileProviderService;
     static new(): _NSFileProviderService;
     init(): _NSFileProviderService;
-    getFileProviderConnectionWithCompletionHandler$(completionHandler: NobjcObject): void;
+    getFileProviderConnectionWithCompletionHandler$(completionHandler: NobjcObject | null): void;
     name(): NSFileProviderServiceName;
 }

package/dist/Foundation/NSFileSecurity.d.ts

@@ -1,4 +1,5 @@
 import type { _NSCoder } from "./NSCoder.js";
+import type { _NSCopying } from "./NSCopying.js";
 import type { _NSObject } from "./NSObject.js";
 export declare class _NSFileSecurity extends _NSObject {
     static alloc(): _NSFileSecurity;
@@ -6,3 +7,5 @@ export declare class _NSFileSecurity extends _NSObject {
     init(): _NSFileSecurity;
     initWithCoder$(coder: _NSCoder): _NSFileSecurity | null;
 }
+export interface _NSFileSecurity extends _NSCopying {
+}

package/dist/Foundation/NSFileVersion.d.ts

@@ -27,7 +27,7 @@ export declare class _NSFileVersion extends _NSObject {
     /**
      * Asynchronously return an array of NSFileVersions associated with the file located by the given URL, or nil if there is no such file or another error occurs. Versions returned by this method do not initially have their contents stored locally on the device, so a download may be required before you are able to access them. File attributes are accessible via -[NSURL getPromisedItemResourceValue:forKey:error:]. You can request a download by performing a coordinated read with NSFileCoordinator on the URL property of the resulting NSFileVersions. When a version is successfully downloaded, its contents are cached locally, and the version will no longer be returned by this method. The version will be returned by +[NSFileVersion otherVersionsOfItemAtURL:] instead, but will retain the same persistentIdentifier value. If the local version is later discarded, future invocations of this method may resume returning the version. If you need to get all versions for a document, both local and non-local, you should use an NSFilePresenter that implements -presentedItemDidGainVersion: and -presentedItemDidLoseVersion: and invoke +[NSFileCoordinator addFilePresenter:], +[NSFileVersion otherVersionsOfItemAtURL:], and this method within a single coordinated read.
      */
-    static getNonlocalVersionsOfItemAtURL$completionHandler$(url: _NSURL, completionHandler: NobjcObject): void;
+    static getNonlocalVersionsOfItemAtURL$completionHandler$(url: _NSURL, completionHandler: NobjcObject | null): void;
     /**
      * For a file located by a URL, return the NSFileVersion identified by a persistent identifier of the sort returned by -persistentIdentifier, or nil if the version no longer exists.
      */
@@ -35,7 +35,7 @@ export declare class _NSFileVersion extends _NSObject {
     /**
      * Add a new version of the file located by a URL, with the contents coming from a file located by either the same or a different URL, and return a new instance that represents the version if successful. If not successful, return NO after setting *outError to an NSError that encapsulates why not. You can add versions only on Mac OS X. When adding or removing versions of a file you should do it as part of a "coordinated" write to the file. The NSFileCoordinator class that you use to do coordinated file access is declared in <Foundation/NSFileCoordinator.h>. Using it properly ensures that NSFilePresenters of the file, or directories that contain the file, receive accurate notifications about versions being added or removed. NSFilePresenter is declared in <Foundation/NSFilePresenter.h>. For example, use -[NSFileCoordinator coordinateWritingItemAtURL:options:error:byAccessor:] when the file URL and the contents url are the same. (NSFileVersion doesn't simply use NSFileCoordinator itself because that would be insufficient when the adding or removing of versions is part of a larger operation that should be treated as one coordinated file access.)
      */
-    static addVersionOfItemAtURL$withContentsOfURL$options$error$(url: _NSURL, contentsURL: _NSURL, options: NSFileVersionAddingOptions, outError: NobjcObject): _NSFileVersion | null;
+    static addVersionOfItemAtURL$withContentsOfURL$options$error$(url: _NSURL, contentsURL: _NSURL, options: NSFileVersionAddingOptions, outError: NobjcObject | null): _NSFileVersion | null;
     /**
      * Given a URL, create a new directory that is suitable for using as the container of a new temporary file that you will create and use with NSFileVersionAddingByMoving. This is useful when you want to create a new version of a file out of something other than the file's current contents, for example, the contents in memory of a document that has not yet been saved to its file. You must remove this directory when you are done with it, using -[NSFileManager removeItemAtURL:error:] for example.
      */
@@ -43,15 +43,15 @@ export declare class _NSFileVersion extends _NSObject {
     /**
      * Delete all of the versions associated with the file located by a URL, except for the current one, and return YES if successful. If not successful, return NO after setting *outError to an NSError that encapsulates why not. When removing versions of a file you should do it as part of a coordinated write to the file. The advice about this for +addVersionOfItemAtURL:withContentsOfURL:options:error: applies here too.
      */
-    static removeOtherVersionsOfItemAtURL$error$(url: _NSURL, outError: NobjcObject): boolean;
+    static removeOtherVersionsOfItemAtURL$error$(url: _NSURL, outError: NobjcObject | null): boolean;
     /**
      * If the passed-in URL locates a file, replace the file with a file whose contents are taken from the version but whose display name is taken from the file. If the passed-in URL does not locate a file then simply write one. If successful, return a URL that locates the resulting file; it may be different from the passed-in URL. The one exception to taking the display name from an existing file is if the version is of a different type than the overwritten file. In that case the file name extension will be taken from the version. (When file name extensions are being hidden in a user-friendly way this is not actually an exception.) If not successful, return NO after setting *outError to an NSError that encapsulates why not. When you use NSFileVersionReplacingByMoving you remove a version of the file, and should do it as part of a coordinated write to the file. The advice about this for +addVersionOfItemAtURL:withContentsOfURL:options:error: applies here too. When you use it to promote a version to a separate file you actually write to two files, and should do it as part of a coordinated write to two files, using -[NSFileCoordinator coordinateWritingItemAtURL:options:writingItemAtURL:options:error:byAccessor:], most likely using NSFileCoordinatorWritingForReplacing for the file you're promoting the version to.
      */
-    replaceItemAtURL$options$error$(url: _NSURL, options: NSFileVersionReplacingOptions, error: NobjcObject): _NSURL | null;
+    replaceItemAtURL$options$error$(url: _NSURL, options: NSFileVersionReplacingOptions, error: NobjcObject | null): _NSURL | null;
     /**
      * Delete the receiver's storage, and return YES if successful. If not successful, return NO after setting *outError to an NSError that encapsulates why not. Subsequent invocations of +versionsOfItemAtURL: won't include an NSFileVersion for a successfully removed version. You cannot use this method to delete the versioned file itself. This method always throws an exception when sent to the result of invoking +currentVersionOfItemAtURL:. Use -[NSFileManager removeItemAtURL:error:] for that instead. When removing versions of a file you should do it as part of a coordinated write to the file. The advice about this for +addVersionOfItemAtURL:withContentsOfURL:options:error: applies here too.
      */
-    removeAndReturnError$(outError: NobjcObject): boolean;
+    removeAndReturnError$(outError: NobjcObject | null): boolean;
     /**
      * The location of the receiver's storage, or possibly nil if the receiver's storage has been deleted. The storage is read-only. The URL will have an arcane path. You must not derive user-presentable text from it.
      */