Date   

Re: Accessing instance variables: Xcode warnings

Ben Kennedy
 

On 11 Dec 2020, at 11:02 am, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

Q1: "Direct" access to an instance variable bypasses its setter/getter methods, but otherwise what is wrong with it?
I haven't seen this warning myself (at least recently), but presumably it is intended to draw attention to the fact that you might be unintentionally avoiding the property accessors.

Q2: Sometimes using the underscore form, _mType, quiets the direct access warning; other times Xcode acts like it doesn't know what I'm referring to. What is the underscore intended for?
Do you have a `@synthesize` directive in the implementation? I believe that by default, `@synthesize` with no arguments will create backing store with the same name as the property. Typically, when the backing store is automatically created, it gets named with the underscore prefix. (You can achieve the same thing manually with `@synthesize mType=_mType;`.)

b


Re: Accessing instance variables: Xcode warnings

Alex Zavatone
 

_mType is the internal class scoped copy of it.

self. is safest. It’s wrapped with the get and set accessors.

On Dec 11, 2020, at 1:02 PM, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

I have an ObjC class that has an instance variable "property" declared as such:

@property (nonatomic,retain,nonnull) NSString *mType;

In a instance method of this class, I can refer to mType in various ways, with warnings:

mType "Instance variable 'mType' is being directly accessed"
_mType "Use of undeclared identifier '_mType'; did you mean 'mType'?"
self.mType (No warning, but is very slow if used in a loop. Needed for blocks)


Q1: "Direct" access to an instance variable bypasses its setter/getter methods, but otherwise what is wrong with it?

Q2: Sometimes using the underscore form, _mType, quiets the direct access warning; other times Xcode acts like it doesn't know what I'm referring to. What is the underscore intended for?

Yes I can turn the Xcode warnings off by deleting -Weverything, but I want to do the right thing...

-Carl






Accessing instance variables: Xcode warnings

Carl Hoefs
 

I have an ObjC class that has an instance variable "property" declared as such:

@property (nonatomic,retain,nonnull) NSString *mType;

In a instance method of this class, I can refer to mType in various ways, with warnings:

mType "Instance variable 'mType' is being directly accessed"
_mType "Use of undeclared identifier '_mType'; did you mean 'mType'?"
self.mType (No warning, but is very slow if used in a loop. Needed for blocks)


Q1: "Direct" access to an instance variable bypasses its setter/getter methods, but otherwise what is wrong with it?

Q2: Sometimes using the underscore form, _mType, quiets the direct access warning; other times Xcode acts like it doesn't know what I'm referring to. What is the underscore intended for?

Yes I can turn the Xcode warnings off by deleting -Weverything, but I want to do the right thing...

-Carl


Re: NSData -writeToFile: returns FALSE

Carl Hoefs
 

Interesting idea. That worked! I never knew that "Full Disk Access" even existed.

-Carl

On Dec 10, 2020, at 5:58 PM, Jon Gotow <gotow@stclairsoft.com> wrote:

Just out of curiosity - go to System Preferences > Security & Privacy > Full Disk Access, click on the padlock in the lower left corner to unlock, then drag your app to the list. Does that fix things?

- Jon


On Dec 10, 2020, at 6:54 PM, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

On Dec 10, 2020, at 5:16 PM, Shane Stanley <sstanley@myriad-com.com.au> wrote:

On 11 Dec 2020, at 11:59 am, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

Adding NSDesktopFolderUsageDescription forces the addition of a provisioning profile, et al.
No it doesn't. It's a simple Info.plist entry.
Ah, yes, you're right. I had added it to the .entitlements file.

I added it to the Info.plist file but no change in behavior...

-Carl


Re: NSData -writeToFile: returns FALSE

Jon Gotow
 

Just out of curiosity - go to System Preferences > Security & Privacy > Full Disk Access, click on the padlock in the lower left corner to unlock, then drag your app to the list. Does that fix things?

- Jon

On Dec 10, 2020, at 6:54 PM, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

On Dec 10, 2020, at 5:16 PM, Shane Stanley <sstanley@myriad-com.com.au> wrote:

On 11 Dec 2020, at 11:59 am, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

Adding NSDesktopFolderUsageDescription forces the addition of a provisioning profile, et al.
No it doesn't. It's a simple Info.plist entry.
Ah, yes, you're right. I had added it to the .entitlements file.

I added it to the Info.plist file but no change in behavior...

-Carl







Re: NSData -writeToFile: returns FALSE

Carl Hoefs
 

On Dec 10, 2020, at 5:16 PM, Shane Stanley <sstanley@myriad-com.com.au> wrote:

On 11 Dec 2020, at 11:59 am, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

