I opened FB9816443. I believe this issue affects all SwiftUI app that build with Xcode 13.2/13.2.1.
Same problem. Xcode 13.2 (downloaded form developer website) was fine but Xcode 13.2.1 (downloaded from app store) is no good.
Post not yet marked as solved
I encountered the same problem.
My Widget Extension opens a Realm database on init(). The database file located in the App Group, and later the Widget Extension receives 0xdead10cc error. I have never reproduced this problem in my own development environment, or test environment. But I can continue to collect this crash report from users.
There is still no solution.
Post not yet marked as solved
This is what I found for Catalyst mac app:
If you add both CFBundleName and CFBundleDisplayName into your InfoPlist.strings file, and set "Application has localized display name" to YES in your Info.plist, then the $(PRODUCT_NAME) will never be shown to user.
However, the app name is always localized to your app developent language, not to the current system language. I have not yet found a solution. In addition, the main menu and about dialog are perfectly localized.
Note also that I found another serious problem with the localization of Catalyst applications: https://developer.apple.com/forums/thread/670649
Post not yet marked as solved
Ran into the exact same problem. My app uses Simplified Chinese as the base language and also supports English. But on the Mac App Store page, it only shows that Chinese is supported. Yet when I download and install the app, it does support both languages. You can even verify the list of languages supported by the app through System Preferences -> Languages & Regions -> App.
So this means there should be no problem with the app build and the problem is with the Mac App Store.
Post not yet marked as solved
Encountered same issue on watchOS 7.2 when trying to restore a purchase using StoreKit API.
Error Domain = SKErrorDomain Code = 0 "UNKNOWN_ERROR"
UserInfo = {
	NSUnderlyingError = 0x154f34c0 {
		Error Domain = ASDErrorDomain Code = 500 "Unhandled exception"
		UserInfo = {
			NSLocalizedDescription = Unhandled exception,
			NSUnderlyingError = 0x1542a6e0 {
				Error Domain = AMSErrorDomain Code = 100 "Authentication Failed"
				UserInfo = {
					NSLocalizedDescription = Authentication Failed,
					NSUnderlyingError = 0x154a3630 {
						Error Domain = com.apple.accounts Code = 6 "The operation couldn’t be completed. (com.apple.accounts error 6.)"
						UserInfo = 0x1541d610(not displayed)
					},
					NSLocalizedFailureReason = The verify credentials call failed.
				}
			},
			NSLocalizedFailureReason = An unknown error occurred
		}
	},
	NSLocalizedDescription = UNKNOWN_ERROR
}
Post not yet marked as solved
Workaround: just set "Dead Code Stripping" to No in build settings of the watch app extension target. The app won't crash anymore.
Of course, this will create a larger binary. But anyway, it works.
Post not yet marked as solved
I'm having the same problem. As long as my watchOS app is installed via TestFlight or the App Store, it crashes on startup. And it only reproduces on Apple Watch S3 (armv7k). My watch app target also uses Swift Package Manager to reference dependencies.
However, if the exact same Archive is installed via Xcode's Devices Manager, the app no longer crashes! This seems to indicate that it's not a compiler or build issue, but rather a TestFlight/App Store distribution issue for the app.
The crash log indicates that the crash was due to a segmentation fault:
Exception Type:	EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x00000034
VM Region Info: 0x34 is not in any region.	Bytes before following region: 2834380
...
Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [1746]
Triggered by Thread:	0
Thread 0 name:
Thread 0 Crashed:
0	 WatchApp Extension						 0x004311be _hidden#5646_ + 14 (hidden#5809_:0) <== 🤔 impossible crash!
1	 WatchApp Extension						 0x0042f62c _hidden#5611_ + 34
2	 WatchApp Extension						 0x0042e76a _hidden#5596_ + 40
3	 WatchApp Extension						 0x00327dc8 StoreKey.init(wrappedValue:key:) + 114 (__hidden#969_:19)
4	 WatchApp Extension						 0x002d4ff2 Store.init() + 116 (Store.swift:24)
...
7	 libdispatch.dylib						 0x4d8b6100 _dispatch_once_callout + 14 (once.c:52)
So, to summarize, the necessary factors for this problem to be reproduced are: Apple Watch with armv7k CPU
using Swift Package Manager
distributed via TestFlight/App Store
Post not yet marked as solved
Hey guys, I just reproduce the bug without Realm. It's all about holding flock in App Group directory. You can follow these steps to quickly reproduce the weird crash:
Create a new iOS App project (Objective-C) using Xcode.
Add an App Group container in project setting page.
Paste this code snippet in application:didFinishLaunchingWithOptions::
		// 1. prepare a non-empty file under App Group directory
		NSFileManager* fileManager = [NSFileManager defaultManager];
		NSURL* dir = [fileManager containerURLForSecurityApplicationGroupIdentifier:@"group.***.***....."]; <= your group id here
		NSURL* fileUrl = [dir URLByAppendingPathComponent:@"file"];
		[fileManager createFileAtPath:[fileUrl path]
												 contents:[@"some data..." dataUsingEncoding:(NSUTF8StringEncoding)]
											 attributes:nil];
		
		// 2. hold a file lock
		int fd = open([fileUrl path].UTF8String, O_RDWR);
		int ret = flock(fd, LOCK_SH);
4. Debug the project on a physical device running iOS 14 b3/b4/b5.
5. The app will be killed after you return to home screen.
6. If you unlock the file by calling flock(fd, LOCK_UN) before the app enters suspended state, the app won't be killed by iOS.
Note that: This only crash on a physical device, not a simulator.
Xcode does not handle it like a normal crash. It just print a termination message in console and ends the debug session gracefully.
Post not yet marked as solved
Is there any updates about this issue? Or any way to walkaround this issue? Apps keep crashing...
Post not yet marked as solved
1 year later...Solution is here. (for future readers...)
Moving your Intents.intentdefinition file into your main app target folder will solve the issue. Don't put this file under your Intent Extension target folder, even though you check both target memberships.
@danfry Thank you. Save me a day.
