I am trying to figure out why my app is not receiving background deliveries from Healthkit. I have a successfully implemented HKObserverQuery  which is being used to send data like step count to a server. I have a successful enableBackgroundDelivery (completes without errors). I have also checkmarked the HealthKit Background Delivery and Clinical Health Records options in my app's Signing and Capabilities configurations. I know the observer is functional because the health data gets sent to the server when the app is running. The problem is I haven't seen any evidence of the observer handler being triggered when the app is not running. What am I missing? And what is the best way to go about debugging what is going wrong?

I have been experiencing many issues trying to integrate the Apple AlarmKit in my app. I essentially keeping getting authorization errors. I was wondering if anyone else was experiencing issues like this and if anyone had guidance or a fix for what I am experiencing. I was under the impression that any devices IOS26+ could use the AlarmKit but maybe I am mistaken. Getting (com.apple.AlarmKit.Alarm error 1.) every time I try and enable alarms.

I am testing a consumable in-app purchase in the StoreKit sandbox and I am seeing behavior that does not seem correct on repeat purchase attempts. Product details Product ID: album.credit.v2 Type: Consumable Test environment: iOS device + StoreKit sandbox Purchase flow triggered from my Flutter app using Apple IAP What happens First purchase attempt works My backend receives the confirmation The album is granted correctly On the second purchase attempt of the same consumable, I do not get a normal new purchase flow Instead, StoreKit returns the product as restored My app then cancels the attempt because a restored transaction arrived during checkout Expected behavior Because this product is a consumable, each purchase attempt should behave like a new purchase and allow the user to buy it again. Actual behavior On the second attempt, the transaction update comes back as restored instead of a new successful consumable purchase. Relevant logs First successful purchase: [ProPurchasePage] ✅ Pay tapped. starting=false iap=true albumProd=album.credit.v2 proProd=pro.monthly [IAP] update: id=album.credit.v2 status=PurchaseStatus.restored pendingComplete=false err=null [IAP] expected=album.credit.v2 starting=true appleFlow=true [ProPurchasePage] album credit success status=PurchaseStatus.restored receiptLen=5334 [AppleIapService] Sending Apple IAP confirmation for albumId=ariie_west_pretty_girl_summer, buyerUid=PYjgu9TMCieCVDLIdTuawY5k4Ay2 [AppleIapService] appleIapConfirm response status: 200 [AppleIapService] appleIapConfirm applied for albumId=ariie_west_pretty_girl_summer buyerUid=PYjgu9TMCieCVDLIdTuawY5k4Ay2 After that, the purchase is written correctly on my side: "libraryAlbums": [ { "AlbumId": "ariie_west_pretty_girl_summer", "paid": true, "Quantity": 1 } ] Second and later attempts: [ProPurchasePage] ✅ Pay tapped. starting=false iap=true albumProd=album.credit.v2 proProd=pro.monthly [ProPurchasePage] buyConsumable (album.credit.v2) returned: true [IAP] update: id=album.credit.v2 status=PurchaseStatus.restored pendingComplete=false err=null [IAP] expected=album.credit.v2 starting=true appleFlow=true [IAP] restored arrived during album checkout — cancelling attempt Question Is this expected StoreKit sandbox behavior for a consumable, or does this suggest: a StoreKit sandbox issue, a problem with how the product is configured in App Store Connect, or a transaction-handling issue in the app/plugin layer? Also, is there any Apple-recommended handling for repeated consumable purchases when sandbox keeps surfacing a restored status?

Hello everyone, I’m an iOS developer working on a real-time communication app that supports VoIP calls using CallKit. The app has been in production for more than 5 years. Over the years, some users have occasionally reported that they do not receive incoming call pushes. We have tried multiple optimizations on both the client and server side, but the improvement has been limited. From Apple documentation and discussions online, I understand that iOS may restrict VoIP pushes if the system detects violations of VoIP push usage rules (for example, not presenting a CallKit call after receiving a VoIP push). However, the exact rules and thresholds for these violations are not clearly documented, so I’d like to ask a few questions to better understand the expected behavior. Below is a simplified description of our current call flow. Call Flow Caller When the user initiates a call: We do not use CallKit The call is handled entirely using a custom in-app call UI Callee When the user receives a call: Device locked or app in background A VoIP push wakes the app The app presents the CallKit incoming call UI App in foreground The server still sends a VoIP push The app first reports the call to CallKit After a very short delay, the app programmatically ends the CallKit call Then a custom in-app call UI is presented via the app's long connection The reason we always send a VoIP push (even when the app is in the foreground) is that we want to maximize call delivery reliability.

