I have an app developed by using the Callkit/Call-Blocking and received feedback from individual users, when using [cxcalldirectorymanager reloadextensionwithidentifier] to write call blocking data, it returned error code 11 with the following contents: errorCode: 11 errorDomain: com.apple.callkit.database.sqlite errorDescription: sqlite3_step for query 'DELETE FROM PhoneNumberBlockingEntry WHERE extension_id =?' returned 11 (11) errorMessage 'database disk image is malformed' I want to know the reasons for this error and how to solve it，Thanks!

My app attempts to upload events and logging data when the user backgrounds the app (i.e., when applicationDidEnterBackground is triggered) by creating an uploadTask using a URLSession with a URLSessionConfiguration.background. When uploading these events after being backgrounded, we call beginBackgroundTask on UIApplication, which gives us about 25-30 seconds before the expirationHandler gets triggered. I am noticing, however, that the expirationHandler is frequently called and no upload attempts have even started. This might be reasonable if, for example, I had other uploads in progress initiated prior to backgrounding, but this is not the case. Could someone confirm that, when initiating an uploadTask while the app is backgrounded using a backgroundSession, there's really no way to predict when that upload is going to begin? My observation is that about 10-20% of the time it does not begin within 20 seconds of backgrounding, and I have many events coming from clients in the field showing as much.

Previously I could get the sub package information after each payment via webhook but today I didn't get it. What happened? My webhook url: https://r-connect-api-dev.mystg-env.com/webhook/appstore/notification/v2

My process running with root privilege, but got below error with API SecStaticCodeCreateWithPath(::_:) to create static code object for Cortex XDR Agent app, it working fine for other app like Safari on same device. 2025-07-22 02:02:05.857719(-0600)[23221:520725] DBG Found /Library/Application Support/PaloAltoNetworks/Traps/bin/Cortex XDR Agent.app,/Library/Application Support/PaloAltoNetworks/Traps/bin/Cortex XDR Agent.app running. Will verify the process now 2025-07-22 02:02:05.859209(-0600)[23221:520725] ERR Failed to create static code for path /Library/Application Support/PaloAltoNetworks/Traps/bin/Cortex XDR Agent.app/Contents/MacOS/Cortex XDR Agent. Error: Optional(UNIX[Operation not permitted]) Code Snippet let fileURL = URL(fileURLWithPath: processPath) var code: SecStaticCode? let rc = SecStaticCodeCreateWithPath(fileURL as CFURL, [], &code) if rc == errSecSuccess, let code = code { staticCode = code } else { ZSLoggerError("Failed to create static code for path \(processPath). Error: \(String(describing: SecCopyErrorMessageString(rc, nil)))") return nil }

I’m testing auto-renewable subscription purchases in the sandbox environment. When I buy a subscription package using a sandbox test user, I don’t receive any Apple Server Notifications from the sandbox. However, when I use the Request Test Notification option in App Store Connect, the notification is received successfully. My sandbox server notification URL is configured correctly and publicly accessible. I also call finishTransaction() after purchase. It looks like sandbox purchase notifications are not being sent, even though the test notification works fine.

