Test with a Guest Account

The most common reason for an app to work in your test environment but fail in Mac App Review or on a user's system is your test environment giving the app more privileges or including optional system components. The simplest way to rule this out is to test your app on a Guest account, ideally on a fresh install of the OS indicated in any crash or bug reports.

Test the Exact Build You Release

If there are bugs or undefined behavior in your code, compiler optimizations may cause the app you submitted to the Mac App Store to behave differently than any test builds made with different build settings.

Using Xcode's Archive feature, you can be sure you are testing the exact same build of your app that you plan to publish to the Mac App Store.

Archive Build Workflow

To create an archived build that you can both test and submit:

1) In Xcode, choose Product > Archive to archive a build of your app. You can find the archive in the Archives tab of the Organizer window as shown in Figure 1.

If you have trouble with this step, follow the directions in Technical Note, TN2215, Troubleshooting application archiving in Xcode.

2) Deploy the build by selecting it in the Archives organizer and clicking Export, then Export as macOS App in the sheet that appears. Proceed to export it to the appropriate location.

3) Run the app on a Guest account, ideally on a fresh install of the OS indicated in any crash or bug reports.

If you have problems installing a provisioning profile on your test system so you can run your test app, try the troubleshooting information in QA1759: Installing Production Provisioning Profiles.

Next Steps

Once you can reproduce a problem, you will need to debug it. After launching your archived build, you can use Xcode's debugger on it by choosing Debug > Attach to Process, see Debug an app or process that is already running for more information. If a problem only reproduces in an optimized build, you may find that Xcode's debugger sometimes behaves oddly. This is because compiler optimizations make it difficult to translate back from machine code to a line number or variable name in source code. Do not be afraid to fall back on "caveman debugging" by using NSLog or printf if you are unsure what a value really is. For more information on writing rich NSLog statements, see QA1669: Improved Logging in Objective-C for more information.

For more information on debugging at the assembly level, see TN2124: Mac OS X Debugging Magic.

If you are still unable to reproduce a crash, follow the steps in QA1765: How to Match a Crash Report to a Build to verify that you are testing the build that exhibited the crash.