Hey guys! I've recently noticed a number of PaaS'es and CPaaS'es offering bulk outgoing messaging using the iMessage the same way it's done with the SMS. I always thought that iMessage sort of only allowed businesses to send outgoings subject to user contacting their account first (to avoid being spammed). But then there's those I mentioned above. Have you faced anything like this? Did Apple make changes to the model so that businesses can now initiate conversations with users? If so, how does it work?

I am trying to port my sandboxed macOS app completely over to iOS using a Catalyst target and SwiftUI. There appears to be an issue when trying to drag to the Finder in Catalyst (and in SwiftUI in General). For some reason, the Finder will not accept multiple file drops, only a single file. On my macOS (non-Catalyst AppKit target), I overcame this by dropping multiple files to a UTType of .folder, and the OS accepted the folder. This workaround is not available for iOS because .folder is a macOS-only option. I have a test app to illustrate the issue. Hopefully someone can help. Download Test App

在watchOS11.5下，Apple watch无法加载天气。无论是否连接自己的iPhone均无法加载

Hi Apple Developer Community, I'm implementing MetricKit launch performance tracking in our iOS app and need clarification on two properties: histogrammedTimeToFirstDraw histogrammedOptimizedTimeToFirstDraw The Documentation Problem: The official MetricKit documentation provides minimal explanation of these properties beyond their names. Based on naming conventions, I initially assumed: histogrammedTimeToFirstDraw = cold launches histogrammedOptimizedTimeToFirstDraw = warm/optimized launches Based on our measurements: The “optimized” metric appears only in a small fraction of launches The "optimized" metric is actually slower The naming suggests the opposite behavior Questions: What specific launch conditions does each metric measure? Why would "optimized" launches be slower and less frequent? Is histogrammedOptimizedTimeToFirstDraw related to iOS app pre-warming or prediction features? If these metrics don’t correspond to cold vs. warm launch times, is there an alternative way to measure them accurately? Any clarification from Apple or insights from developers who've tracked these metrics would be greatly appreciated.

Hello, Because our app package size is relatively large, part of our resources needs to be delivered through Apple-hosted asset packs. If we use the Background Assets framework to download these Apple-hosted packs, our app would only be able to support devices running iOS 26 or later. To maintain compatibility with a broader range of iOS versions, we chose to use iOS On-Demand Resources instead. However, during actual use, we found that even when these packs are marked with the initial install tag, there is still a fairly high probability (around 40%) that they are not available on the first screen after the app is launched for the first time. When we try to access them through conditionallyBeginAccessingResourcesWithCompletionHandler, the resources are unavailable, which forces us to download them again. During testing, we added event tracking and found that out of 22 users who downloaded the app, 9 had to re-download these resource packs on first launch. Each of these packs marked with the initial install tag is about 300 MB in size. We have also made sure to follow the NSBundleResourceRequest limitation that no more than 2000 × 1000 × 1000 bytes of resources should be accessed at the same time. We would like to understand why these packs, even though they are marked as initial install, still have such a high probability (around 40%) of being unavailable on the first screen at first launch.

Hi, We are currently in the process of getting an custom iAP2 device communicating via USB-C. We have been using the 'EADemo' app as a test app to ensure full function before certification. Currently, the device completes the authentication and identification successfully. The device appears within the 'EADemo' app, and we are able to select it and see the available protocol. Selecting the protocol sends the EAStartSession command to the accessory and we ACK it. This is where the issues begin. Attempting to send either a string or hex packet results in nothing being sent. The app does not appear to attempt to send a packet when these are pressed. The 'EADemo' app also does not increment its receive counter when the accessory sends an EA packet, but we do receive the ACK from the device. This indicates the device is receiving the packet, but not processing it in app. Sending the EASessionStatus from the accessory with a status of okay does not change the behavior. Sending the EASessionStatus packet from the accessory with a status of closed results in the device sending an EAStopSession packet. The issue does not appear to be with the accessory or the underlying transport layer. Previous attempts to contact MFi support resulted in them referring me to developer support. Are there any known issues within the 'EADemo' app that we should know about/and or need to fix? Does Apple have any other EA example application? Are there any other publicly avalilbe EA examples that Apple would recommend us trying? Thanks, Mike

Hey there, I have an app where I create custom Advanced App Clip Experiences for other businesses which seems to be a valid thing. I do create them via API. Upon creation everything looks fine: when I go to App Store Connect -> App -> Advanced App Clip Experiences, I do see the new App Clip Experience I've just created. Their status is Received (as any other active experiences) and have a custom URL. The issue is weird timing when the Advanced App Clip Experience actually becomes available on the iPhone (can be triggered via App Clip Code, etc). Some experiences become available literally immediately but others take days (some take 1-2 days, some take ~5 days). I'm not sure why there's a bid difference for an Advanced App Clip to be actually active. Does anyone have any kind of experience with that? I don't change domain settings, app's settings, etc. I'm just creating a new experience (both via API or manually at App Store Connect) and I do have different "activation" times for different App Clips. Same when I delete an Advanced App Clip Experience, it will still be available for next couple days. I get there might be caching stuff, etc. But the difference is quite huge and makes no sense since as I've mentioned some clips become available immediately but some takes days to be available. Thank you!

