I can not simulate the background fetch on the device in xcode

What version of Xcode are you using? iOS?

There’s an ongoing issue with testing background fetch on modern versions of iOS, which you can learn more about in this thread. However, the symptoms don’t match what you’ve described; rather, running the app fails with the message *** has denied the launch request.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Dear, the device ios is 11.2.5 and the xcode is the latest. Updated on test day, so nine. Tested on a high mountain mac. Sorry for English, I'm using a translator because I'm Brazilian and I do not speak English well.

Thanks for the info. It took me a while but I finally twigged as to what you’re doing here, namely, choosing Debug > Simulate Background Fetch. The behaviour you’ve described is expected, but it is definitely confusing if you’re just starting out. Let me explain.

Consider an app like this:

func application(_ application: UIApplication, willFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey : Any]? = nil) -> Bool {
    NSLog("QQQ start")
    UIApplication.shared.setMinimumBackgroundFetchInterval(12 * 60 * 60)
    Timer.scheduledTimer(withTimeInterval: 5.0, repeats: true) { _ in
        NSLog("QQQ ping")
    }
    return true
}

func application(_ application: UIApplication, performFetchWithCompletionHandler completionHandler: @escaping (UIBackgroundFetchResult) -> Void) {
    NSLog("QQQ perform fetch start")
    DispatchQueue.main.asyncAfter(deadline: .now() + 20.0) {
        NSLog("QQQ perform fetch done")
        completionHandler(.newData)
    }
}

That is, at startup it logs the start message and then starts a timer that logs the ping message every 5 seconds. And that’s exactly what it’ll do if you run it on the device.

2018-02-01 11:28:02.493927… QQQ start
2018-02-01 11:28:07.495553… QQQ ping

If you then hit the Home button the app will suspend, and you’ll stop seeing ping messages logged.

The app also has code that logs when it receives a background fetch event (perform fetch start) and when it’s done with that (perform fetch done). You can trigger this using Debug > Simulate Background Fetch. At that point you’ll drop into the debugger inside

mach_msg_trap

. I’ll explain more about this below, but for the moment you can just continue in the debugger ( Debug > Continue). At this point you’ll see something like this:

2018-02-01 11:35:27.744140… QQQ perform fetch start
2018-02-01 11:35:27.845761… QQQ ping
2018-02-01 11:35:32.902913… QQQ ping
2018-02-01 11:35:37.887904… QQQ ping
2018-02-01 11:35:42.895025… QQQ ping
2018-02-01 11:35:47.881230… QQQ ping
2018-02-01 11:35:49.509119… QQQ perform fetch done

That is, the

application(_:performFetchWithCompletionHandler:)

method is called, it logs perform fetch start, and then, roughly 20 seconds later, it logs perform fetch done. In between those times your app is running in the background, and hence the ping message gets logged every 5 seconds. Finally, once the completion handler is called your app gets suspended again and you’re back to where you started.

So, why does it stop in

mach_msg_trap

? The goal is to give you a chance to set a breakpoint in your background fetch handling code, so Xcode forces your app to stop, just like it would if you hit the pause button ( Debug > Pause). It stops in

mach_msg_trap

because that’s where your main thread is sitting when your app is suspended in the background.

In short, when you do a Debug > Simulate Background Fetch and stop in

mach_msg_trap

:

• That’s expected behaviour

• It’s not a sign of any problem problem

• You can safely continue execution via Debug > Continue

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

First of all, I would like to say "thank you", your help was crucial. I clicked "continue" as you said and the code worked and I could see where the fault was. The interesting thing is that it was a fault that was not reproduced in the simulator. In the simulator everything worked normally. on the actual device, the console failed. This is interesting. Anyway, I fixed it and it worked on the device. Now if I have two doubts: 1) Is this pause, which I had to click on continue, only occur in the emulation or can it occur when the user downloads the app? 2) If it worked on the device, connected to XCODE, does it mean that it will work when I submit in the app store? Or does it have things that only work when installed through xcode?

1) Is this pause, which I had to click on continue, only occur in the emulation or can it occur when the user downloads the app?

This pause is an artefact of the debugger, and thus I wouldn’t expect it to show up on user installs.

2) If it worked on the device, connected to XCODE, does it mean that it will work when I submit in the app store?

It’s definitely possible for things to work in your office and fail in the field. DTS has a long technote that suggests various ways to minimise your risk, namely, Technote 2431 App Testing Guide.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

This is not a good feature.

Unexpectedly throwing people into the debugger just causes confusion and leads to a lot of time being needlessly wasted.

Most of us would be perfectly happy to just set a breakpoint and get on with whatever we're working on.

This feature should be removed.

This feature should be removed.

The best way to get this feedback in front of the folks who can enact change is to file a bug report containing your arguments.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Is there any chance that this stop will occur in our online app to user? We are suffering a crash without explicit backtrace, which is appearing after we enabled our background fetch feature.

Is there any chance that this stop will occur in our online app to user?

I’m not entirely sure which part of my response you’re referring to here. However, if you post an Apple crash report of the problem you’re seeing, I’d be happy to take a look. Please put that in a new thread though; this thread is specifically about debugging infrastructure and your issue is one that happens in production.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"