hello, how can I trap specific standard system registers of a vCPU in Hypervisor framework? like the ARM standard HSTR_EL2, which I don't see exposed in the headers.

Hi, Somebody knows how to decode / decrypt emvData on Apple Pay e-commerce when paymentDataType=EMV? Thanks. Reference: https://developer.apple.com/documentation/passkit/payment-token-format-reference#Detailed-payment-data-keys-EMV

I'm building an automated wallpaper updater that fetches images from an API and sets them as desktop wallpaper on macOS Tahoe. The automation uses AppleScript combined with database manipulation to ensure wallpaper applies to all spaces. Current implementation (via Apple Shortcuts): wallpaper_path="$1" osascript -e "tell application \"System Events\" to tell every desktop to set picture to POSIX file \"$wallpaper_path\"" sqlite3 ~/Library/Application\ Support/Dock/desktoppicture.db "UPDATE data SET space=NULL WHERE space IS NOT NULL;" 2>/dev/null killall -HUP Dock Issue First run: Works perfectly - sets wallpaper on all spaces/desktops, "Show on all spaces" is ON After first run: "Show on all spaces" automatically toggles OFF in System Settings Second run onwards: New wallpaper only updates on the active space, inactive spaces show old wallpaper Expected: "Show on all spaces" should remain ON after programmatic wallpaper changes Actual: System Settings automatically disables it, breaking subsequent updates Tested workarounds (all failed): UPDATE data SET space=NULL to clear per-space entries Using every desktop instead of current desktop in AppleScript killall Dock vs killall -HUP Dock vs killall -USR1 Dock Clearing space_id entries from pictures table Running DELETE FROM pictures WHERE space_id IS NOT NULL before setting The database manipulation doesn't prevent macOS from automatically creating per-space entries and disabling the "Show on all spaces" toggle. Question: Is there a way to programmatically set wallpaper while preserving the "Show on all spaces" setting on macOS Tahoe? Environment: macOS: Tahoe (latest) Architecture: Apple Silicon Use case: Daily automated wallpaper updates via Shortcuts

1/ Issue Summary In our application, we use HKObserverQuery together with:HKHealthStore.enableBackgroundDelivery(for:frequency: .immediate) to enable HealthKit Background Delivery, allowing the system to wake our App Extension in the background to process health data updates. Under the same app build, identical HealthKit permission configuration, and the same watchOS version, we have observed significant differences in background delivery frequency across different devices. Specifically, on certain devices (e.g. Apple Watch Series 10, watchOS 26.2.1), the background delivery frequency is significantly reduced, behaving as if it is capped at approximately once per hour. On other control devices, under the same configuration, background delivery is triggered much more frequently and consistently, at approximately every 8–16 minutes. This behavior is consistently reproducible on the affected devices. **We would like to understand whether there are any officially recommended implementation patterns, best practices, or device-/system-level considerations when using HKObserverQuery and Background Delivery, in order to achieve more consistent and predictable background update behavior across different devices running the same system version. ** 2/ Detailed Device Comparison We conducted internal comparison testing across multiple devices with the following results: Device A (Affected / Abnormal) Model: Apple Watch Series 10 (46mm) OS: watchOS 26.2.1 Serial (partial): C*HY Background Delivery Frequency: ~ once every 60 minutes (significantly lower than expected) Device B (Normal) Model: Apple Watch Series 10 (42mm) OS: watchOS 26.2.1 Serial (partial): G*4R Background Delivery Frequency: ~ every 8–16 minutes Device C (Normal) Model: Apple Watch Series 8 (41mm) OS: watchOS 26.3 Serial (partial): C*J6 Background Delivery Frequency: ~ every 8–16 minutes Device D (Normal) Model: Apple Watch Series 5 (41mm) OS: watchOS 10.6.1 Serial (partial): G*TQ Background Delivery Frequency: ~ every 8–16 minutes All devices share the following conditions: HealthKit permissions: Full read/write permissions granted Background App Refresh: Enabled System state: Low Power Mode, Do Not Disturb, and all Focus modes disabled App build: Identical app build installed on all devices HealthKit configuration: Same data types and same frequency parameter used in enableBackgroundDelivery Implementation: Identical HKObserverQuery implementation logic 3/ Abnormal Behavior Observed On the affected device(s), we observe that: HealthKit background delivery appears to be heavily coalesced or throttled The system rarely attempts to wake the App Extension Behavior is clearly inconsistent with other devices using the same configuration The behavior does not match our expectations for HealthKit Background Delivery with .immediate frequency 4/ Troubleshooting Already Performed We have already attempted the following on the affected device(s): Restarted both Apple Watch and paired iPhone Re-paired the Apple Watch Uninstalled and reinstalled the app Revoked and re-granted HealthKit permissions Confirmed that Low Power Mode, Do Not Disturb, and Focus modes are all disabled The issue remains consistently reproducible. 5/ Assistance Requested We would appreciate guidance on: Whether there are any officially recommended implementation patterns, tuning options, or best practices for using HKObserverQuery and HealthKit Background Delivery Whether there are any known device-level or system-level factors that may cause significantly different background delivery behavior on different devices running the same watchOS version How to best achieve consistent and predictable background update delivery behavior across devices for apps that rely on this mechanism 6/ Additional Information We can provide sysdiagnose logs from both affected and unaffected devices for comparison We can also provide a minimal reproducible sample project if needed

