If I use a SwiftUI Scrollview and scroll horizontally, for example, the scroll content goes underneath the inspector or sidebar views on macOS 26 (probably on older versions as well) But by default, the AppKit scrollviews don't exhibit this behaviour. How do I adapt this to match SwiftUI behavior?

Hello, we are currently integrating Writing Tools into our macOS application using NSWritingToolsCoordinator with a custom NSView. Overall, the integration is going well and we are generally satisfied with the API. However, text replacement is sometimes not using NSWritingToolsCoordinator callback function. When selecting “Replace” from a preview in a Writing Tools UI popup, the text replacement is performed via the NSTextInputClient callback function (insertText:), which does not seem correct. This is especially problematic in multi-context scenarios, because NSTextInputClient insertText: does not provide the required information about the Writing tools context being used. As a result, it is not possible to determine which context is being modified when managing more than a single context. In our view, Writing Tools should consistently use the callback function of NSWritingToolsCoordinator for text replacement, whatever is the action performed. This is essential for properly handling multi-context use cases. This issue is reproducible with the sample app project provided here https://developer.apple.com/documentation/appkit/enhancing-your-custom-text-engine-with-writing-tools. If you define a breakpoint in function writingToolsCoordinator:replaceRange:inContext:proposedText:reason:animationParameters:completion: of the Writing tools coordinator, the function is not triggered if text replacement is performed from a preview like for "Summary" with "replace" button. NSWritingToolsCoordinator callback function seems to be called only when text replacement is performed directly inline (in the text view) without external preview so. i have opened a issue with feedback assistant: FB22401950. Best regards.

Hello, we are currently integrating Writing Tools into our macOS application using NSWritingToolsCoordinator with a custom NSView. Overall, the integration is going well and we are generally satisfied with the API. However, text replacement is sometimes not using NSWritingToolsCoordinator callback function. When selecting “Replace” from a preview in a Writing Tools UI popup, the text replacement is performed via the NSTextInputClient callback function (insertText:), which does not seem correct. This is especially problematic in multi-context scenarios, because NSTextInputClient insertText: does not provide the required information about the Writing tools context being used. As a result, it is not possible to determine which context is being modified when managing more than a single context. In our view, Writing Tools should consistently use the callback function of NSWritingToolsCoordinator for text replacement, whatever is the action performed. This is essential for properly handling multi-context use cases. This issue is reproducible with the sample app project provided here https://developer.apple.com/documentation/appkit/enhancing-your-custom-text-engine-with-writing-tools. If you define a breakpoint in function writingToolsCoordinator:replaceRange:inContext:proposedText:reason:animationParameters:completion: of the Writing tools coordinator, the function is not triggered if text replacement is performed from a preview like for "Summary" with "replace" button. NSWritingToolsCoordinator callback function seems to be called only when text replacement is performed directly inline (in the text view) without external preview so. i have opened a issue with feedback assistant: FB22401950. Best regards.

I have a Document based app. It supports different document types. One document type my app supports conforms to another document type that my app also supports. In my app these two UTIs are designated to open different NSDocument subclasses / window controllers. So say we have these two UTIs: com.DocumentType.SuperType com.DocumentType.SubType. Now I just noticed on Tahoe 26.4, the system is launching my app using NSDocument/window controller that is designated for com.DocumentType.SuperType, when I double click a file with the com.DocumentType.SubType UTI. I haven't changed the NSDocument configuration in many years but it looks like something changed recently.

I have been using this block of Swift code for weeks with no problems. Then, today, every time I invoke it it fails: let openPanel = NSOpenPanel() openPanel.canChooseFiles = true openPanel.allowsMultipleSelection = false openPanel.canChooseDirectories = true openPanel.canCreateDirectories = false openPanel.title = NSLocalizedString("Open a CSV file", comment: "Open a CSV File") var result = NSApplication.ModalResponse.OK do { try result = openPanel.runModal() } catch { print("Open Panel failed: \(error)") return } if result == .OK { CSVFile = openPanel.url!.path } else { openPanel.close() print("No CSV file selected.") return } I get this message pointing to the .openModal expression: "Thread 1: Fatal error: Unexpectedly found nil while unwrapping an Optional value" It's a real head-scratcher!

