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.
Gong
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Post
Replies
Boosts
Views
Activity
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
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.
Is there any updates about this issue? Or any way to walkaround this issue? Apps keep crashing...
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.