Re: Substitute for kill(2)?

[Jack Brindle via Cocoa-dev]

I would agree with the use of Distributed Notifications, but there is a new 
limitation that was added a few years ago. The receiver must be in the same 
login. You can no longer use it to send notifications from one user app to a 
different user’s app. This came to light for me when I was trying to send a 
notification from a root app to a user app. Fear not, though, there is a form 
of Notification that works perfectly for this - CFNotifications. The two, of 
course, are closely related, but CFNotifications allow you to use the Darwin 
Notification Center which allows cross-user notifications.

These are easy to use, and, I believe, still the best way to send info from one 
app to another in the Mac system. 

Jack


> On Jul 25, 2023, at 9:38 AM, Rob Petrovec via Cocoa-dev 
>  wrote:
> 
> NSDistributedNotificationCenter is a way to send a notification out across 
> the system. Only processes that are listening for the notification will 
> receive it and have a chance to do something with it. It’s like yelling out 
> in a crowded room to tell a single person something. Everyone will hear your 
> message, but only one will be listening. Make sense?  
> https://developer.apple.com/documentation/foundation/nsdistributednotificationcenter?changes=_4=objc
> 
> But what it really sounds like you want to use XPC (Cross Process 
> Communication) for a more targeted messaging (possibly with payloads) between 
> your app and menuling.  
> https://developer.apple.com/documentation/xpc?language=objc
> 
> —Rob
> 
> 
>> On Jul 25, 2023, at 7:51 AM, Gabriel Zachmann  wrote:
>> 
>> Thanks a lot for your responses!
>> 
>> Sorry for the misunderstanding: I don't want to kill the other process.
>> (In case you forgot: the kill(2) system call is for sending unix signals to 
>> processes, which can listen to those signals (at least, most of them). I 
>> just want to signal the other process, not really kill it. So, SIGUSR1 
>> would've been my choice, if macOS would allow me to send a signal.)
>> 
>> What do you mean by "distributed notification" ?
>> How would I send it?
>> 
>> Best regards, Gabriel
>> 
>> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/jackbrindle%40me.com
> 
> This email sent to jackbrin...@me.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Proper way to retrieve the NSScreenNumber in a screen saver ?

[Jack Brindle via Cocoa-dev]

The NSScreen screen property is nullable.  From the docs for NSWindow screen:

"The value of this property is the screen where most of the window is on; it is 
nil when the window is offscreen."

I would go with Steve’s suggestion as much as possible, The NSScreen class has 
the info you need.

Jack


> On Nov 17, 2022, at 10:44 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> In my screensaver (macOS), 
> I am trying to retrieve the 'screen number' (NSScreenNumber) for the screen 
> on which I am running.
> 
> So, in   
> - (void) viewWillMoveToWindow: (NSWindow *) newWindow
> I have this line of code:
> displayID_ = [ [[newWindow screen] deviceDescription] objectForKey: 
> @"NSScreenNumber"];
> 
> This sometimes works (I get the correct screen number),
> and sometimes it does not, i.e., I get displayID_ = nil!
> (Usually after invoking some other screen savers in System Preferences.)
> 
> I don't see a pattern.
> 
> Curiously, these lines in viewWillMoveToWindow always work:
> 
>for ( NSScreen * s in [NSScreen screens] )
>{
>NSDictionary * device_description = [s 
> deviceDescription];
>NSNumber * n = [device_description objectForKey: @"NSScreenNumber"];
>   [...]
>}
> 
> I always get non-null and correct 'screen numbers' n.
> 
> 
> So, I am wondering, why does the first line sometimes NOT work?
> And what is the proper way to retrieve the screen number on which my screen 
> saver is running?
> Should I use [NSScreen mainScreen] ?
> 
> Please note, that there might be several monitors attached to the Mac!
> (Some users have up to 6)
> 
> Thanks a lot in advance.
> 
> Best regards, Gabriel
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/jackbrindle%40me.com
> 
> This email sent to jackbrin...@me.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Retrieving the EXIF date/time from 250k images

[Jack Brindle via Cocoa-dev]

Instead of using NSOperationQueue, I would use GCD to handle the tasks. Create 
a new Concurrent queue (dispatch_queue_create(DISPATCH_QUEUE_CONCURRENT)), then 
enqueue the individual items to the queue for processing (dispatch_async(), 
using the queue created above). Everything can be handled in blocks, including 
the completion routines. As Christian says the problem then is that data may 
not be in the original order so you will probably want to sort the returned 
objects when done. This should significantly speed up the time to do the whole 
task.

Jack


> On Aug 16, 2022, at 12:26 PM, Steve Christensen via Cocoa-dev 
>  wrote:
> 
> You mentioned creating and managing threads on your own, but that’s what 
> NSOperationQueue —and the lower-level DispatchQueue— does. It also will be 
> more efficient with thread management since it has an intimate understanding 
> of the capabilities of the processor, etc., and will work to do the “right 
> thing” on a per-device basis.
> 
> By leveraging NSOperationQueue and then keeping each of the queue operations 
> focused on a single file then you’re not complicating the management of what 
> to do next since most of that is handled for you. Let NSManagedObjectQueue do 
> the heavy lifting (scheduling work) and focus on your part of the task 
> (performing the work).
> 
> Steve
> 
>> On Aug 16, 2022, at 8:41 AM, Gabriel Zachmann  wrote:
>> 
>> That is a good idea.  Thanks a lot!
>> 
>> Maybe, I can turn this into more fine-grained, dynamic load balancing (or 
>> latency hiding), as follows:
>> create a number of threads (workers);
>> as soon as a worker is finished with their "current" image, it gets the next 
>> one (a piece of work) out of the list, processes it, and stores the iso_date 
>> in the output array (dates_and_times).
>> Both accesses to the pointer to the currently next piece of work, and the 
>> output array would need to be made exclusive, of course.
>> 
>> Best regards, Gabriel
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/jackbrindle%40me.com
> 
> This email sent to jackbrin...@me.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Indexing broken for one project

[Jack Brindle via Cocoa-dev]

In Monterey, /tmp is now only writeable by root. It is quite possible that 
Xcode couldn’t write there for the indexing.

When you changed to a new account, it probably changed where the derived data 
went.

It used to be that /tmp was writeable by anyone. That change bit me recently as 
well. Security?

Jack


> On Feb 13, 2022, at 4:09 PM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
>> This seems to indicate an error somewhere in the Xcode prefs.
> 
> Oh, wow, maybe I have resolved the issue!
> 
> The Derived Data directory is set to /tmp (i have had that setting for years).
> 
> Now, in Xcode / Preferences / Locations / Derived Data / Advanced,
> I set Custom = Relative to Derived Data.
> (Before , it was set to Absolute.)
> I have no idea, why it would not do the indexing before, and exactly what the 
> setting "Absolute" means, 
> but it looks like now it's working! 
> 
> Thanks a million to you all!
> 
> Best regards, Gabriel
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/jackbrindle%40me.com
> 
> This email sent to jackbrin...@me.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: App can't be opened

[Jack Brindle via Cocoa-dev]

In 10.13 this is not a Notarization problem. It could be a quarantine problem, 
though. Have him move the application to any directory other than the one where 
he unzipped the app, then launch the app. That should remove the quarantine and 
allow him to run the app if that was the problem. The Applications folder is a 
good place to move these things.

Jack


> On Sep 9, 2021, at 12:45 PM, Rob Petrovec via Cocoa-dev 
>  wrote:
> 
> The text in an error dialog is typically a washed down version of the actual 
> error.  See if you can get the user to give you a sysdiagnose log, taken just 
> after reproducing the problem, so you can check out the .logarchive to see 
> what the actual error was from the system.  It should provide more insight 
> into what the problem actually is.
> 
> btw, if you sent the app as a zip file you should double check the 
> permissions on the app, including its bundle contents.  Your uid may not be 
> the same has the users uid, so the privs could be set to not allow anyone but 
> you to open it.  Thats why installers are better than sending the raw bits.
> 
> —Rob
> 
> 
>> On Sep 9, 2021, at 7:13 AM, Gabriel Zachmann via Cocoa-dev 
>> mailto:cocoa-dev@lists.apple.com>> wrote:
>> 
>> I have compiled my app for macOS 10.12, because one user runs macOS 10.13.
>> 
>> Now he reports that he gets the error message "app can't be opened due to a 
>> problem"
>> (the err message is in German, but I guess this is what it would say in 
>> English.)
>> 
>> The error message does NOT say ".. unidentified developer"
>> and it does NOT say ".. cannot check it for malicious software".
>> 
>> I have notarized my app using Xcode's Archive utility.
>> I sent the user the app as a zip file - if you want , you can try it for 
>> yourself:
>> 
>>   https://owncloud.informatik.uni-bremen.de/index.php/s/9i3DCYodkgHZeZw
>> 
>> It goes without saying that I can run the app from that very zip file on my 
>> Mac.
>> 
>> Does anyone have an idea what might be causing this funny error message?
>> 
>> Best, G.
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com 
>> 
>> 
>> This email sent to petr...@mac.com 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com 
> )
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com 
> 
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/jackbrindle%40me.com 
> 
> 
> This email sent to jackbrin...@me.com 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Scroller and not apple's mouse

