Starting in iOS 27, opening a tel: URL that contains a call-forwarding MMI code from an app shows a system alert and dials nothing: Malicious Link Blocked: This link was blocked because it contains malware that will forward all of your incoming messages and calls to 1 (XXX) XXX-XXXX. Scammers often provide malicious links that look legitimate via email, text, or chat. On iOS 26 the same call showed the normal call confirmation prompt and the carrier applied the forwarding. Repro (in response to a button tap): UIApplication.shared.open(URL(string: "tel:*21*XXXXXXXXXXX%23")!) Typing *21*XXXXXXXXXXX# into the Phone app's keypad by hand still works on iOS 27, so the capability is still there; only the in-app handoff is blocked. This breaks setup for call-screening and visual-voicemail apps whose onboarding depends on carrier forwarding (*21*, *61*, *67*, *71*, *72). It also blocks the disable codes (##21#, ##004#, *73), so users can't turn forwarding off from inside the app, which works against the user's own safety. The anti-hijack intent makes sense for links arriving from Messages, Mail or Safari. For a user tap inside an installed App Store app, a confirmation sheet ("Forward calls to ...? Allow") seems like the right balance, and disable codes should always be allowed. Filed as FB24843805. Questions: Is this block meant to apply to links opened by an installed app in response to a user tap? Is there a supported API, entitlement or URL form to hand a forwarding code to the Phone app with user confirmation? Our current workaround is to copy the code to the clipboard and ask the user to paste it into the keypad, which is a real drop-off point for our (mostly older) users. If you're affected too, please file your own feedback and reference FB24843805.

We receive live relative-altitude updates from CMAltimeter.startRelativeAltitudeUpdates(to:withHandler:) on iPhone. CMAltitudeData inherits CMLogItem.timestamp, which the documentation describes as the time when the item is valid and as seconds since device boot. We need to determine whether a pressure measurement's event time falls inside an application operation bounded by a supported monotonic clock. Could Apple clarify the supported contract for CMAltitudeData.timestamp on iOS? Does CMAltitudeData.timestamp use the same epoch and rate as mach_absolute_time(), DispatchTime.uptimeNanoseconds, CACurrentMediaTime(), or ProcessInfo.systemUptime? If only some are compatible, which ones? Does it advance or pause during device sleep, device lock, application suspension, and background execution? In particular, are its sleep/suspension semantics guaranteed to match any of the clocks above? Is there a supported API for converting CMLogItem.timestamp to a host CMClock/Mach time, or for sampling “now” in the exact same clock domain used by CMAltitudeData.timestamp? Are the answers contractual across supported iPhone hardware and iOS releases, or are they implementation details that applications should not rely on? If direct comparison is not supported, what Apple-supported clock or conversion mechanism should an application use to compare a CMAltitudeData event time with two application-side monotonic operation boundaries? The question concerns clock semantics only. A minimal reproducer can be supplied if requested, but no application identifier, production data, sensor values, or user data is required to answer it.

Subject: Hard SMC and Kernel bug on 14" MacBook Pro M5 Pro (Mac17,9) in Build 26B5091g - High Power Mode completely unresponsive Hello CoreOS and Apple Silicon Performance Engineering Teams, I am writing to report a severe, reproducible system-level regression regarding High Power Mode and SMC power distribution on the new 14-inch MacBook Pro with the M5 Pro chip (Model Identifier: Mac17,9), currently running macOS 27.2 Beta 2 (Build 26B5091g). The issue prevents the M5 Pro hardware from scaling its cooling and power envelope correctly, rendering High Power Mode completely broken regardless of the power source (tested with both official 96W and 140W Apple power adapters). Key technical diagnostic findings from my device: Kernel vs UI State Mismatch: Running pmset -g via Terminal returns powermode 2, proving that the kernel registers High Power Mode as active. However, the System Information profile reader (Hardware -> Power) shows a direct conflict: "High Power Mode: No" and "Low Power Mode: Yes" (Режим энергосбережения: Да). Unresponsive SMC & Fan Curves: The cooling hardware remains completely unresponsive to the high-performance toggle. The fans fail to engage the pre-emptive 4500-5000 RPM cooling curve under heavy compute or gaming loads, remaining locked in the silent "Automatic" profile, which causes artificial thermal constraints. Powermetrics Telemetry Anomalies: A raw powermetrics trace captured during this state reveals a severe thread management bug: The P0-Cluster (High-Performance cores) shows a down residency of 98.88%, meaning the heavy performance cores are effectively kept asleep by the OS governor during high-power configuration. Combined Power (CPU + GPU + ANE) drops to a mere 429 mW. The thermal sampler entirely fails to pull hardware RPM telemetry from the SMC fan loops, providing only a generic "Current pressure level: Nominal" string. This profile behavior confirms that the macOS 27.2 power governor layer is suffering from a hard breakdown in SMC communication specific to the J614/Mac17,9 platform. The operating system handles the software flag but fails to pass the physical instruction downstream to the hardware control registers. Please prioritize this issue for the next macOS 27.2 beta cycle to ensure full thermal and compute optimization for the M5 Pro architecture prior to the final public release. I have attached the complete sysdiagnose archive, terminal configuration text files, and raw powermetrics logs. Thank you for your dedication to Apple Silicon optimization. FB24929043