I have a desktop application that shows some real estate properties chosen by the user. The application shows those GPP locations on the map. The SwiftUI code is something like the following. import SwiftUI import MapKit struct ContentView: View { var body: some View ZStack { mapView } } private var mapView: some View { Map(position: $propertyViewModel.mapPosition) { ForEach(propertyViewModel.properties) { property in Annotation("", coordinate: CLLocationCoordinate2D(latitude: property.lat, longitude: property.lon)) { Button { } label: { VStack { Image(systemName: "house.circle.fill") .resizable() .scaledToFit() .frame(width: 48) .foregroundStyle(colorScheme == .light ? .white : .black) ... } } .buttonStyle(.borderless) } } UserAnnotation() } .mapControls { MapUserLocationButton() } .mapControlVisibility(.visible) .onAppear { CLLocationManager().requestWhenInUseAuthorization() } } } The application only wants to use the CLLocationManager class so that it can show those locations on the map relative to your current GPS position. And I'm hit with two review rejections. Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage Issue Description One or more purpose strings in the app do not sufficiently explain the use of protected resources. Purpose strings must clearly and completely describe the app's use of data and, in most cases, provide an example of how the data will be used. Guideline 5.1.5 - Legal - Privacy - Location Services The app uses location data for features that are not relevant to a user's location. Specifically, the app is not functional when Location Services are disabled. So I wonder if the application is even required to have 'NSLocationWhenInUseUsageDescription' and/or 'NSLocationUsageDescription'? just in order to show user's current location so that they can see property locations relative to it? The exact location privacy statement is the following. The application needs your permission in accessing your current location so that it will appear on the map