[Jack Brindle via Cocoa-dev]

Apple made a change in Catalina to add a system preference to Show Scroll Bars: 
“Automatically based on mouse or trackpad”. This is now the default. I believe 
you are wanting an alternate choice - “When scrolling”.
Note that the user makes the selection as they wish, so trying to force them to 
an alternate will only alienate users, and is obviously not  good thing.

Jack


> On Apr 13, 2021, at 6:44 AM, Alex Zavatone via Cocoa-dev 
>  wrote:
> 
> And WHICH non-Apple mice are you using?
> 
> Sent from my iPhone
> 
>> On Apr 13, 2021, at 8:44 AM, Alex Zavatone  wrote:
>> 
>> Please show your code.  Otherwise, we have little to go on.
>> 
>> Sent from my iPhone
>> 
>>> On Apr 13, 2021, at 2:41 AM, Allan Odgaard via Cocoa-dev 
>>>  wrote:
>>> 
>>> Probably two things relevant here.
>>> 
>>> One is General in system preferences which look like this:
>>> 
>>> ![](cid:2C16BC1B-F302-426F-9F6A-665F55C99045@simplit.com "PastedImage.png")
>>> 
>>> A Magic Mouse may count as a “track pad” so if you have this setting to 
>>> automatic, the scrollers will only be shown when scrolling.
>>> 
>>> You can manually override the scroller setting: 
>>> https://developer.apple.com/documentation/appkit/nsscroller/1523591-scrollerstyle
>>> 
>>> The style it sounds like you prefer is NSScrollerStyleOverlay.
>>> 
>>> However, I would discourage you from changing this.
>>> 
>>> 
> On 13 Apr 2021, at 9:24, IOS NACSPORT via Cocoa-dev wrote:
 
 Hi,
 
 I connect any non-Apple mouse, turn off the Apple mouse and the scroll 
 shows, in it I can´t change the background color. I used swift and macOS. 
 Without another mouse, only magic mouse I can change this color without 
 problem.
 
 Regards
 
