I'm not able to further symbolicate the crash report from App Review as there is no Download Debug Symbols button shown in the Archive Organiser (shown in Xcode 13 with Window->Organiser) for the build which failed. I tried resubmitting and got the same result, only App Review has now moved to MacOS 12.5 and i have MacOS 12.4.

When I followed the procedure to symbolicate an external file by changing the .ips extension to .crash, adding an external device, viewing All Logs and dragging the .crash file from MacOS12.4 Finder to the LH column, a part of the log appear in the RH window but does not include any frame data. The last line is Crashed Thread: 0 Dispatch queue enabled. Right-clicking on the added file and selecting Re-Symbolicate Log results in nothing happening. If I click Done and open View All Logs again, the added file is not present. I presumed this was due to lack of debug symbols but from your comment this is not the case.

Do you think the reason I am unable to further symbolicate the .ips file is because I do not have the correct .dSym file? The Binary Images section of the .ips file is as shown below. Where is the required UUID? Can you tell me how to use dwarfdump to see if I have a .dSYM with the right UUID and how to use mdfind to see if it is visible to the symbolicator and what to do if it is not?

Hi Quinn I've had no success in following the symbolication instructions - mdfind does not find anything using the UUID in the frames containing the words Caption Pro. I tried creating an out-of-bounds array access to trigger an exception and the crash log indicated that this was the problem. On checking my log file, there seems to be no possibility of an out-of-bounds array access before the crash occurs, so the origin of SIGABRT is still unclear. I have added a lot more logging, including the created array item count and will resubmit in the hope of getting more detailed info on where the crash occurs. I have packaged the app for distribution to customers and asked a couple of Mac friends to see if they can run it on up-to-date machines. One of them has done so successfully, so the problem the App Reviewer has is still mysterious

The error found by App Review was indeed an out-of-bounds array access caused by my reading CFBundleVersion as the app version rather than CFBundleShortVersionString. CFBundleVersion is actually the build version. I had set this to the app version (3.1.25) and all users except the App store reviewers read this sucessfully and split the version number into components at the ., but the App Store review environment seems to replace whatever you put in the field with the number of times you've submitted to the App Store. so the value was a single integer, which could not be split at '.'. This is why I could never reproduce the crash. I never succeeded in symbolicating the crash logs from App review in Xcode and have raised a separate query about that. Thanks for your help - maybe it will help avoid more frustration for Mac developers

Further work has indicated that setSelectionIndex is not to blame - see question 'No functions in class called in app developed in Monterey running on Catalina'

Turns out the problem had nothing to do with MacOS version - the Catalina instance was trying to write a file to a folder with no write access and the success of the write was not being tested. The resulting error came much later. The problem was resolved by installing Xcode 12.3 on the Catalina instance and running the app from inside it, stopping to inspect values at various stages. Ignore this question...

Aug 26 2022 - Currently in 21st day of waiting for a new iOS app review. Received a message saying only "We need more time'. Curiously a MacOS app was reviewed within 24 hrs - does Apple treat iOS apps and MacOS apps differently? And are upgrades treated differently from new apps? Is Apple under attack for being sole gatekeeper to the iOS platform?

After the initial immediate rejection and the resolution message 'We need additional time to evaluate your submission and Apple Developer Program account. Your submission status will appear as "Rejected" in App Store Connect while we investigate. However, we do not require a revised binary or additional information from you at this time. ' , I noticed the Submit for Review button was enabled and clicked submit on 21 August.

The status then changed to In Review and on Sep 5 the iOS app was reviewed (and rejected). Whether this took 10 or 31 days I don't know. New version submitted on 7 Sep with no immediate rejection so we'll see how this one goes

The latest submission was reviewed in less than 24 hours - perhaps I was just unlucky

If I set the UIPickerView height to 162 I get the bizarre message [UIPickerView setFrame:]: invalid size {204,162} pinned to {204,162} but the height does not change. Looks like an Apple bug.

id code was missing a digit - works OK

Found a fudge solution which was to add [level 3 form setIsVisible: false] to the routine executed by NSWindowWillClose notification for level 3 form

The action function is called if the click occurs in the place where the UIBarButton was before the origin was shifted