Apple Maps Guides

For testing permission response we can use the sandbox account However, when testing permission requests using the AskCenter API, none of the ask API works for me in xcode 26.2 rc and iOS 26.2 rc. For SignificantAppUpdateTopic, I got errors like The user is in a region that does not support this type of ask in the console log, but I've already set my billing address to Texas. For CommunicationTopic, the console shows several XPC-related errors, and I’m not sure which of them are relevant. Both of them show an alert view of Can't ask, An unknown error occurred Can someone help to guide us how to test the request flow? Thanks

Hello, we get in touch as we need some guidance from Apple regarding age verification for minors in our app. Our app supports iOS 17 and above. The Declared Age Range API is available only starting on iOS 26, but we must comply with legal requirements (e.g., Texas SB 2420) and ensure that minor users cannot access certain sections of the app, regardless of the version of the operating system. Our question: What is the correct and Apple-approved approach for handling age verification and restricting access for minor users on iOS versions prior to 26, given that the Declared Age Range API is not available on those systems? We want to ensure that our implementation aligns with the regulations, the App Store Review Guidelines and platform expectations.

Trying to support undo & redo in an app that utilizes Swift Data and as with anything other than provided simplistic Apple demo examples the experience is not great. The problem: Im trying to build functionality that allows users to add items to an item group, where item and item group have a many-to-many relationship e.g. item group can hold many items and items can appear in multiple groups. When trying to do so with relatively simple setup of either adding or removing item group from items relationship array, I am pretty consistently met with a hard crash after performing undo & redo. Sometimes it works the first few undo & redos but 95% of the time would crash on the first one. Could not cast value of type 'Swift.Optional' (0x20a676be0) to 'Swift.Array' (0x207a2bc08). Where CodableStructModel is a Codable Value type inside Item. Adding and removing this relationship should be undoable & redoable as typical for Mac interaction and is supported by SwiftData by default, meaning that

I am implementing In App Purchase and integrating App Store Server Notifications version 2. I am able to receive the JWSSignedPayload from Apple. The payload is Base64 encoded and contains header, payload, and signature. The documentation clearly explains how to decode the payload and extract claims such as notificationType and data. What is unclear is how to verify the JWS signature itself. I could not find concrete documentation that explains: Which Apple public key or certificate should be used for verification How to retrieve or rotate the key used to sign the payload The exact steps required to validate the JWS signature before trusting the payload Signature verification is critical for security, and simply decoding the claims without validation is not sufficient. I am looking for official guidance or a recommended approach to verify the JWSSignedPayload signature for App Store Server Notifications v2.

When I use the ColorSync Utility to convert Display P3 color (1, 0, 0) to an XYZ color, the result is (0.5151, 0.2412, -0.0011). I expected that result because that is identical to the red colorant tristimulus value in the Display P3.icc file.When I use the CGColor converted method to do the same, the XYZ color is approximately (0.5151, 0.2412, 0.0). Note that the third element is 0.0 whereas it is -0.0011 when using the ColorSync Utility. I have printed out the Z component to 16 digits of precision, and Z is all 0s. It appears that the CGColor converted method is clamping the result from 0 to 1.My questions are:1. Which conversion is correct? The ColorSync utility or the CGColor converted method?2. I am not a color specialist, but I thought that the XYZ components should never be negative. If so, is the colorant tristimulus value in the Display P3.icc file wrong?3. Because CGColor clamped the Z component to 0, the XYZ color cannot be converted back exactly or closely to the Display P3 color (1, 0, 0). I woul

I have an open Feedback conversation with Apple on this topic, but I am curious if others have run into this, or want to try out my sample code in their set up. there are two API’s for reading controller buttons, axis, and D pads: GCPhysicalInputProfile and GCControllerLiveInput. There are inconsistencies in behaviour between the two of them. Apple recommends we use GCControllerLiveInput, however, there are some capabilities on these controllers that are only accessible through GCPhysicalInputProfile, as I’ll discuss below. PSVR2 R2/L2 buttons, a.k.a. triggers, have force input analogue values. These can only be accessed on GCPhysicalInputProfile PSVR2 thumbstick direction values are read through “axes” on GCPhysicalInputProfile, but only “dpads” on GCControllerLiveInput on both GCPhysicalInputProfile and GCControllerLiveInput, All pressed events of all buttons are fired properly using generic aliases ( Trigger, Grip ,Menu, Right Thumbstick, Left Thumbstick, Right Button A & B (Circle &a