The man page of copyfile sates the following: COPYFILE_CLONE [..] Note also that there is no support for cloning directories" COPYFILE_CLONE_FORCE [...] Note also that there is no support for cloning directories: if a directory is provided as the source, an error will be returned. Now the man page for clonefile: > Cloning directories with these functions is strongly discouraged. Use copyfile(3) to clone directories instead. -- So am I to enumerate the content of a directory build subfolders along the way in the target destination and clone each file inside individually? If I recall NSFileManager seems to clone a large directory instantly (edit actually I remembered wrong NSFileManager does not do this. Finder seems to copy instead of clone as well). On further inspection, clonefile states that it can do this, but it is discouraged. Interesting. I wonder why. If src names a directory, the directory hierarchy is cloned as if each item was cloned individually. However, the use of clonefile(2) to clone directory hierarchies is strongly discouraged. Use copyfile(3) instead for copying directories. P.S. - Forgive me if I posting this in the wrong category, I couldn't find a "category" in the list of available categories on these forums that seems appropriate for this question.

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 and Good day! We are conducting Bonjour Conformance Test (BCT) for Printer device. BCT result is PASSED but with warning in Multicast DNS, specifically, WARNING: SHARED REPLY TIMING - UNIFORM RANDOM REPLY TIME DISTRIBUTION Other Shared Reply Timing is passed: PASSED: MULTIPLE QUESTIONS - SHARED REPLY TIMING - UNIFORM RANDOM REPLY TIME DISTRIBUTION Environment: BCT Tool Version: 1.5.4 (15400) MacOS Sequioa 15.5 DUT Firmware : Linux Debian 9 Apple mDNSResponder 1790.80.10 Service types: _ipps._tcp, _uscans._tcp, _ipp._tcp, _uscan._tcp Router : NEC AtermWR8370N Setup: 1-to-1 [Mac->Router<-DUT connection] Based on debug.log, this is where WARNING occurs: NOTICE 2026-03-04 10:51:06.870187+0900 _shared_reply_timing 04103: Shared reply response times: min = 26ms, max = 114ms, avg = 65.50ms WARNING 2026-03-04 10:51:06.870361+0900 _shared_reply_timing 04136: 50 percent of the replies within the correct range fell in the interval 20ms and 46ms (should be close to 25%). PASSED (SHARED REPLY TIMING) In the same debug.log for MULTIPLE QUESTIONS - SHARED REPLY TIMING is PASSED: NOTICE 2026-03-04 10:52:29.912334+0900 _shared_reply_timing 04103: Shared reply response times: min = 22ms, max = 112ms, avg = 78.00ms DEBUG_2 2026-03-04 10:52:29.912849+0900 recv_packet 01997: received packet (558 bytes) PASSED (MULTIPLE QUESTIONS - SHARED REPLY TIMING) [Details] Looking at Bonjour_Conformance_Guideline.pdf https://download.developer.apple.com/Documentation/Bonjour_Conformance_Test_Guideline/Bonjour_Conformance_Guideline.pdf there were some differences: In 1.6.2 Expected Result: Test Result File of Test that All Tests Passed, this is not displayed: PASSED: SHARED REPLY TIMING - UNIFORM RANDOM REPLY TIME DISTRIBUTION And in II.8 Shared Reply Timing: (Ideally, 25% of the answers should fall in each 21ms quadrant of the range 20ms - 125ms.) and comparing to the debug.log, there was a discrepancy of the interval, because 20ms and 46ms is 26ms interval. From RFC6762 6. Responding, Ideal range is from 20ms-120ms Because of this, please advise on the questions below: I would like to know on the possible cause and resolution for these WARNINGS. And since in current BCT result, (Test result integrity signature is generated), I would like to know if this is acceptable for BCT certification. Thank you.

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

While attempting to read a user’s daily step history spanning backward to the last 7 days, a small but consistent subset of users encounter Error Code 3 with the underlying error description: Error Code 3 "Unable to invalidate interval: no data source available." When this error occurs, we are entirely unable to read their step history. We have received ~10 direct user reports of this within the last couple of weeks.