Adding NSDesktopFolderUsageDescription forces the addition of a provisioning profile, et al.
No it doesn't. It's a simple Info.plist entry.
Ah, yes, you're right. I had added it to the .entitlements file.

I added it to the Info.plist file but no change in behavior...

-Carl


Re: NSData -writeToFile: returns FALSE

Shane Stanley
 

On 11 Dec 2020, at 11:59 am, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

Adding NSDesktopFolderUsageDescription forces the addition of a provisioning profile, et al.
No it doesn't. It's a simple Info.plist entry.

--
Shane Stanley <sstanley@myriad-com.com.au>
<www.macosxautomation.com/applescript/apps/>, <latenightsw.com>


Re: NSData -writeToFile: returns FALSE

Carl Hoefs
 

Yes, the NSError object is nil, but the return status from the invocation is FALSE. Since it's nil, I suspect some app environment issue...

-Carl

On Dec 10, 2020, at 3:10 PM, Steve Christensen via groups.io <punster=mac.com@groups.io> wrote:

I wasn’t clear from your description, but are you calling -writeToFile:options:error:? If so then I would expect that the error might give you at least some clue.

And I haven’t worked on macOS apps in years, but at east as a user I periodically see permissions alerts pop up on my 10.15 iMac asking if an app can write to the desktop, the documents folder, etc. Maybe related to that?


On Dec 10, 2020, at 12:31 PM, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

I think I might have an entitlements issue with my in-house macOS app (10.14). It needs to write to the user's ~/Desktop. NSData's -writeToFile: returns FALSE, even if I try to write to /tmp. Heck, even if I try to write to /dev/null.

I have App Sandbox=NO, and com.apple.security.files.user-selected.read-write=YES

Is there another entitlement I'm needing?

-Carl





Re: NSData -writeToFile: returns FALSE

Carl Hoefs
 

On Dec 10, 2020, at 3:21 PM, Shane Stanley <sstanley@myriad-com.com.au> wrote:

On 11 Dec 2020, at 7:31 am, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

Is there another entitlement I'm needing?
Do you have the relevant privacy string in your Info.plist file (NSDesktopFolderUsageDescription)?
Adding NSDesktopFolderUsageDescription forces the addition of a provisioning profile, et al.

Currently my settings are:

Automatically manage signing - No
Team - None
Provisioning Profile - None
Signing certificate - Sign to run locally

-Carl


Re: NSData -writeToFile: returns FALSE

Shane Stanley
 

On 11 Dec 2020, at 7:31 am, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

Is there another entitlement I'm needing?
Do you have the relevant privacy string in your Info.plist file (NSDesktopFolderUsageDescription)?

--
Shane Stanley <sstanley@myriad-com.com.au>
<www.macosxautomation.com/applescript/apps/>, <latenightsw.com>


Re: NSData -writeToFile: returns FALSE

Steve Christensen
 

I wasn’t clear from your description, but are you calling -writeToFile:options:error:? If so then I would expect that the error might give you at least some clue.

And I haven’t worked on macOS apps in years, but at east as a user I periodically see permissions alerts pop up on my 10.15 iMac asking if an app can write to the desktop, the documents folder, etc. Maybe related to that?

On Dec 10, 2020, at 12:31 PM, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

I think I might have an entitlements issue with my in-house macOS app (10.14). It needs to write to the user's ~/Desktop. NSData's -writeToFile: returns FALSE, even if I try to write to /tmp. Heck, even if I try to write to /dev/null.

I have App Sandbox=NO, and com.apple.security.files.user-selected.read-write=YES

Is there another entitlement I'm needing?

-Carl


NSData -writeToFile: returns FALSE

Carl Hoefs
 

I think I might have an entitlements issue with my in-house macOS app (10.14). It needs to write to the user's ~/Desktop. NSData's -writeToFile: returns FALSE, even if I try to write to /tmp. Heck, even if I try to write to /dev/null.

I have App Sandbox=NO, and com.apple.security.files.user-selected.read-write=YES

Is there another entitlement I'm needing?

-Carl


Re: Installer pkg built with Xcode 12.2 won't open in macOS 10.10 and 10.11

Mark Allan
 

Yeah, I've seen --deep causing problems in the past. I'm using `find` to traverse the directory structure and calling codesign on each file in turn.

I've worked out why the notarisation bit no longer works though - in another part of my script, it strips off extended attributes just before tar'ing up the directory. This is something that was necessary in the past because xattrs used to cause problems with Installer.app on OS X 10.6.8. Removing the line that strips them off allows the notarisation to succeed.

Sure enough, running `ls -la@` on the directory gives the following extended attributes on some files...curiously not on all files, even though all files are signed!
com.apple.cs.CodeDirectory 136
com.apple.cs.CodeRequirements 220
com.apple.cs.CodeRequirements-1 172
com.apple.cs.CodeSignature 9001

