We have a pair of co-operating applications. The standard one maintains the main menu; there's also a login item (installed through +[SMAppService loginItemServiceWithIdentifier:]), which has its own GUI. To the user, both are presented as one application: very often, a login item's window is active while the standard app's main menu is presented (since login items cannot own the menu bar). Normally it works all right. Nevertheless, when the main menu is hidden (System Settings / Control Center / Automatically hide and show the menu bar: Always), sometimes (intermittently) it does not show. We have ascertained that the setup is all right, i.e., the login item is the current app all right (by our own logs; also, NSWorkspace.sharedWorkspace.frontmostApplication of an independent application shows our login item) the standard application owns the menu (again, by our logs, and NSWorkspace.sharedWorkspace.menuBarOwningApplication of an independent code shows our standard app). Yet, when the user brings the pointer to the top of the screen, nothing happens. Notably, when menu is not hidden, the proper menu bar (of the standard application) is shown all the time. Does anybody know what to do to fix the problem?

What do I miss here? root@MacBook-Pro /tmp # sw_vers ProductName: macOS ProductVersion: 13.6.1 BuildVersion: 22G313 root@MacBook-Pro /tmp # log config --mode "level: off" root@MacBook-Pro /tmp # log config --status System mode = INFO root@MacBook-Pro /tmp # log config --mode "level: debug" root@MacBook-Pro /tmp # log config --status System mode = DEBUG root@MacBook-Pro /tmp # log config --mode "level: off" root@MacBook-Pro /tmp # log config --status System mode = DEBUG