I published the latest update of my AppKit app in September with macOS 26.0. I just wanted to create a new update, but compiling on macOS 26.4 now fails because of the symbol NSTextAttachment.character which is referenced in my code. The error is Type 'NSTextAttachment' has no member 'character' I've never experienced before that a symbol suddenly is not available anymore without even a deprecation notice from one OS release to the next, let alone a minor release. Is this a bug in macOS or Xcode, or should I start worrying about symbols becoming unavailable anytime?

Hi all, when I launch my macOS app from Xcode 16 on ARM64, appKit logs me this error on the debug console: It's not legal to call -layoutSubtreeIfNeeded on a view which is already being laid out. If you are implementing the view's -layout method, you can call -[super layout] instead. Break on _NSDetectedLayoutRecursion(void) to debug. This will be logged only once. This may break in the future. _NSDetectedLayoutRecursion doesn't help a lot, giving me these assembly codes from a call to a subclassed window method that looks like this: -(void) setFrame:(NSRect)frameRect display:(BOOL)flag { if (!_frameLocked) [super setFrame:frameRect display:flag]; } I have no direct call to -layoutSubtreeIfNeeded from a -layout implementation in my codes. I have a few calls to this method from update methods, however even if I comment all of them, the error is still logged... Finally, apart from that log, I cannot observe any layout error when running the program. So I wonder if this error can be safely ignored? Thanks!

When I end editing pressing the escape key, the system sometimes plays NSBeep(). I noticed this with NSBrowser. Every time I press escape to end editing the system beeps. At first I thought it was somewhere in my app but I set a symbolic breakpoint and discovered it was not coming from my code. I filed FB22127038. Since then I discovered that NSBeep playing at inappropriate times is not exclusive to NSBrowser. It appears if there is a NSTableView in the window and you just press the escape key (even if you aren't editing anything) AppKit beeps. It can be traced to: #0 0x0000000199e3184c in NSBeep () #1 0x000000019aa03fac in -[NSWindow doCommandBySelector:] () #2 0x000000019ac1d01c in -[NSTableView(NSTableViewViewBased) cancelOperation:] ()

We have a Mac app the allows customers to create a user account in our system. However, we have found that on the 'create account' screen, the system's password autofill is popping up for the "New Password" field. We don't want this, because they need to enter a new password, not pull one from the Passwords app. I built a test project with a basic UI and explicitly set the content type to None in the XIB. However, I can see when I put focus on the "New Password" NSSecureTextField, the system shows the passwords autofill popup. How can I explicitly suppress this on a per text field basis? (We are developing on macOS 26.3 right now with Xcode 26.3)

These days I've observed a strange behavior in my document-based app on macOS: Its NSDocument class implementation is overwriting "saveToURL:ofType:forSaveOperation:completionHandler:", performing some additional checks and calling super by passing the original parameters. As my app is supporting various file formats for writing (and exporting those UTIs) the user can open a file in one format and save it to another. NSDocument is calling the mentioned methods implicitly after completing the "Save as..." dialog. If this happens, the passed-on fileType is still the one of format #1, although the file is saved with the file name extension of format #2. This hick-up is not directly obvious to the user. But if the file is re-saved (e.g. after modifications), Cocoa is trying to extend the sandbox for the URL of type #1, and fails with the following error message at the Xcode console: -[STBDocument saveToURL:ofType:forSaveOperation:completionHandler:] [Line 521] typeName: com.janome.jef -[STBDocument saveToURL:ofType:forSaveOperation:completionHandler:] [Line 523] targetTypeUTI: com.tajima.dst NSFileSandboxingRequestRelatedItemExtension: Failed to issue extension for /Users/matthias/Desktop/Ohne Titel.jef because: Error Domain=NSPOSIXErrorDomain Code=3 "No such process" -[NSFileCoordinator itemAtURL:willMoveToURL:] could not get a sandbox extension. oldURL: file:///Users/matthias/Desktop/Ohne%20Titel.dst, newURL: file:///Users/matthias/Desktop/Ohne%20Titel.jef I'm currently fixing this issue by determining the UTType for the new file name extension and passing it to super. Unfortunately I have no idea how long this issue was already present, and cannot replicate it with a sample app based on Apple's Xcode 26 template (too many differences to my >15 years old app) - so I won't file a bug report. Take this post just for information in case someone else is facing a similar situation...

I'm building a document viewer on macOS Tahoe with a 3-column NSSplitViewController (sidebar | detail | inspector), trying to replicate how Preview displays PDFs with the page centered in the visible gap between the panels, with content bleeding under them when panning or zooming. I'm using the approach from Build an AppKit app with the new design (WWDC25): detailItem.automaticallyAdjustsSafeAreaInsets = true safeAreaInsets reports the correct values (e.g. left: 208, right: 240), and the frame does extend under both panels. But PDFView with autoScales = true anchors the page to the left edge of the window instead of centering it in the visible gap between the sidebar and inspector. I can get the page to center correctly by constraining PDFView to view.safeAreaLayoutGuide, but then content no longer extends under the panels when panning or zooming, which defeats the whole purpose. What's the correct way to center PDFView content within the visible gap while keeping the frame full-width so content bleeds under the panels? I've attached pictures of how Preview does it.

So if I have a selection in NSBrowser. I hit Option+Command+A to invoke "Deselect" the selection in the parent for the last column drops its selections, as expected. But the column doesn't drop off the browser. The delegate method (void)browser:(NSBrowser *)browser didChangeLastColumn:(NSInteger)oldLastColumn toColumn:(NSInteger)column NS_SWIFT_UI_ACTOR; Never fires (since the column isn't dropped off). But we have. dangling last column with no selection in the previous column. Now if there's enough room for me to deselect by clicking the background, the last column drops off, as expected. This seems to be fairly new? Anyone else experiencing this? These 26point updates seem to keep punching me in the face. And yes. deselect all seems somewhat broken in Column view in the Finder as well, but in a seemingly different way. In Finder it just seems to change the selection color like it deactivated the window but doesn't drop the selection. For me, the selection IS dropped but the column remains visible. Maybe they are using Cocoa bindings or something that resyncs the selection after the mess up. I dk.