Summary I'm using Background Assets to download Apple-hosted Asset Packs(downloadPolicy = onDemand). The first download cancellation succeeds, but on the second and subsequent downloads, progress.cancel() fails to work and the download completes to the end. Environment iOS 26.0 – 26.3 RC (all produce the same result) Xcode Version 26.2 (17C52) Using Apple-hosted Asset Packs Steps to Reproduce Start downloading an Asset Pack Call progress.cancel() during download → Succeeds Start downloading the same Asset Pack again Call progress.cancel() during download → Fails (download completes to the end) Observed Error Logs After 1st cancellation: A download with the ID "X-XXXXXXXX-XXX" failed: Error Domain=NSURLErrorDomain Code=-999 "cancelled" ↑ This is expected (cancellation succeeded) The fact that version 0 of the asset pack with the ID "X-XXXXXX-XXX" finished being downloaded couldn't be reported: Error Domain=NSCocoaErrorDomain Code=3851 "Property list invalid for format: 200 (property lists cannot contain objects of type 'CFError')" ↑ Problem: Unable to serialize CFError to plist 2nd cancellation attempt: The download with the ID "X-XXXXXX-XXX" couldn't be canceled: Error Domain=BAErrorDomain Code=113 "The requested download operation failed because the download object did not exist." ↑ The download object we're trying to cancel supposedly doesn't exist Implementation Code // Cancel implementation func cancel(tag: String) async { let statusUpdates = AssetPackManager.shared.statusUpdates(forAssetPackWithID: tag) for await statusUpdate in statusUpdates { if case .downloading(_, let progress) = statusUpdate, progress.isCancellable { progress.cancel() } } } Analysis It appears that when the first cancellation occurs, the system internally tries to save the cancellation state to a plist, but fails to serialize the CFError object. This seems to cause an inconsistent internal state, preventing the system from correctly recognizing the download object on subsequent downloads. Questions Is there a workaround? Is there a planned fix for a future iOS version?

I’m having an issue verifying a domain for a Merchant ID. I’m implementing Apple Pay on the web for a demo, and I’ve configured the Azure server to match Apple’s requirements for domain verification, such as the TLS configuration, not requiring client certificates, and ensuring there are no redirects. I’ve run tests with OpenSSL and PowerShell and all responses return HTTP/1.1 200 OK. I also tested the URL Apple says it uses to validate the file under .well-known, and it does show the expected result. I already have the Apple Pay Payment Processing Certificate and the Apple Pay Merchant Identity Certificate approved; the only thing missing is the domain verification. I’m not sure what else to test—if you could help me with a possible solution, I’d really appreciate it. (The project is built in .NET 8 and hosted on Azure App Service.)

Hello, I'm implementing the wallet extension for a financial app. Right now I'm having a problem, I want to redirect to the main app when the user hasn't logged in. Is it possible? This is my code in the WalletUI. It just doesn't work. let urlString = "bank://login" guard let url = URL(string: urlString) else { return } self.extensionContext?.open(url, completionHandler: { success in if !success { print("Success") } else { self.completionHandler?(.canceled) } }) }

