We are experiencing an issue where our iOS app’s network extension (acting as a VPN) is being unexpectedly terminated by the operating system. The termination appears identical to a user-initiated stop, as the extension receives the following call: NEProviderStopReasonUserInitiated. The issue occurs sporadically but can happen 10–20 times per day on devices with less than 10% free storage. On one affected device, opening the Camera app (or using the camera within another app like WhatsApp) consistently triggers the issue, making it easily reproducible. Memory consumption does not seem to be the cause—the extension is stopped while using only ~10MB of memory, well below the 50MB limit. We noticed a pattern related to swap usage: • On affected devices, the “Swap Used” column shows very low values (a few MB). • On unaffected devices, swap usage is significantly higher (hundreds of MB). • This is the only clear difference we’ve observed. The issue occurs across different device models and iOS versions (18.2.1 and 17.6.1). It also happens across different app builds (compiled with Xcode 15.x and Xcode 16.x). We found a similar report on the Apple Developer Forums: 🔗 https://developer.apple.com/forums/thread/108149 Has anyone else encountered this behavior with Network Extensions? Could low swap usage or system resource constraints be a factor? Any suggestions for debugging or potential workarounds would be greatly appreciated.

I've searched all the App Intent and AssistantSchemas related documentation and I can't find anything related to workout, do I still need to use SiriKit?

We are currently developing a wallet solution that uses the iOS EEA HCE API’s, during the testing of enabling our wallet as the system default wallet, we are being presented with an iOS system alert that states: “Change the default contactless app? You can double-click to use cards in your default app. If Apple Wallet is not your default wallet app, you’ll need to open Wallet to use its cards, keys and tickets. Express Mode will continue to work when iphone is held near a compatible reader” Please can you advise how we can prevent Apple Pay’s express mode from intercepting the customers preferred wallet actions including transit payments. If this is not possible please can you provide the rationale for this not being possible given the Digital Marketing Act interoperability guidelines and EU Commitments in case AT.40452.

Apple multi-peer with 12 devices is unstable. Dear All, Has anyone tried Apple multi-peer with 12 devices connected? We are building an application relying on multi-peer where 12 Ipads will be updating data and each device needs to share data between. Can anyone tell me if we can use multi-peer framework for connecting 12 devices in the multi-peer network? We are facing stability problems in the connection when we connect 12 devices in the network.

We have developed a DNS filter extension that works for most applications, but it does not receive all DNS queries. In particular, if we have our extension installed and enabled, we see Safari browsing cause local DNS servers to be used instead of going through our extension. What is the logic for how DNS servers vs. extensions are chosen to resolve DNS queries?

Hello, We are experiencing slow launch time indicators in our performance monitoring tools(Crashlytics/DataDog/Xcode), and trying to understand what is the best approach to reduce it. Currently, cold launch takes ~900ms on iPhone 16 Pro , but ~2s on iPhone 11. Profiling app launch detected that most of the time is spend on loading the libraries. Our app is massive, we use a total of ~40 3rd parties libraries + 10 internal libraries. We enabled the "mergeable libraries" XCode new feature however the app launch is as written above. We also postponed some of the work in didFinishLaunch, which help a bit... But maybe we are trying to achieve the impossible? Could it be that large apps just can't reach the golden 500ms goal? Currently we are trying to create an "umbrella" library for all the third parties in order to force them to become part of the mergeable libraries. We would like to know if, are we on the right track?