We are seeing a reproducible issue on a physical iPhone with Dynamic Island. Steps to reproduce Install and launch version 1 of the app locally. Start background location tracking using CLLocationUpdate.liveUpdates() together with CLBackgroundActivitySession. Move the app to the background. The blue location indicator appears in the Dynamic Island. While tracking is still active, install version 2 over the existing app. Open the updated app. Stop all location tracking: Cancel the CLLocationUpdate task. Call invalidate() on the CLBackgroundActivitySession. Release all references to the session. Move the app to the background again. Expected behavior The blue background location indicator disappears after the location updates and background activity session have been stopped. Actual behavior The blue location indicator remains permanently visible in the Dynamic Island, even though: No location updates are being received. No CLBackgroundActivitySession is retained. Starting and stopping another location session does not remove it. Force-quitting and reopening the app does not remove it. Only restarting the iPhone makes the indicator disappear. The problem occurs when a new build is installed over an existing installation while a background location session is active. Starting and stopping the same session normally within one installed version works as expected. Comparison with Live Activity background location The app also has a separate location feature that uses an active Live Activity to support background location updates without creating a CLBackgroundActivitySession. Installing a new build while that feature is active does not cause the blue location indicator to become stuck. The problem has only been reproduced when a CLBackgroundActivitySession is active during the installation. This suggests that the issue is specifically related to transferring or cleaning up CLBackgroundActivitySession state across an app update, rather than to CLLocationUpdate.liveUpdates() itself. Questions Is this a known issue with CLBackgroundActivitySession or CLLocationUpdate.liveUpdates()? Is there a supported way for the newly installed app process to invalidate or clean up a background location session created by the previous app process?

I'm using the macOS 26 vmnet network API with Virtualization framework (vmnet_network_create + VZVmnetNetworkDeviceAttachment) and giving each VM a stable address with vmnet_network_configuration_add_dhcp_reservation, plus creation-time rules from vmnet_network_configuration_add_port_forwarding_rule. Both work on the network's first run. But if the network's last interface leaves while I still hold the vmnet_network_ref, then the next interface start brings the network back without its reservations or forwarding rules. The subnet and gateway are kept. How it shows up in practice: a VM that is the only guest on its network gets restarted from inside the guest. Virtualization framework removes and re-adds the VM's vmnet interface about 1 s apart, with no delegate callback. That's enough to stop and restart the network, and the guest comes back on a dynamic lease with its forwarded ports refused. Minimal repro, no VM needed: Create a configuration in VMNET_SHARED_MODE with set_ipv4_subnet, one add_dhcp_reservation and one add_port_forwarding_rule, then call vmnet_network_create. vmnet_interface_start_with_network. InternetSharing logs port forwarding enabled …, and /etc/bootptab contains the reservation. vmnet_stop_interface. InternetSharing logs no internal interface left, stopping network → reset to idle, and /etc/bootptab is emptied. vmnet_interface_start_with_network again on the same, still-retained ref. InternetSharing logs has been started with no port forwarding enabled line, and /etc/bootptab is never rewritten. The forwarded port is refused. Control: release the ref, call vmnet_network_create again from the same configuration, and start an interface. The reservation and the rule are both back. Reproduced on macOS 27.0 (26A428) and (with a minimal vmnet only test, no actual VM) on macOS 26.6.2 (25G83). This seems to contradict the documentation for vmnet_network_create: "The lifetime of such reservation is the same as that of vmnet_network_ref." A related issue: vmnet_interface_add_ip_port_forwarding_rule and its remove and get counterparts return VMNET_FAILURE synchronously on an interface started with vmnet_interface_start_with_network. The same calls work on a vmnet_start_interface interface. The add_port_forwarding_rule documentation points to those calls for managing rules after start, so there's no way to put a rule back after the restart. The same "torn down on last detach while the ref lives on" lifecycle is also reported in apple/container#2051 (https://github.com/apple/container/issues/2051), with a different symptom (two networks sharing a bridge, so tearing one down breaks the other's egress). It proposes the same mitigation: an anchor interface held with vmnet_interface_start_with_network. Filed as: FB24895271: reservations and rules discarded when the last interface is removed FB24895264: the runtime forwarding calls fail on network-attached interfaces FB24895282: suggestion for a network state-change callback and a DHCP lease query by MAC Questions: Is losing reservations and rules when the network goes idle intended? Is holding an app-owned interface on the network (via vmnet_interface_start_with_network) so it never reaches zero interfaces a supported workaround, or does it risk other side effects?

