My app need a specific scene that play a video when my iPhone close to NFC Tags. and my app can read the data from NFC Tags, the data will tell us which kind of video can be play. I tried to write URLScheme or Universal Link in NFC Tags, but all this ways will pop up notifications. not launch my app and play a video, how can I design my app. please give me some advice, thanks!

I'd like to launch my APP via scanning NFC Tags In BackgroundMode. However, every time when I scan NFC tags, there always APP notification pops up, instead of opening APP directly. Please advise me how to skip the APP notification and directly launch APP.

Hello, as the title says, I am trying to access Bluetooth in a system daemon. I am running on MacOS Sonoma 14.5. When initializing Bluetooth, my daemon received Unauthorized state. I have tried to add my daemon in the system settings (System Preferences > Security & Privacy > Privacy > Bluetooth) "Allow applications to access Bluetooth" by adding the program executable path defined by the entry Program of my system daemon as suggested here: https://developer.apple.com/forums/thread/662459. But I am still having the issue. Writing a system daemon with Bluetooth is not my final goal. The bigger picture is the smartcard reader driver with Bluetooth access which as the same issue and the solution is probably related. I do not remember how but my smartcard reader driver use to work with Bluetooth but it does now with the same Unauthorized error. As far as I can see daemon and smartcard drivers does not have support for entitlement. Here are the logs for my sample system daemon: my_daemon [0x6000011b0000] activating connection: mach=true listener=false peer=false name=com.apple.server.bluetooth.le.att.xpc bluetoothd [0x7f804828e8a0] activating connection: mach=false listener=false peer=true name=com.apple.server.bluetooth.le.att.xpc.peer[76672].0x7f804828e8a0 bluetoothd Received XPC message "CBMsgIdCheckIn" from session "" bluetoothd Received XPC check-in from session "my_daemon-5555494498236e3b5e2e395b93c13af176769937-peripheral-76672-67" fAccessLevel 0 fProgrammaticPairing 0 fLimitedForMediaAccess 0 bluetoothd Access level is less than kXPCAccessLevelSystem for session "my_daemon-5555494498236e3b5e2e395b93c13af176769937-peripheral-76672-67". Restricted state operation not allowed bluetoothd Sending 'session attached' event for session "my_daemon-5555494498236e3b5e2e395b93c13af176769937-peripheral-76672-67" bluetoothd Attached session for "my_daemon-5555494498236e3b5e2e395b93c13af176769937-peripheral-76672-67" with session: 0x7f804802d1b0, session handle: 0xef8d0000 bluetoothd Registering peripheral session "my_daemon-5555494498236e3b5e2e395b93c13af176769937-peripheral-76672-67" with backgrounding: off, persistence: off (CBSR) restoreID: (null) bluetoothd Error getting Application State for <private>: <private>, 3 bluetoothd Error getting Application State for <private>: <private>, 3 bluetoothd Session "my_daemon-5555494498236e3b5e2e395b93c13af176769937-peripheral-76672-67" tccRequired : 1 bluetoothd ReadyForTCC. TCC required:1 fLimitedForMediaAccess:0 fDeviceAccessForMediaExtension:0 bluetoothd Session "my_daemon-5555494498236e3b5e2e395b93c13af176769937-peripheral-76672-67" : needsRestrictedStateOperation = 0, overrideRestrictedState = 0 , denylistMode = 0, receivesControllerBTClockEvents=0 my_daemon Received CBMsgIdReadyForTCC my_daemon Running performTccCheck CBManager tccAvail 1, tccRequired 1 my_daemon TCC required my_daemon [0x6000011b8000] activating connection: mach=true listener=false peer=false name=com.apple.tccd my_daemon [0x6000011b8000] failed to do a bootstrap look-up: xpc_error=[3: No such process] my_daemon [0x6000011b8000] invalidated after a failed init my_daemon send_message_with_reply(): user tccd unavailable, sending 0x600000ab4000 to system tccd my_daemon [0x6000011b4000] activating connection: mach=true listener=false peer=false name=com.apple.tccd.system tccd [0x7fd4d1f7ed80] activating connection: mach=false listener=false peer=true name=com.apple.tccd.system.peer[76672].0x7fd4d1f7ed80 tccd REQUEST: tccd_uid=0, sender_pid=76672, sender_uid=0, sender_auid=-1, function=TCCAccessRequest, msgID=76672.1 tccd AUTHREQ_CTX: msgID=76672.1, function=<private>, service=kTCCServiceBluetoothAlways, preflight=no, query=1, client_dict=(null), daemon_dict=<private> tccd AUTHREQ_ATTRIBUTION: msgID=76672.1, attribution={requesting={TCCDProcess: identifier=my_daemon-5555494498236e3b5e2e395b93c13af176769937, pid=76672, auid=0, euid=0, binary_path=/Users/olivier/daemon/my_daemon}, }, tccd AUTHREQ_SUBJECT: msgID=76672.1, subject=/Users/olivier/daemon/my_daemon, tccd Refusing TCCAccessRequest for service kTCCServiceBluetoothAlways from client Sub:{/Users/olivier/daemon/my_daemon}Resp:{TCCDProcess: identifier=my_daemon-5555494498236e3b5e2e395b93c13af176769937, pid=76672, auid=0, euid=0, binary_path=/Users/olivier/daemon/my_daemon} in background session tccd AUTHREQ_RESULT: msgID=76672.1, authValue=0, authReason=5, authVersion=1, error=(null), tccd REPLY: (0) function=TCCAccessRequest, msgID=76672.1 my_daemon [0x6000011b4000] invalidated after the last release of the connection object bluetoothd Received XPC message "CBMsgIdTCCDone" from session "my_daemon-5555494498236e3b5e2e395b93c13af176769937-peripheral-76672-67" tccd [0x7fd4d1f7ed80] invalidated after getting a no-senders notification - client is gone bluetoothd [0x7f80482820f0] activating connection: mach=true listener=false peer=false name=com.apple.tccd.system tccd [0x7fd4d32585f0] activating connection: mach=false listener=false peer=true name=com.apple.tccd.system.peer[169].0x7fd4d32585f0 tccd REQUEST: tccd_uid=0, sender_pid=169, sender_uid=0, sender_auid=-1, function=TCCAccessRequest, msgID=169.48 tccd [0x7fd4d313d880] activating connection: mach=true listener=false peer=false name=com.apple.tccd tccd [0x7fd4d313d880] failed to do a bootstrap look-up: xpc_error=[3: No such process] bluetoothd [0x7f80482820f0] invalidated after the last release of the connection object bluetoothd Bluetooth user permission alwaysAuth: denied tccd [0x7fd4d313d880] invalidated after a failed init tccd FORWARD: to=com.apple.tccd/0, request: { require_purpose=<xpc_null> service="kTCCServiceBluetoothAlways" function="TCCAccessRequest" preflight=true target_token={pid:76672, auid:-1, euid:0} TCCD_MSG_ID="169.48" background_session=false } tccd REPLY: from=com.apple.tccd, reply: { XPCErrorDescription="Connection invalid" } tccd forwardMessage error: Connection invalid. tccd [0x7fd4d3152bf0] activating connection: mach=false listener=false peer=true name=com.apple.tccd.system.peer[169].0x7fd4d3152bf0 bluetoothd [0x7f80482820f0] activating connection: mach=true listener=false peer=false name=com.apple.tccd.system tccd REQUEST: tccd_uid=0, sender_pid=169, sender_uid=0, sender_auid=-1, function=TCCAccessRequest, msgID=169.49 tccd [0x7fd4d32585f0] invalidated after getting a no-senders notification - client is gone tccd [0x7fd4d1f4c810] activating connection: mach=true listener=false peer=false name=com.apple.tccd tccd [0x7fd4d1f4c810] failed to do a bootstrap look-up: xpc_error=[3: No such process] tccd [0x7fd4d1f4c810] invalidated after a failed init tccd FORWARD: to=com.apple.tccd/0, request: { require_purpose=<xpc_null> service="kTCCServiceBluetoothAlways" function="TCCAccessRequest" preflight=true target_token={pid:76672, auid:-1, euid:0} TCCD_MSG_ID="169.49" background_session=false } tccd REPLY: from=com.apple.tccd, reply: { XPCErrorDescription="Connection invalid" } tccd forwardMessage error: Connection invalid.