MacOS(Apple Silicon) IOKit driver for FPGA DMA transmission, kernel panic. Hardware and software configuration: MAC mini M1 2020 16GB, macOS Ventura 13.0 or 13.7.8 FPGA device capability: 64-bit Complete description: We've developed a DMA driver for PCIe devices (FPGA) based on IOKit. The driver can start normally through kextload, and the bar mapping, DMA registers, etc. are all correct. I am testing DMA data transmission, but a kernel panic has occurred. The specific content of the panic is as follows: {"bug_type":"210","timestamp":"2026-01-28 14:35:30.00 +0800","os_version":"macOS 13.0 (22A380)","roots_installed":0,"incident_id":"61C9B820-8D1B-4E75-A4EB-10DC2558FA75"} { "build" : "macOS 13.0 (22A380)", "product" : "Macmini9,1", "socId" : "0x00008103", "kernel" : "Darwin Kernel Version 22.1.0: Sun Oct 9 20:14:30 PDT 2022; root:xnu-8792.41.9~2/RELEASE_ARM64_T8103", "incident" : "61C9B820-8D1B-4E75-A4EB-10DC2558FA75", "crashReporterKey" : "6435F6BD-4138-412A-5142-83DD7E5B4F61", "date" : "2026-01-28 14:35:30.16 +0800", "panicString" : "panic(cpu 0 caller 0xfffffe0026c78c2c): "apciec[pcic0-bridge]::handleInterrupt: Request address is greater than 32 bits linksts=0x99000001 pcielint=0x02220060 linkcdmsts=0x00000000 (ltssm 0x11=L0)\n" @AppleT8103PCIeCPort.cpp:1301\nDebugger message: panic\nMemory ID: 0x6\nOS release type: User\nOS version: 22A380\nKernel version: Darwin Kernel Version 22.1.0: Sun Oct 9 20:14:30 PDT 2022; root:xnu-8792.41.9~2/RELEASE_ARM64_T8103\nFileset Kernelcache UUID: C222B4132B9708E5E0E2E8B8C5896410\nKernel UUID: 0BFE6A5D-118B-3889-AE2B-D34A0117A062\nBoot session UUID: 61C9B820-8D1B-4E75-A4EB-10DC2558FA75\niBoot version: iBoot-8419.41.10\nsecure boot?: YES\nroots installed: 0\nPaniclog version: 14\nKernelCache slide: 0x000000001d1b4000\nKernelCache base: 0xfffffe00241b8000\nKernel slide: 0x000000001e3f8000\nKernel text base: 0xfffffe00253fc000\nKernel text exec slide: 0x000000001e4e0000\nKernel text exec base: 0xfffffe00254e4000\nmach_absolute_time: 0x907c3082\nEpoch Time: sec usec\n Boot : 0x6979adbb 0x00023a6a\n Sleep : 0x00000000 0x00000000\n Wake : 0x00000000 0x00000000\n Calendar: 0x6979ae1a 0x00064953\n\nZone info:\n Zone map: 0xfffffe1000834000 - 0xfffffe3000834000\n . VM : 0xfffffe1000834000 - 0xfffffe14cd500000\n . RO : 0xfffffe14cd500000 - 0xfffffe1666e98000\n . GEN0 : 0xfffffe1666e98000 - 0xfffffe1b33b64000\n . GEN1 : 0xfffffe1b33b64000 - 0xfffffe2000830000\n . GEN2 : 0xfffffe2000830000 - 0xfffffe24cd4fc000\n . GEN3 : 0xfffffe24cd4fc000 - 0xfffffe299a1c8000\n . DATA : 0xfffffe299a1c8000 - 0xfffffe3000834000\n Metadata: 0xfffffe3f4d1ac000 - 0xfffffe3f551ac000\n Bitmaps : 0xfffffe3f551ac000 - 0xfffffe3f5ac94000\n\nCORE 0 recently retired instr at 0xfffffe002569d7a0\nCORE 1 recently retired instr at 0xfffffe002569eea0\nCORE 2 recently retired instr at 0xfffffe002569eea0\nCORE 3 recently retired instr at 0xfffffe002569eea0\nCORE 4 recently retired instr at 0xfffffe002569eea0\nCORE 5 recently retired instr at 0xfffffe002569eea0\nCORE 6 recently retired instr at 0xfffffe002569eea0\nCORE 7 recently retired instr at 0xfffffe002569eea0\nTPIDRx_ELy = {1: 0xfffffe2000c23010 0: 0x0000000000000000 0ro: 0x0000000000000000 }\nCORE 0 PVH locks held: None\nCORE 1 PVH locks held: None\nCORE 2 PVH locks held: None\nCORE 3 PVH locks held: None\nCORE 4 PVH locks held: None\nCORE 5 PVH locks held: None\nCORE 6 PVH locks held: None\nCORE 7 PVH locks held: None\nCORE 0 is the one that panicked. Check the full backtrace for details.\nCORE 1: PC=0xfffffe00279db94c, LR=0xfffffe00260d5d9c, FP=0xfffffe8ffecaf850\nCORE 2: PC=0xfffffe0025be76b0, LR=0xfffffe0025be7628, FP=0xfffffe8fff08f5f0\nCORE 3: PC=0x00000001c7cacd78, LR=0x00000001c7cacd84, FP=0x000000016f485130\nCORE 4: PC=0xfffffe002557f55c, LR=0xfffffe002557f55c, FP=0xfffffe8ffe1dff00\nCORE 5: PC=0xfffffe002557f55c, LR=0xfffffe002557f55c, FP=0xfffffe8fff5eff00\nCORE 6: PC=0xfffffe002557f55c, LR=0xfffffe002557f55c, FP=0xfffffe8ffed8bf00\nCORE 7: PC=0xfffffe002557f55c, LR=0xfffffe002557f55c, FP=0xfffffe8fff11bf00\nCompressor Info: 0% of compressed pages limit (OK) and 0% of segments limit (OK) with 0 swapfiles and OK swap space\nPanicked task 0xfffffe1b33aad678: 0 pages, 470 threads: pid 0: kernel_task\nPanicked thread: 0xfffffe2000c23010, backtrace: 0xfffffe8fff6eb6a0, tid: 265\n\t\t ... Kernel Extensions in backtrace:\n com.apple.driver.AppleT8103PCIeC(1.0)[A595D104-026A-39E5-93AA-4C87CE8C14D2]@0xfffffe0026c619d0->0xfffffe0026c86c97\n dependency: com.apple.driver.AppleARMPlatform(1.0.2)[11A9713E-6739-3A4C-8571-2D8EAA062278]@0xfffffe0025f13ff0->0xfffffe0025f6255f\n dependency: com.apple.driver.AppleEmbeddedPCIE(1)[E71CBCCD-AEB8-3E7B-933D-4FED4241BF13]@0xfffffe002654e0b0->0xfffffe00265684c7\n dependency: com.apple.driver.ApplePIODMA(1)[A419BABC-A7A3-316D-A150-7C2C2D1F6D53]@0xfffffe00269a24b0->0xfffffe00269a6c3b\n dependency: com.apple.driver.IODARTFamily(1)[03997E20-8A3F-3412-A4E8-BD968A75A07D]@0xfffffe00275bcf50->0xfffffe00275d0a3f\n dependency: com.apple.iokit.IOPCIFamily(2.9)[EC78F47B-530B-3F87-854E-0A0A5FD9BBB2]@0xfffffe0027934350->0xfffffe002795f3d3\n dependency: com.apple.iokit.IOReportFamily(47)[843B39D3-146E-3992-B7C7-960148685DC8]@0xfffffe0027963010->0xfffffe0027965ffb\n dependency: com.apple.iokit.IOThunderboltFamily(9.3.3)[B22BC005-BB7B-32A3-99C0-39F3BDBD8E54]@0xfffffe0027a5e3f0->0xfffffe0027b9a1a3\n\nlast started kext at 1915345919: com.sobb.pcie-dma\t1.0.0d1 (addr 0xfffffe00240e47f0, size 9580)\nlast stopped kext at 1774866338: com.sobb.pcie-dma\t1.0.0d1 (addr 0xfffffe00240e47f0, size 9580)\nloaded It seems that the DMA request address initiated by FPGA exceeded 32 bits, which was intercepted by PCIe root port and resulted in a kernel panic.This is also the case on macOS (M2). I have tried the following code interface: IOBufferMemoryDescriptor： a. withCapacity(bufferSize, kIODirectionInOut, true)； b. inTaskWithPhysicalMask(kernel_task, kIODirectionInOut, bufferSize, 0x00000000FFFFFFFFULL)。 The physical addresses of the constructed descriptors are all >32 bits; IODMACommand： a. withSpecification(kIODMACommandOutputHost64, 64, 0, IODMACommand::kMapped, 0, 0)，gen64IOVMSegments() The allocated IOVM address must be>32 bits, which will generate a kernel panic when used later. b.withSpecification(kIODMACommandOutputHost32, 32, 0, IODMACommand::kMapped, 0, 0)，gen32IOVMSegments() The allocation of IOVM failed with error code kIOReturnenMessageTooLarge. So after the above attempts, the analysis shows that the strategy of Dart+PCIe root port on macOS (Apple Silicon) is causing the failure of 64 bit DMA address transfer. I have two questions: a. Does Dart in macOS (Apple Silicon) definitely not allocate <=32-bit IOVM addresses? b. Is there any other way to achieve DMA transfer for FGPA devices on macOS (Apple Silicon)? Thanks！