We are evaluating a lifecycle architecture for a local macOS application and would appreciate guidance on supported public APIs. Proposed architecture: A normally signed, non-root host application. One embedded XPC service with exactly one intended client. No application-created subprocesses inside the service. No privileged helper, persistent LaunchAgent, exported endpoints, private APIs, or reduced system security. One bounded operation per session. Failed or interrupted operations must not automatically be retried. Initial validation would use synthetic workloads only. Our current evaluation target is macOS 15.6 on Apple silicon, using the macOS 15.5 SDK. Please identify any relevant deployment-version limitations. The XPC overview (https://developer.apple.com/documentation/xpc) describes an embedded service as tied to its client's lifetime. We also understand that xpc_connection_cancel (https://developer.apple.com/documentation/xpc/xpc_connection_cancel(_:)) is asynchronous and non-preemptive; we are not treating connection cancellation as proof of service termination. We need clarification on these points: Client death and service startup Does the documented client-lifetime relationship cover client termination, including SIGKILL, during service startup before the first reply? Does it also cover an already running service that is blocked or stopped with SIGSTOP? Which behavior is guaranteed, and which timing or failure cases are intentionally unspecified? Timeout while the client remains alive What supported public mechanism should a normal application use to terminate its own unresponsive embedded service when an operation exceeds its deadline? We want to avoid PID enumeration, PID-reuse races, broad process-group signaling, and exporting a full task-control port. Is there a supported identity-bound termination mechanism? If not, what architecture does Apple recommend? A stopped or hung client remains alive, so we do not assume client-lifetime coupling handles that separate failure case. Observing termination Which public notification reliably identifies the exit of the particular service instance, as distinct from connection invalidation or a missing reply? Because launchd is the parent, the application cannot simply waitpid the service. Is reaping entirely launchd's responsibility, and what completion claim can the application legitimately make? Identity and required privileges Which public signing requirements, launch constraints, sandbox settings, or entitlements are necessary for this architecture? Please distinguish authentication before accepting work from constraints enforced before service code executes. We do not assume peer authentication also grants termination rights. Restart behavior After interruption, cancellation, client exit, or service failure, under what circumstances can launchd or subsequent XPC activity start a replacement service? What supported pattern prevents accidental resubmission or resumption of the same failed operation? We are not asking for hard real-time guarantees during kernel failure, or claiming that forced termination proves callback completion or explicit memory zeroization. If this combination of requirements is unsupported, identifying that boundary and the smallest supported architectural alternative would be a useful answer. Documentation references or a minimal public sample would be welcome.

After scouring the XNU kernel source code, I came across restartable ranges [1]. They seem to be a task-level version of the the part of Linux's restartable sequences [2] for user requested synchronization [3] (akin to MEMBARRIER_CMD_RSEQ). Because of their differences, I would like to know more about how they work and what they are used for. From what I have gathered [4], they seem to be closer to RCU [5] that waits for eviction (as opposed to completion). But the fact that they are barely mentioned anywhere (see [4]) in the XNU source code I'd be really happy if you can point me to more information about them and how they compare to rseq (or rcu). What are the XNU devs planning on doing with them? [1] osfmk/kern/restartable.c: https://github.com/apple-oss-distributions/xnu/blob/f6217f8/osfmk/kern/restartable.c [2] https://criu.org/Restartable_Sequences [3] as opposed to (what I think is what makes rseq really cool) automatic eviction on preemption/CPU migration [4] there seems to be very little information online (including this forum) and the only places inside the XNU kernel source trees that aren't tests are in osfmk/kern/{thread,thread,sched_prim}.{c,h}, which doesn't really give much more information. [5] Read-Copy-Update: https://www.kernel.org/doc/html/latest/RCU/whatisRCU.html

I'm trying to write a NWProtocolFramerImplementation class that will be channeled through a Framer wrapper. There are still some parts I need figuring out. For handleOutput(framer: message: messageLength: isComplete), what do the last two parameters do? Does isComplete refer to the end of the current conversation, or the entire connection? Why would we submit a messageLength if the data size should already be implied within message? If I parse by line breaks, is there a way to indicate if the latest line is the last of the current conversation, either input or output?

We need to retain CarPlay's native A–Z button between the scroll arrows in an audio app. This is core navigation for an album/artist library. We use CPListSection(items:header:sectionIndexTitle:) with single-character labels. The sectionIndexTitle API is still documented and is not deprecated in the Xcode 27 SDK. We need the supported native implementation, not a custom picker. On a parked physical head unit with an iPhone running iOS 27, our app displays populated album rows and section headers but no A–Z. Apple Music displays A–Z on the same head unit. We do not know Apple Music's internal implementation. A standalone, public-API-only reproduction is prepared; its CarPlay scene code is included below. Each tab supplies four A/B/M/Z sections of ten synthetic rows. The variants are initially populated, updated after loading, the full section initializer, and securely archived and decoded sections. No network, authentication or artwork is required. The original app displays functioning native alphabet navigation on the iOS 26.5 CarPlay simulator. The public probe compiles. We cannot run an end-to-end iOS 27 CarPlay simulator session because Device Hub requires a physical device, as confirmed in developer forum thread 834440. Separately, an isolated local diagnostic hosted the native list renderer with CarPlay traits. Both runtimes receive four nonempty index labels and all 40 rows. On iOS 26.5 (23F77), its table data source returns A/B/M/Z. On iOS 27.0 (24A434), the attached UICollectionViewDiffableDataSource returns nil index titles. Both the full initializer and secure archive round-trip preserve titles but produce the same result. This diagnostic is not an end-to-end CarPlay session and does not establish the exact internals on the physical phone. A standard UIKit table supplied with index titles and CarPlay traits still displays the native A–Z button on the same iOS 27 runtime. The control itself still exists; the observed failure is the template-to-index connection. This control experiment is also hosted in a phone window, not a CarPlay session. A standard UIKit collection data source implementing indexTitles(for:) also shows index letters on this runtime; the unmodified template renderer's collection data source returns nil. We have not modified that renderer. Questions: Did iOS 27 move native CPListTemplate alphabet navigation to another API, configuration, or presentation requirement? What is the supported migration? If sectionIndexTitle remains the correct input, is this a known regression in the new list renderer, and what supported correction is available? How should third-party audio apps reproduce Apple Music's native alphabet navigation on iOS 27 without private API or replacing it with a custom control? Please provide a working public-API example or identify the relevant fix/version. Reproduction: use the audio CarPlay entitlement and configure CPTemplateApplicationScene with CarScene as its delegate. This is the scene code from the compiling standalone probe: import CarPlay import UIKit @MainActor func indexedSections() -> [CPListSection] { ["A", "B", "M", "Z"].map { letter in let items = (1...10).map { number in let item = CPListItem(text: "\(letter) Album \(number)", detailText: "Synthetic test entry") item.handler = { _, completion in completion() } return item } return CPListSection(items: items, header: letter, sectionIndexTitle: letter) } } final class CarScene: UIResponder, CPTemplateApplicationSceneDelegate { func templateApplicationScene(_ scene: CPTemplateApplicationScene, didConnect controller: CPInterfaceController) { let ready = CPListTemplate(title: "Ready", sections: indexedSections()) ready.tabTitle = "Ready" ready.tabImage = UIImage(systemName: "list.bullet") let updated = CPListTemplate(title: "Updated", sections: [CPListSection(items: [CPListItem(text: "Loading", detailText: nil)])]) updated.tabTitle = "Updated" updated.tabImage = UIImage(systemName: "arrow.clockwise") let full = CPListTemplate(title: "Full Init", sections: indexedSections().map { CPListSection(items: $0.items, header: $0.header ?? "", headerSubtitle: nil, headerImage: nil, headerButton: nil, sectionIndexTitle: $0.sectionIndexTitle) }) full.tabTitle = "Full Init" full.tabImage = UIImage(systemName: "list.bullet.rectangle") let decoded: CPListTemplate do { let sections = try indexedSections().map { section in let data = try NSKeyedArchiver.archivedData(withRootObject: section, requiringSecureCoding: true) guard let restored = try NSKeyedUnarchiver.unarchivedObject(ofClass: CPListSection.self, from: data) else { throw CocoaError(.coderReadCorrupt) } return restored } decoded = CPListTemplate(title: "Decoded", sections: sections) } catch { decoded = CPListTemplate(title: "Decode failed", sections: [CPListSection(items: [ CPListItem(text: "Section decoding failed", detailText: String(describing: error)) ])]) } decoded.tabTitle = "Decoded" decoded.tabImage = UIImage(systemName: "shippingbox") controller.setRootTemplate(CPTabBarTemplate(templates: [ready, updated, full, decoded]), animated: false) { _, _ in } Task { @MainActor in try? await Task.sleep(for: .seconds(2)) updated.updateSections(indexedSections()) } } }

I’m building an iOS app using MapKit that allows users to create and navigate trails. I need offline map functionality, I was wondering if MapKit supports that. If not I was wondering if MapBox is a viable alternative to MapKit though I would prefer using MapKit. Thanks!

Hi, I’m developing a macOS Finder Sync extension and noticed that NSMenuItem.separator() does not appear to render as a standard separator line when used inside the menu returned from FIFinderSyncController. In a normal AppKit NSMenu, the separator renders as expected. However, when the same kind of menu is returned from the Finder Sync extension, the separator appears as a blank/full-height empty row rather than a thin dividing line. Example: override func menu(for menuKind: FIMenuKind) -> NSMenu { let menu = NSMenu(title: "") menu.addItem(NSMenuItem( title: "First Action", action: #selector(firstAction(_:)), keyEquivalent: "" )) menu.addItem(NSMenuItem.separator()) menu.addItem(NSMenuItem( title: "Second Action", action: #selector(secondAction(_:)), keyEquivalent: "" )) return menu } Expected result: The separator should render as a normal macOS menu separator line between the two menu items. Actual result: In Finder’s context menu, the separator is displayed as blank vertical space / an empty menu row. I understand that Finder Sync menus are rendered by Finder and may not support every NSMenuItem feature. However, NSMenuItem.separator() is a very standard way to visually group menu commands, so I wanted to ask: Is this a known limitation of Finder Sync extension menus? Is there a supported way to display a real separator line in Finder Sync context menus? Should this be filed as a Feedback Assistant issue against Finder Sync / AppKit? I’m trying to avoid fake separators such as disabled menu items with "────" as the title, since that does not feel native and may not behave well with different fonts, accessibility settings, or appearance modes. Thanks!

Hi, Overview I have a SwiftData project which automatically syncs with CloudKit. When I run the app, I see the following error in Xcode logs. Error updating background task request: Error Domain=BGSystemTaskSchedulerErrorDomain Code=3 "(null)" My attempt I can enable Background processing (under Signing & Capabilities > Background modes), but I don't know the BGTaskSchedulerPermittedIdentifiers to add in the Info.plist Questions How can I resolve this? If I should enable background processing, what are the BGTaskSchedulerPermittedIdentifiers to add in Info.plist?

Hi, Problem I have a widget which displays a bright red. When I display the same view inside the app, the red is bright. However when I use the same view on the widget, the color looks a bit dull. Note: Widget Style: Default (Always) It is the same dull red when in focus and when not in focus This happens on iOS (device and simulator) and macOS Questions How can I fix it on the widget? Does widget support Display P3 colors? Any help on this would be much appreciated.

Looking for guidance on how to escalate a PassKit issue that appears to be at the team-account level, after two months of exhausting every client-side variable. SYMPTOM Every .pkpass I sign under team XMJKFS3D66 (Mesh Community AS, Norway) is silently rejected on install with: "Sorry, your Pass cannot be installed to Passbook at this time." The rejection is silent — no user-facing hint at what iOS objects to. WHAT I'VE RULED OUT Reproduced across: 3 separate Pass Type IDs (pass.com.meshcommunity.membership original, .membership after re-issue, brand-new pass.com.meshcommunity.kiosk) 2 independently-issued signing certs on the same identifier 3 iPhone testers on 3 different iOS builds with different Apple IDs Paris Pinkney (WWDR DTS) sent me the standard 6-item team-wide checklist on Aug 5, and I'm verifiably clean on all six: Cert not expired — notBefore 2026-07-08, notAfter 2027-08-07 Cert not revoked — OCSP status "good" from ocsp.apple.com/ocsp03-wwdrg404 WWDR G4 intermediate matches cert issuer OU Program membership active, latest PLA accepted Both Pass Type IDs Active in Portal Team ID XMJKFS3D66 matches everywhere (pass.json.teamIdentifier + cert OU) Also verified: openssl smime -verify -in signature -inform DER -content manifest.json -noverify → "Verification successful" Full chain in signature: Pass Type ID cert → WWDR G4 → Apple Root CA PKCS#7 detached, DER, SHA-256, -noattr CDN serves application/vnd.apple.pkpass THE DEFINITIVE TEST To rule out the last remaining plausible client-side hypothesis (missing primaryFields causing a silent layout rejection, suggested by an independent review), I built a minimal known-good pass: { "formatVersion": 1, "passTypeIdentifier": "pass.com.meshcommunity.kiosk", "teamIdentifier": "XMJKFS3D66", "organizationName": "Mesh Community", "serialNumber": "10001", "description": "Mesh Kiosk Pass", "logoText": "Mesh Community", "foregroundColor": "rgb(255, 255, 255)", "backgroundColor": "rgb(25, 25, 25)", "barcodes": [ { "format": "PKBarcodeFormatQR", "message": "10001", "messageEncoding": "iso-8859-1" } ], "generic": { "primaryFields": [ { "key": "name", "label": "MEMBER", "value": "Test User" } ] } } ASCII-only, no emoji, no hyphenated serial, includes primaryFields, minimal fields Same signing recipe, same G4 chain, verify clean Same 6 standard PNG assets (icon + logo, 1x/2x/3x) Result on a fresh iPhone: identical silent rejection. Same "Sorry, your Pass cannot be installed to Passbook at this time." dialog. At this point every plausible client-side variable has been isolated and eliminated. The block appears to be at team level inside Apple's PassKit backend — invisible from the Developer Portal. WHAT APPLE HAS DONE SO FAR DTS Case-ID: 21008005 — opened 2026-07-13, reproducer.zip attached same day Assigned engineer: Paris Pinkney (WWDR, DTS) since 2026-08-05 Sysdiagnose: filed via Feedback Assistant as FB24516356 on 2026-08-26 (device Serial HWT3HQ2F9F, SEID captured, iOS 23G71, reproduction timestamp 2026-08-13 11:02:15 +0200) with Wallet debug profile installed on the device before reproduction Radio silence since 2026-08-17 — 5 weeks and counting, including no reply to a polite check-in on 2026-09-08 WHAT I'M ASKING Anyone at Apple engineering seeing this: is there a way to accelerate the Case-ID 21008005 / FB24516356 log review? The PassbookUIService / PassKit / PassKitCore entries around the timestamp above would settle this in minutes on your end. Any developer who's hit team-wide PassKit rejection before: what unblocked it? Was it a PLA re-acceptance, a Developer Program Support ticket (separate from DTS), a re-provisioning request, something else? Any way to inspect a team's backend PassKit entitlement state from outside (a Portal page, an endpoint, an xcrun command), so I can either confirm my suspicion or eliminate it myself? Any known-good published .pkpass from a Norwegian-registered (C=NO) Developer Team I can diff against, just to eliminate country-registration as a factor? Working Apple Wallet is a launch-blocker for the Mesh Community Workbar Kiosk rollout — we're currently shipping Google Wallet + QR-in-email as a full fallback and it works everywhere including iPhone, so no user is being turned away. But we'd like to close the Apple Wallet loop, and after 2 months I've run out of things to try from my side. Any pointer welcome. Happy to share the full evidence bundle privately with anyone at Apple who can help. Thanks, Mesh Community AS · Team ID: XMJKFS3D66

-(void)paymentQueue:(SKPaymentQueue*)queue updatedTransactions:(NSArray<SKPaymentTransaction*>*)transactions In the sandbox environment this is called continuously every time my enters the foreground. I call -finishTransaction on approximately 22 transactions. Confirmed by: NSUInteger finishCount = 0; NSUInteger transactionCount = transactions.count; for (SKPaymentTransaction *aTransaction in transactions) { // Check state..if purchased or restored.. [[SKPaymentQueue defaultQueue]finishTransaction:aTransaction]; finishCount++; // Post notification telling everyone here! } NSLog(@"Finsihed %lu of %lu",finishCount,transactionCount); The log at the bottom says - finished 22 of 22 transactions. But every time the app enters the foreground the -paymentQueue:updatedTransactions: is called again with another batch of transactions. How Over and over again. Not sure how this is possible but the transactions seem to never clear from the queue. I hope this may be limited to the sandboxed environment. In this loop after finish transaction is called I then post a notification which kicks off receipt validation...and then I even store something in the keychain. Doing this work over and over again in a tight loop is very unexpected and causes my app to lock up. Yea I know this is deprecated. Will move to my Objective-C storekit 2 wrapper but breaking SK1 on purpose seems kind of um, rude. Hope this is only in the sandbox environment. This app got sidelined even though I got some plans to resurrect it in the back of my head.

Live App Store app. Since 2026-09-01 PDT, StoreKit no longer returns our approved auto-renewable subscriptions on signed builds. The same SKUs load normally in Xcode when using a local StoreKit configuration file. New purchases are blocked. Monthly auto-renewals that were collecting normally through August 31 began failing their renewal attempts starting September 1, with all observed attempts entering Billing Grace / Billing Retry. App Name: Moonlit Bundle ID: moonlit.reading Versions affected: 1.1.1 — App Store version that was already live and working normally before September 1 1.1.2 — subsequently released to the App Store specifically to test whether a fresh production release would restore StoreKit behavior. It did not. Approved auto-renewable subscriptions, both in the same subscription group: moonlit.monthly.subscription moonlit.yearly.subscription Paid Apps Agreement, banking, and tax are Active in App Store Connect. We use an explicit App ID with the In-App Purchase capability enabled. Distribution builds do not contain a StoreKit Configuration file. The local .storekit file is used only for Xcode Run. Through August 31, 2026, Product.products(for:) and SubscriptionStoreView returned both SKUs and their prices correctly on production builds. Beginning September 1, 2026, and continuing through at least September 11: Every production paywall we can measure receives an empty StoreKit catalog with no product IDs, no prices, and no thrown StoreKit error. SubscriptionStoreView remains on its loading state. Our Terms / Privacy footer still renders because it does not depend on StoreKit. showManageSubscriptions / manageSubscriptionsSheet also hangs or fails to connect on the same signed builds. App Store Connect subscription events for the monthly SKU show a complete reversal beginning September 1. All observed renewal attempts in the affected window entered Grace from Paid, with no successful renewals, whereas the comparable August window showed normal successful renewals. Sales reports show no IAP proceeds for the affected September window. App downloads continue to appear normally, so the app itself remains available for sale. What still works Xcode + local StoreKit Configuration: Both products load Prices display The purchase sheet presents normally Analytics and logging continue to function, so this is not an app crash or missing paywall UI. The subscriptions are not Rejected and are not in Developer Action Needed. TN3186 / TN3188 checks have already been completed. This appears similar to other recent reports where App Store Connect contains a valid product catalog but StoreKit does not serve the products to signed builds: https://developer.apple.com/forums/thread/838171 https://developer.apple.com/forums/thread/841722 https://developer.apple.com/forums/thread/838773 https://developer.apple.com/forums/thread/836183 Developer Support case: 102959783559 Request Could an App Store Commerce or StoreKit engineer verify whether the app-to-IAP catalog association for moonlit.reading is populated and being served correctly on Apple’s side, and refresh or reprocess the production catalog if appropriate?

After upgrading to macOS 27.0, I noticed a specific issue in Find My > People. Two people who share their location with me use iPhone 6 devices. Their locations are unavailable in Find My on my Mac running macOS 27.0. The same location-sharing relationships work correctly on my other devices: iPhone running iOS 26: locations are visible iPad running iPadOS 26: locations are visible Mac running macOS 27.0: locations are unavailable Other people using newer iPhones are displayed correctly on the same Mac. This suggests that location sharing itself and my Apple Account are working correctly. The issue appears specific to Find My > People on macOS 27 when receiving location shared from older iPhone/iOS devices. I can reproduce this independently with two different iPhone 6 users. macOS 27.0 is the public release, not a beta. I have submitted this to Apple through Feedback Assistant: FB24761605 Has anyone else seen this specifically with iPhone 6 or devices running older iOS versions after upgrading to macOS 27?

Hi, Does anyone know if Apple has released the SDK to enable 2K streaming in HomeKit for doorbells/cameras? I've not seen anything posted so far, wondered if I've missed it. Thanks

Hello, On July 30, 2026 we submitted a DriverKit USB Transport - VendorID capability request for our iPadOS driver extension. The request ID is 83H9997N3G, team ID W33S637JJQ. Eight weeks later it still shows "Submitted". Developer Support (case 20000135736763) told us a separate team handles these requests and will contact us. We have not heard from that team yet. The driver works with development signing. Without the distribution entitlement we cannot upload a build to TestFlight. Is there anything else we should provide, or a way to find out where the request is in the queue? Thanks, Stepan

The Problem When a user toggles radio buttons or checkboxes in a PDF using Preview, the widgets disappear following subsequent interactions after the file is saved and reopened. This renders the form fields unusable. Steps to Reproduce the Problem Open a PDF with radio buttons or checkboxes in Preview. Toggle a radio button or checkbox. Save and close the file. Re-open the PDF in Preview. Toggle the same button again. The button (and any others with the same field name) will disappear. Expected Results Toggling a radio button or checkbox should update the field value without causing the button (or related buttons) to disappear. This behavior is consistent with previous versions of PDFKit. What is Happening In Preview, interacting with radio buttons and checkboxes correctly updates their appearance as expected. Saving the PDF, however, causes the appearance dictionary to reference a new N entry that is a single appearance stream unassociated with any state. The annotation's AS entry is not updated. The original N entry remains but is no longer referenced. Subsequent interactions fail to update the visual presentation because the appearance stream is missing. Impact on User Experience Radio buttons and checkboxes may disappear and become unusable when toggled. PDF documents become irreparably altered after a button is toggled and the file is saved. PDF file size significantly increases when the file is saved. Users may believe they have successfully completed a form, only for the data to become inaccessible or invisible to recipients. Forms may need to be completely restarted or recreated from scratch if the original becomes unusable. The corrupted PDF structure might cause the file to render incorrectly or crash in third-party PDF viewers. Affected Apps/OSs Tested with Preview 11.0 (1147), as well as other apps that use PDFKit, on macOS Golden Gate 27.0 (26A428). This problem also affects PDFKit on iOS 27.0 and iPadOS 27.0. Feedback/bug report: FB24866826 Related Sample Output Original PDF File Checkbox widget annotation (6 0 obj), its appearance dictionary (17 0 obj), and normal appearance dictionary (18 0 obj). Button is not checked. 6 0 obj << /Border [ 0 0 0 ] /Rect [ 90 390 110 410 ] /T (button1) /F 4 /Subtype /Widget /DA (/.AppleSystemUIFont 13 Tf 0 g) /MK 16 0 R /C [ 0 ] /AP 17 0 R /V /Off /M (D:20260919225320Z00'00') /AS /Off /FT /Btn /Type /Annot /Ff 0 >> endobj 17 0 obj << /N 18 0 R >> endobj 18 0 obj << /Yes 20 0 R /Off 22 0 R >> endobj PDF File after Save Checkbox widget annotation object (6 0 obj), its new appearance dictionary object (8 0 obj), a new normal appearance stream object (20 0 obj), and the original appearance stream dictionary (now 21 0 obj). File saved after user checked button. 6 0 obj << /Ff 0 /Type /Annot /AS /Off /AP 8 0 R /MK 9 0 R /C [ 0 ] /FT /Btn /M (D:20260919225320Z00'00') /DA (/.AppleSystemUIFont 13 Tf 0 g) /Subtype /Widget /F 4 /Border [ 0 0 0 ] /Rect [ 90 390 110 410 ] /T (button1) /V (Yes) >> endobj 8 0 obj << /N 20 0 R >> endobj 20 0 obj << /Filter /FlateDecode /Resources << /ColorSpace << /CS1 [ /ICCBased 29 0 R ] /CS2 [ /ICCBased 30 0 R ] >> >> /BBox [ 0 0 20 20 ] /Type /XObject /Subtype /Form /Length 123 >> stream x UéA ¬0 Ô}≈|†≈nà¢úÛÇ* —SA =}Ïr(»ñµ≤w◊€YËà’|ÙÎŒç'óRï∂#SäÏÌü∞¢S‰Ì§ôRÌX }–É•åY Éçˆ BŒ H " *â´8™ˆZø6z⁄ÿ ”ú6ɀ੠"∫t˘‹;'¬ endstream endobj 21 0 obj << /Off 22 0 R /Yes 23 0 R >> endobj Note: No object references 21 0 obj in the PDF.