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.

I have a persistent WeatherKit authentication failure that could be server-side JWT minting not being enabled for my App ID. Every WeatherService.shared.weather(for:) call fails with: Failed to generate jwt token for: com.apple.weatherkit.authservice Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" The console shows the request reaching Apple's auth service and failing only at the JWT generation step. Account / app: Team ID: 634Q7K5DN8 Bundle ID: com.davidfrauenhofer.TripVault App: shipping on the App Store (this is an update adding a WeatherKit forecast) Device: iPhone 13 Pro, physical device (not simulator) Signing: Xcode automatic Everything I've verified locally: codesign -d --entitlements - on the installed binary confirms com.apple.developer.weatherkit = true, with application-identifier = 634Q7K5DN8.com.davidfrauenhofer.TripVault and matching com.apple.developer.team-identifier. WeatherKit is enabled on the App ID under both the Capabilities and App Services tabs, saved and confirmed. App ID Prefix equals my Team ID (634Q7K5DN8) — no legacy prefix mismatch. Fresh provisioning profiles downloaded; clean build folder; app deleted and reinstalled. Active Apple Developer Program membership; no pending agreements in App Store Connect. Valid coordinates passed (confirmed in logs). This has persisted for several weeks across many rebuilds and reinstalls so i should have cleared any propagation windows. Request to the WeatherKit team: Could someone verify whether JWT minting is enabled server-side for this Team ID / Bundle ID, and whether there is a stuck or incomplete WeatherKit registration for this App ID? Given the entitlement is confirmed present in the signed binary and all client-side configuration is correct, I believe this requires inspection of the auth-service registration on Apple's side. Happy to provide any additional logs or identifiers.

Hello, We are currently developing a macOS application and evaluating Managed Background Assets for delivering additional downloadable content. Our preference is to rely on Apple-hosted asset delivery as much as possible, rather than maintaining a separate CDN or server infrastructure. While reviewing the documentation and forum discussions, we found a few areas that are still unclear and would appreciate your guidance. 1. Scope of the 200GB Apple-hosted asset pack limit Some documentation and discussions seem to describe the 200GB limit as applying per Apple Developer Program team/account, while others suggest it is a per-app bundle limit. Could you clarify the exact scope of this limit? Is the 200GB quota applied per individual app bundle ID? Or is it shared across all apps under the same Apple Developer Program account? References: [LINK1] [LINK2] [LINK3] 2. Storage expansion and hybrid hosting Are there any plans to expand the Apple-hosted asset pack limits in the future, or is there an official process to request additional hosting capacity? If an app eventually exceeds the Apple-hosted limit, is it acceptable or technically possible to use a hybrid approach (i.e., using Apple hosting for some assets while self-hosting the rest)? 3. Recommended strategy for older macOS versions As we understand, Managed Background Assets are only available starting from newer OS releases. However, our application also supports older macOS versions, and we would ideally like to avoid maintaining a completely separate asset delivery backend for them. From Apple’s perspective, what is the recommended strategy in this situation? Is it expected that developers continue using Unmanaged Background Assets for older OS compatibility? Is it acceptable to support Managed Background Assets only on newer systems, while older OS versions simply do not receive the same downloadable-content functionality? Or is there another recommended migration/compatibility approach for apps supporting both newer and older macOS versions? Thank you in advance for your clarification!