This must be new behaviour with Xcode 12.2 rather than macOS 11 specific, as it does the same thing on 10.15.

Sadly, it doesn't get me any closer to being able to create an Installer .pkg file which opens in 10.10 and 10.11 though.....

Mark

On 8 Dec 2020, at 5:39 pm, Jack Brindle via groups.io <jackbrindle=me.com@groups.io> wrote:

I agree with Quinn on this one. If you bring in any libraries, especially any that are previously codesigned, —deep WILL break their signing. With the addition of system extensions and imported libraries, it becomes very important to not modify or replace any of the previously-signed bundles/libraries, or your app will simply not work under Big Sur. Figuring out why Gatekeeper didn’t allow your app to launch can waste considerable time and sanity. Don’t ask how I know this…
I now make sure that we do not use —deep in our code signing, but instead walk the tree of all bundles/libraries and make sure they are signed, or if they are known to be previously signed, don’t re-sign them.

One other thing I have learned recently - for the first time, provisioning profiles are important on the Mac. All the things the iOS devs have gone through in learning how to handle them we will be going through over time. Gatekeeper has changed our world, and is much more stringent on Big Sur. Properly codesigning is the only way to tackle it.

Jack


On Dec 8, 2020, at 9:05 AM, Jon Gotow <gotow@stclairsoft.com> wrote:

On Dec 8, 2020, at 7:51 AM, Mark Allan <markjallan@gmail.com> wrote:

I'm beginning to think there's something wrong with the 'codesign' tool on macOS 11. One of my other build scripts for the same app iterates through a directory of additional binaries and libraries to codesign them prior to being archived. (find .... exec /usr/bin/codesign ... )
Yes, that was my point in my (overly long) reply earlier. The _only_ thing different about the two builds was in codesign. The apps were exactly the same otherwise. The failing copy of my app was signed with macOS 11.1's codesign on Apple Silicon, while the successful one was signed on an Intel machine running 11.1. So codesign has changed.

The codesign tool reports no error whilst signing, but the resulting archive fails notarisation because of a number of unsigned embedded files. Sometimes they all get signed correctly, sometimes one or more files are missed and don't end up getting signed.
In Quinn's unofficial post on the do's and don'ts of code signing, he says not to use the --deep argument, but instead create a script that signs all necessary executables from the inside out (see https://developer.apple.com/forums/thread/128166). Are you signing individual embedded files of your .pkg as necessary, or relying on --deep to do it for you?

- Jon










Re: Installer pkg built with Xcode 12.2 won't open in macOS 10.10 and 10.11

Ben Kennedy
 

On 8 Dec 2020, at 9:55 am, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

It’s now time to remind everyone why I like this tool so much.

https://github.com/chockenberry/Provisioning
FYI: this plugin no longer necessary; the functionality is now built in to MacOS.