I use QLThumbnailGenerator to generate icons. After updating to macOS Tahoe 26.4 the folder color preference of the user is no longer respected. It just makes the icon default 'light blue.'

So I just installed the 26.4 update and unfortunately I have to debug this newly introduced issue (that may work its way into a separate thread). In my debugging steps I'm testing something related to files and I used -activateFileViewerSelectingURLs: to show the file in Finder. Now I am off the main thread. I added this line for testing purposes and I get a crash: NSWindow should only be instantiated on the main thread!' terminating due to uncaught exception of type NSException. So apparently - NSWorkspace is calling through to NSServices APIs and for some reason the system wants to present an NSError, which is a subtopic and other bug on its own because the 'Show in Finder" functionality actually WORKS but it crashed my app! #22in +[NSAlert alertWithError:] () #23in -[NSApplication(NSErrorPresentation) presentError:] () #24 +[NSServicesMenuHandler _performServiceFromEntry:withPasteboard:withRequestor:withInvocationSourceType:withCarbonFocus:withSendTypes:withReturnTypes:canReleasePasteboardImmediately:] () #25 +[NSServicesMenuHandler _performServiceWithoutAlternatesFromEntry:withPasteboard:withRequestor:withInvocationSourceType:] () #26 +[NSServicesMenuHandler _performServiceFromEntry:withPasteboard:withRequestor:withInvocationSourceType:] () #27 [NSWorkspace activateFileViewerSelectingURLs:] What error it is trying to present.. I have no idea. I'm not sure if I actually have a code path that calls this method off the main thread but I guess I'll have to check. This clearly goes against the documentation. NSWorkspace documentation clearly states: -activateFileViewerSelectingURLs: Discussion You can safely call this method from any thread of your app. Is this new in 26.4? I'm not sure but I just noticed. I definitely use other NSWorkspace methods off the main thread in areas of my app. Like -activateFileViewerSelectingURLs: the documentation for those other methods claims you can safely call them off the main thread. So now I'm concerned.