Hello, We are encountering an issue with Apple Pay on the Web in the sandbox environment where payments cannot be completed because the onpaymentauthorized event is not triggered. The same implementation was working normally until March 5, but the issue started occurring consistently from March 6 without any changes to our code, certificates, or merchant configuration. Environment Apple Pay on the Web (JavaScript) Safari (iOS / macOS) Apple Pay Sandbox Merchant domain verified Merchant validation succeeds Observed Flow The Apple Pay flow proceeds normally until authentication: User clicks the Apple Pay button ApplePaySession.begin() is called onvalidatemerchant fires Merchant validation request succeeds completeMerchantValidation() is called Apple Pay sheet is displayed User authenticates with Face ID / Touch ID onpaymentauthorized is never triggered Because this event never fires, the payment token is not returned and the payment cannot proceed. ApplePaySession Request { "countryCode": "JP", "currencyCode": "JPY", "merchantCapabilities": ["supports3DS"], "supportedNetworks": ["visa", "masterCard"], "total": { "label": "Test Payment", "type": "final", "amount": "100" } } Merchant Validation Merchant validation succeeds and returns a valid session from Apple. Relevant fields from the merchant session: merchantIdentifier: 35A786BE6AB4... domainName: secure.telecom-awstest.com displayName: ApplePay Additional Notes Apple Pay sheet appears normally Authentication completes successfully No JavaScript errors are logged onpaymentauthorized is never fired Issue occurs consistently in the sandbox environment Confirmed across multiple iOS versions Question Has anyone experienced a similar issue recently in the Apple Pay sandbox environment, or are there any known changes that could cause the onpaymentauthorized event not to fire after authentication? Any insights would be greatly appreciated. Thank you.

DeviceActivityReportExtension sandbox blocks all output channels — how to export resolved Application.bundleIdentifier? Application.bundleIdentifier only resolves to a non-nil value inside a DeviceActivityReportExtension (ExtensionKit/XPC). The main app and DeviceActivityMonitor extension always return nil. However, the Report Extension's sandbox silently blocks every output channel I've tested: UserDefaults (App Group): Reads succeed, writes silently dropped File writes (App Group container): Fail silently or throw HTTP requests: Network blocked entirely Local Notifications: "Couldn't communicate with a helper application" UIPasteboard: Writes silently fail iCloud KVS: synchronize() returns false Both targets share the same com.apple.security.application-groups entitlement and group identifier. The main app reads and writes to the shared container normally — only the extension's writes fail. This means resolved bundle identifiers can only be rendered in the extension's own SwiftUI view and cannot be communicated anywhere else. My question: Is this sandbox restriction intentional? If so, what is the recommended mechanism for the host app (or a backend) to obtain the resolved bundle identifiers that only the Report Extension can access? Environment: Xcode 16.3, iOS 18.3, physical device. Sample project: https://drive.google.com/file/d/1DPyN2BCUt5p-RKEPA0zsDFFEvgZVHlS_/view?usp=sharing — a minimal two-target project that demonstrates every failing channel. Run on a physical device, grant Screen Time access, select apps, and observe that bundle ID resolution shows PASS but all write channels show FAIL.

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?

We are implementing in-app provisioning in our fintech app; We are reaching out to ask for your help in understanding what is going wrong so we can fix it. What happens: User taps “Add to Apple Wallet” → we present PKAddPaymentPassViewController → they tap Next → after a few seconds the flow fails with "Set Up Later" alert. Device log: "eligibility request failure", "Received HTTP 500" )'; underlyingError: 'Error Domain=PKPaymentWebServiceErrorDomain Code=0 "Unexpected error." UserInfo={PKErrorHTTPResponseStatusCodeKey=500, NSLocalizedDescription=Unexpected error.}'; userInfo: '{ PKErrorHTTPResponseStatusCodeKey = 500; }'; > Feedback Assistant ID: FB22176928 (In-App Provisioning issue 500 Internal Server Error)

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.

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.