> El 12/4/21 a las 23:40, Jack Brindle escribió:
> What is the mouse, and is there any installed software involved that goes 
> with the mouse?
> 
> Jack
> 
> 
>> On Apr 12, 2021, at 12:30 AM, IOS NACSPORT via Cocoa-dev 
>>  wrote:
>> 
>> Hi,
>> 
>> I don't kown is the correct place, In a NSScroller, when I conect the 
>> external mouse, not apple's mouse, the scroll change and show always, 
>> the problem is that I can't change its background color. How could it? 
>> or at least make it clear.
>> 
>> 
>> Regards
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/jackbrindle%40me.com
>> 
>> This email sent to jackbrin...@me.com
 ___
 
 Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
 
 Please do not post admin requests or moderator comments to the list.
 Contact the moderators at cocoa-dev-admins(at)lists.apple.com
 
 Help/Unsubscribe/Update your Subscription:
 https://lists.apple.com/mailman/options/cocoa-dev/lists%2Bcocoa-dev%40simplit.com
 
 This email sent to lists+cocoa-...@simplit.com
>>> 
>>> ___
>>> 
>>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>> 
>>> Please do not post admin requests or moderator comments to the list.
>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>> 
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
>>> 
>>> This email sent to z...@mac.com
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/jackbrindle%40me.com
> 
> This email sent to jackbrin...@me.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: /Library/Application Support off limits?

