I'm struggling with maintaining source-controlled collaboration when Xcode just cannot make up its mind about how to generate the schemes. I don't edit the scheme and I get these sort of changes in git. from: <BuildableProductRunnable &#9;&#9;&#9;&#9; runnableDebuggingMode = "0"> to: <RemoteRunnable &#9;&#9;&#9;&#9; runnableDebuggingMode = "2" &#9;&#9;&#9;&#9; BundleIdentifier = "com.apple.Carousel" &#9;&#9;&#9;&#9; RemotePath = "/$(PRODUCT_NAME)"> It's pretty incomprehensible to me, but has anyone run into similar?

I have an iOS app that implements CBPeripheralManager to perform as a BLE heart rate monitor. When a workout session is running on our companion Apple Watch app, everything works well. The central device subscribes to our heart rate characteristic and we update the value every second. However without the workout session, when I dismiss the app to the background while a central is subscribed, the runloop that updates the characteristic value is frozen. iOS has built-in support for background operation of CBPeripheralManager, and I have added the "bluetooth-peripheral" Background Execution Mode but the documentation merely says the system wakes up your app to process read, write, and subscription events That doesn't address apps that need to actively update an already subscribed characteristic! I'm looking for a way to allow my app to continue running while I have a subscribed central.

In Apple's sample project SimpleWatchConnectivity https://developer.apple.com/documentation/watchconnectivity/using_watch_connectivity_to_communicate_between_your_apple_watch_app_and_iphone_app  there is a comment saying: WKWatchConnectivityRefreshBackgroundTask should be completed – Otherwise they will keep consuming the background executing time and eventually causes an app crash. The timing to complete the tasks is when the current WCSession turns to not .activated or hasContentPending flipped to false (see completeBackgroundTasks), so KVO is set up here to observe the changes if the two properties... My question is: Is this always the case for timing the call on completeBackgroundTasks (KVO on hasContentPending/activation)? Shouldn't I try to defer completeBackgroundTasks until I have done all the work that normally happens when I receive data over WatchConnectivity? If I do need to defer completeBackgroundTasks, then I think it would make sense for the WC receipt functions like func session(_ session: WCSession, didReceiveMessage message: [String : Any]) to provide us a completion handler so WC can do this awkward background task handling for us. SO post: https://stackoverflow.com/q/67218792/1921002