Hello, I have a question regarding how prorated refunds are reflected when a user upgrades a subscription. From my understanding, when a user upgrades to a higher-tier subscription, the remaining value of the current subscription is refunded as a prorated amount, typically represented as REFUND_PRORATED or PRORATED_CREDIT. However, when reviewing the available transaction history and refund-related data (including the App Store Server API and transaction history endpoints), I cannot find any field or record that clearly indicates: the actual prorated refund amount, or the credit applied when upgrading to another subscription In other words, while the concept of REFUND_PRORATED seems to exist conceptually, I cannot identify where the actual prorated value or credit applied to the upgrade is exposed in the transaction or refund history. My questions are: Is there any way to retrieve the actual prorated refund or credit amount when a user upgrades a subscription? Is this information available through the App Store Server API (e.g., Get Transaction History) or any other API endpoint? If not, is there any recommended method to determine how much of the previous subscription was credited toward the upgraded subscription? Any clarification would be greatly appreciated. Thank you for your help.

We have a macOS system extension with NETransparentProxyProvider which is able to intercept traffic and handle it. We also wanted to setup few search domains from our network extension. However, unlike PacketTunnelProvider, NEDNSSettings are completely ignored with NETransparentProxyProvider. So whats the best way to setup few DNS search domains when using NETransparentProxyProvider.

Hello, I have an application that needs to be published to the App Store. This application consists of two processes, A and B, where B is a child process of A. I found that if process B needs to be launched as a child process of A in sandbox mode, it is necessary to set the following keys in the entitlements.plist file: <key>com.apple.security.app-sandbox</key><true/><key>com.apple.security.inherit</key><true/> However, after setting these keys, process B can no longer be launched directly. This issue is particularly prominent because process B has a window and a Dock icon — in this case, if the user pins the Dock icon, they will be unable to launch process B. Could you please advise on a solution to this problem?

Hey everyone, I found a possible SwiftData Release-only issue with nested sort descriptors on an optional relationship. In a minimal repro, sorting a @Query by a nested optional relationship key path like: SortDescriptor(\InvestigationPhotoAsset.imageAnalysis?.overallAestheticsScore, order: .reverse) works in Debug, but crashes at runtime in Release. The surprising part is that the crash depends on file layout: if the active SwiftData models and the sort logic are kept in the same Swift file, the app works if the same models are split into separate files, the Release build crashes, 'Debug' will also work The repro was reduced to just two SwiftData models: InvestigationPhotoAsset InvestigationImageAnalysis So this looks less like an app-modeling issue and more like a SwiftData/compiler/codegen issue related to nested sort metadata in optimized builds. If useful, I can also give you a slightly more formal version with a title and code snippet block. Please check out the code example here Has anyone faced something similar? Bug is reported as FB22173905