I'll try to ask a question that makes sense this time :) . I'm using the following method on NSFileManager: (BOOL) getRelationship:(NSURLRelationship *) outRelationship ofDirectoryAtURL:(NSURL *) directoryURL toItemAtURL:(NSURL *) otherURL error:(NSError * *) error; Sets 'outRelationship' to NSURLRelationshipContains if the directory at 'directoryURL' directly or indirectly contains the item at 'otherURL', meaning 'directoryURL' is found while enumerating parent URLs starting from 'otherURL'. Sets 'outRelationship' to NSURLRelationshipSame if 'directoryURL' and 'otherURL' locate the same item, meaning they have the same NSURLFileResourceIdentifierKey value. If 'directoryURL' is not a directory, or does not contain 'otherURL' and they do not locate the same file, then sets 'outRelationship' to NSURLRelationshipOther. If an error occurs, returns NO and sets 'error'. So this method falsely returns NSURLRelationshipSame for different directories. One is empty, one is not. Really weird behavior. Two file path urls pointing to two different file paths have the same NSURLFileResourceIdentifierKey? Could it be related to https://developer.apple.com/forums/thread/813641 ? One url in the check lived at the same file path as the other url at one time (but no longer does). No symlinks or anything going on. Just plain directory urls. And YES calling -removeCachedResourceValueForKey: with NSURLFileResourceIdentifierKey causes proper result of NSURLRelationshipOther to be returned. And I'm doing the check on a background queue.

We are assisting a client with their app integration. The client believes that NEPacketTunnelProvider, NEHotspotHelper, and NEHotspotManager extensions stop functioning if the containing app hasn't been launched by the user within some recent window (e.g. 30, 60, or 90 days). We haven't been able to find any documentation supporting this claim. Specifically, we'd like to know: Is there any app launch recency requirement that would cause iOS to stop invoking a registered NEHotspotHelper or NEHotspotManager configuration? Is there any app launch recency requirement that would cause iOS to tear down or prevent activation of a NEPacketTunnelProvider? More generally, does iOS enforce any kind of "staleness" check on apps that provide Network Extension or Hotspot-related functionality, where not being foregrounded for some period causes the system to stop honoring their registrations? If such a mechanism exists, we'd appreciate any pointers to documentation or technical notes describing the behavior and timeframes involved. If it doesn't exist, confirmation would help us guide our client's debugging in the right direction. Thank you.

Hi, we have developed an application that streams data from two BLE peripherals at a rate of 14.5kbps per peripheral. Until now, our devices streamed in near real time with no lag on all Apple devices with Bluetooth 5.0 or greater. Since the release of the iPhone 17 series and the iPad A16, we have reports from users of the data being streamed at significantly lower rates than expected. Any help here would be greatly appreciated as our customers are being affected by this change.

I am referencing: https://developer.apple.com/documentation/foundation/pausing-and-resuming-uploads Specifically: You can’t resume all uploads. The server must support the latest resumable upload protocol draft from the HTTP Working Group at the IETF. Also, uploads that use a background configuration handle resumption automatically, so manual resuming is only needed for non-background uploads. I have control over both the app and the server, and can't seem to get it to work automatically with a background url session. In other words, making multiple requests to get the offset then upload, easy but I am trying to leverage this background configuration resume OS magic. So anyone know what spec version does the server/client need to implement? The docs reference version 3, however the standard is now at like 11. Of course, I am trying out 3. Does anyone know how exactly this resume is implemented in iOS, and what exactly it takes care of? I assumed that I can just POST to a generic end point, say /files, then the OS receives a 104 Location, and saves that. If the upload is interrupted, when the OS resumes the upload, it has enough information to figure out how to resume from the exact offset, either by making a HEAD request to get the offset, or handle a 409. I am assuming it does this, as if it doesn't, the 'uploads that use a background configuration handle resumption automatically' is useless, if it just restarts from 0. Note, of course making individual POST/HEAD/PATCH requests manually works, but at that point I'm not really leveraging any OS auto-magic, and am just consuming an API that could really implement any spec. This won't work in the background, as the OS seems to disallow random HTTP requests when it wakes the app for URLSession background resumes. As of right now, I have it 'partially' working, insofar as the app does receive the 104 didReceiveInformationalResponse url delegate call, however it seems to then hang; it stops sending bytes, seemingly when the 104 is received. However, the request does not complete. In other words, it doesn't seem to receive a client timeout or otherwise indicate the request has finished. Right now, I am starting a single request, POSTing to a /files end point, i.e. I am not getting the location first, then PATCHing to that, as if I do that, the OS 'automatic' resuming fails with a 409, i.e. it doesn't seem to make a HEAD request and/or use the 409 offset correction then continue with the PATCH. Any idea what could be going on?

