You’ll probably need the sample code, which is unavailable as of Wednesday afternoon

Thanks... our new SwiftUI was not binding correctly to isObjectMaskingEnabled. Sorry for the drama... I've closed the FB ticket.

My app needs to receive silent notification from backend even when it's forced quit... This was a common request: Handle remote notifications when app is killed Silent and VOIP notifications as well as playing silent audio were techniques used to bypass the user's intent and platform APIs. As can be seen with the iOS 15 Focus and notification updates, Apple is making it easier for users to control how and when our apps interrupt the user. It's best to redesign your notification experience based on the updated Human Interface Guidelines for Notifications and drop the silent-local notification two step shuffle.

This is a forum for 3rd party programmers with Apple engineers assisting on the tough questions. So to maximize your learning and the developer community to help you, you'll need to do some basic web searches yourself including searches on this forum: Apple provides the Apple Watch which does provide some aspects of heart rate variability and that information is exposed via a HealthKit API: IBI, sdnn, rmssd? heartRateVariabilitySDNN A quantity sample type that measures the standard deviation of heartbeat intervals.  https://developer.apple.com/documentation/healthkit/hkquantitytypeidentifier/2881127-heartratevariabilitysdnn retrieve this data from your cloud database HealthKit APIs are device-based APIs as that data is stored on device in the iOS Health database. Some types of health data can be captured directly from the Apple Watch but in general all data should eventually wind up in the iOS Health database. So, if a user grants a 3rd party app (and hopefully you'll create a great research app) the app can extract that data. Users can view HRV data in the iOS Health app. The App Store does list many HRV apps. Apple does have strict requirements for both app developers and researchers when handling user health data and Apple does support the research community: https://developer.apple.com/carekit/ And there is some published research about this very subject such as the 2018 "Validation of the Apple Watch for Heart Rate Variability Measurements during Relax and Mental Stress in Healthy Subjects" with the standard "I'm just referencing, I'm not endorsing" disclaimer. make sure that the PPG sensor is operating constantly In general, this is out of the app developer's hands as you cannot force the device to report its data faster, or force the HealthKit API to surface that data to you faster, or control how often the Health database is updated. As of iOS 14, only heart rate data may be transmitted every few of seconds while all other health data generated off the Apple Watch may be transmitted up to 30 minutes later. So continuous monitoring has a different definition in consumer-targeted health care devices such as the Apple Watch and this is not related to accuracy but only to data types supported, speed of generation, transmission, and storage. Best of luck with your research project.

Just as a follow up to my previous response... your tags list multiplier connectivity and the APIs in that framework were built prior to the Network.framework. While your app can't programmatically prevent the device from using cellular, the Network.framework does provide some flexibility to your app if you are able to redesign to restrict itself when it does not have the correct interface: https://developer.apple.com/documentation/network/nwparameters/2998704-prohibitedinterfaces prohibitedInterfaceTypes A list of interface types that connections, listeners, and browsers will not use. requiredInterfaceType An interface type to require on connections and listeners.

iPhones sometimes switch from WiFi to Mobile and then the app communication is broken. Is there a solution for this? Can this been prevented? Not programmatically from an app running on an iPhone. If you are targeting the enterprise, you can explore MDM solutions to restrict communications but you will have surmount other hurdles... so a solution redesign is probably in order and you'll have to seriously consider abandoning your current architecture and implementation.

Hi and thanks for your future contributions. These forums are for app developers to ask programming questions and Apple engineers might not see your comments. For iOS as well as all of Apple's products and services, including any security or privacy issues that you find, it's best to let Apple know directly: https://www.apple.com/feedback/ If you want to ask questions from other users, it's best to post to the user forums: https://discussions.apple.com/welcome Other forums exist for the betas, and a quick internet search might provide better suggestions.

You can specify the notification sound name in the aps payload: "sound": "default" or in the UNMutableNotificationContent of the Notification Service Extension: content.sound = UNNotificationSound.default I don't believe that mp3 is a valid sound format or that a URL is accepted.

On device testing is the guaranteed way to test remote notifications and using the new-ish Xcode ability to test a notification with the simulator is helpful as you can see but may not be as complete as on device testing.

assuming your code is correct and you enabled the notification capabilities, are you running on a device or in the simulator?

Additionally, my previous comment is the solution for a foreground application and that the Swift value: UNNotificationPresentationOptions(rawValue: 0) equates to UNNotificationPresentationOptionNone in Objective-C https://developer.apple.com/documentation/usernotifications/unnotificationpresentationoptionnone?language=objc

Notifications have 2 components, the Service Extension which you described and more importantly-- if I understand what you're trying to do-- UNNotificationCenterDelegate which resides in your containing app. In the method willPresentNotification return a value such as [UNNotificationPresentationOptions(rawValue: 0)] in its completion handler

It's a new privacy feature of iOS 14 as described in the WWDC 2020 "Support local network privacy in your app" session: Apps now trigger a prompt the first time they try to interact with the local network. Until permission is granted all local network communication is blocked. The prompt includes a usage description that you specify in your app's info.plist. Apps that haven't updated to iOS 14 will show default reason text. If you notice a prompt that you don't expect for your app, you might be using a third party framework that accesses the local network. https://developer.apple.com/videos/play/wwdc2020/10110/

I cross posted and a DTS engineer responded that they are working on it: https://developer.apple.com/forums/thread/651641

https://developer.apple.com/documentation/networkextension/local_push_connectivity/receiving_voice_and_text_communications_on_a_local_network