The callback is not triggered when the app is launched from a terminated state via the notification action

Thanks for the post.

You should check with the support resources provided by the 3rd party, MAUI in this case, to get assistance with their software.

Unless another developer in the forums has experience with the third-party and can provide assistance.

Good luck on your project.

Albert
  Worldwide Developer Relations.

You should check with the support resources provided by the 3rd party

Right.

Alternatively, you can try reproducing this by calling URLSession directly. I suspect that’ll work, which confirms that this is something that your need to discuss with your third-party tooling vendor. OTOH, if you can reproduce it with URLSession, then you’ll calling an Apple API and we can help you here.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thank you for your response. We have also tried using URLSession and will revalidate from our end. Additionally, we connected with the Microsoft team. They confirmed that .NET MAUI is a wrapper over Apple’s native APIs, and this behavior is governed by iOS limitations. When an app is forcefully terminated, all background network tasks are cancelled and cannot resume unless the app is relaunched. Hence, this behavior is expected and cannot be controlled from the application side.PFA.

When an app is forcefully terminated, all background network tasks are cancelled

Correct.

It’d be more accurate to say “tasks in a URLSession background session”, but the gist is right.

I discuss this in some detail in Testing Background Session Code.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thank you for your updates. How do the custom notification buttons for MS Outlook and MS Teams continue to work even after the applications have been manually force-quit or killed? or What background mechanism allows background notification actions to function after an app (like Outlook/Teams) is forcefully terminated by the user?

How do the custom notification buttons … continue to work even after the applications have been manually force-quit or killed?

I’ve no idea, sorry.

I’m not familiar with those products, so I don’t know what those buttons actually do. And even if I did, there’s no guarantee I’d be able to work out how they do it.

However, I can offer some general titbits:

• Removing an app from the multitasking UI is a strong indication from the user that the app should not run in the background again until they manually relaunch it.
• Some subsystem, like URLSession, honour that request scrupulously; others less so. So the exact behaviour varies by subsystem.
• And even within a subsystem it changes over time. Testing Background Session Code explains one change in URLSession, but other subsystems have their own unique history.
• And some stuff that happens in the background doesn’t involve background execution of the app, and thus this request simply doesn’t apply. The most obvious example of that is push notifications, where the badge on the app’s icon is updated by the system, not by the app itself.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thank you for the update. As I understand it, URLSession will not work if the user forcefully terminates the application, and therefore the API call will not be executed. Please let me know if my understanding is incorrect.

Hi, we need this functionality so is there any alternative to fix this issue? Kindly, please let me know.

we need this functionality so is there any alternative to fix this issue?

It’s hard to answer that without more background as to what your app is actually trying to do. Can you describe the bigger picture here?

But, if your specific goal is “I want to start a background download and have it continue even if my app has been ‘force quit’ by the user” then, no, there’s no way to do that.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thank you for the updates. To keep things brief, could you please review my initial post? It includes the problem statement, steps to reproduce, and details of the exact issue we are facing. If you require any additional information, please let us know. Kindly check and advise if there is any alternative solution for kill mode in iOS. Thank you for your time and support.

could you please review my initial post?

I re-read your original post and:

• It’s written in terms of your third-party tooling, which I can’t help you with.
• It doesn’t say anything about your high-level goal.

Regarding that last point, my understanding of the issue as it currently stands is:

1. Your app issues requests in a URLSession background session.
2. You want to do custom HTTPS server trust evaluation on those requests.
3. When the user ‘force quits’ your app, the next time they run the app those requests all fail.
4. Which means that the authentication challenge delegate method never gets called.

Is that correct?

If so, the behaviour you’re seeing is all expected. Specifically:

• In step 3, the act of ‘force quitting’ the app causes all the requests to fail, as I explained above.
• In step 4, a request that’s failing in this way will go straight to urlSession(_:task:didCompleteWithError:), without calling urlSession(_:didReceive:completionHandler:) along the way.

So, when you ask:

is there any alternative to fix this issue?

it’s hard to answer because from Apple’s perspective there’s nothing broken. However, it’s clear that you’re trying to achieve some higher-level goal, and hence the questions in my previous reply.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"