[Jack Brindle via Cocoa-dev]

/Applications is owned by root, and has rwx privileges only for the system, and 
rx for group (admin) and all. This means you will need to have your installer 
(with root privileges) to create your company/application directory inside. 
As an alternative, you can certainly place your directory in /Users/Shared. 
That directory has rwx privileges for everyone. I believe it also has the 
sticky bit set, which means that the “user” that created the file(s) must be 
the one to delete them.

Both are good places to put things that must be shared among multiple users. 
Note that ~/Library/Application Support is not a good place for sharing things 
since it is not accessible by anyone but the ~ user.

Jack



> On Apr 14, 2021, at 11:26 AM, Marco S Hyman via Cocoa-dev 
>  wrote:
> 
> 
>> Our app isn't sandboxed, but when I try to create a "/Library/Application 
>> Support/NewFolder" folder in there I get the following message:
>> 
>> /*You don't have permission to save the file "NewFolder" in the folder 
>> "Application Support."*/
> 
> Yup.  You want ~/Library/Application Support/NewFolder for per user files.  
> Use FileManager.  In swift something like
> 
> let fileManager = FileManager.default
> let supportDir = fileManager.url(for: .applicationSupportDirectory,
> in: .userDomainMask,
> appropriateFor: nil,
> create: true)
> 
> that creates the app support directory for your app.  You can then append 
> NewFolder to the resulting URL and create it.
> 
> I *think* (never used it, might be wrong) if you replace .userDomainMask with 
> .localDomainMask you will get a URL available to all users on the local 
> machine.
> 
> There may be other options that are better suited to your use.
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/jackbrindle%40me.com
> 
> This email sent to jackbrin...@me.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to check signature and notarization?

[Jack Brindle via Cocoa-dev]

Quick followup:

Howard’s app: ArchiChect will do the job you need. The product page is at:

https://eclecticlight.co/32-bitcheck-archichect/

And it is free!

Jack


> On Apr 12, 2021, at 3:40 PM, Jack Brindle via Cocoa-dev 
>  wrote:
> 
> From the code sign man page:
> codesign --display --verbose=4 Terminal.app
> 
> replace Terminal.app with your application name (be sure to unzip first). The 
> information shown will tell you whether it is has a valid signature.
> You might try it on a few other apps just to see what that looks like.
> 
> Be sure that the customer copies the app from wherever they unzip it to the 
> Applications folder, or anyplace else. That will remove the quarantine on the 
> app.
> 
> As for checking Notarization, I don’t remember how, but there is a way. You 
> might explore the apps from Howard Oakley at his Eclectic Mac Light Company 
> web page. He has some very good tools that should show the security info.
> The URL: https://eclecticlight.co <https://eclecticlight.co/>
> 
> We distribute our app in zipped form (no dmg). It is in an installer app that 
> the user unzips, then runs, usually at the same place where they unzipped the 
> file. No problems with GateKeeper in over two years of Notarization so far.
> 
> Jack
> 
> 
> 
> 
>> On Apr 12, 2021, at 10:48 AM, Sean McBride via Cocoa-dev 
>>  wrote:
>> 
>> On Mon, 12 Apr 2021 18:36:12 +0200, Gabriel Zachmann via Cocoa-dev said:
>> 
>>> Is there a way to check that the signature and notarization is proper?
>>> Are there any other checks I can do to determine what is going wrong?
>> 
>> You might find this helpful:
>> 
>> <https://mjtsai.com/blog/2021/03/29/c0design-checker/>
>> 
>> Sean
>> 
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/jackbrindle%40me.com
>> 
>> This email sent to jackbrin...@me.com
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/jackbrindle%40me.com
> 
> This email sent to jackbrin...@me.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Scroller and not apple's mouse

[Jack Brindle via Cocoa-dev]

What is the mouse, and is there any installed software involved that goes with 
the mouse?

Jack


