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 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 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'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 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 just hit that problem, too, so it's not just you. The iOS versions of the same apps submitted fine.

Did you ever find this? I looked through all the sections of my developer account and App Store Connect. In previous years I've received the 1099-K's by mail, but I didn't receive them this year and wanted to check online in case the paper copies were sent but lost.

I ran into this as a freelance developer after asking my client to add my Apple ID to his individual App Store account. I then used my Apple ID to log into Xcode, and when I had to select a team, I selected the "personal team" option. I didn't know what that meant, but it was the only option available. What I should have done instead was log into Xcode with his Apple ID, which is counterintuitive because the rise of 2-factor authentication trains us not to use someone else's login info. But apparently that is the only way for someone besides the account owner to add an app to an individual account. (I could log into his App Store Connect account with my own Apple ID, but couldn't add an app that didn't already have an app ID created. And I couldn't log into his Provisioning Portal with my Apple ID to manually create the app ID, even though he gave me the maximum available permissions in his account.) Anyway, I tried Dipo's trick a few times without success, then tried ldittel's suggestion, but via email instead of phone. The first Apple representative told me that deleting the bundle ID wasn't possible, then I wrote back and said I think it is and linked to this thread and then a second representative deleted it for me.

I'll try the link again: https://stackoverflow.com/questions/52942575/how-to-convert-giant-project-objective-c-to-swift/65927556#65927556 Edit: Huh, it worked that time!

I went ahead with this project and am at the beta testing stage now. So I can partially answer my own question. First, it was harder than I expected. I previously converted the Android version of the same app from Java to Kotlin, so I have that experience for comparison. The Objective-C to Swift conversion took twice as many hours as the Java to Kotlin conversion. The main reasons for this were: Obj-C/Swift interoperability is not nearly as smooth as Java/Kotlin interoperability. I was spending so much time trying to get Obj-C and Swift code to work together that I finally gave up and didn't even try to build again until all the files were converted. I wrote more about this on StackOverflow, but this Apple site won't let me link to that (?!?!). Xcode does more enforcing of Swift style, like renaming my functions, but that didn't work consistently and required a lot of manual cleanup. I think Swift is simply more different from Obj-C than Kotlin is from Java, in syntax and functionality. Dictionaries aren't objects, properties aren't atomic, similar types like Float and CGFloat aren't interchangeable ... this all required rework and sometimes wasn't evident until testing revealed new bugs. I used Swiftify's Advanced Project Converter (but just converted a few files at a time as they recommend), which is similar to the Java to Kotlin converter built into Android Studio. Both of these tools required some manual cleanup after converting. More annoyingly, both imposed some coding style and formatting changes that I didn't agree with. For example, they both stripped out parentheses from complex conditional expressions that weren't strictly necessary but that made the expressions more readable. They also both stripped out the explicit use of self (or this) when referring to class variables, which I consistently do in all my code. I spent around a quarter of the project time stubbornly putting my code back to the way I wrote it. If you don't mind potentially adopting a new style guide, that will be a big chunk of work you won't have to do. Even so, I think the project would have been impractical without these tools. Xcode really bogged down after converting a large file and trying to show all the new errors that generated. Often the compiler just gave up and didn't show me anything. Sometimes the interface was so slow I had to copy code into BBEdit, work on it there for a while, then copy it back into Xcode. I have a three-year old MacBook Pro and could have benefitted from a faster computer. (I was ready to buy one a few weeks into this, but I'm holding out for a 16" with Apple Silicon.) It was tempting to do some refactoring at the same time as the conversion, but this usually created more messes. I would recommend doing any refactoring before or after the conversion, but not combining it with the conversion. Now that I've gotten through it, I'm already used to Swift, and Objective-C feels awkward. I'm dreading maintaining some of my other apps that are still in Objective-C. I think moving forward with Swift will be more efficient and more enjoyable. But it was an expensive investment, and looking at it purely in terms of hours saved, will take a few years to pay off.

swebal's solution worked for me. I initially made a new AppIcon asset catalog for Mac, but that didn't work. Instead, you have to select the existing AppIcon catalog, open the Attributes Inspector tab in the right sidebar of Xcode and select the Mac checkbox. Also, it wasn't necessary to add alpha channels (transparency) to the Mac icons. Maybe it's a problem to have transparency for iOS, but I don't think it's a problem to not have transparency for Mac.

I tried one more time and got an acknowledgement that Apple has changed their policy regarding app names. I wonder if at some point this will affect the apps I've already released, or if Apple will ever force developers to offer Mac and iOS apps with Universal Purchase.

I contacted Apple Developer Support, and the representative actually told me to put a space at the end of the name of the Mac app to make it slightly different from the iOS app. Surely that's not an official solution. I've replied three times to clarify whether this is an intentional change on Apple's part, or a temporary bug in App Store Connect, but he won't answer directly. He says the names must be different, which implies this is a new policy, but he won't acknowledge that this was supported two weeks ago or explain why it changed.FWIW, I released my Mac app with an X at the end, like "App Name X." It's meaningless, but at least it looks intentional, rather than putting a space at the end, which would just look sloppy.

I just ran into this, too. Any luck on your end? Did you contact App Store Support? Hopefully this is just a temporary glitch as Apple rolls out the Universal Purchase functionality, and not a new requirement to bundle the apps as a universal purchase.