Sort of a continuation of - https://developer.apple.com/forums/thread/813641 I've made a great effort to get NSURL -getResourceValue:forKey: calls etc off the main thread. Great progress. So now I'm working with a file on a really slow network volume I discovered a little hang and luckily enough I'm attached to the debugger so I paused that thing. I see where I'm at. It is: NSPathControl's setURL:. It goes a little something like this: in realpath$DARWIN_EXTSN () +fileSystemRealPath () +[FSNode(SandboxChecks) canAccessURL:withAuditToken:operation:] () +FSNode(SandboxChecks) canReadFromSandboxWithAuditToken:] () LaunchServices::URLPropertyProvider::prepareLocalizedNameValue () LaunchServices::URLPropertyProvider::prepareValues () prepareValuesForBitmap () FSURLCopyResourcePropertiesForKeysInternal () CFURLCopyResourcePropertiesForKeys () -[NSURL resourceValuesForKeys:error:] () in function signature specialization <Arg[1] = Dead> of Foundation._NSFileManagerBridge.displayName(atPath: Swift.String) -> Swift.String () in displayName () -[NSPathCell _autoUpdateCellContents] () -[NSPathCell setURL:] () Could maybe, NSPathControl get the display name etc. asynchronously? and maybe just stick raw path components in as a placeholder while it is reading async? Or something like that? If I can preload the resource keys it needs I would but once the NSURL asks on the main main thread I think it will just dump the cache out, per the run loop rules.

Since macOS 26 Beta 1, I notice that the window reopening behavior had changed. Say there are two desktops (spaces), one might: open an app window in desktop 1 close that window switch to desktop 2 reopen the app window (by click on dock tile, spotlight search...) Prior to macOS 26, that window will always reopen in current desktop. This is IMO the right behavior because these windows are most likely transient (message app, chat app, utilities app or note app). In macOS 26, however, will switch to desktop 1 (where the window is closed) and reopen the window in desktop 1. This is weird to me because: Window is "closed", hence it should not be attached to desktop 1 anymore, unlike minimize. Switching desktop interrupts user's current workflow. It's annoying to switch back specially when there're many desktops. This behavior is inconsistent. Some reopen in current desktop, some reopen in previous desktop. Apps like Music, Notes and Calendar reopened in previous desktop, while Mail, Messages, and Freeform reopened in current desktop. I did a little bit of experiment, and find out that apps that reopened in current desktop are most likely because they take an extra step to release the window when it's closed. I believe this is a bug, so I fire a feedback (FB18016497) back in beta 1. But I did not get any response or similar report from others, to a point that I kinda wonder if this is intended. I can easily force my app to reopen in current desktop by nullifying my window controller in windowWillClose, but this behavior essentially change how one can use the Spaces feature that I think I should bring this up to the community and see what other developers or engineers thinks about it.

I have regular NSImage from iPhone and the drawing get's extremely choppy during window resize (especially at small window sizes below 100px). When the window size is large there is no problem with drawing and CPU utilization is low. I have tried kCGImageSourceDecodeToSDR + or another NSImage from CGImage but the CPU utilization is extreme at small sizes. Non-HDR images don't have problems with drawing at small sizes. Video example: https://youtu.be/x8iAYGCyACs import AppKit import AVFoundation class ImageBackgroundView: NSView { @Invalidating(.display) var image: NSImage? = nil override var clipsToBounds: Bool { set { } get { true } } override func draw(_ dirtyRect: NSRect) { super.draw(dirtyRect) NSColor.red.setFill() dirtyRect.fill() guard let image = image else { return } // Calculate aspect-fit rect using AVFoundation let imageSize = image.size let targetRect = bounds let drawRect = AVMakeRect(aspectRatio: imageSize, insideRect: targetRect) image.draw(in: drawRect) } } Copy import Cocoa import UniformTypeIdentifiers class ViewController: NSViewController { @IBOutlet weak var imageView: ImageBackgroundView! @IBAction func buttonAction(_ sender: Any) { let panel = NSOpenPanel() panel.allowedContentTypes = NSImage.imageTypes.compactMap { UTType($0) } panel.begin { response in let nonHDROptions = [ kCGImageSourceDecodeRequest : kCGImageSourceDecodeToSDR, kCGImageSourceDecodeRequestOptions: [kCGComputeHDRStats: false] ] as CFDictionary guard response == .OK, let url = panel.url, let source = CGImageSourceCreateWithURL(url as CFURL, nil), let cgImage = CGImageSourceCreateImageAtIndex(source, 0, nonHDROptions) else { return } self.imageView.image = NSImage(cgImage: cgImage, size: NSMakeSize(CGFloat(cgImage.width), CGFloat(cgImage.height))) } } } Time profiler with HDR NSImage: Time profiler with NSImage + kCGImageSourceDecodeToSDR:

