Hi everyone, I have a question regarding App Store subscriptions and tax country / storefront changes. If a customer originally purchased a subscription while their App Store country was France (so we reported France as the tax country), and later updates or renews that same subscription while located in Hungary, which country should we report going forward? Should we continue using the original country (France)? Or should we start sending the new country (Hungary) once it changes? Also, what happens if the customer changes their App Store region entirely, for example from France to the US? How is Apple’s commission calculated after the region change? If anyone has experience with this scenario or knows the official Apple behavior, I’d really appreciate your help. Thanks!

I've already submitted multiple cases about this issue. My Family Controls Distribution request was apparently approved (or I was told via Developer Support) for my Shield Action & Shield Configuration extensions, but the Distribution option still does not appear in the identifiers. This is blocking my ability to distribute via TestFlight. I need someone who can update the identifier capabilities or explain why the approved capability is not showing.

My Entitlements file contains the following (removed some non related entries): <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.developer.associated-domains</key> <array> <string>webcredentials:app.mydomain.org</string> <string>applinks:*.mydomain.org</string> </array> </dict> </plist> Now when I tap on a link such as abc.mydomain.org, the app is not opened. If I change the generic applinks key from *.mydomain.org to a specific domain, this works correctly and it opens the app as expected. (This makes me think the website part of the AASA file is correct). Since I need to support a lot of subdomains (think about hundreds in the near future), I really need the wildcard to work. Do you have any tips on how to make this work?

I enabled the WeatherKit capability on my App ID (com.saimcan.darkweather, Team 6SWSD6V4ZC) about 12 hours ago. The entitlement is embedded in the binary and the provisioning profile authorizes it, but every request fails at the JWT generation step. Error from the logs: Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" Relevant log excerpt (iOS 26.4 Simulator, same result on a physical device): [AuthService] Calling process is 3rd party process and has the correct entitlement ... accepting the connection [AuthService] Received proxy request for generating a jwt token. url=https://weatherkit.apple.com [WeatherDataService] Starting to generate JWT token request. bundleIdentifier=com.saimcan.darkweather [AuthService] Signed successfully [WeatherDataService] Make new JWT token request. requestIdentifier=... [AuthService] Failed to generate jwt token ... Code=2 What I have verified: Active Apple Developer Program membership (renewed through April 2027) All agreements accepted WeatherKit capability enabled on the App ID codesign -d --entitlements confirms com.apple.developer.weatherkit in the built binary embedded.mobileprovision also includes com.apple.developer.weatherkit App Group (group.com.saimcan.darkweather.shared) correctly bound to both the app and widget App IDs Since "Signed successfully" is logged, the device-side auth plumbing is working. The rejection appears to be server-side. Could someone from the WeatherKit team check whether JWT minting is enabled for this Team ID / Bundle ID? Team ID: 6SWSD6V4ZC Bundle ID: com.saimcan.darkweather

Hi I am trying to implement a minimal DeviceActivityReport extension. Setup: iOS app with FamilyControls authorization (status = approved) DeviceActivityReport displayed in SwiftUI Report extension embedded in PlugIns Correct NSExtensionPointIdentifier: com.apple.deviceactivityui.report-extension No NSExtensionPrincipalClass or storyboard Entitlements: com.apple.developer.family-controls com.apple.developer.family-controls.app-and-website-usage The app installs and runs correctly. Authorization is granted. However, the extension is never loaded: No logs from the extension (init/body/makeConfiguration never called) Console shows: "Failed to discover the client's extension: DeviceActivityReportService... ClientError Code=2" Environment: Xcode 16.2 iOS device running iOS 18.x (latest available) The .appex is correctly embedded and signed. Question: Is there a known issue with DeviceActivityReport extensions not being discovered at runtime with this setup? Is additional configuration required beyond NSExtensionPointIdentifier? Thanks

Hi, We have implemented Age Verification in iOS and wanted to test the workflow before releasing the app. How do we test the app before releasing it in production. We currently use Test Flight for testing. We created users in Sandbox but that shows just Texas in Age Assurance.

hello last year at the WWDC Apple announced a app extension for audio playback in CarPlay for iOS apps is there a guide to add this feature because whenever I open my custom music I can hear the music playing trough the car's speakers and I see the album art, but I have no controls on the display of the car the person I white this app for is a indie producer who wants his huge collection to be available for people to enjoy there is no subscription of login