testing

Hello, I am the developer of an app called one sec which helps users to spend less time on social media: https://one-sec.app Therefore, we make heavy use of the Screen Time API, and thus ManagedSettings and ShieldActionDelegate. One feature of one sec is the so-called “Doom Scroll Emergency Brake”. This blocks a target app after a certain usage threshold (e.g. 5 minutes) and requires going through an intervention (e.g. breathing exercise) to unlock more time. That added friction makes it very effective in reducing time spent on apps. One thing that is confusing for our users is the way they are prompted to unlock more time, if they want to. They have to: Have Push Notifications enabled for one sec Exempt one sec’s notifications from being delayed by AI prioritization (otherwise they are delayed by ca. 10s) Ensure that push notifications can be delivered during foci. Understand that they have to tap on the notification, which is not very straight-forward because it does not make sense from the user’s UX perspective. This is an artificial limitation of Apple’s screen time framework which has no reason (no security / privacy implications here…). Screenshots of the current flow attached. If would be much more reasonable if there was a new ShieldActionResponse.openParentApp value that can be returned from the completion handler of the ShieldActionDelegate.handle(…) callback. We have seen different apps use private API to achieve this, but we are afraid to do the same to avoid getting banned from the App Store. It would be fair if Apple would level the playground for all apps and offer such an API officially. – Frederik PS: Tracked under FB22347946, FB18846650, FB15500681, FB15079668, FB10393561 (all without responses so far…)

Hello, I submitted a request for the Family Controls (Distribution) entitlement, but haven't received status update regarding approval/rejection etc. I submitted a previous contact support ticket as well. I'm wondering the timeline and also if my request went through - currently it says 'submitted' but it's remained this way for a while... I've had other developers in communities saying they were approved earlier, so curious if it's an app issue. Thank you

How can I use the Screen Time API to set a restriction for a child account from my app running on the parent’s account?

We’ve been implementing LiveCallerId using OHTTP and have hit a wall with the production environment. The setup works perfectly in TestFlight, but the release version of the app is consistently being rejected by the Apple OHTTP Relay when trying to tunnel traffic to our gateway. Timeline & Status: Applied via the form in September 2025. Received confirmation in November 2025 that our /.well-known/ohttp-keys endpoint was correctly configured. Since then, we've struggled to get a dialogue with Apple to confirm the final production whitelisting. Technical Observations: Our ohttp-keys endpoint is being polled frequently (every few minutes). Based on the traffic, this is clearly the Apple Relay infrastructure fetching/refreshing the keys, not the devices themselves. This suggests the Relay "sees" our configuration, yet it still refuses to tunnel traffic to our gateway in the production environment. Since everything is functional in TestFlight, our implementation seems correct. It feels like there is a configuration mismatch or a missing "production flip" on the Relay side for our Bundle ID. If anyone from the Apple engineering team could verify the status for this Bundle ID, it would be a huge help. We've been stuck in this "TestFlight-only" state for quite a while now.

Steps To reproduce: Login to application and App has joined the PTC channel. Push the application to background and Lock the device. From the System UI press the talk button which will start transmit. Audio Session has been activated and Audio unit has been initialised properly. On terminator side no media is being played out. Issue observed consistently on specific models which has configured audio codec with Stereo type. More details are added : FB20281626

Hi everyone, I’m currently developing a parental control app that uses the Screen Time API (FamilyControls, ManagedSettings, DeviceActivity). I have a question regarding the customization limits of the Shield UI in ManagedSettingsUI. From the documentation, I understand that we can customize the ShieldConfiguration (background color, blur style, icon, title, subtitle, button labels, etc.). However, I’d like to clarify a few points before finalizing the design: 1. Is it allowed (or technically possible) to display custom media content, such as videos, animations, or interactive elements, inside a custom Shield? 2. Are there limitations on the text length for the title and subtitle fields (e.g. maximum number of characters, multiline support, truncation behavior)? 3. Can the Shield be personalized per user (for example, showing a different title or color scheme based on user preferences or device state)? 4. Are there App Store Review restrictions or UI guidelines that define what a Shield should or should not contain (for instance, whether the Shield can resemble a mini-app experience)? I want to ensure that the implementation fully complies with Apple’s technical and design expectations before submission. Thanks in advance for any official clarification or best practices on how far we can go with Shield customization! Best regards, Ferdinand

We now know the IsEligibleForAgeFeatures API is NOT returning True in Brazil at least 2 days past compliance date, and we don't know if that's the right API, or how it behaves. Folks here: Is there anyone here from Brazil who has tested out this 26.4 API? Has anyone tested out the regulatory feature API? Does it return something like declaredAgeRangeRequired? I don't know how to test it in Brazil without sandbox/physically in Brazil. Much appreciated!!

