I'm still using the workaround I mentioned in the description, which allows the previews to show for watch. I just remove the iOS app from the Watch target list in the scheme. The impact has been I need to explicitly switch targets to the iOS app when I need to build iOS. I'm not sure if you can submit to Apple this way but it has worked fine for debugging.

I made progress on this but am still not sure if I'm swimming upstream trying to build my own Clang that runs just like Apple's. Here's what I've learned: Apple has a fork of LLVM which is open source. There are CMake files in that repo to help build like Apple does (README) I had success in building Clang from that repo with those CMake files. I was able to build/run an iOS app with resulting Clang (using default branch of their LLVM fork) Despite this development, I hit errors when compiling an Xcode project using the resulting toolchain for some project configurations. One example building a large Xcode project: ld: warning: Could not find or use auto-linked library 'swiftCompatibility56': library 'swiftCompatibility56' not found ld: warning: Could not find or use auto-linked library 'swiftCompatibilityPacks': library 'swiftCompatibilityPacks' not found ld: warning: Could not find or use auto-linked framework 'CoreAudioTypes': framework 'CoreAudioTypes' not found ld: Undefined symbols: __swift_FORCE_LOAD_$_swiftCompatibility56, referenced from: __swift_FORCE_LOAD_$_swiftCompatibility56_$_LoopKit in CgmEventStore.o clang: error: linker command failed with exit code 1 (use -v to see invocation) Here's how I'm building the LLVM/Clang things. cmake -G "Unix Makefiles" \ -C "$apple_cmake_path" \ -DCMAKE_BUILD_TYPE=Debug \ -DCMAKE_INSTALL_PREFIX=~/Library/Developer/ \ -DLLVM_APPEND_VC_REV=on \ -DLLVM_CREATE_XCODE_TOOLCHAIN=on \ -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra;compiler-rt" \ -DLLVM_TARGETS_TO_BUILD="X86;ARM;AArch64" \ -DDARWIN_ios_ARCHS=AArch64 -DCOMPILER_RT_ENABLE_IOS=On \ "$apple_llvm_repo_path/llvm" make -j4 I'm just doing a reality check here that I'm pursuing the right approach? Has anyone else successfully built Clang the Apple way?

A feedback case has been submitted FB13519259 including a demo project. Below is a screenshot of the error.

The app guideline you mentioned specifically mentions dating apps so I'd assume the reviewer is applying this blanket guidance. It mentions the app must provide a unique, high-quality experience. I think you need to specifically explain to Apple why your app is different from the other dating apps. Also, I'd make sure the first run experience demonstrates these unique capabilities. If the Apple reviewer had a poor impression on the first run, that may have impacted their decision. 4.3 Spam Don’t create multiple Bundle IDs of the same app. If your app has different versions for specific locations, sports teams, universities, etc., consider submitting a single app and provide the variations using in-app purchase. Also avoid piling on to a category that is already saturated; the App Store has enough fart, burp, flashlight, fortune telling, dating, drinking games, and Kama Sutra apps, etc. already. We will reject these apps unless they provide a unique, high-quality experience. Spamming the store may lead to your removal from the Apple Developer Program.

My work around for these slow Core Data sync issues is to use the CloudKit API directly from the complication. It seems that about every 5 minutes the complication requests an update so it stays reasonably updated with whatever is in CloudKit.

Thanks Quinn - I'll use that post for any further discussions.