Hello, I am wondering if an app that does the following is possible or is impossible due to ios limitations for apps? An app that access all sms messages, and or all phone calls logs? (goal is to save them and not have to filter them manually) An app that control OTHER apps permissions and or read permissions status of all other apps?

On the iPad Pro 12.9-inch (3rd generation) cellular model, when you touch the screen with four fingers and then move your fingers, the touch is no longer detected. The same operation with one to three fingers works normally. This phenomenon does not occur when accessibility is turned on. Is this a beta-specific issue that will be fixed in the official release?

I want to localize the app name, user the String Catalog to set en, en-US, en-CA, however, when the phone language is set to English (United States), the app name is displayed in English, while when the phone language is set to French, the app name is displayed in English-United States. However, the base language of the app settings is English. How can I make it right?

Hello, I am hoping someone from Apple or the community can help escalate or advise on my situation. I submitted a Live Caller ID Lookup entitlement request for my app Zinfo (com.parastashvili.Mobile), Team ID: CNH4KYRW44. A support case was opened on February 17, 2026 (Case ID: 102823550184). Apple's documentation states entitlement review takes up to 2 weeks. It has now been over 3 weeks with no substantive response despite multiple follow-ups. Timeline: Feb 17: Case opened Feb 26: I provided all requested technical details in full — OHTTP endpoints, Privacy Pass token system, DNS TXT record, Apple test number (+1 408 555 1212 returning "Johnny Appleseed"), all fully deployed and ready for validation Feb 27: Apple replied with a generic "appropriate team will be in contact" message Feb 28, Mar 6, Mar 10: Follow-up emails sent — no meaningful response All technical requirements are fully implemented and operational. We are ready for Apple's validation at any time. Has anyone else experienced long delays with Live Caller ID Lookup entitlement reviews? Is there a better escalation path? I have also submitted a new escalation ticket (Case ID: 102840874265) under Development and Technical > Entitlements today. Any advice or visibility from Apple staff would be greatly appreciated. App: Zinfo (com.parastashvili.Mobile) Extension Bundle ID: com.parastashvili.Mobile.LiveCallerID Team ID: CNH4KYRW44

1) Blocked page UX When a URL is blocked, the browser typically shows a generic error like “"Safari cannot open the page because it couldn’t load any data,” with no indication that the page was blocked by a policy. Is there any plan to add an API that allows developers to present a custom “blocked” page or remediation action, similar to NEFilterControlProvider’s remediationMap? Even a minimal hook (custom HTML, deep link, or support URL) would make the experience clearer for users. 2) Cross‑app link‑opening behavior With a block rule in place, direct navigation in Safari is blocked as expected. However, tapping the same URL in a messaging app (e.g., WhatsApp) opens Safari - and the page loads, not blocked. Repro steps: Configure a URL Filter extension that blocks https://example.com. Case A: Open a browser and type the URL in the address bar → blocked (expected). Case B: Tap the same URL in WhatsApp (or another messenger) → a browser opens and the page loads (unexpected). iOS version - 26.0

I am working on an e-commerce app (retail/marketplace) that allows users to place orders for both free and paid products. After receiving a DeclaredAgeRange API response — retrieved via the Family Controls / Screen Time framework — indicating that a user is a minor, I want to understand the recommended approach for handling payment flows. Specifically, is it necessary to block payments for users identified as minors via DeclaredAgeRange, even though our app uses server-side encrypted card processing rather than Apple In-App Purchases (StoreKit)? Any guidance on best practices or App Store policy requirements for this scenario would be greatly appreciated.

Is it somehow possible to get the transport layer (UDP and TCP) payload amounts for TLS or QUIC connections established via the Network framework? (From within the app itself that establishes the connections.) I am currently using the ntstat.h kernel socket calls, but I hope there is a simpler solution. With ntstat, I have not yet been able to observe a specific connection. I have to search for the connection I am looking in all (userspace) connections.

Hello team, I am trying to find out a way to block urls in the chrome browser if it is found in local blocked list cache. I found URL Filter Network very much suitable for my requirement. But I see at multiple places that this solution is only for Enterprise level or MDM or supervised device. So can I run this for normal user ? as my targeting audience would be bank users. One more thing how can I test this in development environment if we need supervised devices and do we need special entitlement ? When trying to run sample project in the simulator then getting below error

