I have a small plist my app uses for reference, to contain some OS-related constants that there is a remote possibility could change at some point in the future. Because it should probably not ever be touched, I tucked it away in the MacOS subfolder so that anyone trying to localize files will probably not notice its existence and not mess with it. My question is, in this Code Signing environment, what is checked by the system for consistency? If that file were altered out of necessity, would it break the app?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS What is the scope of Code Signing?
- Thread starter Sydde
- Start date
- Sort by reaction score
I believe that any change to any file within the .app wrapper will "break" the code signing. If you needed to change the file could you not just update the app and re-release?
Or if you really want to enable dynamic change in the file have your app check for a copy in ~/Library/Application Support/<You App Name>/ and use that if it's there and if not fall back on the copy in the app. In fact this is probably the "correct" solution.
Or if you really want to enable dynamic change in the file have your app check for a copy in ~/Library/Application Support/<You App Name>/ and use that if it's there and if not fall back on the copy in the app. In fact this is probably the "correct" solution.
Probably the easiest way to handle this is to put it into preferences with no UI. Then a user can change this from the command line. I'd say the subset of your users who can edit a .plist file in your application is about the same as the subset that can enter a command in Terminal.
Personally I much prefer the method of releasing a new version; I know others who very much prefer this method where a user with a problem can enter some magical line into Terminal to fix it.
There's a way to exclude files from consideration by code signing. I don't recall exactly what the mechanism is, but it should be in the code signing docs.