> On Apr 12, 2021, at 12:30 AM, IOS NACSPORT via Cocoa-dev 
>  wrote:
> 
> Hi,
> 
> I don't kown is the correct place, In a NSScroller, when I conect the 
> external mouse, not apple's mouse, the scroll change and show always, the 
> problem is that I can't change its background color. How could it? or at 
> least make it clear.
> 
> 
> Regards
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/jackbrindle%40me.com
> 
> This email sent to jackbrin...@me.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to check signature and notarization?

[Jack Brindle via Cocoa-dev]

From the code sign man page:
codesign --display --verbose=4 Terminal.app

replace Terminal.app with your application name (be sure to unzip first). The 
information shown will tell you whether it is has a valid signature.
You might try it on a few other apps just to see what that looks like.

Be sure that the customer copies the app from wherever they unzip it to the 
Applications folder, or anyplace else. That will remove the quarantine on the 
app.

As for checking Notarization, I don’t remember how, but there is a way. You 
might explore the apps from Howard Oakley at his Eclectic Mac Light Company web 
page. He has some very good tools that should show the security info.
The URL: https://eclecticlight.co 

We distribute our app in zipped form (no dmg). It is in an installer app that 
the user unzips, then runs, usually at the same place where they unzipped the 
file. No problems with GateKeeper in over two years of Notarization so far.

Jack




> On Apr 12, 2021, at 10:48 AM, Sean McBride via Cocoa-dev 
>  wrote:
> 
> On Mon, 12 Apr 2021 18:36:12 +0200, Gabriel Zachmann via Cocoa-dev said:
> 
>> Is there a way to check that the signature and notarization is proper?
>> Are there any other checks I can do to determine what is going wrong?
> 
> You might find this helpful:
> 
> 
> 
> Sean
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/jackbrindle%40me.com
> 
> This email sent to jackbrin...@me.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Several different NSUserDefaults in the same app?

[Jack Brindle via Cocoa-dev]

I agree with you, to an extent. NSUserDefaults is very good when used as a 
single-level repository for settings data. When you want to categorize the 
settings by using collections, it starts to show the same problems that a 
regular file has, except slightly worse. Collections are saved as an object, 
which means that the collection itself will be mutable when it is read (i.e. 
you can replace it), but the contents (nodes and leaves) are not. You must do a 
mutable deep copy into a local mutable collection before you are able to modify 
settings in the collection. At this point you are now managing the settings 
yourself. Of course, saving the data in a plist file has the same problem, 
except that you can read in a plist into a collection and have it be mutable 
without too much fuss. As soon as you start using collections in your settings 
you negate much of the benefits provided by NSUserDefaults, especially if the 
collections are very deep.

I have saved preferences using both methods - I prefer using the NSUserDefaults 
method, but I still keep a settings manager for the collections that are saved 
in the defaults. The system gives you the standard user defaults, and 
automatically keeps things like window frames in that version. It also provides 
a nice KVC/KVO facility that is a bit more difficult (but doable) with your own 
plist file. In short, just about everything that NSUserDefaults gives you, you 
can create yourself by saving your own settings plist file. For simple apps, it 
is a no-brainer to use NSUserDefaults. For a much more complex app, with 
multiple collections needed for settings, it is a much more difficult call - 
since you are already having to manage the settings yourself, it may actually 
becomes easier to save and read the settings file yourself.

The collection issue also plays a part in using defaults write to modify 
settings. To use it, the prefs file needs to be copied, collection extracted 
and placed into its own file, change made, then you can use defaults write to 
save it back. I would not put my QA people through that process.

As for populating the defaults, you still have to do that yourself with 
NSUserDefaults. The [NSUserDefaults registerDefaults:] method does that, If you 
are using collections, you still have to create the collection and save it in 
the NSDictionary you create to hand to registerDefaults. In my experience with 
large apps with complex settings, I already have created the managers for 
handling the settings, so this actually becomes less of a feature - the 
managers handle reading in the data and giving the user whatever settings they 
need. Adding a setting is very easy here.

As usual, in the Mac, there are multiple ways of doing things. Each has its own 
tradeoffs. The designer needs to consider the needs of that application in 
order to make the right choice for that app. If the app needs to save multiple 
collections of data, then it very well may be easier to save those collections 
in multiple files, something that NSUserDefaults in not designed to do.

