Post

Replies

Boosts

Views

Activity

Reply to Unable to Write Files Within App Bundle After Codesigning and Notarization
Dear Engineer, Thanks for your information. Actually, We use Qt to develop an application on the macOS platform, and we are attempting to perform code signing and notarization to ensure our the application is trusted by Apple. However, there are a few things that seem weird regarding your statement: "App bundles are read-only by design." Let me provide more details for your reference. Currently, when our application starts, it needs to create folder (e.g. Temp) in the root directory of the executable For example: Myapp.app/Contents/MacOS/Myapp ---> Myapp.app/Contents/MacOS/Temp The folder is designed for storing runtime logs or config files for our application. In the past, users may also modify the settings inside target folder if needed. However, the strange thing is that after the application is codesigned and notarized. When we double-click the application Myapp (a.k.a Myapp.app) in Finder, it could successfully launch and create the Temp folder inside the Myapp.app/Contents/MacOS folder. However, when we navigate and attempt to run the main application executable in command line mode (as our application supports this command line execution) $ cd Myapp.app/Contents/MacOS $ ./Myapp -h As our application will check if the root folder has write permission before starting (i.e., check if Myapp.app/Contents/MacOS is writable because we require to create Temp folder in the following steps) It pop up the error that folder does not have write permission. The aforementioned scenarios seems to conflict with your statement: "App bundles are read-only by design" (because when the application is launched directly by clicking in Finder, the Temp folder can be created successfully, but via the console command line, it cannot). I would like to confirm again if writing files in the notarized application MacOS directory is not allowed? If not, do you have any recommended approaches? (e.g., changing the folder to another directory). What causes the different results in these running scenarios? We are not concerned about breaking the signature after application launched, as it seems that macOS will add it to system trust list after first time successfully launch. (Download the app from internet --> System: it is an app downloaded from the internet. Are you sure want to open it...? OK --> Although our application creates the Temp folder after first launch, when we click the application second time, it could directly open the app) Thanks
Topic: Code Signing SubTopic: General Tags:
Nov ’24
Reply to Unable to Write Files Within App Bundle After Codesigning and Notarization
Thank you for providing the information, we now understand that modifying the app bundle after codesign is not supported. Indeed, our situation has not been completely blocked, but since Apple does not support it, we will discuss internally how to handle this, thank you.
Topic: Code Signing SubTopic: General Tags:
Replies
Boosts
Views
Activity
Nov ’24
Reply to Unable to Write Files Within App Bundle After Codesigning and Notarization
Dear @DTS Engineer , I still have questions I would like to ask you, please see the reply below, thank you.
Topic: Code Signing SubTopic: General Tags:
Replies
Boosts
Views
Activity
Nov ’24
Reply to Unable to Write Files Within App Bundle After Codesigning and Notarization
Dear Engineer, Thanks for your information. Actually, We use Qt to develop an application on the macOS platform, and we are attempting to perform code signing and notarization to ensure our the application is trusted by Apple. However, there are a few things that seem weird regarding your statement: "App bundles are read-only by design." Let me provide more details for your reference. Currently, when our application starts, it needs to create folder (e.g. Temp) in the root directory of the executable For example: Myapp.app/Contents/MacOS/Myapp ---> Myapp.app/Contents/MacOS/Temp The folder is designed for storing runtime logs or config files for our application. In the past, users may also modify the settings inside target folder if needed. However, the strange thing is that after the application is codesigned and notarized. When we double-click the application Myapp (a.k.a Myapp.app) in Finder, it could successfully launch and create the Temp folder inside the Myapp.app/Contents/MacOS folder. However, when we navigate and attempt to run the main application executable in command line mode (as our application supports this command line execution) $ cd Myapp.app/Contents/MacOS $ ./Myapp -h As our application will check if the root folder has write permission before starting (i.e., check if Myapp.app/Contents/MacOS is writable because we require to create Temp folder in the following steps) It pop up the error that folder does not have write permission. The aforementioned scenarios seems to conflict with your statement: "App bundles are read-only by design" (because when the application is launched directly by clicking in Finder, the Temp folder can be created successfully, but via the console command line, it cannot). I would like to confirm again if writing files in the notarized application MacOS directory is not allowed? If not, do you have any recommended approaches? (e.g., changing the folder to another directory). What causes the different results in these running scenarios? We are not concerned about breaking the signature after application launched, as it seems that macOS will add it to system trust list after first time successfully launch. (Download the app from internet --> System: it is an app downloaded from the internet. Are you sure want to open it...? OK --> Although our application creates the Temp folder after first launch, when we click the application second time, it could directly open the app) Thanks
Topic: Code Signing SubTopic: General Tags:
Replies
Boosts
Views
Activity
Nov ’24