For visible pushes, you'd have to build in something to prevent sending the push itself. It is by design that visible pushes are sent after the user killed the app. --> "Alert" notification.For silent pushes see below:This behavior is inconsistent with the documentation.https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1623013-application?language=objc"However, the system does not automatically launch your app if the user has force-quit it. In that situation, the user must relaunch your app or restart the device before the system attempts to launch your app automatically again."To clarify, as the user, you swipe away your application from app switcher, and the OS is relaunching it silently to deliver "content-available = true" push notifications?Out of curiousity, what happens if you disable "background app refresh", or place your device in "low data mode". Both of these should also prevent "background fetch" from occurring. It would be interesting to see if this is not the case either with the latest OS version.I recently ran into the same thing for my app on iOS 13.2.x. As a developer, I'd like the ability to wake up the app given the appropriate circumstance. As a user, I would NOT want every single app to be able to do this without giving it express permission to do so. Enough tracking of users as it is. If I remove an app from app-switcher, I intend for it to not be allowed to run.

Hey Steve,First of, I assume that you ommitted code from your didReceivePush code right? You'd normally want to do something in there with the userInfo that gets passed. I assume from "switch off and then switch on device", that you mean power off, and power back up? If so, are you expecting your app to still be running? 1. What service are you using to send your push notification?2. Is it an Alert notification or content-available one?3. Depending on 2, do you have the "priority" set correctly?4. Do you have the background mode checked for remote notifications?5. If content-available, did you ensure you didn't set alert body, sound, or badge?From some videos it sounds like they're starting to crack down on misconfigured pushes, but that is just speculation. I haven't seen any documentation to state pushes will STOP being sent if misconfigured.

Are you willing to share a sample body of your apns payload? When you submit your silent push to APNs, did you ensure that priority is set to 5 and your badge, sound, and alert keys are not specified?A few other things to check:1. Background app refresh2. Low data modeCheck out the "advances in networking part 2" from this summer, specifically the part about changes to "background fetch" when the new "low data mode" is enabled. Background fetch is described as something that WONT be executed if the user has low data mode enabled for their currently connected network.

The documentation for the push payload explicitly state that sending a "content-available" message with badge, alert, or sound specified is invalid. Can you share what push provider you are using? I'd check the response from APNs request to send if you have access to such information.A few things to check:1. Ensure background app refresh is enabled for the system, and subsequently, the application.2. Ensure low-data-mode is not configured for the connected network.3. Ensure low-power mode is not enabled (which disables background fetch)

Republishing your app will not affect your push certificate. Just as the apple dev support email says, you must configure that under Certificates, Identifiers & Profiles.If you see something about keychain and requesting a certificate from an authority, you're on the right track.Here is an apple link on how to do it:https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/establishing_a_certificate-based_connection_to_apnsOtherwise there are a few quick hits on google "generate push certificate". The look and feel has been updated over the years so a few online articles may look a little dated.

When you're testing are you connected to the debugger? If so, try the "simulate background fetch" operation too.In one of the networking videos this summer, it was stated that if the user is on low data mode (per network), all "background fetch" will be discontinued. Based on the API naming, I assume this means the same API as silent push i.e. fetchCompletionHandler.Double check the test devices are not metering their network with Low Data mode enabled.Out of curiosity, how many silent notifications are you sending per day/per user on average?

Do your messages have the time to live property set? Like facetime voip calls for example, the push would need to be delivered immediately. Wondering if the system is queuing up the messages for a later time or not. I assume any VOIP push would require immediate delivery (or phone offline) for calling purposes, just a thought to double check.

For discussion purposes, can you confirm if the syncing user defaults is working is happening from your iPhone to Watch P2P, or the watch is connected to infrastructure WiFi and circumventing the iPhone?

I've had some success with this. Out of curiosity, how soon after you deploy the iPhone app do you attempt to launch the watch app? I've noticed when deploying with Xcode to iPhone that the watch app isn't immediately installed. You can check this by viewing all apps and see the watch app icon fill the pie as it installs. Could this be what you were experiencing? Another trick, put both devices in airplane mode, delay, disable airplane, then use your watch to "ping" your iPhone. Seems to have done the trick sometimes too.

Are you running this on simulator? Sometimes the methods to change state react really slowly on sim, but not real device. I've had to wait upwards to 15 seconds when calling .stopActivity(date) on the session.

You're using two different types of queries.The HKQuantitySeriesSampleQuery that is available iOS 13+ will give you different results than just the simple HKSampleQuery.1. Is the HeartRate data you are expecting to have returned recorded by your app?2. Does the Health app on the iOS 12 device show many more samples than what you're getting in your query?From your samples provided from iOS 12, looks like the recordings are every 10 minutes. This could be the standard recording from the watch, I can't remember if it was every 6, 8, or 10 minutes that samples would be recroded (when not in an active workout).

Half the battle is knowing what classes to look for. The WWDC videos are a good start to finding your answers.TLDW, here are the things you're looking for.For discussion purposes, if you wanted to make a step counter application, that monitors progress throughout the day and sends local notifications when milestones have been met, I would take a look at one of these two long-running queries:1. https://developer.apple.com/documentation/healthkit/hkanchoredobjectquery2. https://developer.apple.com/documentation/healthkit/hkobserverqueryAs for getting the background updates, refer to: https://developer.apple.com/documentation/healthkit/hkhealthstore/1614175-enablebackgrounddeliveryJump down to the discussion and view the note, depending on the type of data you want to collect, you can get throttled."NoteSome data types, such as step counts, have a minimum frequency of HKUpdateFrequency.hourly. This frequency is enforced transparently."Make sure you're clear and up front with your user about this data you're going to collect and send to your server. Privacy is important.

The preferred approach would be to take an HKWorkout and then create a predicate/query to find associated route samples. I don't think it is possible to go the inverse of that.Check out this link for details: https://developer.apple.com/documentation/healthkit/workouts_and_activity_rings/reading_route_dataOut of curiosity, how are you getting references to your HKWorkoutRoute objects now?

If you're still looking for some details, Chepiok asked a similar question and I replied at length here: https://forums.developer.apple.com/thread/126051

Did you come up with anything on this? Is your objective to determine your launch reason before returning from didFinishLaunching?My use case is to prompt the user to complete onboarding on their phone which includes several user agreements (i.e. Terms of Service and Privacy Statement). I was curious about this. Through experimentation with the simulator, I may have found a way to detect it, but I wouldn't rely on it if your timing or initialization depends on it.watchOSOn InterfaceController X, Y, or Z (activate, load, appear) do:1. Set the delegate to the WCSession.default2. Activate the session3. onActivation, send message (or on controlled event from interface)iOSIn your app delegate, immediately do:1. Set the WCSession delegate2. Activate the session3. Observe the message come inIn this test scenario, I observed that the didReceiveMessage is invoked right away in a different thread.default20:18:54.456641-0600appnameApplication-DelegatesubsystemdidFinishLaunching() options: nildefault20:18:54.468903-0600appnameApplication-DelegatesubsystemReceived message ["OnboardingRequest": 1]default20:18:54.493954-0600appnameApplication-DelegatesubsystemFinished launchingNote: The middle message was captured on a background thread (not the same thread invoking didFinishLaunching). Not ideal but it might work, as long as you account for a potential race condition nightmare.