Hi, I am currently implementing a recurring payment feature using the Apple Pay JS API. Based on the official demo (https://applepaydemo.apple.com/apple-pay-js-api), it appears that the recurringPaymentRequest object only supports a maximum of two stages: trialBilling and regularBilling. However, our service requires a multi-stage billing model with three or more different cycles/amounts as shown below: Example Schedule: Stage 1: 2,000 JPY (2026-03-01 to 2026-04-01) Stage 2: 1,500 JPY (2026-04-01 to 2026-10-01) Stage 3: 1,000 JPY (2026-10-01 to 2027-10-01) Stage 4: 500 JPY (Thereafter) Questions: Is there any way to directly define and display three or more different billing cycles/amounts on the Apple Pay payment sheet? If the API is strictly limited to two stages, what is the Apple-recommended way to provide transparency for such complex schedules while remaining compliant with the guidelines? For instance, is it acceptable to set the final amount in regularBilling and explain the preceding stages in the billingAgreement or paymentDescription fields? I would appreciate any insights or official guidance on this. Best regards,

Hello, We are experiencing an issue related to push notifications after updating devices to iOS 26.4 Beta. Our system stores push notification tokens on the server by associating the device token with the device’s IDFV in the app. After updating a device to iOS 26.4 Beta, we observed that the device token from a previously uninstalled version of the app remains valid for more than a week. As a result, two push notifications are delivered to the same device. The situation is as follows: The user installs the app and a device token is generated. The user uninstalls the app. Later, the user installs the app again and a new device token is generated. However, the previous device token does not become invalid, even after more than a week. Because IDFV changes when the app is reinstalled, our server cannot determine that the device belongs to the same user. Therefore, we cannot overwrite the old token with the new one on the server side. Could you please advise: Is this behavior expected in iOS 26.4 Beta? How long does it normally take for a device token to become invalid after an app is uninstalled? What is the recommended approach to prevent duplicate push notifications in this situation? Any guidance would be greatly appreciated. Best regards

I am building a simple iOS app that shows the total phone usage time for today using the Screen Time APIs. Architecture: Main app → requests authorization using AuthorizationCenter.shared.requestAuthorization(for: .individual) → displays a DeviceActivityReport Report extension → DeviceActivityReportExtension → calculates total usage using DeviceActivityResults<DeviceActivityData> → shows the number in a SwiftUI view The report works correctly. The extension successfully calculates the total usage and displays it on screen. Example logic inside the report extension: for await activityData in data { for await segment in activityData.activitySegments { totalSeconds += segment.totalActivityDuration } } let totalMinutes = Int(totalSeconds / 60) The problem: I need the main app to access that number so I can store it daily in my own database. I tried to send the value from the extension to the main app using: App Group + UserDefaults(suiteName:) App Group + shared file (FileManager.containerURL) writing inside makeConfiguration(...) Example: if let defaults = UserDefaults(suiteName: "group.myapp") { defaults.set(value, forKey: "savedTotalActivity") } But the main app cannot read the value. The report extension displays the number correctly, but the data never appears in shared storage. Questions: Is DeviceActivityReportExtension intentionally sandboxed so Screen Time data cannot be exported to the containing app? Is there any supported way for the main app to access the total usage value calculated in the report extension? If exporting the value is restricted, what is the recommended architecture for apps that want to store daily Screen Time totals for later analysis? Goal: I want a simple app that records something like: 2026-03-08 → 244 minutes 2026-03-09 → 198 minutes and stores it inside the app database. Any guidance on the correct architecture would help.

I've run into what appears to be a bug in PDFKit's radio button serialization. When creating a radio button group with PDFAnnotation, only the first annotation added via page.addAnnotation() gets a correct /AS entry in the written PDF — all other annotations always get /AS /Off, regardless of buttonWidgetState. Minimal reproduction func makeRadioButton(optionId: String, isSelected: Bool) -> PDFAnnotation { let ann = PDFAnnotation(bounds: CGRect(x: 0, y: 0, width: 20, height: 20), forType: .widget, withProperties: nil) ann.widgetFieldType = .button ann.widgetControlType = .radioButtonControl ann.fieldName = "Choice" ann.buttonWidgetStateString = optionId ann.buttonWidgetState = isSelected ? .onState : .offState return ann } let pdf = PDFDocument() let page = PDFPage() pdf.insert(page, at: 0) // Intend to select B page.addAnnotation(makeRadioButton(optionId: "A", isSelected: false)) page.addAnnotation(makeRadioButton(optionId: "B", isSelected: true)) page.addAnnotation(makeRadioButton(optionId: "C", isSelected: false)) _ = pdf.dataRepresentation() // Result: /AS is /Off for all three — B is not selected in the PDF What I observed Selecting A (first annotation added): /AS /A written correctly works Selecting B or C: /AS /Off for all buttons Additionally, dataRepresentation() corrupts the in-memory state as a side effect: buttonWidgetState of the selected annotation is .onState before the call and .offState after. Root cause During serialization, dataRepresentation() internally calls setButtonWidgetState:.onState on each annotation in turn to generate appearance streams. This triggers PDFKit's radio-group exclusivity logic, which silently clears all other annotations — so by the time /AS is written, only the first annotation's selection survives. Workaround It took a while to track this down, so I'm documenting the workaround here in case it helps others. Add the annotation that should be selected first via page.addAnnotation(): // Add selected annotation first page.addAnnotation(makeRadioButton(optionId: "B", isSelected: true)) page.addAnnotation(makeRadioButton(optionId: "A", isSelected: false)) page.addAnnotation(makeRadioButton(optionId: "C", isSelected: false)) Tested on macOS 26.3 / Xcode 26.3. Filed as Feedback FB22167174. Full code including workaround is here: radio_bug_swift.txt Has anyone else hit this? Is there a cleaner method I'm missing?

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.