By the way, I also know developers who use an SQLite database for their 
settings. It was the right way for their app...

Jack 

> On Apr 6, 2021, at 6:41 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> 
>> We don?t use NSUserDefaults in the app. Instead we have an 
>> NSMutableDictionary that holds the settings, and we write them to a file 
>> when they change. We read them in at app startup.
>> That allows us to actually have different settings for various items
> 
> Yes, that certainly works.
> 
> There is, however, a nice feature of NSUserDefaults that you will, I think, 
> loose,
> or that you will have to implement yourself by hand:
> when the app runs for the first time, NSUserDefaults gets populated by the 
> (real) defaults that come (more or less) hard-coded with your app.
> When a user changes one of those settings himself, then the system will know 
> that this is an actual user setting.
> Now, if you later change the values of the (real) defaults that come with the 
> app, maybe because the new default values are better,
> then those new defaults will take effect *except* for those settings that the 
> user has changed himself.
> 
>> (these are USB devices like mice and keyboards), and allows us to work 
>> around the restrictions of NSUserDefaults.
>> 
>> My only real issue with NSUserDefaults is that you cannot hand edit the 
>> prefs file since the system will overwrite your changes with its own cached 
>> data.
> 
> But you can always change them using the 'defaults' command , can't you?
> ('defaults write' even takes a plist as argument.)
> 
> 
> Best regards, Gabriel
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> 

Re: Several different NSUserDefaults in the same app?

[Jack Brindle via Cocoa-dev]

We don’t use NSUserDefaults in the app. Instead we have an NSMutableDictionary 
that holds the settings, and we write them to a file when they change. We read 
them in at app startup.
That allows us to actually have different settings for various items (these are 
USB devices like mice and keyboards), and allows us to work around the 
restrictions of NSUserDefaults.

My only real issue with NSUserDefaults is that you cannot hand edit the prefs 
file since the system will overwrite your changes with its own cached data. 
There was also a time in High Sierra
where changes in NSUserDefaults would trigger two KVO calls instead of just 
one. It caused interesting issues with analytics, making it look like the user 
triggered setting changes twice instead of just once.
Thankfully, Apple fixed that in Mojave.

Having said this, unless there are extenuating circumstances (like a 
requirement for multiple prefs files), I would rather use NSUserDefaults 
because of the facilities it gives us. Having a single file with a dictionary 
for each setting entity is a very valid way of doing things. It still means you 
have to write your own settings handler though, to maintain the individual 
settings dictionaries. It seems like the two approaches end up with the same 
amount of work either way.

Jack

> On Apr 4, 2021, at 8:01 AM, Richard Charles  wrote:
> 
> 
>> On Apr 4, 2021, at 4:50 AM, Mike Abdullah  wrote:
>> 
>>> From the docs - init returns an initialized NSUserDefaults object whose 
>>> argument and registration domains are already set up. This method does not 
>>> put anything in the search list. Invoke it only if you’ve allocated your 
>>> own NSUserDefaults instance instead of using the shared one.
>>> 
>>> So it appears that using alloc int does not return the shared instance.
>> 
>> Where in the docs do you read that? The current NSUserDefaults docs say 
>> contrary:
> 
> 
> Sorry for the confusion. It is older 10.9 documentation for the init method. 
> Apple depreciated initWithUser: and added initWithSuiteName: around this same 
> timeframe.
> 
> 
>> On Apr 4, 2021, at 12:15 AM, Jack Brindle via Cocoa-dev 
>>  wrote:
>> 
>> Gabriel;
>> 
>> It appears you are trying to get NSUserDefaults to do something that Apple 
>> doesn’t want it to do these days. Why not create your own defaults,
>> writing the data to a dictionary that is then written to a file that you 
>> save in the ~/Library/Preferences folder, with a name of your choice?
>> 
>> This does work in Big Sur, we use it ourselves. The down side is that you 
>> don’t have the nice (and infuriating) caching of defaults that the system 
>> provides.
>> Note that the system will still create the standard user defaults file for 
>> you, to save things like window positioning. But, you can save these things
>> yourself in your own files. Just make sure you don’t use the same file name 
>> as the system uses, or it will overwrite yours. You can modify it as you 
>> suggested previously, though.
> 
> 
> So Jack I am curious, do you use alloc then init or initWithSuiteName:nil or 
> initWithSuiteName:@“mySuiteName" to create your own defaults?
> 
> --Richard Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Several different NSUserDefaults in the same app?

