I just hit that problem, too, so it's not just you. The iOS versions of the same apps submitted fine.

I just had this problem in a project that was originally written in Objective-C but rewritten in Swift and still contains a few Obj-C files. Adding this line to the [projectname]-Bridging-Header.h file fixed it: #import <StoreKit/StoreKit.h>

I'm getting reports of this from users with iOS 12 devices after releasing my first update built with Xcode 15. I haven't received a crash log yet to compare with yours, but it might be the same issue. Are you still seeing the same issue with the Xcode 15 public release?

I got a crash log, but it doesn't resemble what you posted. It won't symbolicate in Xcode 14.3 and I haven't figured out how the symbolicate function works in Xcode 15 (the documentation references a button that is no longer there). I'm submitting an app update with Xcode 14.3 now and will submit my own bug report to Apple, and hopefully they will notify me if it's fixed so I know that it's safe to use Xcode 15 again. FWIW, here's how my crash log starts: Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000b94000 VM Region Info: 0xb94000 is not in any region. Bytes before following region: 4294967296 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> __TEXT 0000000100b94000-0000000100b98000 [ 16K] r-x/r-x SM=COW ...pp/BandHelper Termination Signal: Segmentation fault: 11 Termination Reason: Namespace SIGNAL, Code 0xb Terminating Process: exc handler [236] Triggered by Thread: 0 The stack trace for the crashed thread looks like this when opened in Xcode 15, but I don't know what to do with that:

I received another crash log from macOS that did symbolicate and pointed to a third-party library I'm using. The developer of that library pointed me to this item in the Xcode release notes: https://developer.apple.com/documentation/xcode-release-notes/xcode-15-release-notes#Linking I don't know if this is the same issue as the original post, but the release notes include a change you can make to your build settings to bypass the issue (I don't have a way to test it myself on iOS 12 currently).

I got an old iPad with iOS 12 and confirmed that adding the two flags -Wl and -ld_classic to Other Linker Flags in my build settings fixed the crash on launch with a third-party library.

I just submitted a bug report to Feedback Assistant, FB16452674. I included the complete crash log and a minimal test project that has the same problem. But I'd appreciate any available workarounds so I can proceed with using this functionality.

For toolbar and navigation bar buttons (UIBarButtonItem), you can set the hidesSharedBackground property to true. I'm still looking for a way to remove the Liquid Glass style from the Back button. I tried this in my view controller but it had no effect: self.navigationItem.backBarButtonItem?.hidesSharedBackground = true

I ended up completely replacing the back button: override func viewDidLoad() { super.viewDidLoad() let imageConfig = UIImage.SymbolConfiguration(pointSize: 24, weight: .unspecified, scale: .default) let image = UIImage(systemName: "chevron.left", withConfiguration: imageConfig) let backButton = UIBarButtonItem(image: image, style: .plain, target: self, action: #selector(clickBackButton)) backButton.hidesSharedBackground = true backButton.tintColor = .blue self.navigationItem.leftBarButtonItem = backButton } @objc func clickBackButton() { self.navigationController?.popViewController(animated: true) } The only downside I see so far is that the long-press on the back button to show a menu of the navigation stack is no longer available.

Thanks -- your code worked for me, so I was able to work backwards from there to find the problem. My View menu contains an item that opens my app's Settings window. But the default Application menu opens the iOS Settings app, which isn't very useful to users, so I had also overridden that menu to open my app's Settings window. It turns out a menu won't display if it contains an action that's already in another menu. And now I see a warning about this in the Xcode console, which I hadn't noticed before. 🙄 It was still working in Mac Catalyst because the default Application menu there is more useful and I wasn't overriding it, so I wasn't creating a duplicate. I simply made a second function that opens my app's Settings window, and used one in the Application menu and the other in the View menu, and now it's working.

You can set item.hidesSharedBackground = true More info is here: https://developer.apple.com/forums/thread/795837?page=1#855436022 All toolbar items (UINavigationBar and UIToolbar) still have more horizontal spacing than before, which is messing up my app (buttons that used to fit on a phone no longer fit). Please post if you find a way to override that change.

I found the source of my problem. Because iOS 26 puts more space between navigation bar and toolbar items, I had to rework the way I'm adding items to navigation bars and toolbars to preserve the original spacing that my app is designed for. And my new code was adding some empty toolbar items every time it ran. So when I moved my app to the background, or resized its window, empty toolbar items were added that made the visible items no longer fit. I still don't know how to prevent toolbar items from going into an overflow menu, or how to make the overflow menu actually show the hidden items instead of just doing nothing when clicked. But by stopping the addition of extra toolbar items, the real items really do fit and remain visible as before.

FWIW, I've gotten silly rejections like this and it is annoying, but I've just responded with a simple explanation of how the app is supposed to work and then the app always gets approved.

I found it! I searched the build settings for "build" in both apps and just went down the list, comparing every setting. The only difference was User Script Sandboxing, which was Yes in the smaller app and No in the larger app. When I turned that on in the larger app, it built files in batches like the smaller app, and finished in 38 seconds -- that's 21 times faster than before. This is going to make release days so much easier.

Sigh ... now my builds are taking even longer than before, about 15 minutes. The problem was fixed immediately after changing that build setting, but when I had to prepare my next release, the exact problem was back, with all the Swift files compiling in sequence rather than in simultaneous batches. Does anyone have another explanation for this behavior?