Our application (which happens to run in an admin account, thus there's no problem authenticating) collects logs calling /usr/bin/log through NSTask. Usually this works all right, but sometimes all we get is the header Timestamp Thread Type Activity PID TTL and nothing else. The tool finishes with a zero result code, we get nothing on stderr and just the header above on stdout, with a proper EOF (as determined by a zero-length availableData read from an NSFileHandle through the stdout pipe). At the same moment, if the /usr/bin/log tool is run manually in a Terminal window with precisely the same arguments in the same user account the application runs in, we get the logs all right. Any idea what might be the culprit and how to fix the problem? Thanks!

Lately, I've switched from NSLog to the new os_log. My problem is, whatever I try, I can't see the private values in my 13.6 (22G120). My test line is trivial os_log(OS_LOG_DEFAULT,"private shown: %@", [NSString stringWithFormat:@"OK"]); and it prints (both in Xcode and in Console) private shown: <private> I did install in Settings the appropriate profile (as found here, copied down, changed just my company info) — in vain, it did not help, not even after restarting my computer. For the record, the profile is shown below. Can anybody see what am I doing wrong and why it does not work? Thanks! <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>ConsentText</key> <dict> <key>default</key> <string>This will enable showing private strings and data in Unified Logs.</string> </dict> <key>PayloadContent</key> <array> <dict> <key>PayloadDisplayName</key> <string>ManagedClient logging</string> <key>PayloadEnabled</key> <true/> <key>PayloadIdentifier</key> <string>com.apple.system.logging.89AE58D8-0A4A-448B-8AE0-761DEE2D007F</string> <key>PayloadType</key> <string>com.apple.system.logging</string> <key>PayloadUUID</key> <string>89AE58D8-0A4A-448B-8AE0-761DEE2D007F</string> <key>PayloadVersion</key> <integer>1</integer> <key>System</key> <dict> <key>Enable-Private-Data</key> <true/> </dict> </dict> </array> <key>PayloadDescription</key> <string>Allows showing private log messages.</string> <key>PayloadDisplayName</key> <string>Allow Private Logs</string> <key>PayloadIdentifier</key> <string>cz.ocs.enable.private.logs</string> <key>PayloadOrganization</key> <string>OCSoftware</string> <key>PayloadRemovalDisallowed</key> <false/> <key>PayloadType</key> <string>Configuration</string> <key>PayloadUUID</key> <string>529DF49A-6CB3-4DE9-A29F-4C41EC88BFDD</string> <key>PayloadVersion</key> <integer>1</integer> </dict> </plist>

Our application is a login item which runs inactive in background, and in some cases, it shows its popovers in NSModalPanelWindowLevel over a window of an (unrelated) active application. That works well and without a glitch for years. Now we'd like to change the mouse cursor when the mouse is over some subviews of our popover. Is there a way to do that? I've tried essentially all the cursor-related APIs I know of, from the most obvious cursorRects through trackingAreas up to the low-level explicit NSCursor.push/set, but whatever I do, looks like macOS simply ignores it and keeps showing the arrow default cursor, even though the mouse is over our window whose views have proper cursorRects or explicitly call NSCursor.push/set etc. Is there a trick to change the cursor in this case? Thanks!

Our app suite supports autofill through the ASCredentialProviderViewController API, and it works well. We would like though to be also able to record a new login/password when the user enters them directly in his web browser, so that we can offer the pair for autofill the next time he opens the same page. Is there any API for that? Perhaps I'm just blind, but I can't find any. Thanks!

Hi there, the documentation explicitly says this is what's contentView for. I've just tried and found big problems not adding — works like a charm — but positioning my view so that it does not clash with the standard ones. I've added a small badge at the rightmost edge of contentView. Having added the subview into contentView (in tableView:cellForRowAtIndexPath:, after checking that it does not exist yet in a reused cell view), I set up constraints so that it is Y-centered and sticks to the right edge of the contentView, that was very easy and worked nicely at the first try: UILayoutGuide *lg=cell.contentView.layoutMarginsGuide; [badge.trailingAnchor constraintEqualToAnchor:lg.trailingAnchor].active=YES; [badge.centerYAnchor constraintEqualToAnchor:lg.centerYAnchor].active=YES; I've found though if the text in textLabel (I have to address iOS12+, thus I can't use content configurations) is long enough, it clashes with the badge instead of clipping/wrapping/whatever it is set to (wrapping in my case). Thus I've added another constraint which makes sure the trailing edge of textLabel does not exceed the leading edge of my badge: UILayoutGuide *blg=badge.layoutMarginsGuide; [cell.textLabel.trailingAnchor constraintLessThanOrEqualToAnchor:blg.leadingAnchor constant:-6].active=YES; Oops: that pushed the badge right, so that it overlaps the accessory area. By my further testing, seems the culprit is another constraint (probably created dynamically later from the autoresizing mask) which bounds the right edge of textLabel to the right edge of contentView. I've tried to find and remove (deactivate) it in tableView:cellForRowAtIndexPath:, in vain, well, makes some sense perhaps, too soon. I've tried to find and remove it in tableView:willDisplayCell:forRowAtIndexPath:; no luck either. To me, this does not make sense at all. (It sort of looks like the documentation claim “After the delegate returns, the table view sets only the alpha and frame properties, and then only when animating rows as they slide in or out” is highly overstated. Self-evidently, non-trivial layout stuff happens after the delegate returns, but before the cell is drawn.) Eventually, having used updateConstraints explicitly (which does not feel right), I succeeded to find the darn thing, a fixed width constraint for textLabel. Tried to deactivate it: does not work, setting its active property to NO does nothing, no warning, no error, no exception, thing just stays at YES. I've tried to decrease its priority, that's even more funny: it goes down, when checked, it is down, but 1000 is somehow re-surrected after tableView:willDisplayCell:forRowAtIndexPath: returns, but before the cell is finally laid out and drawn. Ick. What's the proper solution of this? I suppose it should be pretty easy, but it is not, or I must be overlooking something pretty obvious. Thanks!

Hi there, we use a UDP broadcast in our iOS application (sending to 255.255.255.255 through GCDAsyncUdpSocket, which boils down to simple send through an UDP socket). We have applied for and got the permission to use the com.apple.developer.networking.multicast entitlement and the application works all right. What confuses us is when testing, we seem to never see the Local Network authorization dialogue (as shown e.g., here). Perhaps I did overlook something in the documentation, but I wonder whether this is a normal behaviour, for Apple does not intentionally show this dialogue for the UDP broadcast? Or do we do something wrong at our side? Do we need to set NSLocalNetworkUsageDescription or not? Thanks for any insight, OC