[Jack Brindle via Cocoa-dev]

Gabriel;

It appears you are trying to get NSUserDefaults to do something that Apple 
doesn’t want it to do these days. Why not create your own defaults,
writing the data to a dictionary that is then written to a file that you save 
in the ~/Library/Preferences folder, with a name of your choice?

This does work in Big Sur, we use it ourselves. The down side is that you don’t 
have the nice (and infuriating) caching of defaults that the system provides.
Note that the system will still create the standard user defaults file for you, 
to save things like window positioning. But, you can save these things
yourself in your own files. Just make sure you don’t use the same file name as 
the system uses, or it will overwrite yours. You can modify it as you suggested 
previously, though.

Jack

> On Apr 3, 2021, at 11:26 AM, Richard Charles via Cocoa-dev 
>  wrote:
> 
> 
>> On Apr 3, 2021, at 9:56 AM, Gabriel Zachmann  wrote:
>> 
>> Sorry for asking: the shared instance is the one that is persistent, right?
> 
> 
> Looks like an instance created from alloc init would not be useful in your 
> situation. It appears you would be in charge of persistence.
> 
> NSUserDefault , Alloc init vs standard Userdefault
> 
> https://stackoverflow.com/questions/36615260
> 
> --Richard Charles
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/jackbrindle%40me.com
> 
> This email sent to jackbrin...@me.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Customizing the Notarization Workflow fails

[Jack Brindle via Cocoa-dev]

Before someone reminds me, be sure to use the Xcode global variables for all 
this work. You will find the build directory in one of the variables (it’s 
Saturday - I don’t remember right now, so I hope someone bales me out again).
You can then use that var in the Notarization script to get your final product.

Once you get the hang of Notarization, you will find it isn’t difficult. 
Getting there is, however.

Jack


> On Apr 25, 2020, at 6:23 PM, Jack Brindle via Cocoa-dev 
>  wrote:
> 
> It seems like it would be easier to find the Build directory’s releases 
> folder and the find the built product somewhere inside. It’s relation to the 
> Build directory won’t change from build to build. Once you find that, just 
> Notarize it in place. You need to make sure that it is already code/product 
> signed (with hardened runtimes enabled).
> 
> Sometimes doing things yourself is easier and simpler than having Xcode do it 
> for you.
> 
> Jack
> 
> 
>> On Apr 25, 2020, at 10:05 AM, Gabriel Zachmann via Cocoa-dev 
>>  wrote:
>> 
>> Thanks a lot for your response.
>> 
>>> I’m not sure how you would script the export, but if you go to menu option 
>>> Window ->  Organizer, you can see your archives.
>> 
>> Yes, I can see them.
>> But when I do "Show in Finder", then "Show package contents", they contain 
>> nothing
>> (except for an empty Products folder, and an Info.plist).
>> 
>>> From there you can export. Apps have the button “Distribute App”, and a 
>>> command line program has the button “Distrubute Content”.
>> 
>> Yes, screen savers have the “Distrubute Content” button, too.
>> 
>>> Clicking that button lets you export the archive or the app/built products. 
>>> Those are exported into a folder named with the date by default.
>> 
>> Yes, but they contain just an empty "Products" folder.
>> 
>> 
>> Best regards, Gabriel
>> 
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/jackbrindle%40me.com
>> 
>> This email sent to jackbrin...@me.com
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/jackbrindle%40me.com
> 
> This email sent to jackbrin...@me.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Customizing the Notarization Workflow fails

[Jack Brindle via Cocoa-dev]

It seems like it would be easier to find the Build directory’s releases folder 
and the find the built product somewhere inside. It’s relation to the Build 
directory won’t change from build to build. Once you find that, just Notarize 
it in place. You need to make sure that it is already code/product signed (with 
hardened runtimes enabled).

Sometimes doing things yourself is easier and simpler than having Xcode do it 
for you.

Jack


