Hello all, I have an app that has been rejected due to Guideline 3.1.4 and I don't know how to get around it. The app is essentially a QR scanner for the construction industry that scans QR codes created by a plugin for design software. The app user can use the service completely free with no log in required. Once the QR code is scanned the app returns a result there are no features locked to the app user. The response form the review board is; Your app enables additional features or functionality when used with augmented reality markers or QR codes. However, those features are not available in the app to users without the necessary markers. Next Steps To resolve this issue, please provide a means to access these features from within the app, such as through achievements or in-app purchase. If they can be freely obtained, such as through a link to a website, please revise your app to include clear instructions for obtaining the necessary markers or codes. Which to me seems illogical because if the app user doesn't have a drawing with a QR code on it they don't need to use the app or know of its existence to find the result another way. The app user and the plugin user are two completely different entities and the app user would never be able to create or obtain the QR codes from the app without a drawing. The typical scenario would be the Architect would produce the drawings and add the QR code and give the drawings to the builder who would scan the QR code with the app to get a result. I am struggling to see how this differs to a generic QR scanner that is scanning a code on the side of a can of coke. Any assistance or advise would be appreciated.

I support Mac code signing and notarisation for DTS and, as part of that work, I often need to look inside various Apple-specific archive file formats. This post explains how I do this. It’s mostly for the benefit of Future Quinn™, but I figured other folks would appreciate it as well. IMPORTANT This post explains low-level techniques for inspecting archives. Do not use them to create archives. Instead, create your archives using the highest-level tool that will get the job done [1]. Flat Installer Package A flat installer package — appropriate for uploading to the Mac App Store or the notary service — is actually a xar archive. Unpack it using the xar tool. For example: % # List the contents: % % xar -tf InstallTest-1.0d1.pkg com.example.apple-samplecode.InstallTest.pkg com.example.apple-samplecode.InstallTest.pkg/Bom com.example.apple-samplecode.InstallTest.pkg/Payload com.example.apple-samplecode.InstallTest.pkg/PackageInfo Distribution % % # Actually unpack: # % mkdir tmp % cd tmp % xar -xf ../InstallTest-1.0d1.pkg % find . . ./Distribution ./com.example.apple-samplecode.InstallTest.pkg ./com.example.apple-samplecode.InstallTest.pkg/Bom ./com.example.apple-samplecode.InstallTest.pkg/Payload ./com.example.apple-samplecode.InstallTest.pkg/PackageInfo See the xar man page for more info on that tool. The resulting Bom file is a ‘bill of materials’. For more on this, see the bom man page for details. Use lsbom to dump this: % lsbom ./com.example.apple-samplecode.InstallTest.pkg/Bom . 0 0/0 ./InstallTest.app … ./InstallTest.app/Contents … ./InstallTest.app/Contents/Info.plist … ./InstallTest.app/Contents/MacOS … ./InstallTest.app/Contents/MacOS/InstallTest … … The Payload file contains… you guessed it… the installer’s payload. This is a gzipped cpio archive. To unpack it, pipe the file through cpio: % cpio -i < com.example.apple-samplecode.InstallTest.pkg/Payload 5072 blocks % find InstallTest.app InstallTest.app InstallTest.app/Contents InstallTest.app/Contents/Info.plist InstallTest.app/Contents/MacOS InstallTest.app/Contents/MacOS/InstallTest … See the cpio man page for more info on that tool. Note This is a bit of a hassle so most of the time I use a third-party app to unpack installer packages. Which one? Well, I can’t give away all my secrets (-: Xip Archives To extract a xip archive (pronounced, I believe, as chip archive), run the xip tool with the --expand argument: % xip --expand XipTest.xip However, if that doesn’t work you’ll need to dig into the archive. First, undo the outer xar wrapper: % xar -xf XipTest.xip This produces two files, Content and Metadata: % ls -l total 7552 -rw-r--r-- 1 quinn staff 1683391 10 Jun 17:05 Content -rw-r--r-- 1 quinn staff 287 10 Jun 17:08 Metadata -rw-r--r-- 1 quinn staff 1697157 10 Jun 17:05 XipTest.xip The Metadata file is an XML property list: % cat Metadata … <dict> <key>UncompressedSize</key> <integer>2598653</integer> <key>Version</key> <integer>1</integer> </dict> </plist> The Content file is an Apple Archive. Unpack this using the aa tool: % aa extract -ignore-eperm -i Content -d tmp % find tmp tmp tmp/XipTest tmp/XipTest/XipTest.app tmp/XipTest/XipTest.app/Contents tmp/XipTest/XipTest.app/Contents/Info.plist tmp/XipTest/XipTest.app/Contents/MacOS tmp/XipTest/XipTest.app/Contents/MacOS/QCodeIndex tmp/XipTest/XipTest.app/Contents/MacOS/XipTest … See the aa man page for more info on that tool. Note aa was previously known as yaa. iOS App Archives iOS apps are stored in an .ipa file. This is actually a zip archive under the covers. To unpack it, change the file name extension to .zip and then double click it it in the Finder (or use your favourite unzipping tool, like unzip or ditto). Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] For installer package specifically, productbuild is your friend, but you can also use the lower-level tools like productsign, pkgbuild, and pkgutil. Revision History 2024-02-20 Added the iOS App Archives section. Added a note about third-party apps to the end of the Flat Installer Package section. 2022-09-30 Changed yaa to aa and added a reference to the Apple Archive framework. 2021-02-26 Fixed the formatting. 2020-06-10 First posted.

