Hello, I’m working on implementing SB2420 compliance using the Declared Age Range framework. While referring to the documentation at https://developer.apple.com/documentation/declaredagerange, I couldn’t find details on how the TX region (transaction region or territory) is determined when using Declared Age Range. Specifically, I’d like to confirm the following points: How does the system determine the TX region when the user’s declared age range is retrieved? Is it based on the App Store region, the device locale, or the user’s Apple ID country? If the app’s backend needs to verify or log the TX region, is there a way to obtain or infer it from the API response or receipt data? Is there any difference in TX region determination between Sandbox and Production environments? If anyone has experience implementing Declared Age Range (SB2420) and handling region determination, I’d appreciate your insights or best practices. Thank you.

When I logged into my cloudkit console to inspect the database for some debugging work I couldn't access the private database. It keeps saying "failed to access iCloud data, please signi n again". No matter how many times I sign in again, whether with password or passwordless key it keeps saying the same thing. It says that message when I click on Public database, and private and shared databases are below it. I only noticed this a couple of days ago. It's done this in the past, but I eventually got back into the database but I don't know what changed to make it work.

Triggered by Thread: 0 Thread 0 Crashed: 0 dyld 0x1a87922b0 lsl::PreallocatedAllocatorLayout<278528ull>::init(char const**, char const**, void*) + 436 1 dyld 0x1a878ba38 start + 1960 Thread 0 crashed with ARM Thread State (64-bit): x0: 0x2010003030100000 x1: 0x0000000fffffc0d0 x2: 0x0000000000000004 x3: 0x00000001a87607a9 x4: 0x0000000000000000 x5: 0x0000000000000000 x6: 0x0000000000000000 x7: 0x0000000000000000 x8: 0x2010003030100000 x9: 0x2010003030100000 x10: 0x000000016d923dfd x11: 0x00000001a87ccf30 x12: 0x0000000000000050 x13: 0x0000000000000044 x14: 0x0000000000052010 x15: 0x0000000000000000 x16: 0x0000000000000000 x17: 0x0000000000000000 x18: 0x0000000000000000 x19: 0x00000001801d0000 x20: 0x000000016d923b50 x21: 0x000000016d923af8 x22: 0x00000001e6184050 x23: 0x000000016d9237d8 x24: 0x0000000fffffc10c x25: 0x0000000000000000 x26: 0x0000000000000000 x27: 0x0000000000000000 x28: 0x0000000000000000 fp: 0x000000016d923870 lr: 0xb0228001a8792130 sp: 0x000000016d9237d0 pc: 0x00000001a87922b0 cpsr: 0x60001000 far: 0x00000001e61840e0 esr: 0x92000047 (Data Abort) byte write Translation fault Binary Images: 0x1a8758000 - 0x1a87db693 dyld arm64e <77c1eed22ed7396aba34e770120d81d4> /usr/lib/dyld 0x1024dc000 - 0x10594ffff main_executable_path_missing arm64 /main_executable_path_missing 0x0 - 0xffffffffffffffff ??? unknown-arch <00000000000000000000000000000000> ??? Error Formulating Crash Report: dyld_process_snapshot_get_shared_cache failed EOF crash.log

On iOS 26 beta 3, after a user purchases an item, initiating a second order for the same product fails to process payment. The system returns the same transaction ID and displays an interface message stating: "You've already purchased this In-App Purchase. It will be restored for free."​​ ​​I’ve tested this – not only did the legacy StoreKit finishTransaction method fail to work, but StoreKit2 finish method also malfunctioned.​​ ​​When will Apple fix this issue? If unresolved, it will prevent a large number of users from making purchases normally, leading to disastrous consequences.​

0 CoreText TDecorationRun::CalculateGlyphIntersections(CGAffineTransform, TRun const&, double, double, std::__1::function<void (double, double)> const&) const + 1704 1 CoreText TDecorationRun::CalculateGlyphIntersections(CGAffineTransform, TRun const&, double, double, std::__1::function<void (double, double)> const&) const + 1440 2 CoreText void TDecorationRun::DrawDecorationRun<(anonymous namespace)::TRunAdapter>(CGContext*, (anonymous namespace)::TRunAdapter, (anonymous namespace)::TRunAdapter, double)::'lambda'(CGPoint, CGPoint)::operator()(CGPoint, CGPoint) const + 508 3 CoreText TDecorator::DrawDecoration(TLineDrawContext const&, TLine const&, TInlineVector<DecorationOverride, 30ul> const*) + 2356 4 CoreText TLine::DrawUnderlines(CGContext*) const + 104 5 CoreText TLine::DrawGlyphs(CGContext*) const + 292