Document based SwiftData apps do not autosave changes to the ModelContext at all. This issue has been around since the first release of this SwiftData feature. In fact, the Apple WWDC sample project (https://developer.apple.com/documentation/swiftui/building-a-document-based-app-using-swiftdata) does not persist any data in its current state, unless one inserts modelContext.save() calls after every data change. I have reported this under the feedback ID FB16503154, as it seemed to me that there is no feedback report about the fundamental issue yet. Other posts related to this problem: https://forums.developer.apple.com/forums/thread/757172 https://forums.developer.apple.com/forums/thread/768906 https://developer.apple.com/forums/thread/764189

I cannot access my corporate invoice. I don't know why I couldn't reach it. How and where can I reach it?

The UIApplication background task mechanism allows you to prevent your app from being suspended for short periods of time. While the API involved is quite small, there’s still a bunch of things to watch out for. The name background task is somewhat misappropriate. Specifically, beginBackgroundTask(expirationHandler:) doesn’t actually start any sort of background task, but rather it tells the system that you have started some ongoing work that you want to continue even if your app is in the background. You still have to write the code to create and manage that work. So it’s best to think of the background task API as raising a “don’t suspend me” assertion. You must end every background task that you begin. Failure to do so will result in your app being killed by the watchdog. For this reason I recommend that you attach a name to each background task you start (by calling beginBackgroundTask(withName:expirationHandler:) rather than beginBackgroundTask(expirationHandler:)). A good name is critical for tracking down problems when things go wrong. IMPORTANT Failing to end a background task is the number one cause of background task problems on iOS. This usually involves some easy-to-overlook error in bookkeeping that results in the app begining a background task and not ending it. For example, you might have a property that stores your current background task identifier (of type UIBackgroundTaskIdentifier). If you accidentally creates a second background task and store it in that property without calling endBackgroundTask on the identifier that’s currently stored there, the app will ‘leak’ a background task, something that will get it killed by the watchdog. One way to avoid this is to wrap the background task in an object; see the QRunInBackgroundAssertion post on this thread for an example. Background tasks can end in one of two ways: When your app has finished doing whatever it set out to do. When the system calls the task’s expiry handler. Your code is responsible for calling endBackgroundTask(_:) in both cases. All background tasks must have an expiry handler that the system can use to ‘call in’ the task. The background task API allows the system to do that at any time. Your expiry handler is your opportunity to clean things up. It should not return until everything is actually cleaned up. It must run quickly, that is, in less than a second or so. If it takes too long, your app will be killed by the watchdog. Your expiry handler is called on the main thread. It is legal to begin and end background tasks on any thread, but doing this from a secondary thread can be tricky because you have to coordinate that work with the expiry handler, which is always called on the main thread. The system puts strict limits on the total amount of time that you can prevent suspension using background tasks. On current systems you can expect about 30 seconds. IMPORTANT I’m quoting these numbers just to give you a rough idea of what to expect. The target values have changed in the past and may well change in the future, and the amount of time you actually get depends on the state of the system. The thing to remember here is that the exact value doesn’t matter as long as your background tasks have a functional expiry handler. You can get a rough estimate of the amount of time available to you by looking at UIApplication’s backgroundTimeRemaining property. IMPORTANT The value returned by backgroundTimeRemaining is an estimate and can change at any time. You must design your app to function correctly regardless of the value returned. It’s reasonable to use this property for debugging but we strongly recommend that you avoid using as part of your app’s logic. IMPORTANT Basing app behaviour on the value returned by backgroundTimeRemaining is the number two cause of background task problems on iOS. The system does not guarantee any background task execution time. It’s possible (albeit unlikely, as covered in the next point) that you’ll be unable to create a background task. And even if you do manage to create one, its expiry handler can be called at any time. beginBackgroundTask(expirationHandler:) can fail, returning UIBackgroundTaskInvalid, to indicate that you the system is unable to create a background task. While this was a real possibility when background tasks were first introduced, where some devices did not support multitasking, you’re unlikely to see this on modern systems. The background time ‘clock’ only starts to tick when the background task becomes effective. For example, if you start a background task while the app is in the foreground and then stay in the foreground, the background task remains dormant until your app moves to the background. This can help simplify your background task tracking logic. The amount of background execution time you get is a property of your app, not a property of the background tasks themselves. For example, starting two background task in a row won’t give you 60 seconds of background execution time. Notwithstanding the previous point, it can still make sense to create multiple background tasks, just to help with your tracking logic. For example, it’s common to create a background task for each job being done by your app, ending the task when the job is done. Do not create too many background tasks. How many is too many? It’s absolutely fine to create tens of background tasks but creating thousands is not a good idea. IMPORTANT iOS 11 introduced a hard limit on the number of background task assertions a process can have (currently about 1000, but the specific value may change in the future). If you see a crash report with the exception code 0xbada5e47, you’ve hit that limit. Note The practical limit that you’re most likely to see here is the time taken to call your expiry handlers. The watchdog has a strict limit (a few seconds) on the total amount of time taken to run background task expiry handlers. If you have thousands of handlers, you may well run into this limit. If you’re working in a context where you don’t have access to UIApplication (an app extension or on watchOS) you can achieve a similar effect using the performExpiringActivity(withReason:using:) method on ProcessInfo. If your app ‘leaks’ a background task, it may end up being killed by the watchdog. This results in a crash report with the exception code 0x8badf00d (“ate bad food”). IMPORTANT A leaked background task is not the only reason for an 0x8badf00d crash. You should look at the backtrace of the main thread to see if the main thread is stuck in your code, for example, in a synchronous networking request. If, however, the main thread is happily blocked in the run loop, a leaked background task should be your primary suspect. Prior to iOS 11 information about any outstanding background tasks would appear in the resulting crash report (look for the text BKProcessAssertion). This information is not included by iOS 11 and later, but you can find equivalent information in the system log. The system log is very noisy so it’s important that you give each of your background tasks an easy-to-find name. For more system log hints and tips, see Your Friend the System Log. iOS 13 introduced the Background Tasks framework. This supports two type of requests: The BGAppRefreshTaskRequest class subsumes UIKit’s older background app refresh functionality. The BGProcessingTaskRequest class lets you request extended background execution time, typically overnight. WWDC 2020 Session 10063 Background execution demystified is an excellent summary of iOS’s background execution model. Watch it, learn it, love it! For more background execution hints and tips, see Background Tasks Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Revision History 2023-06-16 Added a link to my QRunInBackgroundAssertion post. 2022-06-08 Corrected a serious error in the discussion of BGProcessingTaskRequest. Replaced the basic system log info with a reference to Your Friend the System Log. Added a link to Background Tasks Resources. Made other minor editorial changes. 2021-02-27 Fixed the formatting. Added a reference to the Background Tasks framework and the Background execution demystified WWDC presentation. Minor editorial changes. 2019-01-20 Added a note about changes in the iOS 13 beta. Added a short discussion about beginning and ending background tasks on a secondary thread. 2018-02-28 Updated the task name discussion to account for iOS 11 changes. Added a section on how to debug ‘leaked’ background tasks. 2017-10-31 Added a note about iOS 11’s background task limit. 2017-09-12 Numerous updates to clarify various points. 2017-08-17 First posted.

Im having issue with OneDrive that is affected our company iPads. User are able to drag and drop any folder or files over and now they cant. they are on the latest update for OneDrive and the IOS. Can someone look at this and also i reach to Microsoft and they said that nothing have change on there end.

Hi, I’m trying to get an array of strings from the user using AppIntents, but I’m encountering an issue. The shortcut ends without prompting the user for input or saving the value, though it doesn’t crash. I need to get the user to input multiple tasks in an array, but the current approach isn’t working as expected. Here’s the current method I’m using: // Short code snippet showing the current method private func collectTasks() async throws -> [String] { var collectedTasks: [String] = tasks ?? [] while true { if !collectedTasks.isEmpty { let addMore = try await $input.requestConfirmation("Would you like to add another task?") if !addMore { break } } let newTask = try await $input.requestValue("Please enter a task:") collectedTasks.append(newTask) } return collectedTasks } The Call func perform() async throws -> some IntentResult { let finalTasks = try await collectTasks() // Some more Code } Any advice or suggestions would be appreciated. Thanks in advance!

I am able to get location in for ground and back ground but Now I need to get location when user killed app.

Does iOS limit the number of packets per connection event to 4? When transmitting GATT data, each packet is 244 bytes. However, starting from the second packet, the updateValue method returns false, and the waiting time for peripheralManagerIsReadyToUpdateSubscribers callback varies significantly, ranging from 50ms to 100ms. Is this behavior normal?

I have two standalone app written for watchos (standalone). One to authenticate and one for connectivity to real-world devices. The connectivity app uses the authentication app before every action, Im testing this with two xcode projects I have created and tried different things ended up with this error. authapp://authenticate?callback=linkingapp://callback -[SPApplicationDelegate extensionConnection:openSystemURL:]:2418: URL with scheme "authapp" not supported how to get the url scheme working? Tested this in simulator and real device. info.plist and AppDelegate files are placed in both apps.

Hi there, This is my first time posting here. I'm working on small projects on Swift and SwiftUI now and then. I'm currently trying to develop an application that gets some bus arrival data using API and displaying them with live activities. The thing is that I'm not quite sure how frequently updates work yet. Still trying to figure out if I can update the live activity everytime the data coming right from the API changes or use push notification updates each minute passing by, but that is another thread that I'm going to focus with more details. Everytime i'm trying to deploy my app on my iphone or a simulator this error keeps popping up and I can't figure out why. Any ideas? Let me know if you need any snippet of my code. SendProcessControlEvent:toPid: encountered an error: Error Domain=com.apple.dt.deviceprocesscontrolservice Code=8 "Failed to show Widget 'com.gregorikouk.MapKitTut.BusWidgetKit' error: Error Domain=FBSOpenApplicationServiceErrorDomain Code=1 "The request to open "com.apple.springboard" failed." UserInfo={NSLocalizedFailureReason=The request was denied by service delegate (SBMainWorkspace)., BSErrorCodeDescription=RequestDenied, NSUnderlyingError=0xb1282dfe0 {Error Domain=SBAvocadoDebuggingControllerErrorDomain Code=1 "Failed to get descriptors for extensionBundleID (com.gregorikouk.MapKitTut.BusWidgetKit)" UserInfo={NSLocalizedDescription=Failed to get descriptors for extensionBundleID (com.gregorikouk.MapKitTut.BusWidgetKit)}}, FBSOpenApplicationRequestID=0xe5da, NSLocalizedDescription=The request to open "com.apple.springboard" failed.}." UserInfo={NSLocalizedDescription=Failed to show Widget 'com.gregorikouk.MapKitTut.BusWidgetKit' error: Error Domain=FBSOpenApplicationServiceErrorDomain Code=1 "The request to open "com.apple.springboard" failed." UserInfo={NSLocalizedFailureReason=The request was denied by service delegate (SBMainWorkspace)., BSErrorCodeDescription=RequestDenied, NSUnderlyingError=0xb1282dfe0 {Error Domain=SBAvocadoDebuggingControllerErrorDomain Code=1 "Failed to get descriptors for extensionBundleID (com.gregorikouk.MapKitTut.BusWidgetKit)" UserInfo={NSLocalizedDescription=Failed to get descriptors for extensionBundleID (com.gregorikouk.MapKitTut.BusWidgetKit)}}, FBSOpenApplicationRequestID=0xe5da, NSLocalizedDescription=The request to open "com.apple.springboard" failed.}., NSUnderlyingError=0xb1281d830 {Error Domain=FBSOpenApplicationServiceErrorDomain Code=1 "The request to open "com.apple.springboard" failed." UserInfo={NSLocalizedFailureReason=The request was denied by service delegate (SBMainWorkspace)., BSErrorCodeDescription=RequestDenied, NSUnderlyingError=0xb1282dfe0 {Error Domain=SBAvocadoDebuggingControllerErrorDomain Code=1 "Failed to get descriptors for extensionBundleID (com.gregorikouk.MapKitTut.BusWidgetKit)" UserInfo={NSLocalizedDescription=Failed to get descriptors for extensionBundleID (com.gregorikouk.MapKitTut.BusWidgetKit)}}, FBSOpenApplicationRequestID=0xe5da, NSLocalizedDescription=The request to open "com.apple.springboard" failed.}}} Domain: DTXMessage Code: 1 User Info: { DVTErrorCreationDateKey = "2023-10-02 21:06:04 +0000"; } -- System Information macOS Version 14.0 (Build 23A344) Xcode 15.0 (22265) (Build 15A240d) Timestamp: 2023-10-03T00:06:04+03:00

After the implementation of liveUpdates(_:) to receive asynchronous sequence of location updates, we are receiving crash reports on a huge number of users. However we cannot reproduce the crash so any help is much appreciated. This is the stack trace: com.apple.main-thread 0 libsystem_kernel.dylib 0xce4 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x439c mach_msg2_internal + 76 2 libsystem_kernel.dylib 0x42b8 mach_msg_overwrite + 428 3 libsystem_kernel.dylib 0x4100 mach_msg + 24 4 CoreFoundation 0x717b0 __CFRunLoopServiceMachPort + 160 5 CoreFoundation 0x70e90 __CFRunLoopRun + 1208 6 CoreFoundation 0x957f0 CFRunLoopRunSpecific + 572 7 GraphicsServices 0x1190 GSEventRunModal + 168 8 UIKitCore 0x3ca158 -[UIApplication _run] + 816 9 UIKitCore 0x3c8388 UIApplicationMain + 336 10 atto 0x6a41a0 main + 25 (AppDelegate.swift:25) 11 ??? 0x1ac153a58 (Missing) com.apple.uikit.eventfetch-thread 0 libsystem_kernel.dylib 0xce4 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x439c mach_msg2_internal + 76 2 libsystem_kernel.dylib 0x42b8 mach_msg_overwrite + 428 3 libsystem_kernel.dylib 0x4100 mach_msg + 24 4 CoreFoundation 0x717b0 __CFRunLoopServiceMachPort + 160 5 CoreFoundation 0x70e90 __CFRunLoopRun + 1208 6 CoreFoundation 0x957f0 CFRunLoopRunSpecific + 572 7 Foundation 0x74728 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212 8 Foundation 0x73558 -[NSRunLoop(NSRunLoop) runUntilDate:] + 64 9 UIKitCore 0x4bd354 -[UIEventFetcher threadMain] + 424 10 Foundation 0x115f40 NSThread__start + 732 11 libsystem_pthread.dylib 0x1afc _pthread_start + 136 12 libsystem_pthread.dylib 0x1a04 thread_start + 8 com.google.firebase.crashlytics.MachExceptionServer 0 FirebaseCrashlytics 0x21c10 FIRCLSProcessRecordAllThreads + 184 1 FirebaseCrashlytics 0x21ff0 FIRCLSProcessRecordAllThreads + 1176 2 FirebaseCrashlytics 0x18e74 FIRCLSHandler + 48 3 FirebaseCrashlytics 0x1b804 FIRCLSMachExceptionServer + 688 4 libsystem_pthread.dylib 0x1afc _pthread_start + 136 5 libsystem_pthread.dylib 0x1a04 thread_start + 8 com.apple.NSURLConnectionLoader 0 libsystem_kernel.dylib 0xce4 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x439c mach_msg2_internal + 76 2 libsystem_kernel.dylib 0x42b8 mach_msg_overwrite + 428 3 libsystem_kernel.dylib 0x4100 mach_msg + 24 4 CoreFoundation 0x717b0 __CFRunLoopServiceMachPort + 160 5 CoreFoundation 0x70e90 __CFRunLoopRun + 1208 6 CoreFoundation 0x957f0 CFRunLoopRunSpecific + 572 7 CFNetwork 0xeba68 +[__CFN_CoreSchedulingSetRunnable _run:] + 416 8 Foundation 0x115f40 NSThread__start + 732 9 libsystem_pthread.dylib 0x1afc _pthread_start + 136 10 libsystem_pthread.dylib 0x1a04 thread_start + 8 Thread 0 libsystem_kernel.dylib 0xa90 __workq_kernreturn + 8 1 libsystem_pthread.dylib 0x46ac _pthread_wqthread + 368 2 libsystem_pthread.dylib 0x19f8 start_wqthread + 8 Crashed: com.apple.corelocation.shared 0 libobjc.A.dylib 0x2050 objc_release_x8 + 16 1 libsystem_blocks.dylib 0x1d30 bool HelperBase::disposeCapture<(HelperBase::BlockCaptureKind)3>(unsigned int, unsigned char*) + 68 2 libsystem_blocks.dylib 0x16a8 HelperBase::destroyBlock(Block_layout*, bool, unsigned char*) + 116 3 libsystem_blocks.dylib 0x1180 _call_dispose_helpers_excp + 72 4 libsystem_blocks.dylib 0x111c _Block_release + 236 5 libsystem_blocks.dylib 0xff4 bool HelperBase::disposeCapture<(HelperBase::BlockCaptureKind)4>(unsigned int, unsigned char*) + 68 6 libsystem_blocks.dylib 0x16f8 HelperBase::destroyBlock(Block_layout*, bool, unsigned char*) + 196 7 libsystem_blocks.dylib 0x1180 _call_dispose_helpers_excp + 72 8 libsystem_blocks.dylib 0x111c _Block_release + 236 9 libdispatch.dylib 0x1b4f8 _dispatch_client_callout + 16 10 libdispatch.dylib 0xa2cc _dispatch_lane_serial_drain + 736 11 libdispatch.dylib 0xad90 _dispatch_lane_invoke + 380 12 libdispatch.dylib 0x15178 _dispatch_root_queue_drain_deferred_wlh + 292 13 libdispatch.dylib 0x149fc _dispatch_workloop_worker_thread + 540 14 libsystem_pthread.dylib 0x4660 _pthread_wqthread + 292 15 libsystem_pthread.dylib 0x19f8 start_wqthread + 8 Thread 0 libsystem_pthread.dylib 0x19f0 start_wqthread + 142 Thread 0 libsystem_pthread.dylib 0x19f0 start_wqthread + 142 Thread 0 libsystem_pthread.dylib 0x19f0 start_wqthread + 142

My application advertises service uuid FC66 and 00410b66-2553-48d7-cf18-000000002154 in advertising data, and "loading" as local name in response data in foreground. But iOS cut local name to "loadi" and add Hashed UUID data 0100000000000000000000000600000000 to response data. Why iOS add hashed uuid data? Is it because my 128-bit uuid format is wrong? We want to advertise the complete local name data. How to avoid this problem?

I am currently facing an issue when trying to enable Shortcut support and would greatly appreciate your assistance in resolving it. I have successfully enabled Shortcut support, and I can find my app and its respective functionalities within the Shortcuts app. However, I am unable to locate my app when attempting to create an automation within Shortcuts. I would appreciate any guidance or solutions you may offer regarding this matter.

I have auth bloodPressureDiastolic and bloodPressureSystolic, I can sync my bloodpressure data from my app to healthkit, but My app listed as inactive under the Data Sources and Access of Health App

Hello, I would like to ask if there is any possibility to invoke the Apple Sysdiagnose via an API call. I cannot find any API reference for Sysdiagnose. I am aware only about the manually invocation. https://it-training.apple.com/tutorials/support/sup075/ However, this is pretty annoying since a reproduction of a hunted bug takes several hours, so I am looking for the way how to invoke Sysdiagnose from our code.