Hello, We are currently evaluating ways to reduce the app size of the my App. The app contains approximately 200~250 MB of bundled static resources, and we are considering converting these resources into On-Demand Resources（ODR） in order to reduce the initial download and installation size of the app. However, we noticed that ODR is currently marked by Apple as a Legacy Technology. Since we would like these resources to continue being hosted and distributed through Apple CDN / App Store infrastructure, the first alternative we considered is Managed Background Assets, rather than regular Background Assets. We understand that regular Background Assets are available on iOS 16 and later, but they mainly address background download scheduling for apps. What we are specifically looking for is the resource hosting and distribution capability, similar to ODR, where assets can be hosted and delivered through Apple’s infrastructure. This is why we are considering Managed Background Assets. However, my App currently supports devices starting from iOS 14, while the key capabilities of Managed Background Assets require newer iOS versions. As a result, this solution cannot fully cover users who are still on older iOS versions, such as iOS 14 through iOS 18. Given this background, we would like to ask Apple the following questions: Does Apple have any plan to discontinue ODR-related services in the future, especially the App Store-hosted ODR asset download service? If the ODR service is changed or discontinued in the future, would it affect already released App Store apps that rely on ODR asset downloads on older iOS versions? For apps that still need to support iOS 14 and later, while also relying on Apple CDN / App Store infrastructure for resource hosting and distribution, does Apple still recommend using ODR? For apps that cannot immediately raise their minimum supported iOS version to the version required by Managed Background Assets, is there a recommended transition strategy? If ODR services are discontinued in the future, will Apple provide an alternative resource distribution solution that supports older iOS versions, or would developers need to build and maintain their own resource hosting and download system? We would like to better understand the long-term availability and potential risks of using ODR on older iOS versions, so that we can make an appropriate decision for future app size reduction and asset delivery in the App. Thank you.

Dear Apple Developer Support Team, I am writing to seek clarification on the timeline behavior and app status associated with the MetricKit cpuExceptionDiagnostics payload. In a recent diagnostic log collected from production, we observed the following values: timeStampBegin: "2026-07-07 10:37:00" timeStampEnd: "2026-07-07 10:37:00" totalSampledTime: "168 sec" Since both timeStampBegin and timeStampEnd share the exact same second (10:37:00), but the totalSampledTime indicates a continuous sampling duration of 168 seconds, we are having trouble accurately correlating this incident with our internal server logs. Could you please clarify the following questions: What exactly does the timestamp "2026-07-07 10:37:00" represent? Is it the sampling start time, the sampling end time, or the moment the diagnostic log was generated/written by the system? If "2026-07-07 10:37:00" represents the log generation time (or the moment the exception was triggered), how should we determine the actual start and end times of the 168-second sampling window? For instance, does it mean the sampling occurred strictly before this timestamp (from 10:34:12 to 10:37:00), or is there a different calculation method? Does a cpuExceptionDiagnostics event imply that the app crashed or was terminated by the OS? Or is it merely a non-fatal telemetry log capturing heavy CPU usage/resource limit violations while the app remained running? Understanding the precise timeline and lifecycle impact of MetricKit diagnostics is crucial for us to correlate client-side resource issues with backend performance and user activities. Thank you for your time and guidance. Best regards

Hey all, my first time posting on these forums as I've finally become completely stumped. I'm working to implement a ShareLink to share data between users on my app, and have gotten pretty far (file saves, sends correctly), but am having significant issues getting the link to open in my app when sharing by email and not getting any action at all when tapping a shared link in iMessage. I'll go through my setup below: I have declared my new UTType, and created my new model which conforms to transferable here: struct transferTemplate: Codable { var id: UUID = UUID() var name: String = "TempName" var words: [String] = ["word1","word2"] } extension transferTemplate: Transferable { static var transferRepresentation: some TransferRepresentation { CodableRepresentation(contentType: .oltemplate) } } extension UTType { static var oltemplate: UTType { UTType(exportedAs: "com.overloadapp.oltemplate") } } I have declared the document type in my info.plist: <key>CFBundleDocumentTypes</key> <array> <dict> <key>CFBundleTypeName</key> <string>Template Session</string> <key>LSHandlerRank</key> <string>Owner</string> <key>LSItemContentTypes</key> <array> <string>com.overloadapp.oltemplate</string> </array> </dict> </array> I have declared the Exported Type Identifier: <key>UTExportedTypeDeclarations</key> <array> <dict> <key>UTTypeConformsTo</key> <array> <string>public.json</string> </array> <key>UTTypeDescription</key> <string>Template Session</string> <key>UTTypeIconFiles</key> <array/> <key>UTTypeIdentifier</key> <string>com.overloadapp.oltemplate</string> <key>UTTypeTagSpecification</key> <dict> <key>public.filename-extension</key> <array> <string>oltemplate</string> </array> <key>public.mime-type</key> <array> <string>application/json</string> </array> </dict> </dict> </array> I've also included the "LSSupportsOpeningDocumentsInPlace" boolean to True in the PLIST. My physical ShareLink setup is: @State private var transferred: transferTemplate = transferTemplate(name: "NameTemplate", words: ["One","Two"]) ... ShareLink(item: transferred, preview: SharePreview("Share your template", image: Image("tanLogo"))) Heres where the above code gets you: ShareLink brings up the share sheet and allows you to send the file (with the .oltemplate file extension). Sharing via iMessage will send a file, but within iMessage, the file cannot be opened at all. By email, the file can be opened but does not show any information. If you open the ShareSheet within the email attachment, you can manually choose to open the file in my app. If the file is saved to "Files", it will open my app when it is tapped (work as intended). Heres what I have tried to fix this: Modifying the Exported File Type "Conforms to" value. Ive used public.data, public.text, public.json. Including and not including the mime type I've scoured forums trying to solve this issue, and it doesn't seem like there is a clear cut solution for this issue. I appreciate any help you can provide! Please let me know if I can include any more helpful information.