Just curious if there is anyway to expedite the FamilyControl entitlement. I have seen few people stuck in this step for few days. I submit mine on the 4/18, and my Case ID: 102874096254 Just want to see if I can see any estimate time for my request. Thanks, Jing

I would like to enable the app to persist a stable SIM identifier and compare it across app sessions so it can reliably detect when the user has changed SIM cards. When a SIM change is detected—especially while the device is on Wi-Fi—the app should trigger SIM-change handling (for example: refresh auth/session, reload account-specific data, and update feature availability). The implementation must be robust for: Dual-SIM and eSIM devices Temporary network unavailability or delayed carrier info Current challenge: On Wi-Fi, the existing hash can distinguish a different operator but cannot reliably detect a SIM-card-level change. We need a way to uniquely identify the SIM card itself, not just the operator.

Dear Screen Time Team! The Screen Time passcode can be brute-forced without rate limiting by repeatedly attempting guesses through the "Erase All Content and Settings" flow. This allows unlimited passcode attempts with no delay, lockout, or escalation, effectively defeating the purpose of the Screen Time passcode as a parental control mechanism. Impact: Children can bypass Screen Time protections by guessing the passcode No rate limiting enables trivial brute-force attacks (especially for 4-digit codes) Undermines trust in Screen Time as a parental control system Creates real-world safety risks for families relying on Screen Time restrictions Publicly shared methods (e.g. on TikTok) increase likelihood of widespread abuse Steps to Reproduce: Enable Screen Time and set a passcode Open Settings → General → Transfer or Reset iPhone → Erase All Content and Settings When prompted for the Screen Time passcode, enter an incorrect code Repeat the process with different guesses Expected Result: After a small number of incorrect attempts, the system should: enforce exponential backoff delays, or temporarily lock further attempts, or require Apple ID authentication Attempts should be rate-limited across system flows Actual Result: Unlimited passcode attempts are allowed No delay, lockout, or penalty is applied Enables rapid brute-force guessing of the Screen Time passcode Notes: This appears to bypass standard passcode protections that exist in other parts of iOS The issue is especially severe for 4-digit Screen Time passcodes (10,000 combinations) The attack surface is exposed through a system-level reset flow Suggested Fix: Introduce global rate limiting for Screen Time passcode attempts across all entry points Apply exponential backoff after failed attempts Require Apple ID authentication after multiple failures Consider enforcing 6-digit minimum passcodes for Screen Time Log and unify attempt counters across system components Severity: Critical (Security vulnerability enabling brute-force of parental control passcode) See TikTok: https://www.tiktok.com/@aldanaisthebest12170/video/7615053429500644621 Feedback request: FB22263276 – Frederik (one sec app)

Dear Screen Time Team! The current 6 MB memory limit for the DeviceActivityMonitor extension no longer reflects the reality of modern iOS devices or the complexity of apps built on top of the Screen Time framework. When Screen Time APIs were introduced with iOS 15, hardware constraints were very different. Since then, iPhone performance and available RAM have increased significantly…but the extension memory limit has remained unchanged. My name is Frederik Riedel, and I’m the developer of the screen time app “one sec.” Our app relies heavily on FamilyControls, ManagedSettings, and DeviceActivity to provide real-time interventions that help users reduce social media usage. In practice, the 6 MB limit has become a critical bottleneck: The DeviceActivityMonitor extension frequently crashes due to memory pressure, often unpredictably. Even highly optimized implementations struggle to stay within this constraint when using Swift and multiple ManagedSettings stores. The limit makes it disproportionately difficult to build stable, maintainable, and scalable architectures on top of these frameworks. This is not just an edge case…it directly impacts reliability in production apps that depend on Screen Time APIs for core functionality. Modern system integrations like Screen Time are incredibly powerful, but they also require a reasonable amount of memory headroom to function reliably. The current limit forces developers into fragile workarounds and undermines the robustness of apps that aim to improve users’ digital wellbeing. We would greatly appreciate if you could revisit and update this restriction to better align with today’s device capabilities and developer needs. Thank you for your continued work on Screen Time and for supporting developers building meaningful experiences on top of it. Feedback: FB22279215 Best regards, Frederik Riedel (one sec app)