Hello! I am working on a screentime app and wondering if anyone has had success achieving reliable background shield application while using com.apple.ManagedSettingsUI.shield-configuration-service? I recently switched from com.apple.deviceactivity.shield-configuration (which worked reliably but isn't accepted by TestFlight) and have not found any consistency getting shields to apply while the app is backgrounded. I believe this is a known limitation of ManagedSettingsUI and want to know if there are successful workarounds or any specific patterns/timing that improve consistency?

Modern versions of macOS use a file system permission model that’s far more complex than the traditional BSD rwx model, and this post is my attempt at explaining that model. If you have a question about this, post it here on DevForums. Put your thread in the App & System Services > Core OS topic area and tag it with Files and Storage. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" On File System Permissions Modern versions of macOS have five different file system permission mechanisms: Traditional BSD permissions Access control lists (ACLs) App Sandbox Mandatory access control (MAC) Endpoint Security (ES) The first two were introduced a long time ago and rarely trip folks up. The second two are newer, more complex, and specific to macOS, and thus are the source of some confusion. Finally, Endpoint Security allows third-party developers to deny file system operations based on their own criteria. This post offers explanations and advice about all of these mechanisms. Error Codes App Sandbox and the mandatory access control system are both implemented using macOS’s sandboxing infrastructure. When a file system operation fails, check the error to see whether it was blocked by this sandboxing infrastructure. If an operation was blocked by BSD permissions or ACLs, it fails with EACCES (Permission denied, 13). If it was blocked by something else, it’ll fail with EPERM (Operation not permitted, 1). If you’re using Foundation’s FileManager, these error are both reported as Foundation errors, for example, the NSFileReadNoPermissionError error. To recover the underlying error, get the NSUnderlyingErrorKey property from the info dictionary. App Sandbox File system access within the App Sandbox is controlled by two factors. The first is the entitlements on the main executable. There are three relevant groups of entitlements: The com.apple.security.app-sandbox entitlement enables the App Sandbox. This denies access to all file system locations except those on a built-in allowlist (things like /System) or within the app’s containers. The various “standard location” entitlements extend the sandbox to include their corresponding locations. The various “file access temporary exceptions” entitlements extend the sandbox to include the items listed in the entitlement. Collectively this is known as your static sandbox. The second factor is dynamic sandbox extensions. The system issues these extensions to your sandbox based on user behaviour. For example, if the user selects a file in the open panel, the system issues a sandbox extension to your process so that it can access that file. The type of extension is determined by the main executable’s entitlements: com.apple.security.files.user-selected.read-only results in an extension that grants read-only access. com.apple.security.files.user-selected.read-write results in an extension that grants read/write access. Note There’s currently no way to get a dynamic sandbox extension that grants executable access. For all the gory details, see this post. These dynamic sandbox extensions are tied to your process; they go away when your process terminates. To maintain persistent access to an item, use a security-scoped bookmark. See Accessing files from the macOS App Sandbox. To pass access between processes, use an implicit security scoped bookmark, that is, a bookmark that was created without an explicit security scope (no .withSecurityScope flag) and without disabling the implicit security scope (no .withoutImplicitSecurityScope flag)). If you have access to a directory — regardless of whether that’s via an entitlement or a dynamic sandbox extension — then, in general, you have access to all items in the hierarchy rooted at that directory. This does not overrule the MAC protection discussed below. For example, if the user grants you access to ~/Library, that does not give you access to ~/Library/Mail because the latter is protected by MAC. Finally, the discussion above is focused on a new sandbox, the thing you get when you launch a sandboxed app from the Finder. If a sandboxed process starts a child process, that child process inherits its sandbox from its parent. For information on what happens in that case, see the Note box in Enabling App Sandbox Inheritance. IMPORTANT The child process inherits its parent process’s sandbox regardless of whether it has the com.apple.security.inherit entitlement. That entitlement exists primarily to act as a marker for App Review. App Review requires that all main executables have the com.apple.security.app-sandbox entitlement, and that entitlements starts a new sandbox by default. Thus, any helper tool inside your app needs the com.apple.security.inherit entitlement to trigger inheritance. However, if you’re not shipping on the Mac App Store you can leave off both of these entitlement and the helper process will inherit its parent’s sandbox just fine. The same applies if you run a built-in executable, like /bin/sh, as a child process. When the App Sandbox blocks something, it might generates a sandbox violation report. For information on how to view these reports, see Discovering and diagnosing App Sandbox violations. To learn more about the App Sandbox, see the various links in App Sandbox Resources. For information about how to embed a helper tool in a sandboxed app, see Embedding a Command-Line Tool in a Sandboxed App. Mandatory Access Control Mandatory access control (MAC) has been a feature of macOS for many releases, but it’s become a lot more prominent since macOS 10.14. There are many flavours of MAC but the ones you’re most likely to encounter are: Full Disk Access (macOS 10.14 and later) Files and Folders (macOS 10.15 and later) App bundle protection (macOS 13 and later) App container protection (macOS 14 and later) App group container protection (macOS 15 and later) Data Vaults (see below) and other internal techniques used by various macOS subsystems Mandatory access control, as the name suggests, is mandatory; it’s not an opt-in like the App Sandbox. Rather, all processes on the system, including those running as root, as subject to MAC. Data Vaults are not a third-party developer opportunity. See this post if you’re curious. In the Full Disk Access and Files and Folders cases, users grant a program a MAC privilege using System Settings > Privacy & Security. Some MAC privileges are per user (Files and Folders) and some are system wide (Full Disk Access). If you’re not sure, run this simple test: On a Mac with two users, log in as user A and enable the MAC privilege for a program. Now log in as user B. Does the program have the privilege? If a process tries to access an item restricted by MAC, the system may prompt the user to grant it access there and then. For example, if an app tries to access the desktop, you’ll see an alert like this: “AAA” would like to access files in your Desktop folder. [Don’t Allow] [OK] To customise this message, set Files and Folders properties in your Info.plist. This system only displays this alert once. It remembers the user’s initial choice and returns the same result thereafter. This relies on your code having a stable code signing identity. If your code is unsigned, or signed ad hoc (Signed to Run Locally in Xcode parlance), the system can’t tell that version N+1 of your code is the same as version N, and thus you’ll encounter excessive prompts. Note For information about how that works, see TN3127 Inside Code Signing: Requirements. The Files and Folders prompts only show up if the process is running in a GUI login session. If not, the operation is allowed or denied based on existing information. If there’s no existing information, the operation is denied by default. For more information about app and app group container protection, see the links in Trusted Execution Resources. For more information about app groups in general, see App Groups: macOS vs iOS: Working Towards Harmony On managed systems the site admin can use the com.apple.TCC.configuration-profile-policy payload to assign MAC privileges. For testing purposes you can reset parts of TCC using the tccutil command-line tool. For general information about that tool, see its man page. For a list of TCC service names, see the posts on this thread. Note TCC stands for transparency, consent, and control. It’s the subsystem within macOS that manages most of the privileges visible in System Settings > Privacy & Security. TCC has no API surface, but you see its name in various places, including the above-mentioned configuration profile payload and command-line tool, and the name of its accompanying daemon, tccd. While tccutil is an easy way to do basic TCC testing, the most reliable way to test TCC is in a VM, restoring to a fresh snapshot between each test. If you want to try this out, crib ideas from Testing a Notarised Product. The MAC privilege mechanism is heavily dependent on the concept of responsible code. For example, if an app contains a helper tool and the helper tool triggers a MAC prompt, we want: The app’s name and usage description to appear in the alert. The user’s decision to be recorded for the whole app, not that specific helper tool. That decision to show up in System Settings under the app’s name. For this to work the system must be able to tell that the app is the responsible code for the helper tool. The system has various heuristics to determine this and it works reasonably well in most cases. However, it’s possible to break this link. I haven’t fully research this but my experience is that this most often breaks when the child process does something ‘odd’ to break the link, such as trying to daemonise itself. If you’re building a launchd daemon or agent and you find that it’s not correctly attributed to your app, add the AssociatedBundleIdentifiers property to your launchd property list. See the launchd.plist man page for the details. Scripting MAC presents some serious challenges for scripting because scripts are run by interpreters and the system can’t distinguish file system operations done by the interpreter from those done by the script. For example, if you have a script that needs to manipulate files on your desktop, you wouldn’t want to give the interpreter that privilege because then any script could do that. The easiest solution to this problem is to package your script as a standalone program that MAC can use for its tracking. This may be easy or hard depending on the specific scripting environment. For example, AppleScript makes it easy to export a script as a signed app, but that’s not true for shell scripts. TCC and Main Executables TCC expects its bundled clients — apps, app extensions, and so on — to use a native main executable. That is, it expects the CFBundleExecutable property to be the name of a Mach-O executable. If your product uses a script as its main executable, you’re likely to encounter TCC problems. To resolve these, switch to using a Mach-O executable. For an example of how you might do that, see this post. Endpoint Security Endpoint Security (ES) is a general mechanism for third-party products to enforce custom security policies on the Mac. An ES client asks ES to send it events when specific security-relevant operations occur. These events can be notifications or authorisations. In the case of authorisation events, the ES client must either allow or deny the operation. As you might imagine, the set of security-relevant operations includes file system operations. For example, when you open a file using the open system call, ES delivers the ES_EVENT_TYPE_AUTH_OPEN event to any interested ES clients. If one of those ES client denies the operation, the open system call fails with EPERM. For more information about ES, see the Endpoint Security framework documentation. Revision History 2025-11-04 Added a discussion of Endpoint Security. Made numerous minor editorial changes. 2024-11-08 Added info about app group container protection. Clarified that Data Vaults are just one example of the techniques used internally by macOS. Made other editorial changes. 2023-06-13 Replaced two obsolete links with links to shiny new official documentation: Accessing files from the macOS App Sandbox and Discovering and diagnosing App Sandbox violations. Added a short discussion of app container protection and a link to WWDC 2023 Session 10053 What’s new in privacy. 2023-04-07 Added a link to my post about executable permissions. Fixed a broken link. 2023-02-10 In TCC and Main Executables, added a link to my native trampoline code. Introduced the concept of an implicit security scoped bookmark. Introduced AssociatedBundleIdentifiers. Made other minor editorial changes. 2022-04-26 Added an explanation of the TCC initialism. Added a link to Viewing Sandbox Violation Reports.  Added the TCC and Main Executables section. Made significant editorial changes. 2022-01-10 Added a discussion of the file system hierarchy. 2021-04-26 First posted.

Network.framework: Happy Eyeballs cancels also-ran only after WebSocket handshake (duplicate WS sessions) Hi everyone 👋 When using NWConnection with NWProtocolWebSocket, I’ve noticed that Happy Eyeballs cancels the losing connection only after the WebSocket handshake completes on the winning path. As a result, both IPv4 and IPv6 attempts can send the GET / Upgrade request in parallel, which may cause duplicate WebSocket sessions on the server. Standards context RFC 8305 §6 (Happy Eyeballs v2) states: Once one of the connection attempts succeeds (generally when the TCP handshake completes), all other connections attempts that have not yet succeeded SHOULD be canceled. This “SHOULD” is intentionally non-mandatory — implementations may reasonably delay cancellation to account for additional factors (e.g. TLS success or ALPN negotiation). So Network.framework’s current behavior — canceling after the WebSocket handshake — is technically valid, but it can have practical side effects at the application layer. Why this matters WebSocket upgrades are semantically HTTP GET requests (RFC 6455 §4.1). Per RFC 9110 §9.2, GET requests are expected to be safe and idempotent — they should not have side effects on the server. In practice, though, WebSocket upgrades often: include Authorization headers or cookies create authenticated or persistent sessions So if both IPv4 and IPv6 paths reach the upgrade stage, the server may create duplicate sessions before one connection is canceled. Questions / Request Is there a way to make Happy Eyeballs cancel the losing path earlier — for example, right after TCP or TLS handshake — when using NWProtocolWebSocket? If not, could Apple consider adding an option (e.g. in NWProtocolWebSocket.Options) to control the cancellation threshold, such as: after TCP handshake after TLS handshake after protocol handshake (current behavior) That would align the implementation more closely with RFC 8305 and help prevent duplicate, non-idempotent upgrade requests. Context I’m aware of Quinn’s post Understanding Also-Ran Connections. This report focuses specifically on the cancellation timing for NWProtocolWebSocket and the impact of duplicate upgrade requests. Although RFC 6455 and RFC 9110 define WebSocket upgrades as safe and idempotent HTTP GETs, in practice they often establish authenticated or stateful sessions. Thus, delaying cancellation until after the upgrade can create duplicate sessions — even though the behavior is technically RFC-compliant. Happy to share a sysdiagnose and sample project via Feedback if helpful. Thanks! 🙏 Example log output With Network Link Conditioner (Edge): log stream --info --predicate 'subsystem == "com.apple.network" && process == "WS happy eyeballs"' 2025-11-03 17:02:48.875258 [C3] create connection to wss://echo.websocket.org:443 2025-11-03 17:02:48.878949 [C3.1] starting child endpoint 2a09:8280:1::37:b5c3:443 # IPv6 2025-11-03 17:02:48.990206 [C3.1] starting child endpoint 66.241.124.119:443 # IPv4 2025-11-03 17:03:00.251928 [C3.1.1] Socket received CONNECTED event # IPv6 TCP up 2025-11-03 17:03:00.515837 [C3.1.2] Socket received CONNECTED event # IPv4 TCP up 2025-11-03 17:03:04.543651 [C3.1.1] Output protocol connected (WebSocket) # WS ready on IPv6 2025-11-03 17:03:04.544390 [C3.1.2] nw_endpoint_handler_cancel # cancel IPv4 path 2025-11-03 17:03:04.544913 [C3.1.2] TLS warning: close_notify # graceful close IPv4

I’d like to propose that Apple consider introducing a controlled entitlement for the SIM Application Toolkit (STK) on iOS, allowing limited developer access through a secure, user-consented API layer. While I understand the historical restrictions around SIM access for privacy and carrier security, there are legitimate, high-impact use-cases in emerging markets where STK remains a critical part of everyday digital transactions. Currently, developers have no sanctioned way to trigger or interact with STK flows — which leaves millions of iPhone users unable to complete basic offline payment or authentication actions that their Android counterparts can. The Problem In regions such as Sub-Saharan Africa, South Asia, and Southeast Asia, entire financial ecosystems still depend on SIM-based STK interactions (commonly through USSD or encrypted STK sessions). On iOS: The “SIM Applications” menu is buried under Settings → Cellular → SIM Applications, often missing depending on carrier provisioning. Third-party developers cannot programmatically open or trigger STK actions. This results in incomplete or inconsistent payment experiences for iOS users — even when the same SIM card supports rich offline capabilities on Android devices. Proposed Solution Introduce a “SIMToolkitAccess” entitlement, gated behind the following controls: User Consent Prompt When first triggered, the system displays a native dialog: “App ‘X’ would like to initiate a SIM Toolkit action (e.g., payment or balance check). Do you allow this?” The user can approve once, always, or deny. Scoped Access Model Allow only STK command initiation (e.g., “Launch STK Menu,” “Send STK Request”) Prohibit background execution or passive SIM data reading. Require entitlement approval from Apple Developer Relations, similar to CarPlay, CallKit, or HealthKit. Secure Sandbox STK sessions run in a system-managed sandbox with zero data exposure to the calling app. The app simply receives a completion callback with a generic status code (e.g., .completed, .cancelled, .timeout). Key Use-Cases That Would Benefit Offline Mobile Payments (M-PESA, Airtel Money, T-Kash) Many users rely on STK-based menus for sending or receiving money, paying bills, and topping up accounts. → Enabling secure triggers from native apps would unify the payment UX between Android and iOS, increasing inclusivity. SIM-based Authentication / OTP Requests Telecoms and banks in these regions use STK channels for encrypted session-level identity verification. → Allowing STK initiation would enable secure, offline identity confirmation flows. Carrier Value-Added Services (Data Bundles, Utility Payments) Network operators still deliver bundles, electricity token purchases, and airtime loans via STK sessions. → Secure developer access would allow modern iOS apps to wrap these flows in more intuitive interfaces while maintaining carrier security. Offline Resilience / Disaster-Recovery Flows During power or data outages, STK is often the only operational payment method, as it runs directly on the GSM layer. → Allowing iOS apps to gracefully degrade to STK ensures users can still transact safely without internet access. Why It Matters This is not about exposing low-level carrier interfaces — it’s about giving developers the ability to deliver consistent, accessible, and inclusive financial experiences to iPhone users in markets where connectivity cannot be assumed. Apple’s leadership in privacy and safety would make it the perfect platform to define the secure standard for modernized STK integration — something Android’s open access model lacks. A gated entitlement model would preserve integrity while unlocking transformative use-cases for millions.

When we use AppIntents to configure WidgetKit complications, the description we provide in IntentRecommendation is ignored after applying a .watchface file that includes those intent configurations. In the Watch app, under Complications, the labels shown next to each slot do not match the actual complications on the face—they appear to be the first strings returned by recommendations() rather than the selected intent configuration. Steps to Reproduce Create an AppIntent used by a WidgetKit complication (e.g., .accessoryRectangular). Provide multiple intent recommendations with distinct descriptions: struct SampleIntent: AppIntent { static var title: LocalizedStringResource = "Sample" static var description = IntentDescription("Sample data") @Parameter(title: "Mode") var mode: String static func recommendations() -> [IntentRecommendation<Self>] { [ .init(intent: .init(mode: "A"), description: "Complication A"), .init(intent: .init(mode: "B"), description: "Complication B"), .init(intent: .init(mode: "C"), description: "Complication C") ] } func perform() async throws -> some IntentResult { .result() } } Add two of these complications to a Modular Duo face (or any face that supports multiple slots), each with different intent configurations (e.g., A in one slot, B in another). Export/share the face to a .watchface file and apply it on another device. Open the Watch app → the chosen face → Complications. Expected Each slot’s label in Complications reflects the specific intent configuration on the face (e.g., “Complication A”, “Complication B”), matching what the complication actually renders. Actual The labels under Complications do not match the visible complications. Instead, the strings shown look like the first N items from recommendations(), regardless of which configurations are used in each slot. Notes The complications themselves render correctly on-watch; the issue is the names/labels displayed in the Watch app UI after applying a .watchface. Filed Feedback: FB20915258

Hi Team, I want to perform bluetooth advertising (no need to pair) from a macOS machine even before the user login to the macOS(i.e before user provide password and submit). Is there a way to achieve this?

I have an iOS app with ExtensionFoundation. It runs well on my local device, but when I upload on the AppStore it gets rejected with: Validation failed Invalid Info.plist value. The value of the EXExtensionPointIdentifier key, AsheKube.app.a-Shell.localWebServer, in the Info.plist of “a-Shell.app/Extensions/localWebServer.appex” is invalid. Please refer to the App Extension Programming Guide at https://developer.apple.com/library/content/documentation/General/Conceptual/ExtensibilityPG/Action.html#/apple_ref/doc/uid/TP40014214-CH13-SW1. (ID: ae8dd1dd-8caf-4a48-9651-7a225faed4eb) The Info.plist in my Extension is: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>EXAppExtensionAttributes</key> <dict> <key>EXExtensionPointIdentifier</key> <string>com.example.example-extension</string> </dict> </dict> </plist> so the Info.plist that causes the issue has been automatically generated by Xcode. I can access it as well, and it says: { "BuildMachineOSBuild" => "25A354" "CFBundleDevelopmentRegion" => "en" "CFBundleDisplayName" => "localWebServerExtension" "CFBundleExecutable" => "localWebServer" "CFBundleIdentifier" => "AsheKube.app.a-Shell.localWebServerExtension" "CFBundleInfoDictionaryVersion" => "6.0" "CFBundleName" => "localWebServer" "CFBundlePackageType" => "XPC!" "CFBundleShortVersionString" => "1.0" "CFBundleSupportedPlatforms" => [ 0 => "iPhoneOS" ] "CFBundleVersion" => "1" "DTCompiler" => "com.apple.compilers.llvm.clang.1_0" "DTPlatformBuild" => "23A339" "DTPlatformName" => "iphoneos" "DTPlatformVersion" => "26.0" "DTSDKBuild" => "23A339" "DTSDKName" => "iphoneos26.0" "DTXcode" => "2601" "DTXcodeBuild" => "17A400" "EXAppExtensionAttributes" => { "EXExtensionPointIdentifier" => "AsheKube.app.a-Shell.localWebServer" } "MinimumOSVersion" => "26.0" "NSHumanReadableCopyright" => "Copyright © 2025 AsheKube. All rights reserved." "UIDeviceFamily" => [ 0 => 1 1 => 2 ] "UIRequiredDeviceCapabilities" => [ 0 => "arm64" ] } What should I do to be able to upload on the AppStore?

Hello, We have observed a change in the presentation behavior of the AlarmKit Live Activity banner when our application is in the foreground, following the update from iOS 26.0 to iOS 26.1. We would like to clarify which behavior is intended. In iOS 26.0: When our application was in the foreground, the AlarmKit Live Activity banner did not present. In iOS 26.1: The AlarmKit Live Activity banner now presents even when our application is in the foreground. Could you please advise on what the correct or desired behavior is for this scenario? Thank you for your clarification.

Colombia is not yet listed as a Tap to Pay user, but it is in the process of becoming so. We are currently a group of developers at a company in Colombia working on a project to integrate Tap to Pay into our application. After reviewing Apple's documentation, my company is not certified to meet Apple's security requirements, PCI standards, or licensing requirements. However, the payment service provider we have contracted for this is in the process of obtaining the certifications, authorizations, and licenses that Apple specifies. Our team members and managers overseeing this Tap to Pay project have told us that we, as iOS developers, should integrate and use the Proximity Reader API, but we know that we, as developers, are not authorized by Apple to do so. Is the payment service provider the only one who can make this possible, enabling its use with NFC and Proximity Reader? I would like to know if the service provider will provide us with the SDK containing the Proximity Reader API for integration into the project, or if my company will have to implement the Proximity Reader API ourselves?

Hi, I have a workout app in the App Store which mirrors workout data between the phone and watch. Since iOS 26.x I've been having issues and received reports of the mirroring no longer working. Users in iOS 18 have no problems with this functionality. Bug description: A workout session is started from the phone app and starts mirroring to the watch companion device. The watch starts the workout session and then the mirroring session is disconnected / lost. Sending data to the companion device fails and ending the session on the phone doesn't end the session on the watch...essentially they become completely disconnected. Please note I am testing this on physical devices...not simulators. As a sanity check I've also tried the "Building a multidevice workout app" sample code and it has the same problem. To re-create on the sample app, I start a workout from the phone, the watch workout starts and then the mirroring session seems to disconnect and is unable to send data. This is the log from the "Building a multidevice workout app" sample code. Successfully started workout Type: Notice | Timestamp: 2025-10-17 06:57:07.341401+02:00 | Process: MirroringWorkoutsSample Watch App | Library: MirroringWorkoutsSample Watch App.debug.dylib | Subsystem: com.example.apple-samplecode.MirroringWorkoutsSampleABC123.watchkitapp | Category: MirroringWorkoutsSampleForWatch | TID: 0x1b2ca7 -[SPRemoteInterface _appRecoverAnyExtendedRuntimeSession:]_block_invoke:4350: Got no sessions back from -[CSLSSessionService existingRunningSessions:] or -[CSLSSessionService existingScheduledSessions:] after receiving a PUICInitializeSessionServiceAction Type: Error | Timestamp: 2025-10-17 06:57:07.641571+02:00 | Process: MirroringWorkoutsSample Watch App | Library: WatchKit | Subsystem: com.apple.watchkit | Category: default | TID: 0x1b2ca7 Session state changed from 1 to 2 Type: Notice | Timestamp: 2025-10-17 06:57:07.647883+02:00 | Process: MirroringWorkoutsSample Watch App | Library: MirroringWorkoutsSample Watch App.debug.dylib | Subsystem: com.example.apple-samplecode.MirroringWorkoutsSampleABC123.watchkitapp | Category: MirroringWorkoutsSampleForWatch | TID: 0x1b2e87 Failed to send data: Error Domain=com.apple.healthkit Code=100 "Failed to send data to remote session." UserInfo={NSLocalizedDescription=Failed to send data to remote session.} Type: Notice | Timestamp: 2025-10-17 06:57:07.669922+02:00 | Process: MirroringWorkoutsSample Watch App | Library: MirroringWorkoutsSample Watch App.debug.dylib | Subsystem: com.example.apple-samplecode.MirroringWorkoutsSampleABC123.watchkitapp | Category: MirroringWorkoutsSampleForWatch | TID: 0x1b2ca7 Would appreciate any help with this problem as it's affecting customers. Thank you

Unexpected behavior encountered when scanning NFC tags. Imagine a link shortener web service where users can create lots of different URLs that are hosted on the same domain eg, https://short.com/unique-path The service has optional App Clip capability -- users can select any of their links and have the service create an App Clip for the selected link(s). Users can encode their URLs into NFC tags and have their customers scan NFC tags. Let's take just two URLs for example: https://short.com/foo https://short.com/bar The /foo link does have an App Clip associated with it while /bar does not have it. Each link has been encoded into appropriate NFC tag. Expected behavior when scanning from an iPhone: /foo -- shows an App Clip popup. /bar -- shows a "Open in Safari" default notification. What's actually happening /foo -- opens App Clip poput with correct metadata (title, subtitle, image) which is totally expected behavior. /bar (the one that doesn't have app clip associated with it) -- opens an App-Clip-like popup with the following error: CPSErrorDomainError 2 (see attachment below) So for some reason when someone scans an NFC tag with a URL that is not an App Clip and never has been -- it always shows that error regardless whether the URL exists or does not exist. I've tried few different/random URLs (which don't have an App Clip associated with it) and all of them show the same error. Additional details: All links use the same domain and URL format: domain.com/path where path is a short string of random a-Z characters. All App Clips are created at the same iOS app. AASA is good: Cache and Debug -- both green. This issue has happened to lots of users on lots of different iPhones and iOS'. Since the issue's been happening to lots of different users on different iPhone(s)/iOS' no sysdiagnose is attached. Actually it works the same on every device/iOS we've tried. Before submitting the issue, I've found few other developers reporting the same issue. What's interesting though is none of the links I've went through comes with a definite answer and it seems like this issue just randomly comes and goes without any specific changes on the server and/or iOS app. Dropping the links of similar issues below. https://developer.apple.com/forums/thread/671433 https://developer.apple.com/forums/thread/665969 https://developer.apple.com/forums/thread/775316 https://developer.apple.com/forums/thread/764545

I face this issue only on macOS 26 and only on the Intel architecture. I'm unable to download files from a file provider's folder when I make them read-only. STEPS TO REPRODUCE Download the sample from https://developer.apple.com/documentation/fileprovider/synchronizing-files-using-file-provider-extensions?language=objc Follow the steps on the page to configure the project. Build the project. Run it. Add a domain. Open the domain's folder in the Finder. Move a file to the domain's folder. Right-click on the file in the domain's folder and select "Remove Download". Close the Finder's window with the domain's folder and kill all the "Provider" processes to get rid of running instances of the extension. Change Item's capabilities in Item.swift to make the items read-only: var result: NSFileProviderItemCapabilities = [ .allowsContentEnumerating, .allowsReading ] Rebuild the project and run it. Open the domain's folder and try to drag and drop the file from the extension's folder to, let's say, the Desktop folder. EXPECTED RESULT The file is copied ACTUAL RESULT A dialog pops up with text "The file “filename” cannot be downloaded. Do you want to skip it?" Stop/Skip

Hi, I'm using SwiftData in my app, and I want to sent data to iCloud with CloudKit, but I found that If the user turns off my App iCloud sync function in the settings App, the local data will also be deleted. A better way is maintaining the local data, just don't connect to iCloud.How should I do that? I need guidance!!! I'm just getting started with CloudKit And I would be appreciated!

Some users of my app are reporting total loss of data while using the app. This is happening specifically when they enable iCloud sync. I am doing following private func setupContainer(enableICloud: Bool) { container = NSPersistentCloudKitContainer(name: "") container.viewContext.automaticallyMergesChangesFromParent = true container.viewContext.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy guard let description: NSPersistentStoreDescription = container.persistentStoreDescriptions.first else { fatalError() } description.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey) description.setOption(true as NSNumber, forKey: NSPersistentStoreRemoteChangeNotificationPostOptionKey) if enableICloud == false { description.cloudKitContainerOptions = nil } container.loadPersistentStores { description, error in if let error { // Handle error } } } When user clicks on Toggle to enable/disable iCloud sync I just set the description.cloudKitContainerOptions to nil and then user is asked to restart the app. Apart from that I periodically run the clear history func deleteTransactionHistory() { let sevenDaysAgo = Calendar.current.date(byAdding: .day, value: -7, to: Date())! let purgeHistoryRequest = NSPersistentHistoryChangeRequest.deleteHistory(before: sevenDaysAgo) let backgroundContext = container.newBackgroundContext() backgroundContext.performAndWait { try! backgroundContext.execute(purgeHistoryRequest) } }

Original discussion pre iOS 26 Our app uses Auth0 with HTTPS callback, we've found the issue where AASA file is not ready immediately when app is initially launched, which is the exact issue from the above link. The issue seems mostly fixed on later versions on iOS 18, however, we are seeing some indications of a regression on iOS 26. Here's some measurement over the last week. | Platform | iOS 18 | iOS 26 | |---------------|----------|--------| | Adoption rate | 55% | 45% | | Issue seen | 1 | 5 | | Recover? | Yes | No | This only 1 iOS 18 instance was able to recover after 1 second after the first try, however, all iOS 26 instances were not able to recover in couple tens of seconds and less than 1 minute, the user eventually gave up. Is there a way to force app to update AASA file? Are there some iOS setting (like using a VPN) that could potentially downgrade the AASA fetch? Related Auth0 discussion: https://community.auth0.com/t/ios-application-not- recognizing-auth0-associated-domain/134847/27