(I don't know when it became standard, but I have no custom QL plugins any more on my 10.15 system and I get provisioning profile previews just fine.)

-ben


Re: Installer pkg built with Xcode 12.2 won't open in macOS 10.10 and 10.11

Jack Brindle
 

We are developing for non-App Store distribution. The app has a kext, which is being moved to a dext for Big Sur. The last big hurdle was getting the provisioning profile and entitlements right for Big Sur. The surprise was the need to add com.apple.application-identifier and com.apple.developer.team-identifier attributes to the entitlements file. These are automatically added by Xcode, but since we codesign externally, they were not in the file. They are now.

So, I am seeing it for pretty much all apps that need things that must be specified in a provisioning profile on the Mac. Primarily these are system extensions at the moment.

Jack


On Dec 8, 2020, at 11:58 AM, Sak Wathanasin <sw@...> wrote:



On 8 Dec 2020, at 17:39, Jack Brindle via groups.io <jackbrindle@...> wrote:

One other thing I have learned recently - for the first time, provisioning profiles are important on the Mac. All the things the iOS devs have gone through in learning how to handle them we will be going through over time. Gatekeeper has changed our world, and is much more stringent on Big Sur. Properly codesigning is the only way to tackle it.

Does this apply generally or just for AppStore apps?

Sak



Re: Installer pkg built with Xcode 12.2 won't open in macOS 10.10 and 10.11

Alex Zavatone
 

Sak, it might be worthwhile to make a clone of your working OS to an external and try updating that to 11. Or install VMWareFusion, and run the OS in a VM so that you can have the same OSes on your CI machine and just fire it up when needed.

Cheers,
Alex Zavatone

On Dec 8, 2020, at 1:57 PM, Sak Wathanasin <sw@...> wrote:



On 8 Dec 2020, at 10:49, Mark Allan <markjallan@...> wrote:

Surely that means 10.10 is able to handle SHA 256.



Not necessarily: I think the 10.15 codesign generates both SHA1 & SHA256 sigs, and the macOS 11 codesign on the TDK at least only generates SHA256.

I've been follwoing this thread with great interest since pur apps have pretty similar requirements. At the moment none of our build boxes are running macOs 11.x, but we may have to update at least 1 to support iOS builds.

So, this afternoon, I tried building our (macOS) app on the DTK box (running 11.0.1). So far, I'd only been using it for testing, so had to install Xcode 12.2, the certs etc etc. Our app also has embedded dylibs, Finder sync extension, privileged helper tool etc all of which is signed from the inside-out by a build script written in python. The script also (optionally) notarizes the built packages.

The good news is that it all still works: the resulting package is notarized and stapled; the bad news is that, as expected, the package will not open in 10.11 (and presumably earlier).

I'm not sure why your script has trouble with the signing - some difference in behaviour between zsh & bash possibly? Does signing the recalcitrant dylibs in the Terminal work?

 Regards
Sak Wathanasin
Network Analysis Limited           http://www.network-analysis.ltd.uk



Re: Installer pkg built with Xcode 12.2 won't open in macOS 10.10 and 10.11

Sak Wathanasin
 



On 8 Dec 2020, at 17:39, Jack Brindle via groups.io <jackbrindle@...> wrote:

One other thing I have learned recently - for the first time, provisioning profiles are important on the Mac. All the things the iOS devs have gone through in learning how to handle them we will be going through over time. Gatekeeper has changed our world, and is much more stringent on Big Sur. Properly codesigning is the only way to tackle it.

Does this apply generally or just for AppStore apps?

Sak


Re: Installer pkg built with Xcode 12.2 won't open in macOS 10.10 and 10.11

Sak Wathanasin
 



On 8 Dec 2020, at 10:49, Mark Allan <markjallan@...> wrote:

Surely that means 10.10 is able to handle SHA 256.



Not necessarily: I think the 10.15 codesign generates both SHA1 & SHA256 sigs, and the macOS 11 codesign on the TDK at least only generates SHA256.

I've been follwoing this thread with great interest since pur apps have pretty similar requirements. At the moment none of our build boxes are running macOs 11.x, but we may have to update at least 1 to support iOS builds.

So, this afternoon, I tried building our (macOS) app on the DTK box (running 11.0.1). So far, I'd only been using it for testing, so had to install Xcode 12.2, the certs etc etc. Our app also has embedded dylibs, Finder sync extension, privileged helper tool etc all of which is signed from the inside-out by a build script written in python. The script also (optionally) notarizes the built packages.

The good news is that it all still works: the resulting package is notarized and stapled; the bad news is that, as expected, the package will not open in 10.11 (and presumably earlier).

I'm not sure why your script has trouble with the signing - some difference in behaviour between zsh & bash possibly? Does signing the recalcitrant dylibs in the Terminal work?

 Regards
Sak Wathanasin
Network Analysis Limited           http://www.network-analysis.ltd.uk


Xcode and device management.

Alex Zavatone
 

A few days ago, I noticed that my iOS devices which do not have automatic update enabled automatically updated themselves to iOS 14.2.

As I still have a fair amount of 32 bit software that I rely on, some of my macs are still running macOS 10.14.6 and Xcode 11.3, limiting the ability to build to a maximum of iOS 13.2 and not able to build directly to these devices.

I can’t be the only person who has this problem.

Do any of you out there have strategies for
- downgrading iOS to a specific version with an Apple supported IPSW?
- adding the libraries from Xcode 12.2 to a previous version of Xcode so that they can target iOS 14.2?

Thanks in advance.
Alex Zavatomne


Re: Installer pkg built with Xcode 12.2 won't open in macOS 10.10 and 10.11

Alex Zavatone
 

On Dec 8, 2020, at 11:39 AM, Jack Brindle via groups.io <jackbrindle=me.com@groups.io> wrote:


One other thing I have learned recently - for the first time, provisioning profiles are important on the Mac. All the things the iOS devs have gone through in learning how to handle them we will be going through over time. Gatekeeper has changed our world, and is much more stringent on Big Sur. Properly codesigning is the only way to tackle it.

Jack
It’s now time to remind everyone why I like this tool so much.

https://github.com/chockenberry/Provisioning

It lets you select a provisioning profile in the Finder and press the space bar to preview its contents. It also works on certs.

There are some newer forks of the repo which may be more useful, but this has been a godsend for me in the past.

Cheers,
Alex Zavatone

161 - 180 of 1432