Hi, We are the developers of Morning Call (https://morningcall.info), and we believe we may have identified an AlarmKit / system UI bug on iPhone. We can reproduce the same behavior not only in our app, but also in Apple’s official AlarmKit sample app, which strongly suggests this is a framework or system-level issue rather than an app-specific bug. Demonstration Video of producing zombie Live Activity https://www.youtube.com/watch?v=cZdF3oc8dVI Related Thread https://developer.apple.com/forums/thread/812006 https://developer.apple.com/forums/thread/817305 https://developer.apple.com/forums/thread/807335 Environment iPhone with Dynamic Island Alarm created using AlarmKit Device is unlocked when the alarm begins alerting Steps to reproduce Schedule an AlarmKit alarm. Wait for the alarm to alert while the device is unlocked. The alarm appears in Dynamic Island. Instead of tapping the intended stop or dismiss button, swipe the Dynamic Island presentation away. Expected result The alarm should be fully dismissed. The Live Activity should be removed. No empty UI should remain in Dynamic Island. Actual result The assigned AppIntent runs successfully. Our app code executes as expected. AlarmKit appears to stop the alarm correctly. However, an empty “zombie” Live Activity remains in Dynamic Island indefinitely. The user cannot clear it through normal interaction. Why this is a serious user-facing issue This is not just a cosmetic issue for us. From the user’s perspective, it looks like a Live Activity is permanently stuck in Dynamic Island. More importantly: Force-quitting the app does not remove it Deleting the app does not remove it In practice, many users conclude that our app has left a broken Live Activity running forever We receive repeated user complaints saying that the Live Activity “won’t go away” Because the remaining UI appears to be system-owned, users often do not realize that the only reliable recovery is to restart the phone. Most users do not discover that workaround on their own, so they instead assume the app is severely broken. Cases where the zombie state disappears Rebooting the phone Waiting for the next AlarmKit alert, then pressing the proper stop button on that alert Additional observations Inside our LiveActivityIntent, calling AlarmManager.shared.stop(id:) reports that the alarm has already been stopped by the system. We also tried inspecting Activity<AlarmAttributes<...>>.activities and calling end(..., dismissalPolicy: .immediate), but in this state no matching activity is exposed to the app. This suggests that the alarm itself has already been stopped, but the system-owned Live Activity UI is not being cleaned up correctly after the swipe-dismiss path. Why this does not appear to be an app logic issue The intent is invoked successfully. The alarm stop path is reached. The alarm is already considered stopped by the system. The remaining UI appears to be system-owned. The stuck UI persists even after our own cleanup logic has run. The stuck UI also survives app force-quit and app deletion.

hello, i have an issue spawning continued background processing tasks: they are never started, even after restarting the device, regardless of which app spawns a task. deleting and reinstalling an app, or installing a new app that didn't exist before also does not work. it can be reproduced by setting your device local time to one year in advance and then trying to spawn the task. the task will not start and even after returning to the proper date, all apps on the device are still unable to spawn any. i also believe there are other things that trigger this issue (or something related), as many of my users have complained about tasks not starting. prior to my changing the date of my device, they worked perfectly for me. one user changed their date to test at the same time as me and the only fix they found was erasing their device and restoring a backup. on ios 26 tasks fail silently, but on ios 27 with the new api to submit a task, an error is caught: Error Domain=BGTaskSchedulerErrorDomain Code=1 "connection to service with pid 94 named com.apple.duetactivityscheduler" UserInfo={NSDebugDescription=connection to service with pid 94 named com.apple.duetactivityscheduler} in addition, a more detailed error with a stack trace is logged at the same time: <NSXPCConnection: 0x10c60c0a0> connection to service with pid 94 named com.apple.duetactivityscheduler: Exception caught during decoding of reply to message 'submitTaskRequest:withHandler:', dropping incoming message and calling failure block. Ignored Exception: Exception while decoding argument 0 (#1 of invocation): <NSInvocation: 0x10c6d72c0> return value: {v} void target: {@?} 0x0 (block) argument 1: {@} 0x0 Exception: value for key 'NS.objects' was of unexpected class 'NSSet' (0x20620c358) [/System/Library/Frameworks/CoreFoundation.framework]. Allowed classes are: {( "'NSDate' (0x20620c268) [/System/Library/Frameworks/CoreFoundation.framework]", "'NSError' (0x2061fd3b0) [/System/Library/Frameworks/Foundation.framework]", "'NSNumber' (0x2061fd478) [/System/Library/Frameworks/Foundation.framework]", "'NSData' (0x20620c650) [/System/Library/Frameworks/CoreFoundation.framework]", "'NSArray' (0x20620c6c8) [/System/Library/Frameworks/CoreFoundation.framework]", "'NSString' (0x2061fd428) [/System/Library/Frameworks/Foundation.framework]", "'NSDictionary' (0x20620c538) [/System/Library/Frameworks/CoreFoundation.framework]", "'NSURL' (0x20620c678) [/System/Library/Frameworks/CoreFoundation.framework]" )} ( 0 CoreFoundation 0x000000019fbc2e0c 43092235-E272-3CAF-B9AE-76669EC5AE46 + 622092 1 libobjc.A.dylib 0x000000019f940298 objc_exception_throw + 88 2 Foundation 0x00000001a002beac E642F95D-61DA-3E8C-A2D2-CFEB7F7B688B + 126636 3 Foundation 0x00000001a0035090 E642F95D-61DA-3E8C-A2D2-CFEB7F7B688B + 163984 ...

Dear Apple: 1、We want to create a socket application using the C language interface on the WiFi Aware channel, utilizing native socket APIs such as socket, connect, bind, etc., to transmit data through the established WiFi Aware channel. However, we wrote a demo and tested it. On the iOS side, when initiating a socket connect, we received error code 65. We also used the IPv6 protocol. We would like to ask for help: Is it impossible to use native socket APIs for programming on the WiFi Aware channel? 2、If native sockets are not available, which interfaces are recommended for WiFi Aware communication on iOS? Thanks.

Hello, I am currently developing call-related features for our app, and I have a question regarding one of the APIs. When the app is launched from the Recents list by selecting a recent call, the activityType of the userActivity is provided as either INStartAudioCallIntentIdentifier or INStartVideoCallIntentIdentifier. However, I understand that these identifiers have been deprecated since iOS 13, and the documentation recommends using INStartCallIntentIdentifier instead. The issue is that when the app is launched from the Recents list, INStartCallIntentIdentifier is never provided. Instead, the deprecated identifiers (INStartAudioCallIntentIdentifier and INStartVideoCallIntentIdentifier) continue to be delivered. I have reviewed the available documentation, but it is not clear how developers are expected to handle this situation. Could you please advise on the recommended approach for supporting this flow? Is it expected that applications continue to handle the deprecated identifiers in this case, or is there another recommended implementation? I would greatly appreciate any guidance you can provide. Thank you.

Here's a much shorter version with just the questions: Hi Apple Developer Support, We're an ad network already registered for SKAdNetwork and are integrating AdAttributionKit. We have a few questions regarding postback URL registration: Do we need to register a separate postback URL for AdAttributionKit, or is our existing SKAdNetwork postback URL reused automatically? If a separate AAK registration is required, can the AAK postback URL be the same as our existing SKAN postback URL, or does Apple require a different URL/path? If the same URL is used for both, are AAK postbacks always delivered as a JWS payload while SKAN postbacks continue to use the existing JSON format? When WWDC states that existing SKAdNetwork ad networks require "no further enrollment," does that refer only to reusing the existing ad network ID, or also to reusing the registered postback URL? Is the Developer Mode AdAttributionKit testing flow the correct way to validate ad network postback delivery? Thanks!

Hi Team, I'm trying to understand the behavior of the following API: HTTPCookieStorage.shared.setCookies(_:for:mainDocumentURL:) Specifically, does this API persist cookies synchronously, or does it perform the storage asynchronously in the background? Our use case is storing FCAP (frequency capping) cookies so they persist across app sessions. We call setCookies(_:for:mainDocumentURL:) and want to know whether the cookies are guaranteed to be written before the method returns, or if the actual persistence happens asynchronously. I couldn't find documentation describing the persistence semantics of this API, so I'd appreciate any clarification or guidance from Apple or anyone familiar with its implementation. Thanks

Hello everyone, We are encountering a critical regression introduced in iOS 26.4 that results in permanent workout data loss for users. When invoking HKWorkoutBuilder.finishWorkout(completion:) while the iOS device is locked, the save operation fails completely. However, it fails silently: the completion handler executes but returns both a nil workout and a nil error. Expected Behavior: Before iOS 26.4 finishWorkout resulted in a workout id, and correctly stored the workout data in HealthKit. According to HealthKit data protection documentation, saving data when the device is locked should either succeed (writing to a temporary journal file to be merged upon unlock) or explicitly throw an error such as HKError.Code.errorDatabaseInaccessible. Actual Behavior: Because the framework returns nil for both the object and the error, the application has no way to detect that the save failed. We cannot implement a retry mechanism or queue the save, resulting in silent data loss. Steps to Reproduce: We have built a Minimal Reproducible Example (MRE) that reliably triggers this: Initialize an HKWorkoutBuilder and call beginCollection(withStart:) followed by endCollection(withEnd:). Wrap the finishWorkout call in a short 5-second asynchronous delay, protected by a UIBackgroundTask to prevent app suspension. Lock the physical device during this 5-second window. The finishWorkout completion handler will execute while the device is locked, returning workout == nil and error == nil. Existing Reports: We have filed this via Feedback Assistant (a month ago) and opened a TSI (a week ago), providing the MRE project and a sysdiagnose captured at the time of failure: Feedback ID: FB22396180 TSI Case-ID: 19755043 As we have not yet received a response or a suggested workaround through these official channels, we are reaching out to the community. Has anyone else encountered this silent failure with HKWorkoutBuilder recently? Any insights or escalation help would be greatly appreciated.

Bonjour à la communauté et à l'assistance Apple, Je vous contacte concernant un problème de sécurité et d'intégrité critique survenu sur une application macOS que j'ai développée personnellement. Le contexte et le problème : Jusqu'à très récemment, le paquet de mon application fonctionnait parfaitement et contenait environ 17 Go de données. Sans aucune intervention de ma part, j'ai constaté une altération majeure du paquet : Le volume des données a drastiquement chuté, passant de 17 Go à seulement 3 Go. L'application ne se lance plus de manière native. Elle ne s'ouvre désormais qu'exclusivement via l'exécuteur Python dans le terminal. Mes inquiétudes : L'application traitant et contenant des données financières, cette réduction massive et inexpliquée de la taille du paquet me laisse fortement soupçonner une exportation ou une exfiltration non autorisée de mes données. Le fait que l'exécutable ait été altéré pour forcer une ouverture via le terminal renforce cette suspicion. Ma demande : La situation exigeant une analyse technique approfondie, j'ai besoin d'organiser un appel avec un spécialiste de l'assistance Apple de niveau supérieur ou un ingénieur système. L'objectif est d'obtenir une assistance directe pour inspecter l'altération, réorganiser le contenu du paquet de mon application (.app) et sécuriser l'environnement. Pourriez-vous m'indiquer la marche à suivre exacte pour planifier cet appel ou faire remonter ce dossier à l'ingénierie ? Je vous remercie par avance pour votre réactivité. Cordialement, Maxime Hello to the community and Apple Support, I am reaching out regarding a critical security and data integrity issue that occurred on a macOS application I developed personally. Context and Problem: Until very recently, my application package worked perfectly and contained approximately 17 GB of data. Without any intervention on my part, I noticed a major alteration to the package: The volume of data has drastically dropped, going from 17 GB to only 3 GB. The application no longer launches natively. It now opens exclusively via the Python executor within the terminal. My Concerns: Because this application processes and contains financial data, this massive and unexplained reduction in the package size leads me to strongly suspect an unauthorized export or exfiltration of my data. The fact that the executable has been altered to force an opening via the terminal heavily reinforces this suspicion. My Request: As this situation requires a deep technical analysis, I need to schedule a call with a senior Apple Support specialist or a system engineer. The goal is to obtain direct assistance to inspect the alteration, reorganize the contents of my application package (.app), and secure the environment. Could you please advise on the exact procedure to schedule this call or escalate this case to engineering? Thank you in advance for your prompt response. Best regards, Maxime

Our client's site uses Apple Pay, and once a month we get a series of email notifying us that the domain verification is about to expire: Your website domain that uses Apple Pay has an SSL Certificate that expires on Oct 11, 2020. We were unable to automatically to reverify your domain. To ensure uninterrupted use of Apple Pay on your website, revalidate your domain by Oct 11, 2020 in Certificates, Identifiers & Profiles. The site uses Let's Encrypt to automatically renew its SSL cert monthly. Every time that happens, we need to log into the Apple Developer tools, navigate to Certificates, Identifiers, and Profiles -> Identifiers -> Merchant IDs -> ID -> Merchant Domains, then download the file and drop it onto the server with SFTP. It's a pain. Is there a way to automate this process (or better yet, stop it from happening)? I can't imagine monthly-renewing SSL certificates is a particularly uncommon thing.

Hi everyone, We are integrating Apple Pay on the Web, and we're trying to get the automatic renewal of the domain verification working according to the documentation: https://developer.apple.com/documentation/apple_pay_on_the_web/maintaining_your_environment Initially the domain verification is successful, but then the automatic renewal does not work. We keep getting the emails with the subject "Your domain will expire soon.", but they only say "We were unable to automatically to reverify your domain." without any further details. We confirmed that the site's SSL certificate has already been renewed by the time Apple attempted the renewal of verification, the certs are renewed 30 days before their expiry (using Let's Encrypt). So according to the docs, at least the renewal attempts 15, and then 7 days before the expiry should be successful. One example domain is this one: https://www.kayak.com/.well-known/apple-developer-merchantid-domain-association.txt, but we have the same issue for all our other domains as well. Does anyone have suggestions how to troubleshoot this further? (I tried creating a support ticket, but they basically replied that they're non-technical, and just linked me to the documentation. I've seen others complaining about this too, but couldn't find a conclusive solution, so I thought I'd signal boost and create a fresh topic to see if there are any more recent findings about this problem.) Thanks! Regards, Mark

Hello, We are requesting urgent help with what appears to be repeated presentation of the native in-app rating prompt in our production app, Jízdní řády IDOS: https://apps.apple.com/cz/app/j%C3%ADzdn%C3%AD-%C5%99%C3%A1dy-idos/id473503749 This issue is materially affecting our App Store rating and user trust. We estimate that it has resulted in dozens of negative reviews explicitly mentioning that the native “Rate this app” prompt is shown repeatedly or “all the time”. The actual impact on our overall rating is difficult to determine, as not all affected users explicitly reference this issue in their reviews. The affected builds are App Store production builds, not Debug builds or TestFlight builds. Initially, we used the deprecated SKStoreReviewController API. We suspected that this could be the cause, so we migrated to the current API on iOS 18 and later: import StoreKit import UIKit @MainActor static func requestReview(from view: UIView) { if #available(iOS 18.0, *), let scene = view.window?.windowScene { AppStore.requestReview(in: scene) } else if #available(iOS 14.0, *), let scene = view.window?.windowScene { SKStoreReviewController.requestReview(in: scene) } else { SKStoreReviewController.requestReview() } } Unfortunately, this change did not resolve the issue. Users have continued to report that the native rating prompt appears repeatedly in the App Store version of our app. We understand that StoreKit controls whether the prompt is actually presented and should enforce the documented display limit. However, the volume and consistency of user feedback make us concerned that this limit may not be reliably enforced in our case. We have also found a similar report from another developer: https://developer.apple.com/forums/thread/827331 Could you please clarify: Can SKStoreReviewController.requestReview() or AppStore.requestReview(in:) result in the prompt being shown more than three times within 365 days in a shipping App Store build? Is there any known issue, limitation, or behavioural difference affecting either SKStoreReviewController.requestReview(in:) or AppStore.requestReview(in:) that could explain repeated presentation of the native rating prompt in a shipping App Store build? Could the SwiftUI RequestReviewAction API behave differently from AppStore.requestReview(in:) with respect to enforcing the presentation limit? Would migrating to RequestReviewAction be expected to resolve this issue? Our application is predominantly UIKit, so adopting the SwiftUI API would require non-trivial integration work. More importantly, we do not want to use production users to test another implementation while the issue may continue to negatively affect our rating. We would therefore appreciate guidance on the expected behaviour and the recommended implementation before making this change. We can provide affected app versions, iOS versions, device details, screenshots, and examples of user feedback immediately if useful. Thank you.

I'm a contributor to Trio, an open-source automated insulin delivery (AID) app for iOS/watchOS maintained by the Nightscout Foundation. I'm posting at the recommendation of the engineering team via Feedback Assistant FB22619409 (Developer Support case 102865854185). The goal We're prototyping direct BLE connectivity between the Trio watchOS extension and the Dexcom G7 CGM sensor — eliminating dependence on iPhone-to-Watch relay via WatchConnectivity. For an AID app, stale CGM data affects insulin dosing decisions; this is a patient safety concern. The entitlements needed To maintain a BLE connection to the G7 while backgrounded and with the display off/wrist lowered, the WatchKit extension requires: com.apple.developer.bluetooth-central-background com.apple.developer.bluetooth-central-screen-off-scanning What I've confirmed Both entitlements are present on Dexcom's shipping G7 WatchKit extension (com.dexcom.g7app.watchkitapp.watchkitextension), verifiable via: codesign -d --entitlements :- \ "Dexcom G7.app/Watch/G7Watch.app/PlugIns/G7Watch Extension.appex" Output includes: com.apple.developer.bluetooth-central-background = true com.apple.developer.bluetooth-central-screen-off-scanning = true These are not self-service capabilities exposed through Xcode or the developer portal for our account: Xcode → Trio Watch App target → Signing & Capabilities → + Capability → searching com.apple.developer.bluetooth-central-background returns No Matches Certificates, Identifiers & Profiles → WatchKit Extension App ID (org.nightscout.5QE6TMMEH2.trio.watchkitapp.watchkitextension) → the entitlement does not appear under Capability Requests A screen recording demonstrating both is attached to FB22619409. The May 16 Apple Feedback response noted that the entitlement was visible in an internal Xcode project — consistent with it being a restricted/managed entitlement not exposed through standard developer accounts. My questions What is the correct process to request com.apple.developer.bluetooth-central-background for a watchOS extension App ID where it does not appear in Capability Requests? Is com.apple.developer.bluetooth-central-screen-off-scanning available through a private/managed entitlement process, and how do we enter that process? Is there a formal Apple program (e.g., MFi, HealthKit entitlements, or similar) applicable to CGM-connected medical apps that covers these entitlements? Full account details, screen recording, and entitlement output are attached to FB22619409 / Developer Support case 102865854185. Happy to provide a test build, full entitlement output, or additional context if needed. Thank you

On my iPhone (iOS 26.5), the Call Filtering "Spam" setting under Settings → Apps → Phone isn't working as described. The setting's own text says calls identified as spam or fraud by Xfinity Mobile will be silenced, sent to voicemail, and moved to the Spam list, but in practice these calls ring through normally with no silencing at all, even though the toggle is enabled and Unknown Callers is off. This looks related to a broader CallKit regression that's been reported on Apple's Developer Forums since the iOS 26 beta cycle (threads 794740, 799694, and 800415), where call-blocking and filtering entries are being ignored or applied inconsistently; other developers have already filed Feedback IDs FB19140680, FB19140594, and FB20276986 for related symptoms. It would be great to get this fixed, since it defeats the purpose of carrier-level spam filtering on the phone.

Trying to virtualize macOS 27 on a 26.6 host failed at 77% install progress, even with Xcode 27 beta installed. But worked fine on a macOS 27 host. Are there any tricks to use a 26 host? Thanks!

Environment: iOS Version: iOS 27.0 Framework: ActivityKit Xcode Version: Xcode 26.1 Issue Description: In iOS 27, Live Activities fail to adapt to the system colorScheme. Regardless of whether the system theme is set to Light or Dark mode, @Environment(.colorScheme) inside the Live Activity view always returns .dark. This behavior worked as expected on iOS 26, where the Live Activity correctly responded to light/dark mode changes and rendered the appropriate theme. Expected Behavior: The Live Activity view should respect the system's current colorScheme (returning .light when the system is in Light Mode) on iOS 27, consistent with the behavior on iOS 26. Actual Behavior: The Live Activity view strictly defaults to .dark mode on iOS 27, even when the device is explicitly set to Light Mode. struct LockScreenView<T: BaseLiveActivityAttributes>: View { let context: ActivityViewContext<T> @Environment(\.colorScheme) var colorScheme var isLight: Bool { colorScheme == .light } var body: some View { Color(isLight ? .white : .black) .overlay(alignment: .topTrailing) { VStack(alignment: .trailing, spacing: 2) { Text("colorScheme: \(String(describing: colorScheme))") } .font(.system(size: 9, weight: .bold, design: .monospaced)) .foregroundColor(.yellow) .padding(4) .background(Color.black.opacity(0.6)) .cornerRadius(4) .padding(.trailing, 8) .padding(.top, 4) } } } Any insights or workarounds would be greatly appreciated. Thanks!

Overview When the macOS app is closed, the os logs (debug) logs are not visible in the Console app. However even when the iOS app is closed / killed, the os logs (debug) logs are visible in the Console app. What I have tried Console app menu Action > Include Debug Messages is checked Searched by subsystem Created a macOS app from the archive by choosing selecting Debugging option Note OS debug logs are visible when the macOS app is open Questions How can I make macOS debug logs visible in the Console app when the Mac app is closed? Should I be searching by some other fields? Or is there any other alternative / workaround this because I need to debug this scenario when app is closed?

My scenario I have an app which stores data using SwiftData / CloudKit automatic sync It works as expected on iOS, sync happens even when the app is closed. On Mac, when mac app is closed the data from the CloudKit is not pulled into the DB. It would be nice if the widget on the Mac is updated even when the Mac app is closed. Like from a sync from an iPhone. My problem: I don't do anything for sync other than just initializing the ModelContainer and everything is taken care of. The local store has its own system level tables to maintain the sync states. So I am a bit hesitant to do a separate sync in the background process (LoginItem / LaunchAgent / LaunchDaemon. I need to read a lot on this because I am just beginning to explore this part Questions Is it feasible / advisable to have one instance of the ModelContainer created in the background process and access it in the main app for the Mac? Reason for asking is because ModelContainer is the one that does all the sync magically. Or is this too much of an overhead and users can open the app to keep the widget updated?

Filed as FB23904785 with pcaps, a mid-episode sysdiagnose, & a userspace test harness. Posting here because the behavior localizes to the receive-window computation in xnu & I'd value a sanity check from anyone who knows what changed in this area for 27. On 26A5378n (MacBook Air M2, RTL8156B 2.5GbE via the in-kernel AppleUSBNCM driver), TCP downloads on the wired interface intermittently drop to 6-10 Mbps for stretches of minutes to 40 minutes, then recover on their own. Wi-Fi on the same machine pulls 50-70 Mbps from the same servers in the same seconds. Packet captures show why: during these stretches the kernel advertises a 5,440-byte receive window from the first post-handshake ACK & doubles it on 1.000 s ± 0.01 s wall-clock boundaries, seven doublings in a row, in two separate connections started 6.5 minutes apart, while bytes-per-interval varied 16x. Byte-count triggers can't produce byte-rate-invariant timing; that's a clock. What I ruled out inside a live occurrence: SO_RCVBUF of 4 MB (getsockopt-verified; identical staircase, so it isn't autotuning), ECN on/off (three toggles, no change), both link_heuristics sysctls, the WAN (during one occurrence ICMP loss was WORSE on Wi-Fi, 20% vs 10%, yet Wi-Fi ran 5x faster), & the wire itself (0.1% retransmissions, ACK timestamp-echo p50 43 ms, zero zero-window advertisements). TCP_CONNECTION_INFO confirms the on-wire numbers: tcpi_rcv_wnd 10,880 at t=2 s against a 4 MB buffer that stays 97% empty, tcpi_srtt 41 ms. The throttled flow itself hit 32.7 Mbps at t=7 s once the staircase reached 347 KB, so path capacity was there the whole time. The signature resembles a receiver-side LEDBAT governor (RFC 9840 describes exposing a reduced window through the receive window; tcp_rledbat.c in published xnu clamps recwin for sockets flagged receive-background). Two things don't add up though. First, I ported the published tcp_rledbat.c to userspace & drove it with the exact packet timeline from my capture: no parameterization reproduces constant 2x steps on one-second boundaries, because every growth law in that file counts bytes or RTTs, not seconds. Second, kern.ipc.throttle_best_effort reads 1 on a clean boot of this beta with no sysctl.conf, no profiles, & no third-party launch items, while published xnu initializes it to 0. That switch arms the demotion of best-effort sockets to receive-background on interfaces that recently carried realtime-marked traffic. Questions: did the receive-window governor change in 27, & did the throttle_best_effort default flip intentionally? And is there a supported way to see which sockets carry SOF1_TRAFFIC_MGT_TCP_RECVBG at runtime, to pin down what's marking these flows? Happy to attach anything from the evidence set to the FB or run diagnostics on request; the fault reproduces several times a day here.

I'm testing iOS 27 and face this issue that the accessoryImage on the CPListItem is no longer shown properly. It works fine up until iOS 26.5 but on 27 it is way to small. Check attached screen shot for details. Also filed FB23903072, hope this gets fixed before iOS 27 final arrives. 🤞

I have created a share extension for my app which supports accepting an image. However the app do not appear in the "Share with App" action of shortcuts. It only shows "Health" and "Reminders" which are default apple apps. What I found though is that if I open some other app like Photos and share an image from it, then go to end of app's list and click more. And in the list if I toggle my app off and on again. And then come back to shourtcuts app, the app then appears. Step 1: Open share sheet, click more Step 2: Toggle the app off and on again and save. And then it switching to shortcuts app, it appear now. I am unable to find a way on how to make this app's share extension support the "Share with app" action of shortcuts by default. This looks like a bug. I did not find any proper documentation as well for this. Can anyone point me to correct way / resource to add my app as supported app here out of the box. Minimal reproducible example: ZIP file of xcode project