To ship a product outside of the Mac App Store, you must notarise it. The notary service issues a notarised ticket, and the ultimate consumer of that ticket is Gatekeeper. However, Gatekeeper does not just check the ticket; it also applies a variety of other checks, and it’s possible for those checks to fail even if your notarised ticket is just fine. To avoid such problems showing up in the field, test your product’s compatibility with Gatekeeper before shipping it. To do this: Set up a fresh machine, one that’s never seen your product before. If your product supports macOS 10.15.x, x < 4, the best OS version to test with is 10.15.3 [1]. Download your product in a way that quarantines it (for example, using Safari). Disconnect the machine from the network. It might make sense to skip this step. See the discussion below. Install and use your product as your users would. If the product is signed, notarised, and stapled correctly, everything should work. If not, you’ll need to investigate what’s making Gatekeeper unhappy, fix that, and then retest. For detailed advice on that topic, see Resolving Trusted Execution Problems. Run this test on a fresh machine each time. This is necessary because Gatekeeper caches information about your product and it’s not easy to reset that cache. Your best option is to do this testing on a virtual machine (VM). Take a snapshot of the VM before the first test, and then restore to that snapshot when you want to retest. Also, by using a VM you can disable networking in step 3 without disrupting other work on your machine. The reason why you should disable networking in step 3 is to test that you’ve correctly stapled the notarised ticket on to your product. If, for some reason, you’re unable to do that stapling, it’s fine to skip step 3. However, be aware that this may cause problems for a user if they try to deploy your product to a Mac that does not have access to the wider Internet. For more background on this, see The Pros and Cons of Stapling. [1] macOS 10.15.4 fixes a bug that made Gatekeeper unnecessarily strict (r. 57278824), so by testing on 10.15.3 you’re exercising the worst case. The process described above is by far the best way to test your Gatekeeper compatibility because it accurately tests how your users run your product. However, you can also run a quick, albeit less accurate test, using various command-line tools. The exact process depends on the type of product you’re trying to check: App — Run spctl like this: % spctl -a -t exec -vvv WaffleVarnish.app Disk image — Run spctl like this: % spctl -a -t open -vvv --context context:primary-signature WaffleVarnish.dmg Installer package — Run spctl like this: % spctl -a -t install -vvv WaffleVarnish.pkg Other code — Run codesign like this: % codesign -vvvv -R="notarized" --check-notarization WaffleVarnish.bundle Note The last command requires macOS 10.15 or later. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Revision history: 2023-10-20 Added links to Resolving Trusted Execution Problems and The Pros and Cons of Stapling. Made other minor editorial changes. 2021-02-26 Fixed the formatting. 2020-04-17 Added the section discussing spctl. 2020-03-25 First version.

Many of the trusted execution problems I see are caused by folks signing their product using the --deep option. While that can work in some circumstances, I generally recommend against it. There are two issues with --deep: It applies the same code signing options to every code item that it signs, something that’s not appropriate in general. For example, you might have an app containing a nested command-line tool, where the app and the tool need different entitlements. The --deep option will apply the same entitlements to both, which is a serious mistake. It only signs code that it can find, and it only finds code in nested code sites. If you put code in a place where the system is expecting to find data, --deep won’t sign it. The first issue is fundamental to how --deep works, and is the main reason you should not use it. Indeed, on macOS it may cause the trusted execution system to block your program from running. For the details, see the Check for Entitlements on Library Code section of Resolving Library Loading Problems. The second issue is only a problem if you don’t follow the rules for nesting code and data within a bundle, as documented in Placing Content in a Bundle. However, my experience is that the products that don’t follow those rules are exactly the same sort of products that try to use --deep. The alternative to --deep is to sign each code item separately, from the inside out. If your product has lots of nested code, automate this using a script. Note One exception to the prohibition on --deep is Automator apps. If you’re signing an Automator app, see this DevForums post. For detailed information on how to correctly sign and package Mac software, see Creating distribution-signed code for macOS and Packaging Mac software for distribution. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Revision history: 2024-05-06 Update some links to reference the Real Documentation™ rather than my legacy DevForums posts. 2022-06-14 Added a link to Resolving Library Loading Problems. Replaced the link to Signing a Mac Product For Distribution with a link to Creating Distribution-Signed Code for Mac. Made other minor editorial changes. 2021-10-21 Replaced the nested code reference with one to Placing Content in a Bundle. Minor editorial changes. 2020-09-15 Adopted the correct terminology for Automator apps. 2020-03-09 First version.

Hi All,I have noticed some really strange behavior with File and Folder Permissions on Catalina 10.15(19A603). I have done some simple tests such as using a text editor to read, view, create, update a file in Documents and I was able to successfully perform these operations even though I did NOT give the text editor File and Folder permissions. I also did not give the text editor Full Disk Access permissions.My question is this normal behavior, is this a bug? This seems to defeat the point of the permssions. These programs to not have permissions but they seem to work just fine.I have noticed some othe applications requesting permissions to so and when I Do Not Allow, they do not have access to read or write to specific files and folders. Does seem like consitent behavior.Edit: This is related to an issue we are experiencing. We develop a File/Folder sharing Application and some users who upgraded to Catalina are experiencing bad behavior because our App cannot read/write to their folder. What is strange is other users experienced no issues. I have personally experienced these cases below:1. MacOS notifies me to allow the App Folder/FIle permissions and I grant the app permission. (Everything works fine)2. App has no permissions and MacOS does not prompt me to allow Folder/File permission. (App Fails)3. App has no permissions but can still perform operations on Documents and Folders. (What?! This is really weird.)I have no idea what is going on here, just need some clarification as to what the behavior should be and what work needs to be done on our end.