Hello, I’m planning to use MapKit JS for a production web/mobile application and I’m trying to better understand the quota limits and pricing model. From the documentation, I understand that MapKit JS provides a free daily limit of: 250,000 map views 25,000 service calls per Apple Developer Program membership. However, I’m not clear about what exactly happens if these limits are exceeded. My questions: If my application exceeds 250,000 map views or 25,000 service calls in a day, what happens? Will the API simply start returning errors (for example HTTP 429), or will Apple automatically charge for additional usage? Is there an official pricing model for usage above the free quota, or do we need to contact Apple to request higher limits? Are these limits strict daily hard limits that should never be exceeded in production? I’m trying to design the architecture of my application and would like to understand whether we must strictly stay below these limits or whether scaling beyond them is possible. Thank you.

Our game application is developed based on StoreKit 1, and an exception occurs on iOS 26.4: after players complete a payment, the finishTransaction method fails to properly remove the transaction from the SKPaymentQueue; as a result, when players restart the app, the system still triggers the retry process for this transaction (reconciliation of unpaid orders). Has anyone encountered this issue? If there is a solution, we would appreciate it if you could share it with us.

Our watchOS app is exploring adding audio VOIP calling capability using our in-home platform. We are using LiveCommunicationKit for this and have that all hooked up nicely in a proof of concept implementation. Our use case is primarily based around supporting end-users through various tasks with assistance from a remotely based expert. We would like for our platform to be able to display visual content on the watch's screen during the call – in other words, we would like to be able to treat this as a video call. LiveCommunicationKit fully supports all video-related flags on watchOS and doesn't appear to have any different symbol availability versus its iOS version. This high-quality thread (https://developer.apple.com/forums/thread/798090) from a DTS engineer suggests that our use case should be valid (i.e. whiteboarding apps) and that the system's response to an accepted income video call is to dismiss the LCK's incoming call screen and bring the target app to the foreground, allowing it to render its custom content. Unfortunately, on watchOS the system doesn't seem to treat a video call any differently from an audio call, and won't dismiss the system UI once it's answered. We fully realize that Apple Watch doesn't have a camera for outbound video, doesn't support VideoToolbox or other low-level video convenience libraries for simplified rendering and decoding, etc. That's not what we're worried about (yet). The documentation is at best unclear about whether LCK (or CallKit, for that matter) can hand off calls flagged as video-compatible according to how we think they should, which is passing foreground UI over to the app once the call has been accepted by the user. Can any Apple people shed some light on this? I recognize we are probably trying to do something not many people have before.

Hello, I’m implementing VoIP calling in an iOS application using PushKit (VoIP pushes) together with CallKit. The standard call flow works correctly: Happy scenario User A initiates a call. Server sends a VoIP push to User B. User B’s device receives the push and reports the incoming call using CallKit. User B answers the call. However, I would like clarification about non-happy scenarios and when it is acceptable to use VoIP pushes to update or stop a CallKit ringing state. Apple documentation warns that VoIP pushes must be used only when they result in a call-related action, so I want to ensure the following cases are compliant. Scenario A — Caller Cancels Before Answer User A calls User B. Server sends a VoIP push to User B. User B’s device starts ringing via CallKit. Before User B answers, User A cancels the call. Question: Is it acceptable to send another VoIP push to User B indicating that the call has been cancelled so the device can: stop the CallKit ringing UI end the call optionally mark it as missed or cancelled Or should this state change be handled using a regular remote push or another signaling mechanism instead of VoIP push? Scenario B — Callee Rejects the Call User B rejects the call from CallKit. The server must inform User A that the call was rejected. Question: Is it acceptable to send a VoIP push to User A to update the CallKit state and terminate the outgoing call UI? Scenario C — Multiple Devices per User User B may be logged in on multiple devices. User A calls User B. VoIP push is sent to all devices of User B. One device answers. Question: Is it acceptable to send a VoIP push to the remaining devices instructing them to: stop ringing end the CallKit incoming call UI Or is there a recommended alternative pattern for this case? Main Question Aside from the initial incoming call VoIP push, in which situations is it considered acceptable to send additional VoIP pushes to terminate or update CallKit state (cancelled, rejected, answered on another device)? The goal is to remain compliant with PushKit policies, particularly the guidance that VoIP pushes should only be used when they result in a call-related user action. Any guidance on the recommended architecture for these cases would be greatly appreciated. Thank you.