Date   

Re: Code Signing

Leo
 

On Thu, Feb 11, 2021 at 08:06 PM, Jon Gotow wrote:
Take a look at this tool for a all-in-one command line:
Thanks, good to know someone made such a tool.

I do have my own utilities that automate the entire process as I release updates often (albeit not 28 in one day!)


Leo


Re: Code Signing

Shane Stanley
 

On 12 Feb 2021, at 3:07 pm, Jack Brindle via groups.io <jackbrindle=me.com@groups.io> wrote:

Another way to think of it - do you really want to be responsible for someone else’s code?
If I'm bundling it in my app, I already am.

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


Re: Code Signing

Jack Brindle
 

I would disagree. There are very specific circumstances where the embedded code must be signed by the original developer. Anything that is shared falls into this category. If you re-sign a shared third-party dext or sext you won’t get the behavior you want, and you will break other vendors applications. Another way to think of it - do you really want to be responsible for someone else’s code? In some cases you would be breaking the agreement you made to use that framework, bundle, tool, or other piece of code.

In general, if it comes signed, leave it that way and don’t overwrite it with another signature. You just might be breaking it. Worse, lawyers just might get involved...

Jack

On Feb 11, 2021, at 8:01 PM, Shane Stanley <sstanley@myriad-com.com.au> wrote:

On 11 Feb 2021, at 9:53 am, Jack Brindle via groups.io <jackbrindle=me.com@groups.io> wrote:

If you have any third party components, it will overwrite their signature with yours.
Which is what you generally want. The code in the bundle should all be signed with the same identity.

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






Re: Code Signing

Jon Gotow
 