Hi everyone, With the rapid growth of digital banking, payments, and AI-driven financial services, building secure and scalable FinTech apps on iOS has become more complex than ever. From handling sensitive user data to ensuring compliance and seamless performance, iOS developers face multiple technical challenges. Key areas that usually require deep expertise include: Apple Pay and Wallet integrations Secure authentication (Face ID / Touch ID / biometrics) Real-time transaction processing Core ML for financial predictions SwiftUI dashboards for financial analytics Data encryption and regulatory compliance https://www.nimbleappgenie.com At Nimble AppGenie, we’ve worked extensively as a FinTech app development expert, helping startups and enterprises design and build iOS financial applications that are secure, scalable, and user-centric. Our experience shows that the most successful fintech apps are those that balance strong security architecture with intuitive UX and performance optimization. I’m interested to hear from the community: What are the biggest challenges you’ve faced while building fintech apps on iOS? Are there any recent iOS updates or Apple frameworks that significantly improved your fintech workflows? How are you handling compliance and security in production apps? Looking forward to learning from everyone’s experiences and best practices.

App is repeatedly rejected under Guideline 2.5.1 for referencing the private API:_SecCertificateIsValid Reported custom framework CommonLibrary.framework. The SDK is written in Objective-C and uses only public Security APIs. It does not use any deprecated APIs. We have verified the framework binary using nm, otool, and strings, and _SecCertificateIsValid does not appear in exported or hidden symbols. Bitcode is disabled, dead-code stripping is enabled, and the Release build uses -Os. Despite this, App Store Connect continues to detect _SecCertificateIsValid. We have attached herewith screenshots of our analysis for the reference. Can Apple’s server-side analysis or Security.framework internals still surface _SecCertificateIsValid? Is there a recommended way for SDK authors to prevent this symbol from being flagged?