When I register & schedule a Background Task on an iPad, it runs properly. Running the exact same code on an M1 MacBook Pro, though, never schedules the task. There's no error, just a failure to schedule. After scheduling and calling getPendingTaskRequests, on the iPad you can see that it has a pending task, but not on the Mac. Why would this be? BGTaskScheduler.shared.register(forTaskWithIdentifier: taskIdentifier, using: nil) { [self] task in print("task to run") } do { try BGTaskScheduler.shared.submit(request) BGTaskScheduler.shared.getPendingTaskRequests { [self] tasks in print(tasks.count) //Prints 1 on iPad, prints 0 on Mac } } catch { //Code never comes here. print(error) }

Hi team, I'm working on an MQTT client for Apple platforms (macOS, iOS, and possibly tvOS and watchOS). I would like the client to listen to messages even when the application is in the background. I would appreciate any suggestions on the best approach to achieve this. Based on iOS Background Execution Limits, it seems that my best bet is to use a long-running background process with BGProcessingTaskRequest while setting up the connection. Does that sound like the right approach? Is there any limits for the bg tasks? I currently have a working BSD socket. I'm not sure if it is necessary to switch to the Network Framework to have the background task working, but I'm open to switching if it's necessary. If the approach works, does that mean I could built a http client to process large upload/download tasks without using NSURLSession? As I'm working on a cross platform project, it would be benefit if I dont need a separate http client implementation for Apple. Any insights on this topic would be greatly appreciated. Additionally, it's off topic, but the link to "WWDC 2020 Session 10063 Background Execution Demystified" (https://developer.apple.com/videos/play/wwdc2020/10063/) is broken. Is there a way to access the content there? Thanks in advance for your help and insights!

We have a BLE app and we are trying to get it to work in Background Mode consistently. Use case: RFID BLE reader is attached to a printer Person installs the iOS app on phone and enables Background Mode Person walks to the printer with phone iOS App connects to RFID BLE reader and authenticates to allow secure printing Current status/Problem: On several tests, we were able to connect to the BLE device, but with inconsistent results. For example, for 5 - 2 min tests - (1) we see 8 successful scans, (2) 1 successful scan, (3) 20 successful scans, (4) 15 successful scans, and (5) 11 successful scans. In the above tests, we were getting a scan every 3-4 secs and then it scanning stops. The objective is to maintain continuous scanning until user closes app or disables background mode. Why does scanning stop? How can we make scanning continuous? Any guidance you can provide is appreciated.

Hi, I'm developing a Live Activity Widget that shows a count down timer. In the current solution I have a stop watch that is responsible for handling the start, stop, resume, reset function. When the stop watch starts I have timer that calls on an updateTime function every 0.2 seconds. This works well. The problems comes when I try to use my stop watch in the Live Activity Widget. I have a timer that updates the live activity attributes with content every 0.5 second. // Start the activity let activity = try? Activity.request(... DispatchQueue.main.async { self.logger.log("Start internal timer") self.timer = Timer.scheduledTimer(withTimeInterval:0.5, repeats: true) { _ in self.logger.log("Update activity widget.") self.updateActivity() } } Is this a correct approach? If not what should I use to implement a stop watch with a count down timer and a corresponding progress bar/view?

My team and I would like to develop a mechanism that collects the user’s location a few times per day, to detect when the user travels to a different country, for the user’s convenience. The app is very likely going to be opened very rarely. The user would of course be made aware of why collecting the location a few times a day is desired - namely, saving them the effort of having to remember to open the app every time they travel. My question is the following: given that the app would rarely be interacted with, what is the best strategy for collecting the location? The goal is to handle scenarios where the OS might avoid sending location events or notifications to the app. I imagine that the backend might need to intervene and send the occasional push notification to remind the user to open the app from time to time. There are 3 strategies that I’m aware of: LocationManager’s startMonitoringSignificantLocationChanges Scheduling BGAppRefreshTasks Using silent push notifications scheduled by the server. Ideally, using a location push service extension Keeping in mind the “Background execution demystified” WWDC session, documentation, and other threads, I concluded the following: The first idea is probably the least suitable, since it probably requires the app to be opened often, and the location updates would not be sent by OS if the app has been terminated from the app switcher. The second approach would also suffer from infrequent use and termination. The third approach seems not to be affected as much by infrequent usage. I understand that the 3rd strategy might also lead to the OS omitting to wake up the app when it has been terminated by the user. How would you implement this mechanism?

Issue Statement: I am encountering difficulties with executing network calls from within a Flutter method during iOS native background task handling. Background: In my iOS Flutter application, I've implemented background task handling using native iOS code (Swift), leveraging the BGTaskScheduler's BGProcessingTask provided by iOS. The background task is set up to perform periodic network requests, but the network calls are made through a Flutter method invoked via platform channels from the iOS code. Problem Description: While the background task executes as expected and invokes the Flutter method successfully, the network calls initiated within the Flutter method fail to complete during background task execution. The method execution seems to proceed up to the point of initiating the network call, but the call itself does not complete successfully.

I am trying to code out a background refresh part of my app but there are two centralManager functions in the app. func centralManager(_ central: CBCentralManager, didDiscover peripheral: CBPeripheral, advertisementData: [String : Any], rssi RSSI: NSNumber) { if peripheral.identifier.uuidString == selected { selectedPeripheral = peripheral centralManager?.stopScan() centralManager?.connect(selectedPeripheral!, options: nil) } } func centralManager(_ central: CBCentralManager, didConnect peripheral: CBPeripheral) { print("Connected to peripheral: \(peripheral)") // Subscribe to disconnection events peripheral .publisher(for: \.state) .sink { [weak self] state in if state == .connected { self?.isConnected = true } else if state == .disconnected { // Peripheral is disconnected, send notification if self?.isConnected == true { self?.sendNotification() self?.isConnected = false } } } .store(in: &amp;cancellables) } and this is the refresh part private func handleBluetoothMonitoring(task: BGAppRefreshTask, bluetoothMonitor: BluetoothMonitor) { let queue = DispatchQueue(label: "com.yourcompany.bluetoothmonitor") task.expirationHandler = { // Handle expiration of the task if needed } queue.async { // Perform Bluetooth monitoring tasks here if let centralManagerInstance = bluetoothMonitor.centralManager { DispatchQueue.main.async { bluetoothMonitor.centralManagerDidUpdateState(centralManagerInstance) } } else { print("Central manager is nil") } // End the task task.setTaskCompleted(success: true) } } Is there a way to solve this? Thanks!

Is there any possible way to run a background task in an iOS App when the app is forced quit or when the app is not in the App Switcher?

I'm trying to start and stop recording when my app is in background periodically. I implemented it using Timer and DispatchQueue. However whenever I am trying to initiate the recording I get this error. This issue does not exist in foreground. Here is the current state of my app and configuration. I have added "Background Modes" capability in the Signing & Capability and I also checked Audio and Self Care. Here is my Info.plist: <plist version="1.0"> <dict> <key>UIBackgroundModes</key> <array> <string>audio</string> </array> <key>WKBackgroundModes</key> <array> <string>self-care</string> </array> </dict> </plist> I also used the AVAudioSession with .record category and activated it. Here is the code snippet: func startPeriodicMonitoring() { let session = AVAudioSession.sharedInstance() do { try session.setCategory(AVAudioSession.Category.record, mode: .default, options: [.mixWithOthers]) try session.setActive(true, options: []) print("Session Activated") print(session) // Start recording. measurementTimer = Timer.scheduledTimer(withTimeInterval: measurementInterval, repeats: true) { _ in self.startMonitoring() DispatchQueue.main.asyncAfter(deadline: .now() + self.recordingDuration) { self.stopMonitoring() } } measurementTimer?.fire() // Start immediately } catch let error { print("Unable to set up the audio session: \(error.localizedDescription)") } } Any thoughts on this? I have tried most of the ways but the issue is still there.

I have an app with which users take photos and upload them in batches. It's used often on older devices, in areas with less than ideal network, and for durations of a full workday - so often the device has low power. The current implementation of uploads uses an NSURLSession configured for the foreground, and as a result my users are used to having to keep the app in the foreground while an upload completes. However, these uploads are big and connectivity is often low, so this takes a long time - often users are stuck waiting with the app foregrounded for 15 minutes or so while the upload completes. So, I created a build which uses an NSURLSession configured for the background. In the ideal case, users could start the upload, put the device in their pocket and continue their workday, and the next time they open their device it will be complete. For some users this ideal case has come true. However, for others, the uploads sit in progress for an indeterminate amount of time, making no progress. My suspicion is that this is because the OS is deferring them until a time when network and power is more available. However, my users are using work devices at a work location - reliable power and network might never be available. Being able to background the app and continue working is valuable for these users, but having the upload complete promptly is essential for them. My questions are: Is it true that background configured NSURLSessions will defer network requests when connectivity or power is low, even if discretionary = NO? Is the exact behavior for when requests will be attempted in the background documented? Is there a way to reliably test background configured NSURLSessions in XCode? I've attempted throttling my connection with Charles Proxy, and using my device in Low Power Mode, but I'm unable to reproduce the request stalling behavior my users are experiencing in the wild. Is there a way to create an NSURLSession that will muscle through difficult or inefficient uploads in the background, with the same reliability as a foreground session? If not, what is Apple's recommended approach to situations like mine? I've considered queueing both a background and foreground upload, and cancelling the other once one completes, but this seems disrespectful to the user's resources. Will setting timeoutIntervalForResource to a lower value cause the OS to more aggressively attempt uploads? Or simply to throw an error sooner? I want the OS to give the upload a long time to complete, but I also want it to attempt it right away. Thanks for any information!

We have an iOS app built using Capacitor. We are seeing a large increase in app crashes on iOS 17.4 (iPhone). Other OS versions seem to be showing significantly fewer crash numbers. We are unsure what is causing this, as our app did not go through any major releases. I have attached the crash log below. Thanks Exception Type: EXC_CRASH (SIGKILL) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: RUNNINGBOARD 0xd00d2bad

I am running two different background modes(not at the same time), 1 with a workout and 1 with a location. I noticed that the app logo appears above the watch face for both background modes but does not show up consistently. I wonder what the significance of the logo showing up above watch face is? Additionally why does it show up sometimes but not others? Thanks

We are developing an app which connects to a BLE peripheral in the background whenever it gets close to it. What we have used so far is that we monitor a circular region. When the phone enters the region the app will start scanning for peripherals and when it discovers the peripheral it connects to it. This worked pretty well for the last few iOS versions, perhaps iOS 14-16. It wasn't perfect but for the most part it would feel like it connected rather quickly when you would approach the BLE peripheral. If you listen to music via BLE or talk to someone using your BLE headset then it could sometimes work noticeably worse. But, as said, for the most part it would work satisfactory. Starting with iOS 17 and analyzing the functionality over the past 6 months or so we've noticed a clear worsening of it. It does generally connect to the peripheral but the user might often have to wait for quite some time. Rather frequently the user must even light up the screen of the phone before anything even happens. It appears that some sort of resource allocation, battery saving feature or similar has affected this functionality greatly. The time difference between entering a region and physically approaching the device is generally around 2-3 minutes. We have tried to do it more in line with documentation and follow the guidelines that we find in: https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetoothBackgroundProcessingForIOSApps/PerformingTasksWhileYourAppIsInTheBackground.html So in doing this we do not start scanning for peripherals when a region is entered, but instead we directly invoke connectPeripheral:options:. This way we offload to the system that we want to connect to that peripheral. However, when testing this we see no real improvement. Sometimes it connects satisfactorily. Sometimes it doesn't really connect at all. Many times it connects if the user lights up the screen. So just looking at what the user is experiencing our analysis is that doing it this way works even worse than what we previously did. I understand that the system has many resources to consider and that some may have to wait while others perform things. But are there any documentation on what one could expect from initiating a connectPeripheral:options: from the background? In the link I posted it simply states the iOS device will reconnect when the user returns home. So not much detail in terms of performance which is crucial for our application. If there aren't any further details on the performance, are there any other ways to improve this functionality? We are not looking at draining the battery whatsoever but we simply need our background running app to be as responsive as possible for a few minutes after it has been launched by the region monitoring. We understand that battery life is important but since this happens rarely and sparsely (not more than a few times per day) it seems reasonable that there should be a way to be able to make it function properly.

First off - I have read and fully understand this post - Apple doesn't want us abusing users' hardware so as to maximize the quality of experience across apps for their customers. I am 100% on board with this philosophy, I understand all design decisions and agree with them. To the problem: I have an app that takes photo assets, processes them for network (exportSession.shouldOptimizeForNetworkUse = true), and then uploads them. Some users have been having trouble, did some digging, they're trying to upload 4K 60FPS videos. I think that is ridiculous, but it's not my place. The issue is that the export time for a 4K60FPS video that is ~40s long can be as long as 2m. So if they select a video to upload, and then background the app that upload will ALWAYS fail because the processing fails (I have BG uploads working just fine). My understanding is that default I have 30s to run things in the background. I can use UIApplication.pleasegivemebackgroundtime to request up to 30 more seconds. That is obviously not enough. So my second option is BGProcessingTask - but that's not guaranteed to run ever. Which I understand and agree with, but when the user selects a video while the app is in the foreground the expectation is that it immediately begins processing. So I can't use a BGProcessingTask? Just wondering what the expected resolution here is. I run tasks, beg for time, if it doesn't complete I queue up a BGTask that may or may not ever run? That seems ****** for a user - they start the process, see it begin, but then if the video is too big they just have to deal with it possibly just not happening until later? They open up the app and the progress bar has magically regressed. That would infuriate me. Is there another option I'm not seeing? Some way to say "this is a large background task that will ideally take 30-60s, but it may take up to ~5-7m. It is user-facing though so it must start right away"? (I have never seen 5-7m, but 1-2m is common) Another option is to just upload the full 4K60FPS behemoth and do the processing on my end, but that seems worse for the user? We're gobbling upload bandwidth for something we're going to downsample anyway. Seems worse to waste data than battery (since that's the tradeoff at the end of the day). Anyway, just wondering what the right way to do this is. Trivially reproducible - record 1m 4K60FPS video, create an export session, export, background, enjoy failure.

So, we've got a mobile app that is using background processing to occasionally scan for nearby BLE beacons. When running a debug / local build of the app, everything behaves as expected, but if we upload a build to TestFlight and install from there, the background processing doesn't happen. This behavior would seem to point to a capability in the App ID not being provisioned, but when I look in the Identifiers section of Apple Developer, Background Modes as a capability isn't listed for either the existing Application Identifier or when creating a brand new one. The app has the Background Modes capability assigned if I look at it in XCode. Any thoughts as to where to look next or what I'm missing?

We are developed app based on driver behaviour using location and sensor data. It's working in both background and foreground using region monitoring. Its consume more battery comparing other apps like. Its reduce 5% for every 5 to 10 mins of duration. We are using for our app functionality Location (Always) - every 1sec Sensor - Accelerometer - every 20data for 1sec Background - Region monitoring Time Action - 1sec for 20time Any possible way to reduce battery consuming? If any please suggest your points. Thanks in advance for your comments.

Hi All, I have a strange issue. I am using enableBackgroundDelivery for updating user step count in background mode using health kit. It works fine when I execute the app by pressing 'Run' in xcode. But the code is not triggering when I am directly launching it on my device. I have tried many different things but cannot figure out the issue from 2 days 😭. I would really appreciate any suggestions. Thanks