My App is a rather small menu-bar status-item app with 2 informational windows. It does NOT make use of ANY of the APIs mentioned here: https://developer.apple.com/forums/thread/663874 that are bound to need "Local Network" hence trigger TCC dialog.
Yet - on first run of the app, the dialog pops.
App is Obj-C, and the only APIs used are Notification-Center (for scheduling local notifications to the user), XPC connections and calls to other (our) apps for gathering that information, plus normal AppKit windowing (Controls, Text-fields, etc.) nothing else.
Obviously SOMETHING I do causes the thing - and I know for sure this app DOES NOT NEED access to the local network - only I do not know how to identify the specific API I need to avoid using (or change the way I'm using)
Are there any specific system logs to watch for?
Is there any official set of APIs that will trigger the dialog?
Provided that I cannot avoid this - could this permission be granted via MDM profile payload? Our product comes with
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Hi. My MacOS application (Obj-C, Cocoa MacOS 10.15 or later) sets itself as delegate for UNNotificationCenter, and implements both
- (void)userNotificationCenter:(UNUserNotificationCenter *)center
willPresentNotification:(UNNotification *)notification
withCompletionHandler:(void (^)(UNNotificationPresentationOptions))completionHandler
and
- (void)userNotificationCenter:(UNUserNotificationCenter *)center
didReceiveNotificationResponse:(nonnull UNNotificationResponse *)response
withCompletionHandler:(nonnull void (^)(void))completionHandler
It creates and schedules many user-notifications (mostly with no "trigger" meaning - present to the user ASAP and sometimes 2.5 seconds in the future, so to group notifications better.
Each notification is also holding som dictionary of "UserInfo" containing some data.
My AppDelegates handles user responses (both standard open, cancellation, and "cancel-all") and also custom user-actions I attach to the category.
All works well on most Macs and almost always.
However -
On few Macs, at arbitrary times, users complain that "clicking a notification in Notification Center will not open the app" and that "expected notifications are missing altogether".
My logs show the following. Quite frequently I see the following: error log lines:
2023-02-16 17:32:21.413065+0200 0xa58109d Error 0x0 51690 0 <UserNotifications`__104-[UNUserNotificationServiceConnection addNotificationRequest:forBundleIdentifier:withCompletionHandler:]_block_invoke_2.cold.1> myApp: (UserNotifications) [com.apple.UserNotifications:Connections] [com.myCompany.myApp] Adding notification request failed with error: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service on pid 451 named com.apple.usernotifications.usernotificationservice" UserInfo={NSDebugDescription=connection to service on pid 451 named com.apple.usernotifications.usernotificationservice}
followed by my own log lines - like this:
2023-02-16 17:32:21.413279+0200 0xa5811b5 Error 0x0 51690 10 <myApp> myApp: [com.myCompany.myApp:UI] NotificationRequest B6096CDE-6229-42AA-A6BC-EBCC06540C53 stage:scanFinished failed to schedule: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service on pid 451 named com.apple.usernotifications.usernotificationservice" UserInfo={NSDebugDescription=connection to service on pid 451 named com.apple.usernotifications.usernotificationservice}
Of course - the un-scheduled notification won't appear to the user, but worse -
clicks on other, DELIVERED notifications, won't call back my delegate.
Strangely enough - few seconds later, sometimes minutes - other attempts to schedule new notifications - succeed without any error. I guess this "connection" is somehow automatically re-established.
I looked for information about this error (Domain=NSCocoaErrorDomain Code=4097) and it seems to be pretty generic, and used for many scenarios where connection to some service is lost.
Of course my code doesn't maintain any such connection manually/programmatically - I guess it is the [UNUserNotificationCenter currentNotificationCenter] implementation which holds connection to its "daemon" or "agent" or some XPC service.
The really bad thing here - is that I DO NOT KNOW how to improve anything here.
[UNUserNotificationCenter currentNotificationCenter] Is a singleton, that I can't control, or re-create, to somehow revive the connection
There is no way I know of, to tell it to do so, or even to check whether it has a connection.
I rely on Notification-Center to maintain my MODEL DATA for scheduled requests, in case my App is relaunched - and now I can't get it.
Please advise. this is quite urgent for me.
The issue appears more on Big Sur.
Hi, I have a LaunchAgent (whose .plist is in /Library/LaunchAgents/ as expected)
It is build as a single un-bundled binary, and installed away from regular user access at /Library/MyCompany/executables/
When I try to init a reference to UNUserNotificationCenter:
UNUserNotificationCenter *unc = [UNUserNotificationCenter currentNotificationCenter];
I immediately have an exception, like thus:
2021-05-02 19:57:39.297823+0300 agent[12504:225879] *** Assertion failure in +[UNUserNotificationCenter currentNotificationCenter], /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/UserNotifications/UserNotifications-281.6/UNUserNotificationCenter.m:44
2021-05-02 19:57:39.299464+0300 agent[12504:225879] [General] An uncaught exception was raised
2021-05-02 19:57:39.299518+0300 agent[12504:225879] [General] bundleProxyForCurrentProcess is nil: mainBundle.bundleURL file:///Users/mshneor/Library/Developer/Xcode/DerivedData/agent-dgvdlbtivmsjdgdkhhjwaxgrkyht/Build/Products/Debug/
Obviously the problem is bundleProxyForCurrentProcess is nil: mainBundle.bundleURL
Now... I could try to bundle my agent somehow, but that's a bit awkward, and I don't know how - it's not an App, and It's not a part of any App, and I don't know about a special "Code Bundle" type (like plugins etc.) that fits a LaunchAgent. Moreover - it will never be "launched" by it's info.plist in the bundle - only via the .plist in /Library/LaunchAgents by launchd.
So... is it possible to work around this? Could I somehow tell my Agent's process "Here is our main-bundle" at runtime, and provide a special bundle the agent is not embedded in?
what does UNUserNotificationCenter need from main bundle? maybe I can supply this programmatically in advance?
Any hint will be greatly appreciated.
My new EndpointSecurity client code receives event messages of type esmessaget. These contain 3 time values.
struct timespec time;
uint64_t mach_time;
uint64_t deadline;
To interpret the deadline I refer to the mach_time. However, when I wish to log/formet/otherwise-consider the "wall time" where the event was created - I need to translate the timespec into NSDate (hmm... NSTimeInterval?) and I fail to find any documentation or hint about the right way to do so.
What I tried so far looks like this:
NSDate * timestamp = [NSDate dateWithTimeIntervalSince1970:(double)(message->time.tv_sec) + (double)(message->time.tv_sec) / 1E9 ];
which at least mathematically seems reasonable, but I'm not sure this is the right answer, and I don't know anything about the behaviour of timespec, its origin and accuracy, and whether or not it is consistent.
Can anyone shed a little light on the relation between these two time formats?
Thanks!
Topic:
App & System Services
SubTopic:
Drivers
Tags:
System Extensions
Endpoint Security
Objective-C