I am developing a standard UAC 2.0 device and encountered an issue where the channel names do not update according to the iChannelNames field in the Class Specific AS Interface Descriptor when switching between different channel counts. For example: AS1 (6 channels) is configured with the following channel names: ADAT 1, ADAT 2, ADAT 3, ADAT 4, HP L, HP R AS2 (4 channels) is configured with: ADAT 1, ADAT 2, HP L, HP R However, when switching from AS1 (6 channels) to AS2 (4 channels), the channel names displayed in Audio MIDI Setup do not reflect the change as expected. The actual result is: ADAT 1, ADAT 2, ADAT 3, ADAT 4 The system simply hides the last two channels; the names of the remaining channels are not updated. Initial Topology My original topology was as follows: Later, I discovered that macOS uses the iChannelNames field from the Input Terminal to display channel names. Therefore, I modified the USB device descriptors and updated the topology to the following: To distinguish the channel names for different channel counts, each Input Terminal is assigned a unique iChannelNames value. This method worked perfectly on macOS 15. However, after updating to macOS 26, this topology no longer displays the correct channel names. Question On macOS 26, what is the correct method to ensure that the channel names update dynamically when switching between different audio channel configurations?

I am developing a standard UAC 2.0 device and encountered an issue where the channel names do not update according to the iChannelNames field in the Class Specific AS Interface Descriptor when switching between different channel counts. For example: AS1 (6 channels) is configured with the following channel names: ADAT 1, ADAT 2, ADAT 3, ADAT 4, HP L, HP R AS2 (4 channels) is configured with: ADAT 1, ADAT 2, HP L, HP R However, when switching from AS1 (6 channels) to AS2 (4 channels), the channel names displayed in Audio MIDI Setup do not reflect the change as expected. The actual result is: ADAT 1, ADAT 2, ADAT 3, ADAT 4 The system simply hides the last two channels; the names of the remaining channels are not updated. Initial Topology My original topology was as follows: Later, I discovered that macOS uses the iChannelNames field from the Input Terminal to display channel names. Therefore, I modified the USB device descriptors and updated the topology to the following: To distinguish the channel names for different channel counts, each Input Terminal is assigned a unique iChannelNames value. This method worked perfectly on macOS 15. However, after updating to macOS 26, this topology no longer displays the correct channel names. Question On macOS 26, what is the correct method to ensure that the channel names update dynamically when switching between different audio channel configurations?