Hello! We are in the progress of migrating a large Swift 5.10 legacy code base over to use Swift 6.0 with Strict Concurrency checking. We have already stumbled across a few weird edge cases where the "guaranteed" @MainActor isolation is violated (such as with @objc #selector methods used with NotificationCenter). However, we recently found a new scenario where our app crashes accessing main actor isolated state on a background thread, and it was surprising that the compiler couldn't warn us. Minimal reproducible example: class ViewController: UIViewController { var isolatedStateString = "Some main actor isolated state" override func viewDidLoad() { exampleMethod() } /// Note: A `@MainActor` isolated method in a `@MainActor` isolated class. func exampleMethod() { testAsyncMethod() { [weak self] in // !!! Crash !!! MainActor.assertIsolated() // This callback inherits @MainActor from the class definition, but it is called on a background thread. // It is an error to mutate main actor isolated state off the main thread... self?.isolatedStateString = "Let me mutate my isolated state" } } func testAsyncMethod(completionHandler: (@escaping () -> Void)) { let group = DispatchGroup() let queue = DispatchQueue.global() // The compiler is totally fine with calling this on a background thread. group.notify(queue: queue) { completionHandler() } // The below code at least gives us a compiler warning to add `@Sendable` to our closure argument, which is helpful. // DispatchQueue.global().async { // completionHandler() // } } } The problem: In the above code, the completionHandler implementation inherits main actor isolation from the UIViewController class. However, when we call exampleMethod(), we crash because the completionHandler is called on a background thread via the DispatchGroup.notify(queue:). If were to instead use DispatchQueue.global().async (snippet at the bottom of the sample), the compiler helpfully warns us that completionHandler must be Sendable. Unfortunately, DispatchGroup's notify gives us no such compiler warnings. Thus, we crash at runtime. So my questions are: Why can't the compiler warn us about a potential problem with DispatchGroup().notify(queue:) like it can with DispatchQueue.global().async? How can we address this problem in a holistic way in our app, as it's a very simple mistake to make (with very bad consequences) while we migrate off GCD? I'm sure the broader answer here is "don't mix GCD and Concurrency", but unfortunately that's a little unavoidable as we migrate our large legacy code base! 🙂

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

Hello, I’m building an app that helps people spend less time on social media apps. For that, I make heavy use of Apple’s Screen Time APIs, such as ManagedSettings and FamilyControls. When an app is locked using a ShieldConfiguration, the user has to open my app in order to unlock it (e.g. enter a code). This is very cumbersome because no documented API exists to open the parent app (=my app) from the ShieldActionDelegate (also part of my app) when the user presses a button of the ShieldConfiguration. The ShieldActionDelegate callback just offers three options in its ShieldActionResponse: .none .defer .close .openParentApp is missing. We are working around this limitation by sending a local push notification that the user has to tap on. This has multiple drawbacks: It has to be ensured that notification permission has been granted. It has to be ensured that notifications can be delivered even while focus is enabled. Features such as Apple Intelligence notification summaries and notification prioritization can heavily delay delivering notifications and thus frustrate the user. Neither my users nor myself do understand why this is not possible in a smoother way, at least according to the documentation. There are 3rd party apps that have such functionality, they can directly open their own app from a button press in the Shield, see here: https://apps.apple.com/us/app/applocker-passcode-lock-apps/id1132845904 It would be great if Apple could level the playfield for all developers and document how this is achievable, because technically it clearly is. Thanks a lot and have a great day!

My use case is the following: Every user of my app can create as an owner a set of items.  These items are private until the owner invites other users to share all of them as participant. The participants can modify the shared items and/or add other items. So, sharing is not done related to individual items, but to all items of an owner. I want to use CoreData & CloudKit to have local copies of private and shared items. To my understanding, CoreData & CloudKit puts all mirrored items in a special zone „com.apple.coredata.cloudkit.zone“. So, this zone should be shared, i.e. all items in it. In the video it is said that NSPersistentCloudKitContainer uses Record Zone Sharing optionally in contrast to hierarchically record sharing using a root record. But how is this done? Maybe I can declare zone „com.apple.coredata.cloudkit.zone“ as a shared zone?

Just wanted to clarify some expected behaviors here. It seems that there are two distinct behaviors for Live Activity flows for freshly installed apps. When you start a Live Activity for the first time and the user hasn't yet clicked on Allow/Don't Allow in the activity interface, there are two different sequences: Starting a Live Activity locally Request a Live Activity locally via Swift Live Activity starts .pushTokenUpdates is immediately triggered, even if the Allow/Don't Allow buttons appear under the Activity UI Starting a Live Activity via push-to-start Send a push-to-start notification to launch a Live Activity Live Activity starts .pushTokenUpdates is not triggered, and .pushToken returns nil. If a user clicks on Allow in the Activity UI, only then is .pushTokenUpdates triggered.

Will UVC native support come for the Iphone as well? So, using external cameras with the ipad is greatly beneficial, but for the iphone, it can make it a production powerhouse! So, have there been discussions around bringing UVC support for the Iphone as well? and if so, what were your conclusions?

We have an application, which activates two network extensions (Content Filter, Transparent Proxy) during app launch which is written in Swift. When we are activating multiple network extensions under the same app bundle, in Ventura and Sonoma, under Privacy and Security it shows "Details" button. On click of it we see below issues: - It shows the app bundle name instead of respective network extension bundle name. - On click of OK button, it adds only one extension under "Network -> Filters -> Filters & VPN" and only after machine restart, we can see both the extensions under this screen. These issues are not seen in Sequoia. In Sequoia, it shows the extension names under the app name. There are separate controls to enable/add each of the extension. Attached the screenshots of Sonoma and Sequoia for reference Already submitted the feedback ticket. (FB16331169)

We persist ApplicationTokens in a storage container that ShieldConfigurationExtension has access to. In rare, cases all the ApplicationTokens for a user seem to change. We know this because the Application parameter passed into configuration(shielding application: Application) -> ShieldConfiguration function has a Token that does not match (using == ) any of the ones we are persisting in storage. Interestingly, the persisted ones still work, so I don't believe storage has gotten corrupted or anything. We can use them to add or remove shields, we can use them to display labels of the apps they represent, etc. But they don’t match what’s passed into the ShieldConfiguration extension. If the user goes into the FamilyPicker at this point and selects an app of a token that we are already persisting, the FamilyPickerSelection will have a token matching the new one that is passed into ShieldConfigurationExtension, not the one we persisted when they last selected that app. This leads me to believe the tokens are updated/rotated in some cases. When and why does this happen, and how can we handle it gracefully?

After the macOS Sequoia update, my app seems to have an issue with Bluetooth communication between macOS and iOS that uses CoreBluetooth for Central-Peripheral communication. Setup: The iPhone (in my case: iPhone 14 Pro with iOS 18.0 (22A3354)) acts as the Central, and the Mac (in my case: 14" MacBook Pro 2023 with macOS 15.0 (24A335)) as the Peripheral. I’ve implemented a mechanism where the Central (iPhone) sends a message to the Peripheral (Mac) every 15 seconds to keep the connection alive (Because it needs to wait for notify characteristic updates). I never noticed this kind of issue before, but with macOS Sequoia I get it permanently. Issue: The connection drops unexpectedly after a period of time (sometimes 20 seconds, sometimes a few minutes) with CBErrorDomain - code 6: The connection has timed out unexpectedly. Sample Code: Peripheral (Mac): ContentView (Peripheral).txt ContentViewModel (Peripheral).txt Central (iPhone): ContentView (Central).txt ContentViewModel (Central).txt Reproduce: I attached sample code including the Central-Sample (for iPhone) and Peripheral-Sample (for Mac). Just run the Peripheral-Sample (after granting Bluetooth permissions). Then run the Central-Sample and select the Mac device in the list After selecting it should connect, discover the service & characteristic and should start writing messages to it. After some time the func centralManager(_ central: CBCentralManager, didDisconnectPeripheral peripheral: CBPeripheral, error: (any Error)?) {should get called with timed out unexpectedly error. Could anyone please look into this issue and advise on whether there’s a known bug or any workaround? Any guidance would be greatly appreciated, as this impacts the stability of Bluetooth communication between the devices. Thanks in advance. Logs: I also ran the console.app during this issue which got these errors (if this is helpful): console_logs.txt

Hi there 👋🏻 We are facing an issue that started on 24 June 2025 where some users that have an active subscription with an offer are not being able to use/restore their subscription since Transaction.currentEntitlements is empty. We have tried to call the server with this endpoint https://developer.apple.com/documentation/appstoreserverapi/get-transaction-history and it's returning the correct transactions correctly. Any idea what is happening?

Hi everyone, I am having issues with all my MacOS devices (3 so far) and push notifications. My app is in development and when i send a Test APN (From the Push Notification Console) to any of my MacOS devices (using the device token), the log is "discarded as device was offline". Fun fact, if i run the command : sudo kill apsd I receive the previously "discarded" Push notification immediately. Is it a known bug or something is wrong in my configuration ? Note : my debugProfile.entitlements is fine and the value is set to "development", i have already reloaded my certificate by cleaning the project and rebuilding (according to ChatGPT) but nothing works... I am using Xcode 26.0.1 and MacOS 26.0.1 on my 3 different MacOS devices all having this issue. Thanks in advance, Tom

I’m hitting a WeatherKit JWT failure (WDSJWTAuthenticatorServiceListener Code = 2) at runtime even though the entitlement is present in both the signed binary and the embedded provisioning profile. Environment Team ID 5SZLQLQ9MD Bundle ID ParkProfessor.ParkProfessorDisneyland Device / OS iPhone 15 Pro · iOS 17.4.1 (hardware, not simulator) Xcode 15.3 (15E204a) Console output Failed to generate jwt token for: com.apple.weatherkit.authservice Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" Entitlement & profile snippets codesign -d --entitlements :- WeatherKitTest.app | grep -A2 weatherkit com.apple.developer.weatherkit security cms -D -i embedded.mobileprovision | grep -A2 weatherkit com.apple.developer.weatherkit What I’ve already tried Regenerated a new development certificate and a new iOS App Development provisioning profile with WeatherKit enabled. Confirmed the capability is selected in Certificates ▸ Identifiers ▸ Profiles and added in Xcode target settings. WeatherKit Terms of Service accepted in the portal. Deleted the app, removed any device management profiles, rebooted the phone, clean-built & ran again. Reproduced the issue in a minimal SwiftUI app that calls: WeatherService.shared.weather(for: CLLocation(latitude: 33.8121, longitude: -117.9190), including: .current) – same Code 2 error. Request It looks like the App ID may need a backend entitlement sync. Could someone from the WeatherKit team please check the status for Team 5SZLQLQ9MD, Bundle ID ParkProfessor.ParkProfessorDisneyland and enable WeatherKit token generation? Thanks!

All of my apps stopped working with WeatherKit this morning. They all return an "Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2" error. I am certain that the WeatherKit capability added (in project) and enabled as a Capability & App Service (on developer portal for the identifier). All other iCloud features of my apps are working as expected. I have also done all the normal troubleshooting using codesign / security cms, etc. to verify entitlements. I created the following simple project to verify the integration. import WeatherKit import CoreLocation struct ContentView: View { @State private var temp: Measurement<UnitTemperature>? = nil var body: some View { VStack { if let t = temp { Text("\(t.value.rounded())°\(t.unit.symbol)") } else { Text("Fetching…") .task { let service = WeatherService() do { let location = CLLocation(latitude: 50.318668, longitude: -114.917710) let weather = try await service.weather(for: location, including: .current) temp = weather.temperature } catch { print("Error:", error) } } } } } } Any ideas what may be happening?

When a VPN is active, RCS messaging does not work on iOS 18. I work on an iOS VPN app, and we were very appreciative of the excludeCellularServices network flag that was released during the iOS 16 cycle. It's a great solution to ensure the VPN doesn't interfere with cellular network features from the cellular provider. Separately - As a user, I'm excited that iOS 18 includes RCS messaging. Unfortunately, RCS messaging is not working when our VPN is active (when checking on the iOS 18 release candidate). My guess is that RCS is not excluded from the VPN tunnel, even when excludeCellularServices is true. It seems like RCS should be added in this situation, as it is a cell provider service. Can RCS be added as a service that is excluded from the VPN tunnel when excludeCellularServices is true? (I've also sent this via feedback assistant, as 15094270.)

Our app includes showing external web service with WebView or Safari and returning to the app with custom URL scheme or universal link. When we set "Hide and Require Face ID" feature which was available on iOS 18, neither custom URL scheme nor universal link activated the app. If we only set "Require Face ID", the deep link worked properly. Here is what we've tried: Define custom URL scheme or universal link in the app https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app https://developer.apple.com/documentation/xcode/supporting-universal-links-in-your-app Implement external web service with one of the following frameworks ASWebAuthenticationSession https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession/ SFSafariViewController https://developer.apple.com/documentation/safariservices/sfsafariviewcontroller Safari WKWebView https://developer.apple.com/documentation/webkit/wkwebview On iOS 18 device, install the app and set "Hide and Require Face ID" Access external web page and tap the link which activates custom URL scheme or universal link We expected the deep link to work, but the results were: Custom URL scheme &amp;amp; ASWebAuthenticationSession/SFSafariViewController/Safari The system shows "Cannot open the page because the address is invalid" Custom URL scheme &amp;amp; WKWebView Nothing happens when tapping the link Universal link Directed to the server with associated domain file, but the system doesn't call the app which is defined in the associated domain file We tested the feature with the app built with Xcode16 beta 6, and the device with iOS 18 Seed 8(22A5350a). Does hide app feature support custom URL scheme and universal link?