I am implementing an Unwanted Communication Reporting Extension (IdentityLookupUI) to allow users to report spam messages to our backend. The extension works perfectly in terms of data collection and network reporting (using ILClassificationExtensionNetworkReportDestination). However, I’ve encountered an issue with the message lifecycle: whenever the user taps "Done" and I return a response, the system automatically moves the reported message to the Recently Deleted folder. I want to report the data but keep the message in its current folder (especially when the user classifies it as "Safe"). I have tried varying the ILClassificationAction, but it seems the system ignores the action in favor of "cleaning up" the thread. Example of my current implementation: override func classificationResponse(for request: ILClassificationRequest) -> ILClassificationResponse { // Even when returning .none or .reportNotJunk let action: ILClassificationAction = (self.type == "spam") ? .reportJunk : .none let response = ILClassificationResponse(action: action) response.userInfo = ["type": self.taggedType, "sender": self.sender] return response } My Questions: Is there a specific ILClassificationAction or userInfo key that tells iOS not to move the message? Is this movement a mandatory "post-report cleanup" behavior of the IdentityLookup framework that cannot be overridden? Does anyone know a workaround to report the communication while maintaining its original location in the Messages app?

Hi, I’m building an iOS app called SocialLite using Apple’s Screen Time APIs, primarily FamilyControls and ManagedSettings. My goal is to block access to the Instagram app itself, while still allowing the user to receive and see Instagram notifications. Right now, when I apply the shield/block using the Screen Time API, the Instagram app is blocked as expected, but its notifications also appear to be blocked/suppressed at the same time. What I’m trying to achieve: Block the Instagram app from being opened Still allow Instagram notifications to come through normally Current behavior: The app is blocked Notifications are also blocked or no longer visible My question: Is there any supported way with Apple’s Screen Time API / ManagedSettings to shield or block an app while still allowing that app’s notifications? Or are app access and notifications tied together by design when a shield is applied? If this behavior is expected, I’d appreciate confirmation from Apple or guidance on whether there is another supported approach. Thanks.

Similar Issue to FB13556935: On iOS 26.3.1, deviceactivityd produces zero log output and never wakes a DeviceActivityMonitor extension at the scheduled time, even when the schedule is successfully registered. The extension's intervalDidStart(for:) method is never called. Steps to Reproduce: Create an app with a DeviceActivityMonitor extension subclass Add the com.apple.developer.family-controls entitlement to both the main app and extension targets Add a shared App Group entitlement to both targets In the main app, call: let center = DeviceActivityCenter() center.stopMonitoring([.myActivity]) let schedule = DeviceActivitySchedule( intervalStart: DateComponents(hour: 17, minute: 30), intervalEnd: DateComponents(hour: 17, minute: 45), repeats: true ) try center.startMonitoring(.myActivity, during: schedule) Verify registration succeeds: DeviceActivityCenter().activities.contains(.myActivity) returns true Background the app completely and wait for the intervalStart time (5:30 PM in this example) Expected Result: intervalDidStart(for:) is called in the extension process at 5:30 PM. ManagedSettings shields are applied without any user interaction. Actual Result: intervalDidStart(for:) is never called. No extension process is launched. Filtering Console.app for deviceactivityd on the device returns 0 messages — the daemon produces no logs whatsoever despite an active registered schedule. Shields are never applied. Additional Evidence: Third-party apps using DeviceActivity (e.g. Prayer Lock) successfully apply shields at scheduled times on the same device and OS version, confirming the framework is not universally broken Filtering Console.app for the app's bundle ID at the trigger time shows the main app process applying shields via a UNCalendarNotificationTrigger fallback — but no extension process activity DeviceActivityCenter().activities correctly lists the registered activity before and after the trigger time, confirming the schedule registration API is functional Environment: iOS 26.3.1 Physical device (required for FamilyControls) Development-signed build with com.apple.developer.family-controls entitlement provisioned App Group shared between main app and extension targets

We’re seeing a change in Spotlight search behavior on iOS 17 and later: Observation: User‑visible keywords we index (e.g. via Core Spotlight / CSSearchableItemAttributeSet with keywords) only start appearing in Spotlight suggestions after the user has typed more than 3 characters. With 1–3 characters, our app’s content often doesn’t show up at all, even when it clearly matches. Before iOS 17: The same indexed content could appear with fewer characters (e.g. 1–3 characters). Environment: Reproduced on multiple devices running iOS 17.x / 18.x; behavior is consistent. We’d like to confirm: Is this a documented change in iOS 17 (e.g. minimum character threshold for third‑party Spotlight results)? If yes, where is it documented? If it’s not intentional, could this be treated as a bug and considered for a fix in a future release? We’re happy to provide a sample project or more detail if that would help. Thank you.

Hello, iOS 26.4 has new APIs which is great. This brings new capability and updated permissions "flow". However as soon as we add the "Family Controls App and Website Usage" capability, then anyone on iOS 26.4 and above can either only approve full access or no access at all. (https://developer.apple.com/documentation/familycontrols/authorizationstatus/approvedwithdataaccess) The previous permission is impossible to obtain. Am I missing something? Is this intended behavior? We can imagine a situation where the user doesn't want to give full access (perhaps because the permissions screen says the app is able to see usage - which is not correct) but they still want to approve Screen Time permissions so the app can apply shields and what not. Thanks.