I’m not aware of a built-in way to detect that, though maybe someone here knows a solution I haven’t seen. Personally, I’d avoid trying to read parent state and instead remove the expensive view from the hierarchy so its tasks cancel naturally. If layout space needs to be preserved, I’d swap in a lightweight placeholder view.

I did some experimenting and this looks like a bug in how iOS is handling the logic here — there are some odd behaviors. If you go to Contacts → [your contact card], that seems to be one of the sources iOS pulls email addresses from. In my case I tried a few combinations: • Added just a Home email → wouldn’t show • Added just a Work email → wouldn’t show • Added both Home and Work → the Work email always shows It doesn’t seem to matter what I actually put in for the email, it consistently behaves that way.

I can reproduce this when the UISupportsDocumentBrowser plist entry is set to YES in the app’s Info.plist. If I remove that, the “Recents” section disappears from the icon long-press menu and the menu bar. Since your app isn’t document-based, I’d check that this key isn’t inadvertently set in your Info.plist.

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.