> On Apr 25, 2020, at 10:05 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> Thanks a lot for your response.
> 
>> I’m not sure how you would script the export, but if you go to menu option 
>> Window ->  Organizer, you can see your archives.
> 
> Yes, I can see them.
> But when I do "Show in Finder", then "Show package contents", they contain 
> nothing
> (except for an empty Products folder, and an Info.plist).
> 
>> From there you can export. Apps have the button “Distribute App”, and a 
>> command line program has the button “Distrubute Content”.
> 
> Yes, screen savers have the “Distrubute Content” button, too.
> 
>> Clicking that button lets you export the archive or the app/built products. 
>> Those are exported into a folder named with the date by default.
> 
> Yes, but they contain just an empty "Products" folder.
> 
> 
> Best regards, Gabriel
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/jackbrindle%40me.com
> 
> This email sent to jackbrin...@me.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Future of Cocoa

[Jack Brindle via Cocoa-dev]

I would add that for those of us developing for the Mac platform, the security 
sessions have been critical for the last two years. Without a good 
understanding of the issues discussed in those sessions, I don’t see how a 
developer's application could run properly on Catalina.

I see the WWDC sessions as part of my job as a Mac developer. Staying up to 
date on Mac developments is critical, otherwise I become stale and not as 
useful in my work. So, I do devote time to watching important Mac WWDC videos 
for things that I need to learn or be refreshed on.

Jack


> On Nov 21, 2019, at 1:08 PM, Jens Alfke via Cocoa-dev 
>  wrote:
> 
> 
> 
>> On Nov 21, 2019, at 12:20 PM, Pier Bover via Cocoa-dev 
>>  wrote:
>> 
>> If someone can afford days/weeks to do watch WWDC sessions consistently
>> every year it's great. That's not a luxury all of us can afford and it's
>> ridiculous to think this should be a requirement.
> 
> All you need to watch are the keynote, and the "State Of The Union" talks the 
> same day. That's maybe 3-4 hours. Or if you're really short on time you can 
> read the multitude of blog posts and news articles, or read through the text 
> transcripts of the talks after Apple posts those.
> 
> If you're developing for Apple platforms, you need to keep abreast of what's 
> happening on those platforms. That's just common sense. Tech moves fast, and 
> if you don't stay informed and stay educated, you'll be left behind.
> 
> —Jens
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/jackbrindle%40me.com
> 
> This email sent to jackbrin...@me.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Apple Notary Service returning false "Could not find the RequestUUID"

[Jack Brindle via Cocoa-dev]

Jerry;

Thanks for updating that info. Your info has helped a lot in my own 
notarization efforts.

The Notarization system consists of two parts - the front end that our scripts 
communicate with to request takes and get info, and a back-end that actually 
does the notarization work. When we get that error, it is the back-end that is 
down.
And the response is correct - the front end doesn’t know anything about that 
task, because no one is at home to tell it. The data is queued, and will run 
eventually when the back end comes back up. If you watch your history info over 
time, you will see the task complete. Still, when this happens it is 
aggravating. Adding a check for that error in the script really helps; at least 
it tells me why Notarization is taking so long. My scripts will then abort the 
request, and we will queue up a fresh build later.

The notarization service should be running just fine at present, at least that 
is what the developer status page is indicating: 
https://developer.apple.com/system-status/ 


Jack


> On Nov 2, 2019, at 2:43 PM, Jerome Krinock via Cocoa-dev 
>  wrote:
> 
> I think this list still has a lot of Mac developers.
> 
> Recently, and particularly today, Apple Notary Service has been returning 
> false errors code 1519 “could not find the RequestUUID” responses to 
> notification info requests which in fact contain good Request UUIDs.  One 
> short answer is to ignore this error and keep trying; after several hours, 
> the response will change to the expected “in progress” and shortly 
> thereafter, “success”.  I’m shipping several Developer ID apps and have seen 
> this happen 5 times so far today.
> 
> I’ve posted a longer answer here:
> 
> https://stackoverflow.com/questions/56890749/macos-notarize-in-script/56890758#56890758
> 
> Scroll down to "UPDATE 2019-11-03”.
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/jackbrindle%40me.com
> 
> This email sent to jackbrin...@me.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com