Agreed - as I wait for 28 separate disk images to notarize (they're TTS Voice installers for a client).

Take a look at this tool for a all-in-one command line:

https://github.com/Mortennn/Notarize/releases/tag/1.0.0

So far it's worked pretty well for me. My only issue is that for the current project I'm doing, a full release involves 28 notarizations, and doing them serially with this tool takes an hour or two. So I'm back to having to roll my own scripts so that I can submit all of their installers at once.

- Jon

On Feb 11, 2021, at 8:56 PM, Leo <leo.r@rogers.com> wrote:

What we had to get instead is a single command line tool that would do everything notarization is supposed to do, whatever it is, in one take - and return a clear result (success or otherwise). This tool would take care of polling the results on Apple's server and deal properly with zip, dmg, app and whatever else would be fed to it. Developers really shouldn't be intimately involved in every minutia of the notarization process.


Re: Code Signing

Shane Stanley
 

On 11 Feb 2021, at 9:53 am, Jack Brindle via groups.io <jackbrindle=me.com@groups.io> wrote:

If you have any third party components, it will overwrite their signature with yours.
Which is what you generally want. The code in the bundle should all be signed with the same identity.

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


Re: Code Signing

Leo
 

I agree totally regarding the notarization.

It's a cumbersome, archaic, convoluted, ridiculous process unbecoming of Apple at all.

It was concocted by people who clearly didn't care about developers who'd have to implement it. 

The documentation was useless at best - and misleading at worst. It was written by people who just LOVE talking about notarization on and on and on in absurd lengths as it apparently turns them on. It wasn't written with a goal to clearly and concisely explain it to developers who are unfamiliar with the process.

It took absolutely enormous time to implement this bizarre process. Not to mention the extra time it now takes to post any new update.

What we had to get instead is a single command line tool that would do everything notarization is supposed to do, whatever it is, in one take - and return a clear result (success or otherwise). This tool would take care of polling the results on Apple's server and deal properly with zip, dmg, app and whatever else would be fed to it. Developers really shouldn't be intimately involved in every minutia of the notarization process. 

At least that's my take on it.


Cheers,
Leo


Re: Problems with exporting an archived app

James Walker
 

On Feb 11, 2021, at 8:15 AM, John Brownie <john_brownie@sil.org> wrote:

OK, more weirdness. It now works in Xcode 12, but the summary before export is blank, and yet I get a valid export. I guess the back and forth has removed some bad cached data or preference, and it's more or less working.
If you mean the “review zip content” page, I’ve been getting a blank for that for a while. I sent Apple a bug report, but couldn’t tell them how to reproduce it, so it will probably go into the bug black hole.


Re: Problems with exporting an archived app

Alex Zavatone
 

I'm always pressed for space on my computer, so I don't have enough spare space to have both versions installed. If this persists, I may have to work out what I can move to an external disk and have both available.
John, may I recommend several things to help you with computer space.

https://ingmarstein.github.io/Monolingual/

This app lets you remove language translations from apps for languages that you will never use. It’s generally good for a few GB.


As an Xcode developer, our drives get filled up way too easily. You can look in several places for several GB to recover.

For example, checking the ~/Library/Developer folder on this Mac shows that I’ve got 64 GB used in that folder.
33.23GB for the Xcode folder
30.67GB for the CoreSimulator folder

Within the ~/Library/Develope/Xcode folder, the big eaters of space are in iOS DeviceSupport from all OSes from 9.1 to 14.3 with 30 GB used. Check yours and see what can be thinned out.



There’s also a lovely trick that you can do if you have a fast external drive. Move your user folder to the external. This can also help with R/W performance as all reads & writes may be going through a separate bus than your system and apps. From the System Preferences, select Users & Groups. Click the lock to unlock and enter your password. Pressing control, click on your user name and select Advanced Options and then next to Home directory: click the Choose… button and select a folder on your external. All of your user data will be migrated to the external drive.

In the past I did this to test out moving my entire user folder to a RAM drive for nearly instant builds on iOS.

https://vimeo.com/172822499

You should also right click on Xcode and select Show Package Contents. View the directory as list, press command J and make sure to select Calculate all Sizes and then sort by Size in descending order.
/Contents/Developer/Platforms will be the largest folder.
Mine is 14GB
Look at all the platforms you never develop for and delete them.

MacOS also isn’t perfect. Look in /Library/Updates and see how large that folder is. Delete the contents if there is anything there you don’t need. I just found almost 2 GB of .pkg files sitting in there from 10.12.6.

Looking in /Library I just found another 700 MB for an old defunct install of MacOS Server from 2016 that I no longer need.

You can also do a quick check for duplicates or large files by performing a command F in the Finder, clicking + and searching for File Size that is > 1 GB. I’ve just found 3 copies of the same 80 GB sparseimage that can be nuked as well as a bunch of old 40 GB VMs.

I hope this helps. If you want, you can email me off list and I can give you a few more details if you wish to let me know which Mac you’re currently using. I’ve taken a few older MacBooks and added large internal SSDs without blowing the heat profile out of the water. Apple’s well on the way to making that impossible these days.


Re: Problems with exporting an archived app

John Brownie
 

OK, more weirdness. It now works in Xcode 12, but the summary before export is blank, and yet I get a valid export. I guess the back and forth has removed some bad cached data or preference, and it's more or less working.

John
--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland


Re: Problems with exporting an archived app

John Brownie
 

Glenn L. Austin wrote on 11/2/21 17:03:
Yes, M1 requires Xcode 12.
I got it to work by archiving in Xcode 12, then doing the distribute from Xcode 11.
I haven't done any QL plugins, but it's entirely possible that there's a bug in Xcode 12 where it's not recognizing the "older" QL structure.
Seems to be something like that.
I've got several versions of Xcode on my machine, and have never had to do the uninstall/reinstall dance - I either "xcode-select" the one I need if I'm going to working with it for a longer period of time, or if I'm just doing a couple of command-line processes, I "export DEVELOPER_DIR=" to the Xcode path. The "xcode-install" gem helps a lot with that as well.
I'm always pressed for space on my computer, so I don't have enough spare space to have both versions installed. If this persists, I may have to work out what I can move to an external disk and have both available.

John
--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland


Re: Problems with exporting an archived app

Steve Mills
 

On Feb 11, 2021, at 09:04, Glenn L. Austin <glenn@austinsoft.com> wrote:

I haven't done any QL plugins, but it's entirely possible that there's a bug in Xcode 12 where it's not recognizing the "older" QL structure.
Hmm, I wonder if that’s what’s causing my Xcode to crash when I submit a build to the App Store, only it has a Spotlight plugin, not a QL plugin. The crash log shows its trying to access an NSURL while building the package to upload (I assume), but it’s nil. I reported it, since it shouldn’t just crash, and it worked in previous Xcode, and other projects without plugins worked just the other day.

Steve via iPad


Re: Problems with exporting an archived app

Glenn L. Austin
 

Yes, M1 requires Xcode 12.

I haven't done any QL plugins, but it's entirely possible that there's a bug in Xcode 12 where it's not recognizing the "older" QL structure.

I've got several versions of Xcode on my machine, and have never had to do the uninstall/reinstall dance - I either "xcode-select" the one I need if I'm going to working with it for a longer period of time, or if I'm just doing a couple of command-line processes, I "export DEVELOPER_DIR=" to the Xcode path. The "xcode-install" gem helps a lot with that as well.

-- 
Glenn L. Austin, Computer Wizard and Race Car Driver         <><
<http://www.austinsoft.com>

On Feb 11, 2021, at 4:16 AM, John Brownie <john_brownie@...> wrote:

Stuck in a very time-consuming loop here. I removed Xcode 12, rebooted, installed Xcode 11.6, and the process doesn't complain in the same way for the older archive builds. But the new project was created with Xcode 12, so the project file is too new for Xcode 11.6, so I have to remove 11.6, reinstall 12.4, open the project and save it in an appropriate folder, then remove 12.4 again, install 11.6, and then I should be able to manage it... Limited disk space on my one machine makes it all rather a pain.

A horrible thought comes now: does Apple Silicon compatibility require Xcode 12? If so, I might have to try the archive in 12.4, then the export for distribution on 11.6. If that doesn't work, I don't know where to go next, other than perhaps dropping the QL generator.

John

Alex Zavatone via groups.io wrote on 10/2/21 19:39:
I keep old installers of Xcode around for just this reason.

Can you open this in an older version to see if it will successfully code sign?

On Feb 10, 2021, at 11:28 AM, John Brownie <john_brownie@...> wrote:

This gets weirder. I fixed the location of the QL plugin (should be Contents/Library/QuickLook, not Plugins), but it still failed with the same message. So I then got one of the older archived versions from the Organizer, and I get the same error message! Same with checking out an older version.

So that makes me think that it is either a newer version of macOS or Xcode that's doing it. I moved to Big Sur last week, and Xcode 12 quite some time ago, but this is probably the first time I'm aiming to do a release since moving to Xcode 12.

Any further ideas? All I can think of at the moment is that QuickLook plugins were changed in 10.15, and I only have the older technology at present. Does Big Sur require that I have both old and new?

John

Alex Zavatone via groups.io wrote on 10/2/21 16:24:
Somehow it thinks that the path to the app’s bundle is nil.  It’s a little hard to tell if it’s trying to find the target app name, or the folder for it (the bundle).

By any chance, did you delete a setting value while you were making your changes?  Can you check out a previous version of your app’s code to a different folder and do a diff on the project folders?  That should show you differences between the two and help narrow down your error.

You can also do that and only diff your .xcprroj file and that should show you the difference between what worked and what now fails to help you find the problem.

Cheers,
Alex Zavatone

On Feb 10, 2021, at 5:37 AM, John Brownie <john_brownie@...> wrote:

I've got a current version of my app out there, and want to do a bug release. Due to my own error, I changed the main repository to a sandboxed version, so I had to create a new project to build the current release, and this may be a consequence of not setting things up correctly.

Anyway, I successfully archived the app, but then I want to export it as a Developer ID app, and I get a fail with this error message (slightly redacted):

Failed to generate distribution items with error: Error Domain=IDEFoundationErrorDomain Code=1 "Didn't find executable for bundle NSBundle <(null)> (not yet loaded) at path <DVTFilePath:0x7fbf681b52c0:'/Users/john/Library/Developer/Xcode/Archives/2021-02-10/appname 10-2-21, 11.54.xcarchive/Products/Applications/appname.app/Contents/PlugIns/appname Quick Look Generator.qlgenerator'>."

Doing a web search for the error turns up either nothing at all (if I include up to "path") or nothing of use that I could see. The Quick Look Generator does exist at the specified path as a bundle which is pretty standard, of the form:
Contents
   __CodeSignature
      CodeResources
   MacOS
      appname Quick Look Generator
   Resources
      appnameQLResources.plist
   info.plist

I don't know where to look to find where the NSBundle <(null)> might be coming from. Can anyone point me in the right direction?

Thanks,
John
--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland








--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland










--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland







Re: Code Signing

Sak Wathanasin
 



On 10 Feb 2021, at 22:53, Jack Brindle via groups.io <jackbrindle@...> wrote:

There seems to be a steep learning curve, but once you are successful you will ask yourself why it took so long to figure out. 

Well, one reason is that it seems to me that the whole notarization process is unnecessarily complicated. For example, when there is some issue, you get back an email with a UUID that you then have to use with xcrun altool to get the URL for the error page. Hells bells! Couldn't they have put the URL into the notification email?

And why does the "stapling" have to be a separate step? The Notarization servrice knows whether it's worked or not, and can staple it (or not). Surely Apple must be aware that people use Bamboo/Hudson/Jenkins/whatever for CI builds, not just XCode Server?

I, for one, resent the amount of time and energy I had to spend tweaking our build scripts. I'll put some Bach on now and calm down...

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


Re: Problems with exporting an archived app

John Brownie
 

Stuck in a very time-consuming loop here. I removed Xcode 12, rebooted, installed Xcode 11.6, and the process doesn't complain in the same way for the older archive builds. But the new project was created with Xcode 12, so the project file is too new for Xcode 11.6, so I have to remove 11.6, reinstall 12.4, open the project and save it in an appropriate folder, then remove 12.4 again, install 11.6, and then I should be able to manage it... Limited disk space on my one machine makes it all rather a pain.

A horrible thought comes now: does Apple Silicon compatibility require Xcode 12? If so, I might have to try the archive in 12.4, then the export for distribution on 11.6. If that doesn't work, I don't know where to go next, other than perhaps dropping the QL generator.

John

Alex Zavatone via groups.io wrote on 10/2/21 19:39:

I keep old installers of Xcode around for just this reason.

Can you open this in an older version to see if it will successfully code sign?

On Feb 10, 2021, at 11:28 AM, John Brownie <john_brownie@sil.org> wrote:

This gets weirder. I fixed the location of the QL plugin (should be Contents/Library/QuickLook, not Plugins), but it still failed with the same message. So I then got one of the older archived versions from the Organizer, and I get the same error message! Same with checking out an older version.

So that makes me think that it is either a newer version of macOS or Xcode that's doing it. I moved to Big Sur last week, and Xcode 12 quite some time ago, but this is probably the first time I'm aiming to do a release since moving to Xcode 12.

Any further ideas? All I can think of at the moment is that QuickLook plugins were changed in 10.15, and I only have the older technology at present. Does Big Sur require that I have both old and new?

John

Alex Zavatone via groups.io wrote on 10/2/21 16:24:
Somehow it thinks that the path to the app’s bundle is nil. It’s a little hard to tell if it’s trying to find the target app name, or the folder for it (the bundle).

By any chance, did you delete a setting value while you were making your changes? Can you check out a previous version of your app’s code to a different folder and do a diff on the project folders? That should show you differences between the two and help narrow down your error.

You can also do that and only diff your .xcprroj file and that should show you the difference between what worked and what now fails to help you find the problem.

Cheers,
Alex Zavatone

On Feb 10, 2021, at 5:37 AM, John Brownie <john_brownie@sil.org> wrote:

I've got a current version of my app out there, and want to do a bug release. Due to my own error, I changed the main repository to a sandboxed version, so I had to create a new project to build the current release, and this may be a consequence of not setting things up correctly.

Anyway, I successfully archived the app, but then I want to export it as a Developer ID app, and I get a fail with this error message (slightly redacted):

Failed to generate distribution items with error: Error Domain=IDEFoundationErrorDomain Code=1 "Didn't find executable for bundle NSBundle <(null)> (not yet loaded) at path <DVTFilePath:0x7fbf681b52c0:'/Users/john/Library/Developer/Xcode/Archives/2021-02-10/appname 10-2-21, 11.54.xcarchive/Products/Applications/appname.app/Contents/PlugIns/appname Quick Look Generator.qlgenerator'>."

Doing a web search for the error turns up either nothing at all (if I include up to "path") or nothing of use that I could see. The Quick Look Generator does exist at the specified path as a bundle which is pretty standard, of the form:
Contents
__CodeSignature
CodeResources
MacOS
appname Quick Look Generator
Resources
appnameQLResources.plist
info.plist

I don't know where to look to find where the NSBundle <(null)> might be coming from. Can anyone point me in the right direction?

Thanks,
John
--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland





--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland






--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland


Re: Code Signing

Peter Hudson
 

Thanks Jack.



On 10 Feb 2021, at 22:53, Jack Brindle via groups.io <jackbrindle@...> wrote:

The answer is no. After an app is notarized you may not make any changes to the app bundle without rendering the app useless. That means you cannot store copy anything inside the app bundle after it is notarized.

It is easiest to sign and notarize an app within Xcode. If you cannot do that (perhaps you build from a script), then you will be using the codesign tool on the components of the app (or the app itself) to do the signing. Notarizing actually can help you with this. The process generates a report when it finds any signing issues within the app. Apple has three notes on Notarization that are well worth printing out - they contain lots of good info. 

Hints for signing using the codesign tool: don’t use —deep. If you have any third party components, it will overwrite their signature with yours. Use hardened runtime. Without it, you won’t notarize. Be sure to add Apple’s timestamp. Basically, follow the suggestions for signing that are outlined in the Notarization documents.

There seems to be a steep learning curve, but once you are successful you will ask yourself why it took so long to figure out. Learning how to interpret the notarization report is key, especially if your app is complex with lots of libraries and embedded tools (which all must be signed). When you run into problems, just ask. Lots of good resources here who have been through it before.

Jack


On Feb 10, 2021, at 9:53 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

Sorry didn’t explain properly Alex.  It is a macOS app.

The license issue is about whether, for now, I can sign the application with the license file in /Contents in the bundle.
Or, as each license is different, I need to place it outside the bundle. 

I couldn’t determine, from the docs to hand, whether putting the license in the bundle would be a problem in the context of signing.

I’ll share what unfolds !

Atb

Peter

 

On 10 Feb 2021, at 17:21, Alex Zavatone via groups.io <zav@...> wrote:



On Feb 10, 2021, at 10:23 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

Alex

Book suggestion looks good - have got a copy on the way !

Have been looking at the keychain as a home for the license file as part of the reorg for signing.

I’m not sure I understand.  Your license for a purchaser and the code signing should be two different things.  If you grant a license to a purchaser, then simply storing the license value in the keychain should be all you need for that, but you still will need to sort out code signing separately.

You also mentioned notarizing.   The book existed before that process, but the concepts in chapter 4 are foundational to wrap your head around code signing.

It just occurred to me that since you’re notarizing your app you need to code sign a Mac app. not an iOS one.  It’s still really important to understand the guts behind code signing and the book will help.

Here is a brief on Mac app notarizing that may help. 


Note the details about Hardened Runtime.  Is that enabled in your app?

Good luck.  Please share what you find.  

Alex Zavatone

Many thanks

Peter





On 10 Feb 2021, at 16:02, Alex Zavatone via groups.io <zav@...> wrote:

FYI, you should be storing the license in a more secure location such as the keychain.



On Feb 10, 2021, at 9:55 AM, Alex Zavatone via groups.io <zav@...> wrote:

Chapter 4 of Essential Build and Release by Ron Roche is what got me what I needed to learn.


Cheers,
Alex Zavatone




On Feb 10, 2021, at 9:48 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

All

I finally need to sign an app that has been running for some time.  I’m looking at what docs I can find and two questions emerge.

1.    Could anybody point me at the best instructions for code signing / notarisation - I have never done it before.
   I’ve looked at the docs in Xcode and they seem to raise more questions than they solve.

2.    I currently squirrel away the license file for each install in the Contents folder of the bundle. 
   The license file is a simple text file and is different for each install.
   I wondered if this is going to cause problems in the context of code signing ?


Many thanks

Peter
   
    











Re: Code Signing

Jack Brindle
 

The answer is no. After an app is notarized you may not make any changes to the app bundle without rendering the app useless. That means you cannot store copy anything inside the app bundle after it is notarized.

It is easiest to sign and notarize an app within Xcode. If you cannot do that (perhaps you build from a script), then you will be using the codesign tool on the components of the app (or the app itself) to do the signing. Notarizing actually can help you with this. The process generates a report when it finds any signing issues within the app. Apple has three notes on Notarization that are well worth printing out - they contain lots of good info. 

Hints for signing using the codesign tool: don’t use —deep. If you have any third party components, it will overwrite their signature with yours. Use hardened runtime. Without it, you won’t notarize. Be sure to add Apple’s timestamp. Basically, follow the suggestions for signing that are outlined in the Notarization documents.

There seems to be a steep learning curve, but once you are successful you will ask yourself why it took so long to figure out. Learning how to interpret the notarization report is key, especially if your app is complex with lots of libraries and embedded tools (which all must be signed). When you run into problems, just ask. Lots of good resources here who have been through it before.

Jack


On Feb 10, 2021, at 9:53 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

Sorry didn’t explain properly Alex.  It is a macOS app.

The license issue is about whether, for now, I can sign the application with the license file in /Contents in the bundle.
Or, as each license is different, I need to place it outside the bundle. 

I couldn’t determine, from the docs to hand, whether putting the license in the bundle would be a problem in the context of signing.

I’ll share what unfolds !

Atb

Peter

 

On 10 Feb 2021, at 17:21, Alex Zavatone via groups.io <zav@...> wrote:



On Feb 10, 2021, at 10:23 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

Alex

Book suggestion looks good - have got a copy on the way !

Have been looking at the keychain as a home for the license file as part of the reorg for signing.

I’m not sure I understand.  Your license for a purchaser and the code signing should be two different things.  If you grant a license to a purchaser, then simply storing the license value in the keychain should be all you need for that, but you still will need to sort out code signing separately.

You also mentioned notarizing.   The book existed before that process, but the concepts in chapter 4 are foundational to wrap your head around code signing.

It just occurred to me that since you’re notarizing your app you need to code sign a Mac app. not an iOS one.  It’s still really important to understand the guts behind code signing and the book will help.

Here is a brief on Mac app notarizing that may help. 


Note the details about Hardened Runtime.  Is that enabled in your app?

Good luck.  Please share what you find.  

Alex Zavatone

Many thanks

Peter





On 10 Feb 2021, at 16:02, Alex Zavatone via groups.io <zav@...> wrote:

FYI, you should be storing the license in a more secure location such as the keychain.



On Feb 10, 2021, at 9:55 AM, Alex Zavatone via groups.io <zav@...> wrote:

Chapter 4 of Essential Build and Release by Ron Roche is what got me what I needed to learn.


Cheers,
Alex Zavatone




On Feb 10, 2021, at 9:48 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

All

I finally need to sign an app that has been running for some time.  I’m looking at what docs I can find and two questions emerge.

1.    Could anybody point me at the best instructions for code signing / notarisation - I have never done it before.
   I’ve looked at the docs in Xcode and they seem to raise more questions than they solve.

2.    I currently squirrel away the license file for each install in the Contents folder of the bundle. 
   The license file is a simple text file and is different for each install.
   I wondered if this is going to cause problems in the context of code signing ?


Many thanks

Peter
   
    










Re: Xcode 12.4 crashes when trying to Distribute App or Validate App

Alex Zavatone
 

On Feb 10, 2021, at 3:20 PM, Steve Mills via groups.io <sjmills=mac.com@groups.io> wrote:

On Feb 10, 2021, at 14:25:58, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

Lots of this is detailed in chapter 4 of the book you just ordered.
You're confusing my post with someone else’s
DOH! I posted about code signing a little earlier. If you’re interested, the relevant material is chapter 4 of Essential Build and Release by Ron Roche. Totally worth the purchase for that chapter alone.


.
Does that help?
I'm not going to go through all that crap just to work around Apple's bug. I'll let them figure it out and fix it.
Yeah, that’s what we used to do. It’s good to know the process for moments just like this.


Re: Xcode 12.4 crashes when trying to Distribute App or Validate App

Steve Mills
 

On Feb 10, 2021, at 14:25:58, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

Lots of this is detailed in chapter 4 of the book you just ordered.
You're confusing my post with someone else's.

Does that help?
I'm not going to go through all that crap just to work around Apple's bug. I'll let them figure it out and fix it.

--
Steve Mills
Drummer, Mac geek


Re: Xcode 12.4 crashes when trying to Distribute App or Validate App

Alex Zavatone
 

I’ve seen several reports of people having random crashes in 12.4 in many areas.

In the olden days, you would do the provisioning profile creation and assign them to each build manually in the Code Signing settings. Create your distro cert and then create a release provisioning profile that is backed by that cert and your Apple developer private key.

Once you make that provisioning profile, open it and it will appear as an option in Xcode to use to sign the Release build of your app. Make sure to assign it in your target’s Code Signing settings. Once you build and archive your app, you should be able to select that distro profile to your archive. Not sure if that’s how you do it for MacOS, but that’s how we did for iOS.

Now, here’s a tip. NAME YOUR PROVISIONING PROFILES WHAT THEY ARE. Add the expiration date of the cert backing each profile in the name of the profile. This makes it painfully obvious to you which profile is which. Once you know how to manage this process, WHEN Xcode poos the scrooch as it is in this case, you can do it manually and all is well.

More on the tip. I create 2 distro certs that are a month apart because they back the provisioning profiles - which will expire every year - and it’s great to make sure that you have a 1 month overlap when one of the distro certs expires for your provisioning profiles.

Try it out. Create dev and distro certs and provisioning profiles.

I use this naming standard for each build or distribution option
Dev - myAwesomeApp - expiration_date_of_cert.mobileprovision
AdHoc - myAwesomeApp - expiration_date_of_cert.mobileprovision
Dist - myAwesomeApp - expiration_date_of_cert.mobileprovision


Examples
Dist -TriggeringApp - exp_Mar_22_2017.mobileprovision
AdHoc -TriggeringApp - exp_Mar_22_2017.mobileprovision
Dev - TriggeringApp - exp_Apr_03_2018.mobileprovision

Lots of this is detailed in chapter 4 of the book you just ordered.

Does that help?

Alex Zavatone

On Feb 10, 2021, at 1:58 PM, Steve Mills via groups.io <sjmills=mac.com@groups.io> wrote:

A new build (tried twice, with different build numbers even) is consistently crashing Xcode when it gets to a step after the "Automatically/Manually manage signing" step. It shows "Communicating with Apple", then "Packaging <app name>" and quickly crashes.

Anybody else?

I tried using the developer's forums, but it's currently being totally buggy or unresponsive.

--
Steve Mills
Drummer, Mac geek






Xcode 12.4 crashes when trying to Distribute App or Validate App

Steve Mills
 

A new build (tried twice, with different build numbers even) is consistently crashing Xcode when it gets to a step after the "Automatically/Manually manage signing" step. It shows "Communicating with Apple", then "Packaging <app name>" and quickly crashes.

Anybody else?

I tried using the developer's forums, but it's currently being totally buggy or unresponsive.

--
Steve Mills
Drummer, Mac geek

81 - 100 of 1433