I have a textfield in accessory view of NSSavePanel. For user convenience there are default actions supported natively by macOS (such as pressing Enter, keyEquivalent). However this doesn't work for enter under Sonoma. Escape key works. Is enter keypress dangerous for malicious actors so it's not supported? I have workaround below but I am not confident if I am not violating sandbox (future proof). Original code demonstrating the issue: class ViewController: NSViewController, NSTextFieldDelegate, NSControlTextEditingDelegate { let savePanel = NSSavePanel() override func viewDidLoad() { super.viewDidLoad() let customView = NSView() let textField = NSTextField(string: "11111111") textField.delegate = self // to get focus using tab keypress savePanel.accessoryView = textField } override func viewWillAppear() { savePanel.runModal() } } Workaround: // variable set to true in delegate method controlTextDidEndEditing var didUseTextFieldWithEnterPressed = false override func performKeyEquivalent(with event: NSEvent) -> Bool { if #unavailable(macOS 14) { return super.performKeyEquivalent(with: event) } guard let panel, didUseTextFieldWithEnterPressed == true, event.type == .keyDown && (event.keyCode == UInt16(kVK_Return) || event.keyCode == UInt16(kVK_ANSI_KeypadEnter)) else { return super.performKeyEquivalent(with: event) } return panel.performKeyEquivalent(with: event) }

I have two NSTextField as an accessoryView of NSSavePanel. When I try to change focus in between them with a caps lock on the whole panel will crash. This will also happen when NSTextField if focused with caps lock on and i press cmd+tab (app switching). This happens on Sonoma + Sequoia beta. On top I have noticed editing NSTextField in accessoryView is completely broken on Sonoma and I can only edit it ONLY when the textfiled is using bindings. I am trying to find a workaround for the caps lock indicator being displayed. The only idea I have ATM is to observe NSApp.windows and look for TUINSWindow and force close it when it's visible. Is there any other workaround to prevent this crash? https://youtu.be/BCVjZH7684U Sample code: import Cocoa class ViewController: NSViewController { let savePanel = NSSavePanel() override func viewDidLoad() { super.viewDidLoad() let view = NSGridView(views: [[NSTextField(string: "111111")], [NSTextField(string: "22222222")]]) savePanel.accessoryView = view } override func viewWillAppear() { savePanel.runModal() } } Crash report: Cannot remove an observer <TUINSCursorUIController 0x600001844340> for the key path "visible" from <NSSavePanel 0x10ff05200> because it is not registered as an observer. ( 0 CoreFoundation 0x000000019a2522ec __exceptionPreprocess + 176 1 libobjc.A.dylib 0x0000000199d36158 objc_exception_throw + 60 2 Foundation 0x000000019b30436c -[NSObject(NSKeyValueObserverRegistration) _removeObserver:forProperty:] + 628 3 Foundation 0x000000019b3040a4 -[NSObject(NSKeyValueObserverRegistration) removeObserver:forKeyPath:] + 136 4 TextInputUIMacHelper 0x0000000253d9e598 -[TUINSCursorUIController deactivate:] + 416 5 AppKit 0x000000019dbda3e4 -[NSTextInputContext deactivate] + 288 6 AppKit 0x000000019da3fff4 +[NSTextInputContext currentInputContext_withFirstResponderSync:] + 228 7 AppKit 0x000000019da4f084 -[NSView _setWindow:] + 692 8 AppKit 0x000000019db7d880 -[NSTextView(NSPrivate) _setWindow:] + 216 9 AppKit 0x000000019e4da778 __21-[NSView _setWindow:]_block_invoke.146 + 268 10 CoreAutoLayout 0x00000001a2aba588 -[NSISEngine withBehaviors:performModifications:] + 88 11 AppKit 0x000000019da4f4b4 -[NSView _setWindow:] + 1764 12 AppKit 0x000000019da7712c -[NSView removeFromSuperview] + 168 13 AppKit 0x000000019dc7c0e8 -[_NSKeyboardFocusClipView removeFromSuperview] + 56 14 AppKit 0x000000019dbc5474 -[NSWindow endEditingFor:] + 368 15 AppKit 0x000000019da770d0 -[NSView removeFromSuperview] + 76 16 AppKit 0x000000019dc7c0e8 -[_NSKeyboardFocusClipView removeFromSuperview] + 56 17 AppKit 0x000000019dc7be00 -[NSCell endEditing:] + 452 18 AppKit 0x000000019dc7b994 -[NSTextField textDidEndEditing:] + 264 19 CoreFoundation 0x000000019a1d2144 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 148 20 CoreFoundation 0x000000019a2663d8 ___CFXRegistrationPost_block_invoke + 88 21 CoreFoundation 0x000000019a266320 _CFXRegistrationPost + 440 22 CoreFoundation 0x000000019a1a0678 _CFXNotificationPost + 768 23 Foundation 0x000000019b2bd2c4 -[NSNotificationCenter postNotificationName:object:userInfo:] + 88 24 AppKit 0x000000019dc7b5fc -[NSTextView(NSSharing) resignFirstResponder] + 668 25 AppKit 0x000000019db2ca80 -[NSWindow _realMakeFirstResponder:] + 196 26 AppKit 0x000000019dcc1764 -[NSWindow _makeParentWindowHaveFirstResponder:] + 76 27 ViewBridge 0x00000001a296c8c0 -[NSAccessoryViewWindow makeFirstResponder:] + 80 28 AppKit 0x000000019dbdbb9c -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 3148 29 AppKit 0x000000019db67504 -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 288 30 AppKit 0x000000019db67210 -[NSWindow(NSEventRouting) sendEvent:] + 284 31 ViewBridge 0x00000001a296cecc -[NSAccessoryViewWindow sendEvent:] + 64 32 AppKit 0x000000019e2304f0 -[NSApplication(NSEventRouting) sendEvent:] + 1604 33 AppKit 0x000000019dc6df6c -[NSApplication _doModalLoop:peek:] + 276 34 AppKit 0x000000019dc6ce38 __35-[NSApplication runModalForWindow:]_block_invoke_2 + 56 35 AppKit 0x000000019dc6cde4 __35-[NSApplication runModalForWindow:]_block_invoke + 108 36 AppKit 0x000000019dc6c6b0 _NSTryRunModal + 100 37 AppKit 0x000000019dc6c570 -[NSApplication runModalForWindow:] + 292 38 AppKit 0x000000019e690490 -[NSSavePanel runModal] + 340 39 SavePanelAccessory 0x0000000100435ad4 $s18SavePanelAccessory14ViewControllerC14viewWillAppearyyF + 60 40 SavePanelAccessory 0x0000000100435b0c $s18SavePanelAccessory14ViewControllerC14viewWillAppearyyFTo + 36 41 AppKit 0x000000019db387f4 -[NSViewController _sendViewWillAppear] + 32 42 AppKit 0x000000019db386bc -[NSViewController _windowWillOrderOnScreen] + 80 43 AppKit 0x000000019e4e7b38 -[NSView _windowWillOrderOnScreen] + 56 44 AppKit 0x000000019e4e7ba4 -[NSView _windowWillOrderOnScreen] + 164 45 AppKit 0x000000019db38570 -[NSWindow _doWindowWillBeVisibleAsSheet:] + 40 46 AppKit 0x000000019e4fc418 -[NSWindow _reallyDoOrderWindowAboveOrBelow:] + 1028 47 AppKit 0x000000019e4fcfec -[NSWindow _reallyDoOrderWindow:] + 64 SHORTENED

So I'm in the middle of an asynchronous file operation. I publish an NSProgress and it displays wonderfully in Finder. But it is a folder and while the operation is in progress the user should not be allowed to enter it, modify it, etc, while the work is being done. I want to do this to protect the user from doing something silly. But Finder does not prevent the selection with the published progress. And while it would be kind of dumb to do - the user can just go about adding/removing contents to the folder while it has progress. If I remember correctly publishing an NSProgress did use to prevent the file from being selectable in Finder until either the progress finished or my app is quit (or maybe not)? But now the user is free to select, edit, modify during progress which could cause problems if the user does something unexpectedly silly. Is there a way to mark the file 'unselectable' with the published progress? Thanks in advance.