Hello Apple Developer Support Team, We are developing an iOS iPhone application and would like clarification on whether Apple provides any APIs or system-level support to implement parental approval workflows aligned with certain regional regulatory requirements (for example, Texas, Utah, and Louisiana). Our intended use cases are outlined below: Initial Approval (App Download Stage) We understand that, in some situations, when a minor attempts to download an app from the App Store on iPhone, iOS may require approval through Family Sharing / Ask to Buy. We would like to confirm: • Whether there is any developer-accessible API that allows an iPhone app to detect if installation was approved via parental consent. • Whether apps can receive any callback, status indicator, or system signal confirming parental approval or rejection. • Whether the Declared Age Range API or any related framework provides access to parental approval or age verification signals. Ongoing Approval for Significant Changes For regulatory compliance, we may need to request parental re-approval when introducing significant application updates (for example, adding chat functionality, social interaction features, or modifying data collection practices). We would like clarification on: • Whether iOS provides any mechanism or API that allows iPhone apps to trigger or request parental re-approval after the application has already been installed. • Whether Apple provides any built-in workflows, system prompts, or entitlement-based approaches that support this type of re-approval process. In-App Handling of Parent Approval Requirements If our backend determines that a minor user requires parental approval before continuing to use certain app features, we would like to understand: • Whether Apple provides any APIs, SDKs, or recommended frameworks that allow initiating or facilitating parental authorization from within the iPhone app. • Whether there are any callbacks, permission states, entitlement checks, or system notifications that developers can use to determine and track parental consent status. If any such capabilities exist, we would greatly appreciate links to official documentation, technical guidance, or sample implementations demonstrating how approval status can be retrieved and handled in an iOS iPhone application. Also from which iOS version this capabilities will work & how to handle lower iOS version which is not supporting. Additionally, if Apple recommends alternative compliance approaches using existing frameworks such as Family Sharing, Screen Time APIs, or Declared Age Range, we would appreciate guidance on best practices for implementation. Also, could you please clarify the minimum iOS version that supports these capabilities? We would also appreciate recommendations on how developers should manage or implement fallback handling for devices running lower iOS versions where these capabilities are not supported. Thank you for your assistance and guidance in ensuring compliance with Apple platform policies and regional regulatory requirements. Kind regards

I am building an app for iOS and MacCatalyst that indexes files by storing their local paths. Because the app relies on the file remaining at its original location, I only want to accept items that can be opened in place. I am struggling to determine if an item is "Open In Place" compatible early in the drag-and-drop lifecycle. Specifically: In dropInteraction(_:canHandle:) and dropInteraction(_:sessionDidUpdate:), calling itemProvider.registeredTypeIdentifiers(fileOptions: [.openInPlace]) returns an empty array. Only once the drop is actually committed in dropInteraction(_:performDrop:) does that same call return the expected type identifiers. This creates a poor user experience. I want to validate the "In Place" capability at the very start of the session so the drop target only activates for valid files. If an item is ephemeral (like a dragged photo from the Photos app or a temporary export), the drop zone should not react at all. How can I reliably detect if an NSItemProvider supports .openInPlace before the performDrop delegate method is called?

I am developing an application on macOS in SwiftUI which exchanges files with other processes on a network. Some of these processes may be on Linux and write to a network drive. The files are refreshed at 10, 15 or 60 second intervals, and keep the same name. The software is supposed to run 24/7 and have persistent paths, so that on restart it does not need setting up. And it runs in the sandbox. I have got this working with macOS-only external processes by putting the exchange files in a fixed folder on the network storage and using security-scoped bookmarks to the file and or folder. But it doesn't work so well when one of the writing processes is a Linux process writing to its own storage. I can put a symlink in my fixed folder and if i select the folder and the symlink after each app restart, it works. but how can i make such a set-up persistent so it works after app restart without manual selection?