Hi, We’ve been observing crashes when calling “try await DeclaredAgeRange.AgeRangeService.shared.isEligibleForAgeFeatures”. Our crash logs show a “suspend resume partial function” crash from libswift_Concurrency.dylib swift::runJobInEstablishedExecutorContext. Based on our analysis, this is because once Apple’s eligibility check completes, it attempts to resume the Swift task continuation directly on its own internal background thread instead of yielding back to the Swift cooperative thread pool. Because the caller task inherits @MainActor isolation (due to a UIViewController being passed into our pipeline further up as it’s needed for requestAgeRange), the Swift runtime crashes when trying to reconcile the @MainActor context on Apple's foreign background thread. Has anyone encountered this and found a fix, and is this a known issue? Thanks!

Hi there, Starting with iOS 26.2 RC, all my DeviceActivityMonitor.eventDidReachThreshold get activated immediately as I pick up my iPhone for the first time, two nights in a row. Feedback: FB21267341 There's always a chance something odd is happening to my device in particular (although I can't recall making any changes here and the debug logs point to the issue), but just getting this out there ASAP in case others are seeing this (or haven't tried!), and it's critical as this is the RC. DeviceActivityMonitor.eventDidReachThreshold issues also mentioned here: https://developer.apple.com/forums/thread/793747; but I believe they are different and were potentially fixed in iOS 26.1, but it points to this part of the technology having issues and maybe someone from Apple has been tweaking it.

Hello dear community, I have an iMessage extension running perfectly on iOS 16.4, but on 17.0.1 and 17.1.1 it's having real issues. Messaging in iMessage on the iOS 17.0.1 simulator isn't working at all. MSMessageLiveLayout works perfectly on iOS 16.4, but on iOS 17.1.1 (physical iPhone 15, 14, 13, 12, SE 2020) the MSMessagesAppViewController won't render after didStartSending and subsequent willBecomeActive. The iPhones will just show "Loading...". I debugged through it, couldn't find any issues and works perfectly fine on iOS 16.4 both in the simulator and on a physical device. I'm debugging through the physical devices with XCode, but couldn't find any root cause on why. Has anyone experienced similar issues with MSMessagesAppViewController in iOS 17.1.1? Any ideas on how to fix this? Thanks, Jan

最常见的是这个： 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 ()

Hi, it seems that something in OS27b3 changed regarding Core Spotlight: Whatever I try, Siri and Spotlight only seem to find the text inside the title or displayName attribute. But attributes like textContent or contentDescription or keywords seem to be ignored. Those attributes are still found, when I do a manual search using CSUserQuery or using the AppEntityDefinition.spotlightQuery(_:) in App Intent Testing. I have already filed a Feedback – but wonder whether anyone else is having this issue? FB23635795 Thanks, Friedrich

Hi There, My app is a legacy project built with Objective C. The host app shared data with the service extension by using NSUserDefaults *userDefault = [[NSUserDefaults alloc] initWithSuiteName:@"group.com.myapp.project"]; and it worked until a customer recently reported a bug (iOS 18.6). After debugging, I found that data sharing from the host app to the service extension was not working correctly. The host app updated a field's value, but the service still used the old or stale value, causing the issue. HostApp saved info 2026-06-01 13:44:07.020 [INFO] (VMP)(ThreadID: 0x10a85c000): "Saved Vomo information { "EXT_AP_IP" = 1c28af0f9d73; "EXT_PING_DND" = 0; "EXT_PING_USER_NAME" = aaa08AA541F8; "EXT_SERIAL_ACK_TIME" = "2026-06-01 20:44:07 +0000"; "EXT_SERIAL_NO" = 689; "EXT_SERVER_NAME" = "10.xxx.xxx.182"; "EXT_VOICE_LOGIN" = 1; }" Service extension read value: 2026-06-01 13:46:09.678 [INFO] (VMP) - (EXTENSION)(ThreadID: 0x1050a41d0): "start Vomo with Server: [10.xxx.xxx.79] and userName [aaa08AA541F8]" I can see the value shared from host app is: 10.xxx.xxx.182, but service extension still took the stale value 10.xxx.xxx.79 First I thought it is synchronized issue, however, apple deprecated those API, CFPreferencesAppSynchronize((__bridge CFStringRef)@"group.com.myexample.project"); How to ensure the shared value successfully delivered to service extension? Thanks.

I am the developer of a screen time awareness app currently on the App Store. It uses the Family Controls and DeviceActivity frameworks, with the distribution entitlement approved, to show users their own cumulative screen time since install. All tracking today is fully on-device and nothing leaves the user's phone. I am planning an optional social feature and I want to confirm Apple's position before building it, because I want to stay clearly within the Developer Program License Agreement, specifically Section 3.3.3(P) regarding data received through the Family Controls framework. Here is how the feature would work: The app monitors the user's own device activity via DeviceActivityMonitor threshold events. This is the same mechanism the app already uses for its on-device counter. On-device, that counter is converted into an abstracted, gamified score. The score is not expressed in hours, minutes, or any unit of time, and the app never displays it as time. If, and only if, the user opts in to the feature, the app uploads a self-chosen username, the date the user's count began, and the user's abstracted score values to my backend. Score values may be computed over different time windows, for example a lifetime score alongside daily, weekly, or monthly scores, but they are all the same abstraction: no raw time totals, no per-app or per-category data, no contacts, and no identifiers beyond what the account itself requires. Friends who have mutually opted in see each other's usernames and scores on a leaderboard. The app never displays another person's screen time, and no time values are stored server-side. The feature is off by default, data is encrypted in transit and at rest, and users can delete their account and all associated data from within the app at any time. The privacy policy will disclose all of this. My question: does transmitting this opt-in, abstracted score, derived on-device from DeviceActivity threshold events, comply with DPLA Section 3.3.3(P) and the intended use of the Family Controls framework? If this specific design is not acceptable, is there any form of opt-in social comparison feature that would be, and what constraints would it need to satisfy? I am aware of earlier threads here where sending screen time data off-device was flagged as non-conforming, which is exactly why I am asking before writing any code rather than after. I would rather design this correctly from the start than risk a rejection later. Thank you for your time. Happy to provide any additional detail about the design.

The Deligate 'didFetchResult' method of fetching data past 24 hours from SensorKit is not being called. It is confirmed that you have already granted full access to the SensorKit and that data on the Ambient value in the device's personal information -> research sensor & usage data are recorded. It is possible to export to an lz4 file. I want to have the data after 24 hours called to the app, but other Deligate methods are called, but only Deligate that gets the illumination value is not called. Is it understood that only data past 24 hours can be imported after startRecoding() is called? If so, in order to receive data past 24 hours, do I have to continue to receive the illumination data value in the background for more than 24 hours to receive the Ambient value afterwards? import Foundation import SensorKit import UIKit final class SensorKitManager: NSObject, ObservableObject, SRSensorReaderDelegate { static let shared = SensorKitManager() private let ambientReader = SRSensorReader(sensor: .ambientLightSensor) var availableDevices: [SRDevice] = [] @Published var ambientLightData: [AmbientLightDataPoint] = [] var isFetching = false var isRecordingAmbientLight = false private override init() { super.init() setupReaders() checkAndRequestAuthorization() } private func setupReaders() { ambientReader.delegate = self } // MARK: - Permission Request func requestAuthorization() { SRSensorReader.requestAuthorization(sensors: [.ambientLightSensor]) { [weak self] error in DispatchQueue.main.async { guard let self = self else { print("Permission request aborted") return } if let error = error { print("Permission request failed: \(error.localizedDescription)") } else { print("Permission request succeeded") self.startRecordingAmbientLightData() } } } } func checkAndRequestAuthorization() { let status = ambientReader.authorizationStatus switch status { case .authorized: print("Ambient light sensor access granted") startRecordingAmbientLightData() case .notDetermined: print("Ambient light sensor access undetermined, requesting permission") requestAuthorization() case .denied: print("Ambient light sensor access denied or restricted") @unknown default: print("Unknown authorization status") } } // MARK: - Ambient Light Data Logic func startRecordingAmbientLightData() { guard !isRecordingAmbientLight else { print("Already recording ambient light data.") return } print("Starting ambient light data recording") isRecordingAmbientLight = true ambientReader.startRecording() fetchAmbientLightData() fetchAmbientDeviceData() } func fetchAmbientLightData() { print("Fetching ambient light data") let request = SRFetchRequest() let now = Date() let fromTime = now.addingTimeInterval(-72 * 60 * 60) let toTime = now.addingTimeInterval(-25 * 60 * 60) request.from = SRAbsoluteTime(fromTime.timeIntervalSinceReferenceDate) request.to = SRAbsoluteTime(toTime.timeIntervalSinceReferenceDate) print("Fetch request: \(fromTime) ~ \(toTime)") ambientReader.fetch(request) } private func displayAmbientLightData(sample: SRAmbientLightSample) { print("Ambient light: \(sample.lux.value) lux") print("Current ambientLightData content:") for data in ambientLightData { print("Timestamp: \(data.timestamp), Lux: \(data.lux)") } } // MARK: - Device Data Logic private func fetchAmbientDeviceData() { print("Fetching device information") let request = SRFetchRequest() let now = Date() let fromDate = now.addingTimeInterval(-72 * 60 * 60) let toDate = now.addingTimeInterval(-24 * 60 * 60) request.from = SRAbsoluteTime(fromDate.timeIntervalSinceReferenceDate) request.to = SRAbsoluteTime(toDate.timeIntervalSinceReferenceDate) if availableDevices.isEmpty { print("No devices available") ambientReader.fetchDevices() } else { for device in availableDevices { print("Starting data fetch (Device: \(device))") request.device = device ambientReader.fetch(request) print("Fetch request sent (Device: \(device))") } } } // MARK: - SRSensorReaderDelegate Methods func sensorReader(_ reader: SRSensorReader, didFetch devices: [SRDevice]) { availableDevices = devices for device in devices { print("Fetched device: \(device)") } if !devices.isEmpty { fetchAmbientDeviceData() } } func sensorReader(_ reader: SRSensorReader, fetching fetchRequest: SRFetchRequest, didFetchResult result: SRFetchResult<AnyObject>) -> Bool { print("sensorReader(_:fetching:didFetchResult:) method called") if let ambientSample = result.sample as? SRAmbientLightSample { let luxValue = ambientSample.lux.value let timestamp = Date(timeIntervalSinceReferenceDate: result.timestamp.rawValue) // Check for duplicate data and add it if !ambientLightData.contains(where: { $0.timestamp == timestamp }) { let dataPoint = AmbientLightDataPoint(timestamp: timestamp, lux: Float(luxValue)) ambientLightData.append(dataPoint) print("Added ambient light data: \(luxValue) lux, Timestamp: \(timestamp)") } else { print("Duplicate data, not adding: Timestamp: \(timestamp)") } // Output data self.displayAmbientLightData(sample: ambientSample) } return true } func sensorReader(_ reader: SRSensorReader, didCompleteFetch fetchRequest: SRFetchRequest) { print("Data fetch complete") if ambientLightData.isEmpty { print("No ambient light data within 24 hours.") } else { print("ambientLightData updated") for dataPoint in ambientLightData { print("Added ambient light data: \(dataPoint.lux) lux, Timestamp: \(dataPoint.timestamp)") } } } }

Hello, I have an app for a research study that has been approved and authorized to use SensorKit. All my permissions, entitlements and authorizations are in order, but I still can't get any data. The didFetchResult is not being called even though didCompleteFetch is called. I have waited for over 24 hours, but it still returns no samples. Please, I would appreciate any help on this issue. Thank you func sensorReader( _ reader: SRSensorReader, fetchingRequest: SRFetchRequest, didFetchResult result: SRFetchResult<AnyObject> ) { receivedResultsInCurrentFetch = true print("✅ SensorKit fetch result received for: \(sensorKey)") AppLogger.shared.log("SensorKit fetch result received for \(sensorKey)") if let sample = result.sample as? T { print("✅ SensorKit sample matched expected type for \(sensorKey): \(T.self)") AppLogger.shared.log("SensorKit sample matched expected type for \(sensorKey): \(T.self)") processSample(sample) } else { print("❌ SensorKit sample did not match expected type for \(sensorKey): \(T.self)") AppLogger.shared.log("SensorKit sample did not match expected type for \(sensorKey): \(T.self)") } } func sensorReader(_ reader: SRSensorReader, didCompleteFetch request: SRFetchRequest) { if receivedResultsInCurrentFetch, let lastRequestedUpperBound { session.setSensorKitLastFetchTime(lastRequestedUpperBound, for: sensorKey) print("✅ SensorKit fetch completed with samples for \(sensorKey). Checkpoint updated.") } else { print("⚠️ SensorKit fetch completed for \(sensorKey) with no samples.") AppLogger.shared.log("SensorKit fetch completed for \(sensorKey) with no samples. Keeping previous checkpoint so delayed SensorKit data is not skipped.") } isFetchInFlight = false completePendingFetches(success: true) print("✅ SensorKit fetch completed for: \(sensorKey)") AppLogger.shared.log("Fetch request completed for sensor type: \(T.self)") }

We have a published, approved App Clip that works correctly via QR code and the Safari Smart App Banner, but URL-based invocation does not trigger the App Clip card in any context. Most notably, Apple's own default App Clip URL does not work either: https://appclip.apple.com/id?p=hazel-torus.Clip **Tapping this link in Messages or Notes does nothing. ** Long-pressing it shows a generic website link preview rather than the App Clip card, even though appclip.apple.com is Apple's domain and requires no configuration on our end. Setup details: App Clip bundle ID: hazel-torus.Clip Team ID: 2UNR2APH47 App Clip experience URL: https://passportreader.app/open AASA includes a correctly formatted appclips key with 2UNR2APH47.hazel-torus.Clip (confirmed via https://app-site-association.cdn-apple.com/a/v1/passportreader.app that AASA is correctly cached) Associated Domains entitlements (appclips:passportreader.app) are present on the App Clip target App and App Clip experience are both Approved / Ready for Sale Tested on two physical devices, neither with the full app installed Since QR and Safari banner invocation work, the App Clip itself and its entitlements appear correctly configured. The fact that even Apple's own appclip.apple.com URL fails, and is treated as an arbitrary website link, suggests this may be a backend indexing issue specific to this App Clip rather than a client-side configuration problem. Has anyone else encountered this, or know what could cause appclip.apple.com to not be recognized as an App Clip URL?

In the System Settings > General > Login Items & Extensions - Extensions pane, when I select the By App tab, I can see multiple instances of extensions for different applications and sub-types. e.g. Books (from Apple) is listed twice with the Sharing subtype. For the specific extension I'm checking, I can see multiple instances listed for the File Provider sub-type. The number of instances does not seem to correspond to anything. There are 5 instances listed and it seems like these are not exact duplicates because when I disable one using the (i) dialog, the others are still enabled. This number (5) corresponds to nothing obvious: at one time, there is only 1 instance of the File Provider (a Finder Extension) installed. if I use the pluginkit command line tool to list the extensions, it only reports 3 known versions of this extension. As a developer I'm puzzled by this list with duplicates. As an end user, I'm totally puzzled by this list with duplicates. macOS Tahoe 26.5 (25F71) [Q] What is this list in the Login Items & Extensions pane supposed to represent? Is it known to be buggy when it comes to its contents?

Hi everyone, I am facing a critical issue where the CallKit provider delegate method provider(_:didActivate:) is intermittently not triggered. This occasionally results in a total loss of audio during some VoIP calls, while other calls work perfectly fine. Here is the sequence of steps I am currently implementing: Report Incoming Call: The app receives a VoIP push notification and reports the call using reportNewIncomingCall(with:update:completion:). Answer Action: The user taps the answer button, and the app processes the CXAnswerCallAction. Configure Audio Session: Inside the provider delegate, I configure the AVAudioSession category and mode (e.g., setting category to .playAndRecord and mode to .voiceChat). Note: As per Apple's guidelines, I do not call setActive(true) manually, expecting CallKit to activate it automatically. Despite following this standard flow, there are times when provider(_:didActivate:) is skipped entirely, meaning the audio engine fails to initialize for that specific call session. We are currently receiving a large volume of user complaints regarding this issue, as it heavily impacts the core calling experience in production. Could an Apple engineer or anyone from the community look into this? Any insights into what might be causing CallKit to occasionally fail to activate the audio session or how to work around this would be highly appreciated. Thank you!

I would like to clarify the expected behavior of a default App Clip link regarding tap responsiveness. Issue: When I tap the default App Clip invocation URL in Safari or the Notes app, the first tap does not respond (no App Clip card appears). Only the second tap successfully presents the App Clip card. Steps to Reproduce: Place the default App Clip URL in Safari (or Notes app) Tap the link once → no App Clip card appears Tap the same link again → App Clip card appears as expected Environment: Invocation source: Safari / Notes app App Clip type: Default App Clip experience (appclip.apple.com URL) Observation: This issue reliably occurs when there is no cached App Clip metadata on the device. When the metadata is already cached, the App Clip card appears on the first tap as expected. What I've already checked: Not in Private Browsing mode Question: Is this the expected behavior? Is there a recommended way to make the first tap reliably present the App Clip card even without a pre-existing cache? Thank you for your assistance.

The context is partially expressed in an earlier post. In summary: There is an iOS App target that contains minimal code, only to load a Framework explicitly at runtime using dlopen and dlsym, instead of the usual load-time imports in Apple platforms. For iOS app (C++ (primary) and Swift), the entry point is a UIApplicationDelegate conformer class - AppDelegate, marked with @main. But the problem is, the AppDelegate class cannot remain in the App target, which has barely any logic. The App target is a thin loader. The AppDelegate contains some methods such as application(_:didRegisterForRemoteNotificationsWithDeviceToken:) that needs some logical processing, which is not present in the App target. Instead of using dlsym (to hand over to the Framework) for every AppDelegate event that doesn't have a broadcast notification, the thought was to move the AppDelegate class into the Framework, and the entry point in App target is now main.swift. This keeps the Framework clean and minimal with the following steps: Interop to C++ Explicitly loading the MachO binary inside the Framework using dlopen Loading the symbol using dlsym Invoking the Framework entry point Then, the Framework entry point in C++ creates the UIApplication class and the UIApplicationDelegate using UIApplicationMain(_:_:_:_:) method, which doesn't return as it transfers control to the UIApplicationDelegate. This is against the recommended @main entry point, but based on research, @main seems like syntactic sugar to avoid writing boilerplate code. But in my case, which needs to avoid instantiating the UIApplicationDelegate in the App target, using main.swift, even for an iOS app, is the best fit. I understand that main thread has to be returned back to the OS asap for processing user events etc., and the intent is to not execute the entire startup logic of the app in main thread. Wanted to confirm if this approach of using main.swift entry point is valid for iOS, iPadOS and tvOS apps too and in which case, these flows can converge to macOS, which is already using main.swift approach.