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.

I am investigating premature DeviceActivityMonitor.eventDidReachThreshold callbacks on physical devices running iOS 26.x. I have also observed similar overcounting behavior on iOS 18.x. In one repeatable test, an all-activity event configured with a 10-minute threshold fired after approximately 5 minutes of actual unlocked usage. The event was created with: A single completion threshold. includesPastActivity: false. A nonrepeating DeviceActivitySchedule. A unique activity and event identity for each monitoring generation. However, eventDidReachThreshold could still arrive significantly earlier than expected. Defensive mitigation I have been testing a defensive mechanism that treats eventDidReachThreshold only as a wake-up signal, rather than authoritative proof that the configured usage duration has elapsed. When the callback arrives, the monitor extension independently validates the duration against locally persisted timing state. The flow is: Each logical work cycle has a unique cycle identifier and generation number. The app stores a local timing anchor when monitoring begins or resumes. When the threshold callback arrives, the extension verifies: The cycle identifier. The generation number. The activity name. The current application state. The extension calculates a locally trusted elapsed duration. If the local duration has not reached the configured duration: It does not send a notification. It does not apply any user-visible action. It persists only the locally trusted progress. It increments the generation number. It stops the previous monitor. It registers a new event for only the locally remaining duration. Completion is accepted only when the locally calculated duration is due. Delayed callbacks from previous generations are ignored. Simplified pseudocode: override func eventDidReachThreshold( _ event: DeviceActivityEvent.Name, activity: DeviceActivityName ) { let state = loadPersistedState() guard eventMatchesCurrentGeneration( event: event, activity: activity, state: state ) else { // Ignore stale or duplicated callbacks. return } let now = Date() let trustedElapsed = calculateLocallyAccountedElapsed( state: state, now: now ) let tolerance: TimeInterval = 3 if trustedElapsed + tolerance < state.configuredDuration { let remaining = state.configuredDuration - trustedElapsed var nextState = state nextState.confirmedElapsed = trustedElapsed nextState.generation += 1 // Persist the new generation before replacing the monitor. persistAtomically(nextState) center.stopMonitoring([activity]) let nextActivity = makeActivityName( cycleID: nextState.cycleID, generation: nextState.generation ) let completionEvent = DeviceActivityEvent( threshold: normalizedDateComponents(remaining), includesPastActivity: false ) do { try center.startMonitoring( nextActivity, during: makeNonRepeatingSchedule(), events: [ makeCompletionEventName(nextState): completionEvent ] ) } catch { // Persist a recoverable unavailable state. recordMonitoringFailure(error) } return } transitionToCompletedState() scheduleUserNotification() } Durations are normalized before creating the event: func normalizedDateComponents( _ duration: TimeInterval ) -> DateComponents { let seconds = max(1, Int(duration)) return DateComponents( minute: seconds / 60, second: seconds % 60 ) } This avoids using values such as second: 300. Example For a configured duration of 10 minutes: DeviceActivity incorrectly delivers the completion callback after approximately 5 minutes. Local accounting reports only approximately 5 minutes. No notification or other user-visible action is performed. The previous monitor is replaced with a new generation configured for the remaining approximately 5 minutes. Completion is accepted only after the locally trusted timing state is due. This mechanism has so far prevented premature DeviceActivity callbacks from producing premature notifications during my physical-device testing on iOS 26.x. Additional precautions The implementation also uses the following precautions: Only one completion event is registered instead of multiple minute checkpoints. includesPastActivity is explicitly set to false. Every replacement monitor has a new generation identity. Generation state is persisted before the old monitor is replaced. Callbacks from an old cycle, generation, or activity name are ignored. The extension performs only small, bounded state updates. User-visible actions occur only after local validation succeeds. Limitations This is a defensive workaround, not a fix for the underlying DeviceActivity or Screen Time accounting issue. Known limitations include: It cannot prevent iOS from delivering an incorrect callback. If the system never delivers another callback, completion may be delayed or missed. If every new event immediately fires, repeated re-registration may occur. startMonitoring may fail if the system considers the activities too numerous or too tightly scheduled. Local unlocked-time accounting depends on reliable lock and unlock observations. Wall-clock calculations must consider manual system-time changes. The approach cannot correct Screen Time’s internal activity data. For modes that intentionally count locked time, absolute local-notification scheduling may be more reliable and may avoid DeviceActivity thresholds entirely. All processing in this mitigation occurs on-device. It does not require uploading activity tokens, Screen Time data, user identifiers, or diagnostic logs. The implementation uses only public APIs. Questions for Apple Is treating eventDidReachThreshold as a wake-up signal and validating it against locally persisted timing state an acceptable design? Is stopping the current monitor and registering a new generation for only the locally remaining duration from the monitor extension considered a supported recovery pattern? Are there documented or recommended limits, rate controls, or backoff requirements for this type of defensive re-registration? Is there a more reliable supported API for usage-based completion when eventDidReachThreshold fires prematurely on iOS 26? I would appreciate confirmation from Apple engineers or feedback from other developers who have tested a similar approach.

We submitted Live Caller ID Lookup requests for two apps and both remain “In Review.” Our PIR server, Privacy Pass issuer and OHTTP gateway are deployed, DNS TXT records are published for both bundle identifiers, and the test number returns correctly. Is there a way to verify from our side that Apple’s automated endpoint validation passes? Any common misconfiguration that causes a request to sit without feedback?

Configuring a VPN with includeAllNetworks causes CarPlay / Netflix Cast. Even enabling excludeLocalNetworks does not resolve this issue. Is this a known issue and can we work around this?

Overview I would like to observe calendar changes using NotificationCenter.messages(of: for:) I want receive Sendable messages, not traditional Notification which is not Sendable Problem I can't seem to get the following code to compile import EventKit NotificationCenter.default.messages( of: EKEventStore.EventStoreChanged.Subject.self, for: .changed ) Reference https://developer.apple.com/documentation/foundation/notificationcenter/messageidentifier/changed-50yz5 Questions How can I use by using NotificationCenter.messages(of: for:) for Calendar changes?

Hi Team, Our universal links were working fine but since last week we are facing issues and when tapping the links outside app it takes to browser and not the app. Apple CDN is returning 404 for our domain and not the contents of AASA file. https://app-site-association.cdn-apple.com/a/v1/app.ooredoo.om sudo swcutil dl -d app.ooredoo.om returns The operation couldn’t be completed. (SWCErrorDomain error 7.) Can we get the exact issue apple is facing to cache the AASA file in CDN. Any server config which we need to do for AASA bot to access the file. Thanks in advance.

Hi all, I'm the developer of OV Message, an end-to-end encrypted SMS messaging app already shipped on Google Play (Android, where it natively encrypts SMS content). The iOS port aims to be the default carrier-messaging app, handling SMS, MMS, and RCS through TelephonyMessagingKit with the com.apple.developer.carrier-messaging-app entitlement under the EU programme. While testing the cold-launch flow on iOS 26.x, I've hit a reproducible bug that silently drops the first SMS/MMS/RCS that wakes the app, and I'd like to confirm whether other devs working with this API see the same. The bug When a default carrier-messaging app is force-killed and a message arrives, iOS correctly: Routes the message via CommCenter (IMS in my case — SFR France) Wakes the app in background (state = .background at didFinishLaunchingWithOptions) Acquires a TelephonyMessaging runningboard assertion on the app But CommCenter then pushes the pending message via XPC before the client TMK library has finished registering its messageHandlersByID dictionary. Result: client responds Received unhandled request, server logs TMKXPCError Code=2, message is dropped, never delivered to for await in incomingMessageNotifications. Subsequent messages (with the app warm) work fine. Native log sequence (from idevicesyslog with the Telephony logging profile) T+0.000 CommCenter: SMS arrives via IMS (k3GPP) T+0.003 CommCenter: Default app is set to com.example.app T+0.004 CommCenter: Attempting to launch and acquire process assertion T+0.083 CommCenter: Notifying SMS message received, target: bundleID=... T+0.085 CommCenter(TMK): There are no client connections matching, pending message [~125 ms — app boots] T+0.128 App(TMK): Configuring connection T+0.128 App(TMK): Pinging remote end T+0.130 CommCenter(TMK): Received new connection from PID T+0.130 CommCenter(TMK): New incoming connection, flushing pending messages (1) ← server flushes T+0.130 App(TMK): Received unhandled request ← client not ready T+0.131 CommCenter(TMK): Failed to send pending message: TMKXPCError Code=2 T+0.132 App(TMK): Registered for IncomingMessageNotification (smsReceived) ← ~2 ms too late The race window between Pinging remote end (client) and Registered for IncomingMessageNotification (client) is 2–7 ms across my measurements. CommCenter considers the connection ready as soon as the ping completes, but the client library populates messageHandlersByID slightly after, so the dispatch fails. Minimal reproduction I built a ~50-line Swift app to confirm this isn't specific to OV Message. UIKit AppDelegate, single for await in TelephonyMessagingSession.shared.smsService.incomingMessageNotifications started in didFinishLaunchingWithOptions. No SwiftUI, no other modules, no Darwin notifications. Just TMK. Steps: Build & install on iPhone iOS 26.x with carrier-messaging-app entitlement (auto-provisioned in iOS 26) Settings → Apps → Default Messaging → select the test app Force-kill, then send 2 SMS in rapid succession from another phone Wait 30 s, open the app — log shows only the 2nd SMS Same result: the 1st SMS is gone. I've reproduced this consistently dozens of times. Source code (Swift + xcodegen project.yml): https://gist.github.com/ovmessage/fbc529292a65222191bec6ce5e5a4275 What I've tried Task.detached(priority: .userInitiated) to decouple the for await from main thread scheduling — no effect (race is internal to TMK lib, before our scheduling) Pre-fetching cellularServices synchronously — no effect Subscribing MMS + RCS in parallel — no effect Direct XPCSession/xpc_connection_create_mach_service to com.apple.commcenter.tmk.xpc — Apple has marked these unavailable on iOS for 3rd-party apps (no public way to bypass the lib) I've also done runtime introspection of the TMK framework via Mirror, which confirms the architecture: a single XPCConnection.messageHandlersByID dict shared by smsReceived, mmsReceived, rcsReceivedNotification — all four entries (incl. serviceStatusNotification) are populated after the XPC ping. So the same race affects SMS, MMS, and RCS equally. Suggested fixes (Apple-side) Either: Server (CommCenter): defer flushing pending messages until the client confirms its handlers are registered (extra XPC handshake message) Client (TelephonyMessagingKit): register messageHandlersByID entries before sending Pinging remote end, so they exist when the server starts flushing Buffer client-side: cache messages received before handler registration completes, dispatch on attach Filed in Feedback Assistant FB[YOUR_FB_NUMBER_HERE] Question for fellow devs If you're also building with carrier-messaging-app entitlement (Beeper, Google Messages on iOS, anyone in the EU programme), can you confirm whether you see the same race? Especially interested in whether: It happens with non-IMS carriers (mine is SFR France, IMS-routed via SIP) iOS 26.1 / 26.2 changed the timing Anyone has found a workaround I haven't tried Thanks.

Hi everyone, I'm developing an iOS app that includes both a Message Filter Extension and a Call Blocking Extension. I'd like to understand whether there is any supported way to collect or access statistics for these extensions, such as: Number of messages filtered (allowed vs. junk) Number of blocked calls Number of identified calls Extension invocation count Filtering success/failure metrics Any analytics or usage data exposed by the system I understand that these extensions are privacy-sensitive, so I'm not expecting access to user content. I'm specifically looking for aggregate statistics or system-provided metrics that an app can legally and technically access. My questions are: Does iOS expose any APIs or callbacks for collecting usage statistics from a Message Filter Extension? Is there any way to determine how many calls were blocked or identified by a Call Blocking Extension? Are there any recommended Apple-supported approaches for tracking extension usage without violating user privacy? If no APIs are available, is this limitation intentional due to the privacy model of these extensions? I'd appreciate any guidance or best practices from Apple engineers or developers who have worked with these extensions. Thank you!

Summary Our Share Extension works correctly on iOS 18 but silently fails on iOS 26. The app appears in the share sheet, the user taps it, the sheet dismisses — and nothing else happens. The containing app never opens. Environment App: com.yourcompany.app Extension: com.yourcompany.app.shareaudio (com.apple.share-services) Source app: Voice Memos Deployment target: iOS 17.0 iOS 18.x (TestFlight): ✅ works — extension runs, app opens, file imports iOS 26.x (same build): ❌ fails — share sheet closes, extension appears to terminate immediately What we've tried Activation rule — NSExtensionActivationRule with UTI-CONFORMS-TO covering com.apple.quicktime-audio, public.audio, public.mpeg-4-audio, com.apple.m4a-audio, public.file-url. Loading the file — tried loadFileRepresentation(forTypeIdentifier:), loadInPlaceFileRepresentation, and loadItem, with fallbacks prioritizing public.file-url and com.apple.quicktime-audio. Logged registeredTypeIdentifiers to confirm what the provider exposes. Opening the containing app — calling extensionContext?.open(url) before completeRequest. Also tested a secondary URL scheme. App Group is configured; we write a pending flag and check it in sceneDidBecomeActive. Voice Memos export modes — tested both Rendered (.m4a) and Editable (.qta). None of this changed the behavior on iOS 26. Specific questions What does NSItemProvider.registeredTypeIdentifiers return on iOS 26 for Voice Memos recordings, especially .qta files? Is com.apple.quicktime-audio still the correct UTI for .qta on iOS 26, or has it changed? Has the recommended API for loading shared audio changed in iOS 26 — loadFileRepresentation, loadInPlaceFileRepresentation, or loadItem? Is NSExtensionContext.open(_:completionHandler:) still the supported way to open the containing app from a Share Extension on iOS 26? Are there new entitlements or restrictions? Is there any WWDC25 session or updated documentation covering Share Extensions receiving Voice Memos exports (including AVFileType.qta)? Is this a known regression in iOS 26? Happy to share logs, a TestFlight build, or a minimal reproducible project if that helps.

您好，想咨询下Configuration ID为32b92585-4221-4b39-a305-c3de951bb53a的Live Caller ID Request的最新审批状态，目前功能开发已完成缺少OHTTP网关就可以正式投入使用。

Related feedback: FB16995719 This is an old one, that has not been solved in iOS 27. This is very annoying since iOS 27 brings new AI stuff to Spotlight, that can't be used because of this bug. Jennifer has acknowledged this bug during a one-on-one session last year (WWDC25) where we carefully reviewed my code. I simply would like that the app documents content to be indexed. It's simple text that I pass to textContent. ------- try await CSSearchableIndex.default().indexAppEntities([entity]) // How the indexing is called ------- @available(iOS 18, *) /// The IndexedEntity struct DocumentEntity: IndexedEntity, Identifiable { static var typeDisplayRepresentation: TypeDisplayRepresentation { TypeDisplayRepresentation(name: LocalizedStringResource("INTENT_DOCUMENT_DISPLAY_REP")) } static let defaultQuery = DocumentQuery() // A unique identifier for each document let id: NSManagedObjectID let title: String? let thumbnailData: Data? // The document's text to be indexed let textContent: String? let pageCount: Int // A display representation for UI purposes. var displayRepresentation: DisplayRepresentation { DisplayRepresentation( title: "\(title ?? "")", image: thumbnailData == nil ? nil : .init(data: thumbnailData!) // INDEXED successfully through the use of @available(iOS 18, *) struct DocumentEntity: IndexedEntity, Identifiable { static var typeDisplayRepresentation: TypeDisplayRepresentation { TypeDisplayRepresentation(name: LocalizedStringResource("INTENT_DOCUMENT_DISPLAY_REP")) } static let defaultQuery = DocumentQuery() // A unique identifier for each document (for example, your NSManagedObject's objectID). let id: NSManagedObjectID let title: String? let thumbnailData: Data? // The OCR text to be indexed let textContent: String? let pageCount: Int // A display representation for UI purposes. var displayRepresentation: DisplayRepresentation { DisplayRepresentation( title: "\(title ?? "")", image: thumbnailData == nil ? nil : .init(data: thumbnailData!) ) } } ) } } @available(iOS 18, *) extension DocumentEntity { // The attributeSet for Spotlight var attributeSet: CSSearchableItemAttributeSet { let attributeSet = defaultAttributeSet attributeSet.title = title attributeSet.displayName = title // THIS ONE IS INDEXED attributeSet.contentType = UTType.plainText.identifier attributeSet.textContent = textContent // THIS ONE IS **NOT** INDEXED attributeSet.pageCount = NSNumber(integerLiteral: pageCount) // THIS ONE IS INDEXED attributeSet.thumbnailData = thumbnailData attributeSet.creator = Constants.APP_NAME return attributeSet } } Related: https://discussions.apple.com/thread/256061571

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.

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

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.

最常见的是这个： Thread 1 Queue : com.apple.main-thread (serial) #0 0x0000000190bcb3c4 in CFRelease.cold.2 () #1 0x0000000190a2c50c in CFRelease () #2 0x00000001d194ad38 in -[PDFTileSurface releaseSurface] () #3 0x00000001d194c230 in -[PDFTilePool releasePDFTileSurface:] () #4 0x00000001d194f618 in -[PDFPageLayerTile dealloc] () #5 0x0000000190a4778c in -[__NSArrayI_Transfer dealloc] () #6 0x000000018d5d57f8 in AutoreleasePoolPage::releaseUntil () #7 0x000000018d5d5684 in objc_autoreleasePoolPop () #8 0x000000019668d43c in -[UIScrollView setContentOffset:] () #9 0x000000018dd70918 in -[NSObject(NSKeyValueObservingPrivate) _changeValueForKeys:count:maybeOldValuesDict:maybeNewValuesDict:usingBlock:] () #10 0x000000018ddd1298 in -[NSObject(NSKeyValueObservingPrivate) _changeValueForKey:key:key:usingBlock:] () #11 0x000000018ded5b28 in _NSSetPointValueAndNotify () #12 0x0000000196c49af0 in -[UIScrollView _smoothScrollSyncWithUpdateTime:] () #13 0x0000000196c491a0 in -[UIScrollView _smoothScrollWithUpdateTime:] () #14 0x0000000196c490b0 in -[UIScrollView smoothScrollDisplayLink:] () #15 0x000000026186a66c in -[DYDisplayLinkInterposer forwardDisplayLinkCallback:] () #16 0x00000001914cc77c in CA::Display::DisplayLinkItem::dispatch () #17 0x00000001914a4388 in CA::Display::DisplayLink::dispatch_items () #18 0x00000001914bb2b8 in CA::Display::DisplayLink::dispatch_deferred_display_links () #19 0x000000019671e2a8 in _UIUpdateSequenceRunNext () #20 0x000000019671b834 in schedulerStepScheduledMainSectionContinue () #21 0x00000002a437256c in UC::DriverCore::continueProcessing () #22 0x0000000190a3f1d8 in __CFMachPortPerform () #23 0x0000000190a81824 in CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION () #24 0x0000000190a8174c in __CFRunLoopDoSource1 () #25 0x0000000190a4c6e4 in __CFRunLoopRun () #26 0x0000000190a4b54c in _CFRunLoopRunSpecificWithOptions () #27 0x0000000235da7498 in GSEventRunModal () #28 0x0000000196744244 in -[UIApplication _run] () #29 0x00000001966af158 in UIApplicationMain () #30 0x00000001968bb618 in ___lldb_unnamed_symbol_1893835b0 () #31 0x0000000105a7a308 in static UIApplicationDelegate.main() () #32 0x0000000105a7a278 in static AppDelegate.$main() () #33 0x0000000105a7a3cc in main () #34 0x000000018d659c1c in start ()

您好，想咨询下Configuration ID为2641fd1b-8023-4644-b301-1d57785b8f6c的Live Caller ID Request的最新审批状态，目前功能开发已完成缺少OHTTP网关就可以正式投入使用。

I'm building a tool that works with contact cards (iCloud CardDAV as source). I need to obtain the pronouns set for a user to know if they are to be addressed as a he, she, etc. Pronouns set on a contact in Apple Contacts sync to iCloud and appear on the CardDAV vCard as itemN.X-ADDRESSING-GRAMMAR, but the value is opaque after base64 decode (not plaintext, XML plist, or binary plist). Third-party CardDAV clients authenticated as the account owner therefore cannot read pronouns, even though other contact fields (name, phones, emails, related names, etc.) are readable. RFC 9554 PRONOUNS is not present on these cards. How do I get these from contact cards?

I have an app that shares files between users of the app by attaching the file to either an email or an iMessage. The original implementation attached a JSON file but I was able to build a smaller binary file, allowing me to have more content within the file size limit. Mail attachments work just fine. I've modified the info plist to define the app-specific file extension. But no matter where I define it, iMessage refuses to put up a preview where the user can select my app to open it. I tried putting it in a document type with a public.text, public.data roles. I tried adding it to the Exported Type Identifiers as a public-mime-type. I made sure the identifiers all have the reverse url com... My temporary iMessage workaround is to name the file with .zip, a known public extension. It doesn't have valid zip data, it just declares it as a zip file and allows the user to pick my app to open it because I added zip as an exported type identifier. But I don't want the user to think my app can also open zip files. I would be happy if the preview looked similar to what is done for zip files - a file icon, but with my app's name inside the icon. Any help with this configuration nightmare is appreciated. Mike

Hi everyone, I'm exploring an app idea that would help users organize their Home Screen, the app would move or rearrange other apps' icons on the user's behalf (for example, auto-grouping apps or repositioning them based on how often they're used). My question is twofold: Is there currently any entitlement, API, or permission that lets an app programmatically move or rearrange other apps' icons on the Home Screen? From what I can tell, the sandbox model prevents an app from touching anything outside its own container, so I suspect this isn't possible today but I'd be glad to be corrected if I've missed something. If it genuinely isn't possible, is this something Apple would consider adding? For instance, a user-granted permission (similar to how Notifications, Screen Time, or Accessibility permissions work) that the user could explicitly enable to let a trusted app manage their Home Screen layout. The user would stay in full control and could revoke it at any time. I understand there are solid privacy and security reasons behind the current restrictions, so I'm not looking for a workaround, I'm asking whether a supported, user-consented path could exist. Has anyone run into this or found any official guidance? And if this is better filed as a feature request through Feedback Assistant, I'm happy to do that too. Thanks!

Following up on my earlier thread about non-blocking interventions. I ran a clean, isolated test on iOS 26.5.2: I start DeviceActivityCenter.startMonitoring with a single event whose threshold is 2 minutes of usage for a selected app (includesPastActivity = false), with actions on eventDidReachThreshold. Result: the event's recorded trigger time is +0 seconds from monitoring start (immediate), it fires without any real usage, and after 2 minutes of actual use no notification and no ManagedSettings shield are applied. This matches the regression discussed in Forum thread 808470 / FB18061981. Concretely, the feature we want to build: while a user is using a selected app, deliver a repeating local notification every N minutes of usage (e.g., every 15 minutes) whose body states how many minutes they've used that app today (e.g., "You've used TikTok for 45 minutes today"). This is a gentle, factual awareness nudge — no blocking. This is exactly what eventDidReachThreshold with multiple thresholds (15/30/45 min…) + sendNotification would do, but that path is broken by the regression above. Questions: Is there a fix timeline for the eventDidReachThreshold immediate-fire regression (iOS 26.x)? Any FB to watch? What is the supported way to implement the feature above — a repeating notification every N minutes of usage, containing the cumulative minutes used today for that app — without relying on the broken threshold event? Specifically: a. How should we obtain the cumulative usage minutes for a selection to put in the notification body? Is the only source a DeviceActivityReport (which renders in an extension and isn't readable as a value in the app)? b. How should we trigger every N minutes of usage if threshold events are unreliable? Is there any usage-based trigger other than eventDidReachThreshold? Until a fix, is a DeviceActivitySchedule-based (wall-clock) approach the only reliable path? Is applying a ManagedSettings shield from the DeviceActivityMonitor extension expected to interrupt an app that is already in the foreground (mid-use), or only at next launch? Our app is non-blocking by design (a brief "pause" nudge + factual usage reminders), fully on-device, Family Controls (Distribution) approved. We'd rather build on a supported path. Thank you.