Hello there, We’re currently integrating Apple Wallet pass functionality into our application and am looking for clarification around the automatic update flow. Particularly regarding secure management of the authenticationToken. We’ve reviewed the documentation here: Adding a Web Service to Update Passes authenticationToken Documentation From our understanding: When a user downloads a pass from our service, the .pkpass includes both a webServiceURL and an authenticationToken. Once the pass is added to Wallet, the Wallet app makes authenticated requests to our webServiceURL, using the token in the Authorization header. We then validate this token server-side to serve updates or handle device registration. So far, this flow is clear. However, we’re looking for clarification on two key scenarios: If a user adds the same pass twice on the same device, should the authenticationToken remain the same in both cases? If the same user adds the same pass on a different device, should the authenticationToken also remain consistent across devices? If the answer to both is “yes,” we assume that our backend must store the original authenticationToken in a retrievable form (not just as a hash) to regenerate the same pass for re-download or multi-device sync. Our main question is: What is Apple’s recommended or acceptable approach to storing authenticationToken values securely on the backend? Should these tokens be: Stored in plaintext (e.g. in a protected DB field)? Encrypted using a symmetric key? Hashed (not reversible, but limits reuse)? We want to ensure we align with Apple’s best practices for Wallet security and token management, especially in contexts where the same pass may be installed on multiple devices or reissued later.

This is stemmed from another forum post on Apple Unified Logging. A few additional questions were raised towards a relevant but different topic - activity tracing, starting a new post following The Eskimo's suggestion. The first question is on log capture from an activity chain. The related documentation stated something but very vaguely. https://developer.apple.com/documentation/os/generating-log-messages-from-your-code?language=objc#Choose-the-Appropriate-Log-Level-for-Each-Message If an activity object exists, the system captures information for the related process chain We had hoped that this would somewhat play into the "speculative logging" approach we had touched upon in the original post, in the sense that if we try to log an error or fault within an activity, then it helps to capture and persist other logs on the activity chain even though they are originally not meant to be. But unfortunately from our test it didn't seem to be behaving towards that understanding. Then our question is, if we may ask - what are the exact additional information the system captures "for the related process chain"? 2nd question - are activity objects always persisted and would they also contribute to log quarantine? Our thoughts were that if we can, we'd like to create an independent activity for each event we receive from the system so the logs on every event are automatically correlated (we have a use case described in FB21839588). However as demonstrated in the FB ticket, that would mean A LOT of events and hence a lot of os_activity_create. I noticed we do have a flag Signpost-Persisted to control persisting for signposts, but there isn't a control for activities. My assumption is that they (the activity objects themselves) are always to be persisted so they would indeed contribute to quarantine in the worst case, is that correct? (Although from log stats it looks like each individual activity object is tiny in terms of storage size, so maybe they are not a big concern themselves?) And finally we noticed this control flag Propagate-with-Activity used by some logging configuration files from Apple. We didn't find any official Apple documentation but some 3rd party MDM vendors mentioned something about Propagate-with-Activity Messages attached to the activity tree Messages are attached to the activity tree in Console and crash dumps Right now based on our observation messages are always attached to the activity tree in Console regardless, and we can't seem to be able to find anything to do between activities and crash dumps. Maybe this flag is obsolete?

The tutorial only says a notification will be sent, but what happens next..? what should we do about the child account..? are we blocking them..? what happens on the child account? https://developer.apple.com/documentation/storekit/testing-age-assurance-in-sandbox

When Live Caller ID first came out I experimented with it and got it working using the Example PIR database. All my links from that time are now out of date and no longer work, however I seem to have found where the PIR database example and documentation has moved to (https://swiftpackageindex.com/apple/pir-service-example/main/documentation/pirservice/testinginstructionslivecalleridlookup) But what I can't find is an exact definition of the the logo size/max size/dimensions/format should be. My memory from that time is that it was very pernickety, and if things weren't exactly right, the logo wasn't displayed. I can remember the format had to be HEIC to get it to work. Looking through the documentation however, I can't see exact requirements specified. My question is - for the Live Caller ID logo what are the exact image requirements, and where are they documented?