Sign-in with Apple suddently broke in my App. The button trigger the system Apple sign in modal, I can sign in without errors but then nothing happens on my App. It seems it never goes in the onCompletion. SignInWithAppleButton( .signIn, onRequest: { }, onCompletion: { // Never get called } ) The button is inside a custom modal.

Hello, I am researching the technical feasibility of developing a Default Dialer App for the EU market using the specific entitlements granted under the Digital Markets Act (DMA). Our primary goal is to implement a Cellular/VoLTE-based calling system—not mVoIP—and we need to clarify whether it is possible to provide features such as STT (Speech-to-Text) and Call Summarization, which require In-call Audio Recording. Regarding the Default Dialer App Entitlement in the EU, I would like to clarify the following: Access to Raw Audio Stream: When an app is granted the Default Dialer status in the EU, does it gain programmatic access to the downlink and uplink audio streams of a cellular/VoLTE call for recording purposes? LiveCommunicationKit & Recording APIs: Does LiveCommunicationKit (or any related framework for iOS 26) provide specific APIs for a third-party dialer to capture native telephony audio? Entitlement Scope for Partners: If an EU-based partner obtains the necessary entitlements, can those entitlements be used to grant our application the authority to process cellular calls and access the associated audio data? Recommended Implementation: Are there any Apple-sanctioned methods or specific frameworks for implementing call recording for AI-driven services within the scope of the new EU-specific regulations? We need to confirm these technical boundaries to establish the implementation scope with our EU partners. Any guidance on whether a third-party app can technically and legally record cellular calls under these specific conditions would be greatly appreciated. Thank you.

Hello, I am researching the technical feasibility of developing a Default Dialer App for the EU market using the specific entitlements granted under the Digital Markets Act (DMA). Our primary goal is to implement a Cellular/VoLTE-based calling system—not mVoIP—and we need to clarify whether it is possible to provide features such as STT (Speech-to-Text) and Call Summarization, which require In-call Audio Recording. Regarding the Default Dialer App Entitlement in the EU, I would like to clarify the following: Access to Raw Audio Stream: When an app is granted the Default Dialer status in the EU, does it gain programmatic access to the downlink and uplink audio streams of a cellular/VoLTE call for recording purposes? LiveCommunicationKit & Recording APIs: Does LiveCommunicationKit (or any related framework for iOS 26) provide specific APIs for a third-party dialer to capture native telephony audio? Entitlement Scope for Partners: If an EU-based partner obtains the necessary entitlements, can those entitlements be used to grant our application the authority to process cellular calls and access the associated audio data? Recommended Implementation: Are there any Apple-sanctioned methods or specific frameworks for implementing call recording for AI-driven services within the scope of the new EU-specific regulations? We need to confirm these technical boundaries to establish the implementation scope with our EU partners. Any guidance on whether a third-party app can technically and legally record cellular calls under these specific conditions would be greatly appreciated. Thank you. Access to Raw Audio Stream: When an app is granted the Default Dialer status in the EU, does it gain programmatic access to the downlink/uplink audio streams of a cellular call for recording purposes? LiveCommunicationKit & Recording: Does LiveCommunicationKit provide any specific APIs or delegates that allow a third-party dialer to capture call audio, or is the recording still restricted by the system’s sandbox? Entitlement Scope: If our EU partner obtains the necessary entitlements, can they authorize our application to handle the cellular call processing entirely, including the access to telephony audio data? AI Service Implementation: Are there any Apple-recommended ways to implement AI features (STT, Summarization) within a Default Dialer App without violating current iOS security architectures? We need to provide a clear "Feasibility Report" to our EU partners during upcoming meetings. Any technical guidance on whether a third-party app can legally and technically record cellular calls under this new EU-specific policy would be extremely helpful. Thank you.

Hello, I’m developing an Apple Watch companion app for my swimming application and the app keeps uninstalling/disappearing from Apple Watch. I have a specific Scheme to install it to my watches, it appears there, I can debug but after a while it disappears. It’s my first app for this device but it doesn’t seem normal to me. any idea?

I’m running an experiment around generating and importing .vcf files on iOS and wanted to sanity check expected behavior with others who may have explored this deeper. Goal Programmatically generate a vCard (v3.0) that, when imported into iOS Contacts, includes: Standard fields (name, phone, email, organization, etc.) Contact photo (PHOTO) Social profile (e.g., LinkedIn via X-SOCIALPROFILE) What I tested I tried to eliminate formatting issues by using iOS itself as the source of truth. Steps: Created a new contact directly in iOS Contacts Added name, phone, email Added a contact photo Added a social profile (LinkedIn) Exported that contact as a .vcf Deleted the contact from the device Re-imported the exported .vcf Result Core fields (name, phone, email, etc.) are restored correctly Contact photo is NOT restored Social profile is NOT restored as a native social entry This happens even though: The exported .vcf clearly contains a PHOTO field The exported .vcf includes X-SOCIALPROFILE;type=linkedin:... Additional testing I also generated my own .vcf files that closely mirror the structure produced by iOS (field order, encoding, etc.), and observed the same behavior: Photo does not reliably import Social profiles do not appear as native social entries in Contacts Question Is this expected behavior on iOS? More specifically: Are PHOTO fields intentionally ignored (or restricted) during .vcf import? Is X-SOCIALPROFILE supported for import, or only used internally/exported by Contacts? Is there any supported way to programmatically create a contact with: a photo social profile entries via .vcf import? Current understanding Based on testing, it appears that: iOS may export more data than it will accept on import Some fields (like social profiles and possibly photos) may only be fully supported when created via native APIs (e.g., Contacts framework) rather than .vcf Would appreciate confirmation or any documentation pointers if this is known behavior or if there are recommended alternatives. Closing thought If this is by design, it would be helpful to know which vCard fields are officially supported for import vs. export on iOS, since the current behavior is not entirely symmetric.

Hi, we have several clarification questions on how SensorKit collect phone call/text message data: when people use non-native apps, e.g. WhatsApp, to make calls or messages, will they be picked up as phone call or text message by SensorKit, or will they only be counted as app usage? When people react to a message by long-press the message and thumb-up/heart it, will it be counted as one outgoing message or not? If the incoming call is not picked up, will it be counted as one phone call or not? When people text within a group, will the unique number of contacts be 1 or the number of members in the group? Thanks! Yu

Hi folks, in my application I write some logs over debugPrint or directly over print. The application is already distributed and some part of functionality failed with application traceback. I would like to ask user for providing logs from the App. Is it possible to get those logs? Thanks Petr

Hi Apple Support, We're reaching out to clarify what appears to be unexpected behavior in the AdServices token attribution API, specifically around reinstall attribution for apps with high reinstall rates. The problem For an app with a high reinstall rate, our ASA install counts are significantly higher than what the Apple Ads dashboard reports. Total install counts across all sources match closely — the discrepancy is specifically in ASA-attributed installs. What we tested To investigate, we ran a controlled experiment: Installed an app by tapping an Apple Search Ads ad. Deleted the app. Reinstalled the app approximately 15 minutes later directly from the App Store, without tapping any ad. Fetched a new AdServices token and exchanged it with Apple's attribution API. The API returned attribution: true with the original campaign details (same campaignId, adGroupId, keywordId) and conversionType: Download. The reinstall was attributed to the ASA campaign even though the user did not interact with any ad before the second install. Question about documentation The Apple Ads help page defines a tap-through Redownload as: "A redownload is when a user downloads your app, deletes it, then downloads it again on the same device or a different one following an ad tap." Could you clarify: does "following an ad tap" mean the redownload must be directly triggered by a tap on an ad? Or does it mean any redownload that occurs within the 30-day attribution window of a prior ad tap? Question about intended token API behavior Is the AdServices token API intended to return attribution: true for installs where the user did not tap an ad before that specific install, but had interacted with an ad within the past 30 days? In other words, is the token API designed to attribute all installs within the 30-day window regardless of whether the current install was ad-driven, or should it only attribute installs that were directly preceded by an ad interaction? We would appreciate any clarification on the intended behavior, as this directly impacts how we reconcile install counts between the AdServices API and the Apple Ads dashboard. Thank you for your time.

There appears to be a data loss bug in NSFileWrapper on macOS 26.4. It may have been around longer but I just never noticed ... So I write a RTFD file wrapper: NSFileWrapper *rtfd = [attributedString RTFDFileWrapperFromRange:NSMakeRange(0, attributedString.length) documentAttributes:@{NSDocumentTypeDocumentAttribute:NSRTFDTextDocumentType}]; Now IF I use -writeToURL:options:originalContentsURL:error: without using the NSFileWrapperWritingAtomic option and I pass in an existing URL, the followings happens: -The method returns NO and populates the NSError with NSFileWriteFileExistsError, as expected. This is what I want. -BUT the existing file is nuked. It just disappears. Foundation kills it. Poof. Another thing I gotta workaround. Getting pretty ridiculous, I must say. Just my lucky day I guess. It would be wonderful if I could work on my own features and fixing my own bugs.