While developing our wifi-aware implementation we ran into a specific issue where TCP connections seem to never reach a "ready" state (ready to transfer data). It stays in “”preparing” state trying to connect for forever. We tried to recreate a new TCP connection every time after the connection stays in "preparing" for longer than 10 seconds. This helps to "recover" eventually, but it only happens after 1.5 - 2 minutes. Creating a completely new NetworkBrowser and NetworkListener doesn’t speed up this process. The issue occurs when the browser and listener are setting up the NAN/TCP connection, at that time if the user opens the DevicePairingView it seems that it disrupts or interferes with the connection, entering an invalid state. From what we can see it takes around 2 minutes for it to recover, presumably this is when NAN drops the connection (timeout) and creates a new one.

 STEPS TO REPRODUCE Reproduction steps:

 Open the app on 2 wifi-aware devices.
 Device 1 presses “Pair with device”. Device 2 navigates to “Receive” and presses the “”Pair with sender”.
 Complete the pairing process.

 Device 1 (Send) presses the start button.
 Device 2 (receive) presses start button, Directly after the button press, device 1 presses the “”Pair with sender” button
 Observe TCP connection never fully establishes (1.5 - 2 mins) PLATFORM AND VERSION iOS Development environment: Xcode 26.3, macOS 26.4.1 Run-time configuration: iOS 26.5 test project with a recording showing the issue: https://github.com/DeveloperNiels/WAIssue

We are developing an audio-entitled CarPlay app with Xcode 27.0 (27A266a), targeting iOS 27. Apple Music displays a circular magnifying-glass control beside the MiniPlayer while its root tabs remain visible. Selecting it starts a Siri media request. We want the supported equivalent in our audio app without reserving an assistant row on every browsing screen. Our root is CPTabBarTemplate containing native list templates. The current CPBarButtonProviding documentation explicitly says root templates in a tab bar do not display leading/trailing bar buttons. We have checked the iOS 27 public headers, the June 8, 2026 CarPlay Developer Guide, WWDC26 session 212 and the current downloadable CarPlay Music sample. The public Siri-media entry point we found is CPAssistantCellConfiguration(assistantAction: .playMedia). Could Apple clarify: Does iOS 27 expose a separate system Search/Siri control beside MiniPlayer for third-party audio apps? If so, which public API or configuration enables it while retaining the root tabs? Does CPTemplate.tabSystemItem = .search receive any special placement or activation behavior in iOS 27 CarPlay, or is it only an ordinary tab icon/title? Is there a supported public media-Siri activation API for a CPBarButton, independent of the messaging-only compose button and the assistant cell? We are asking about Apple's Siri, not an app-owned voice recognizer. Typed search through CPSearchTemplate is a separate capability. If this first-party control is unavailable publicly, please confirm that distinction and consider a compact system media-Siri entry point for audio apps.

Hello Apple Developer Relations and the HealthKit team, I'm a hobbyist developer and recreational swimmer building a personal app to make better use of my own Apple Watch workout data. My goal is training management, post-workout reviews, and long-term summaries of my swimming history. Design goal I would like to create a global map of places where I have swum, similar to the map view in Apple Photos: When zoomed out, group locations by country or region and show the number of distinct swimming places, rather than the number of workouts. When zoomed in, reveal individual places and their associated workouts. Venue or water-body names could be added later where they can be reliably identified. For pool swimming, a single location point is sufficient. A route is not required. For open-water swimming, show the place first, then reveal an individual workout's route when selected. Group repeated visits to the same place while retaining each workout for review. Data requirement The key requirement is read-only access to a location associated with an existing workout, including historical pool workouts recorded using Apple's Workout app. A coordinate linked to the workout would be enough to begin with; I am not expecting HealthKit to identify or name the venue. What I have observed In on-device tests, I can read routes for open-water swimming workouts. For the historical pool workouts I checked, no route was returned, and I did not find usable location coordinates in the public workout, activity, event, or route metadata I inspected. However, Apple Fitness displays a map point for historical pool workouts. The absence of a route therefore does not establish the absence of a recorded location. I have read the DTS response explaining that there is currently no public API for third-party access to indoor workout locations: https://developer.apple.com/forums/thread/827939 Current obstacle Without a supported way to obtain these historical points, the app cannot automatically build a useful map of past pool visits. Recording locations from now on or asking users to assign old workouts manually would not recover the existing history. A computer-backup extraction workflow also would not meet the intended standalone iPhone app experience. Questions and enhancement request Beyond the current HealthKit APIs, is there any supported, user-initiated export or import path that preserves historical indoor workout coordinates and their association with the workout? If there is no supported path today, could Apple consider read-only access to historical workout locations through HealthKit, with explicit user authorization and clear handling of missing or approximate locations? I understand that a formal enhancement request belongs in Feedback Assistant. I am sharing this concrete design and data requirement here to clarify the use case and ask whether a supported alternative already exists. Thank you for considering this request.

Hello, Submitted a request for endpoint protection and I can see the status is "Submitted" and I am curious how long users are seeing the process take? Luke

We are implementing regional age-assurance checks for an iPhone app that supports iOS 17 and later. It is a paid toddler app with no backend, app accounts, ads, in-app purchases, messaging or shared user content. All content is suitable for young children. Optional family voice recordings remain on the device. We plan to request Declared Age Range when Apple's regulatory signals require it, process the response locally, and avoid logging, storing or transmitting age data. We are seeking supported technical behavior, rather than legal advice or preapproval: What supported API or platform guarantee establishes that initial download/purchase parental consent was obtained? The age-range response does not appear to expose a separate initial-consent status. Apple's age-assurance Q&A says the platform prevents launching an app after a parent revokes consent. The implementation guidance also describes RESCIND_CONSENT through App Store Server Notifications. For an app with no backend or remotely accessible service, can local access rely on the platform's launch blocking, or is a notification server still required? If a server is required, what local enforcement behavior should it drive? What is the supported behavior for offline reopening and unavailable or network-error results, particularly on older supported iOS versions where the regulatory APIs are unavailable? Does platform enforcement also cover an app already running when consent is revoked, and how should an offline app handle that transition? Documentation or a sample showing this entirely local case would be helpful.

After transferring the App ownership to a different account, if you update the app on iOS, two identical apps will show up in Settings > Screen Time. Users can't control the blocking settings from before the update - the only fix is to restart the phone. After the next execution of manageStore.shield.applications, users still can't manually disable the restrictions - their only option is to uninstall and reinstall the app. I believe this is related to how Screen Time API's authentication works - it's not just tied to the app's bundle ID, but also linked to the developer account's organization ID. Any suggestions for a clean solution that would allow smooth app updates after the transfer without running into these issues?

I am developing an iOS/iPadOS app using SwiftUI, SwiftData, CloudKit, and CKShare. I need help determining why an already-approved CKShare recipient is not receiving updated application-level authorization. Architecture The owner stores working data locally in SwiftData and explicitly mirrors shared data into a custom CloudKit zone named AthleteVaultSharedSchoolData. The owner writes these records to privateCloudDatabase. Recipients accept a zone-wide CKShare and read the accepted zone through sharedCloudDatabase. Each approved recipient also has an AVSchoolMembershipAuthorization record in that shared zone. Its deterministic record name is based on the recipient's CloudKit user record ID: AVSchoolMembershipAuthorization- The authorization contains the recipient's role and arrays of permitted team, sport, and player UUIDs. What works The recipient successfully accepted the share and can download the shared school data. The recipient has previously fetched his authorization from the accepted shared zone and received the correct initial permissions. The owner can change that recipient's permissions and save the updated authorization. I verified in CloudKit Console → Production → Private Database that there is exactly one authorization record for this recipient. It is active and contains the newly selected playerIDs. The record's updatedAt also changes when the administrator saves the permissions. Both owner and recipient are testing the same TestFlight Production build. The problem After changing an already-approved recipient's permissions, the Production authorization record is correct, but the recipient continues operating with the previous player permissions after closing and reopening the app. For example, the administrator removes Player A and grants Player B. CloudKit Console shows the authorization now contains Player B instead of Player A, but the recipient continues seeing Player A and does not see Player B. On the recipient I obtain the current CloudKit user record ID, locate the accepted shared zone, construct the deterministic authorization record ID, and fetch it from the shared database: let recordID = CKRecord.ID( recordName: "AVSchoolMembershipAuthorization-(userRecordID.recordName)", zoneID: acceptedZoneID ) container.sharedCloudDatabase.fetch(withRecordID: recordID) { record, error in // decode current authorization } Once the authorization is returned, the app explicitly reconciles its local SwiftData permission rows: permissions absent from the current authorization are deleted and newly granted permissions are inserted. Production schema During troubleshooting I discovered that AVSchoolMembershipAuthorization had initially existed only in Development. That schema has now been deployed to Production. Before deployment, Production correctly returned a “Cannot create new type AVSchoolMembershipAuthorization in production schema” error. After deploying the schema, the owner save succeeds and the updated authorization is visible directly in the Production CloudKit Console. Therefore the current problem occurs after the Production authorization has been successfully saved. Questions With a zone-wide CKShare, should records created or modified in the owner's shared custom zone automatically become visible to an already-accepted participant through sharedCloudDatabase? If AVSchoolMembershipAuthorization was created after the recipient originally accepted the zone-wide share, is any additional operation required to expose that record to the existing participant? Is sharedCloudDatabase.fetch(withRecordID:), using the accepted shared-zone ID and exact deterministic record ID, the appropriate way to retrieve the latest server version? Can an accepted participant continue receiving an older version of a record after the owner successfully saves a newer version to the Production private database? If so, what API or synchronization pattern should be used to reliably obtain the current version? When changing CKShare.Participant.permission for an existing participant at the same time as changing application-level authorization in a custom CKRecord, is there another CKShare operation required? Is a per-recipient authorization CKRecord inside a zone-wide shared zone an appropriate CloudKit design, or is there a recommended pattern for per-recipient authorization? I can provide the relevant CloudKit service code, CloudKit Console screenshots, and additional diagnostics if needed. Thank you for any guidance on the expected CloudKit behavior for updated records in an already-accepted zone-wide CKShare.

Environment: iPhone 17 Pro, iOS 27.0, Xcode 27, dev build (aps-environment development), sandbox APNs, token-based auth. The app uses the PushToTalk framework with one restored channel; audio is WebRTC, started only after didActivate. Push headers: apns-push-type pushtotalk, apns-topic .voip-ptt, apns-priority 10, apns-expiration 0. Payload about 460 bytes. APNs returns 200 to every push in about 250 ms. What we then see is after a pushtotalk push is delivered and handled, the next push sent about 6 to 7 minutes later is not delivered to the app (no incomingPushResult call), although APNs returned 200. Pushes sent about 13 or more minutes after the last delivered one are almost always delivered. Overnight automated runs, phone on power, Focus off, no calls. Pushes sent after a delivered push: 38 of 38 lost (one run), 31 of 32 lost (another run). Pushes sent about 13+ minutes after the last delivered push: 38 of 40 delivered, and 37 of 41 in the other run. Lost pushes are not late: none arrived within 5 minutes after sending. What we ruled out: App state: the loss is the same whether the woken app is terminated about 37 s after the push or left to suspend on its own, and whether or not it sets activeRemoteParticipant to nil when the remote audio ends (the audio session deactivates in that case). Push token: the server's token matches the token the app last received. Focus and calls: Focus off, and pushes near calls were excluded. Separately, pushes sent within the first few minutes after the app is launched (by hand or by devicectl) are also mostly lost. Questions: Is there a limit, documented or expected, on how often the system delivers pushtotalk pushes or wakes the app after a recent incoming push? Could apns-expiration 0 cause these pushes to be discarded, for example if the device is briefly unreachable after a Push to Talk wake? Is a short non-zero expiration appropriate for pushtotalk? Is this expected in the sandbox environment, and would production behave differently? Beyond setting activeRemoteParticipant to nil when the remote speaker stops, should the app do anything after handling an incoming push so that the next push is delivered? We can share log excerpts or a sysdiagnose on request.

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.

Any plans to provide (a subset of) the FUSE3 API directly on top of FSKit/an underlying primitive, in a way that doesn't compromise the new security model, but also reduces porting friction?

I have a watchOS app communicating with a BLE peripheral during an active HKWorkoutSession. The workout provides sufficient runtime: once connected, the Watch can receive a notifying GATT characteristic approximately once per minute for hours, including while the display is off. In normal conditions the connection is very stable. The difficult case is outdoor use with marginal RF conditions. The peripheral and application protocol otherwise work reliably, but outdoors there are fewer reflected RF paths and normal body movement can intermittently obstruct the Watch-to-peripheral path. In those situations the link occasionally terminates with CBError.connectionTimeout. Reconnection is particularly important because this peripheral advertises for reconnection only approximately once per minute. We also know approximately which second of each minute the peripheral becomes active, so missing a single advertising opportunity can cause a relatively long data gap. I’m trying to better understand the supported CoreBluetooth/watchOS behavior in this situation. Maintaining a marginal existing connection Once the BLE connection is established, are there any public CoreBluetooth mechanisms or recommended practices for making that connection more robust against CBError.connectionTimeout? In particular, can application-level GATT activity have any influence on connection scheduling or link robustness, or is this entirely handled by the Bluetooth stack below CoreBluetooth? CBConnectPeripheralOptionEnableAutoReconnect with sparse advertising When CBConnectPeripheralOptionEnableAutoReconnect is enabled and the connection is lost, how does watchOS handle a peripheral that advertises only very infrequently? Does CoreBluetooth simply keep the reconnect pending and wait for subsequent advertisements indefinitely, subject to system policy? Known peripheral activity timing If the app knows approximately when the peripheral becomes active and advertises each minute, is there any supported way to make use of that timing during reconnection? Or should the app simply leave AutoReconnect pending and let CoreBluetooth handle reception? WWDC22 reduced reconnection range WWDC22 session 10135 says: “If your device is on the edge of Bluetooth range and repeatedly disconnects while in Background BLE connection, the reconnection range will be reduced. This means only devices close to the Apple Watch will reconnect.” The session also says these limits are counted over a rolling 24-hour window and are reset when the user interacts with the app. I would particularly appreciate clarification of how this works in practice: What conditions cause a disconnect to count toward this policy? Does this policy apply while an app has an active HKWorkoutSession and continues executing in the background? Is the state maintained per peripheral, per app, or more globally? What exactly constitutes the user interaction that resets it? Does bringing an already-running workout app back to the foreground reset it, or does the app need to be relaunched? Is there any public API or diagnostic indication that reduced reconnection range is currently active? Is there any supported way to explicitly clear/reset that state? Connection parameters Does watchOS expose any supported mechanism for a CoreBluetooth central to influence parameters relevant to connection robustness, such as connection interval, supervision timeout, PHY, transmit power, or similar link parameters? Diagnosing CBError.connectionTimeout When CoreBluetooth reports CBError.connectionTimeout, is there any supported diagnostic method to determine whether the Watch stopped receiving the peripheral, the peripheral stopped receiving the Watch, or whether this should simply be treated as a link-layer timeout without attribution to either side? For context, this is not primarily a background-runtime problem. The active workout keeps the app running and the normal persistent BLE connection can operate flawlessly for many hours. I’m specifically trying to understand the best supported strategy for preserving and recovering the BLE link when RF conditions temporarily become marginal, especially with a peripheral that advertises very sparsely after a disconnect. DTS asked me to post this question here for review.

While building an SMB 2/3 client as an FSKit file system module (FSUnaryFileSystem + FSVolume, the macOS 27 Handler protocols), I ran into a number of framework-level issues. I have filed each one with a title starting "FSKit:" so they are easy to find, and every report has a minimal reproduction attached: a small in-memory FSKit module (no network, no disk, no cache of its own), so none of them depend on SMB. All were measured on macOS 27.0 (26A5406e and 26A5416b) with Xcode 27.0 beta 5. Summaries below in case anyone else is hitting these. FB24419773: renameatx_np with RENAME_SWAP returns success but destroys the destination file. On any FSKit volume a RENAME_SWAP is performed as an ordinary clobbering rename: rc=0, but the destination's contents are silently lost instead of exchanged. The module cannot refuse it because renameItem receives no flags; a swap and a plain overwriting rename look identical. (RENAME_EXCL works correctly.) FB24419825: a negative lookup is cached permanently. Once anything gets ENOENT for a name on an FSKit volume, the kernel serves that ENOENT for the life of the vnode. If the file is created later (for example by another machine on a network volume), it stays unopenable by that name indefinitely, while ls of the same directory lists it. There is no API through which a module can report that a name now exists. FB24419858: a data-cache grant from openItem can be applied after the module has already invalidated. The grant in FSOpenItemResult is applied asynchronously after the module's reply, and an invalidation issued in that window succeeds (setCacheState returns no error) and is then overwritten by the stale grant. The result is a kernel cache no future event will invalidate; readers see stale data. FB24419870: synchronize(flags:) is never called on a URL-backed volume. fsync(2), fcntl(F_FULLFSYNC), fcntl(F_BARRIERFSYNC) and sync(8) all return success with zero calls reaching the module, so durability is reported and never established. A packet capture of the same SMB share shows five SMB2 FLUSH requests through Apple's smbfs and zero through an FSKit module. FB24419894: FSItemSetAttributesRequest.consumedAttributes is never observed, and wasAttributeConsumed(.changeTime) answers about the wrong attribute. Consuming everything and consuming nothing are indistinguishable to the caller (chmod returns 0 either way), even though the setAttributes documentation says the upper layers will detect unsupported attributes. Separately, wasAttributeConsumed answers YES for changeTime when only accessTime was consumed, and never answers correctly about changeTime itself; this part reproduces by constructing the request directly, no file system needed. FB24419911: restrictsOwnershipChanges = true does not reject non-superuser chown. The property is documented as "the volume rejects a chown(2) from anyone other than the superuser", but on an -o owners mount a non-root chgrp is delivered to the module's setAttributes anyway, so every module has to enforce the policy itself. FB24419932: a failed activate wedges the resource URL. After a module's activate throws once, every later mount of the same URL string fails with "Resource busy" (fskitd logs "Can't start new task, resource state is 5"), while the same volume under a different URL spelling mounts fine. For a network module the ordinary trigger is one wrong password. Recovery requires killing both fskitd and the extension process. FB24419964: enumeration cannot report extended-attribute presence. FSItem.Attributes has no per-item "has xattrs" field, so one cold ls -l of a 500-entry directory costs about 2,000 FSKit boundary crossings: an xattr call per entry plus a "._name" AppleDouble sidecar lookup per entry, and each of those ENOENTs is then pinned by FB24419825. Suggestion: a per-entry hasExtendedAttributes flag so getattrlistbulk can be satisfied from the enumeration. FB24419974: no byte-range lock operations. flock(2) and fcntl(2) locks on an FSKit mount stay kernel-local and never reach the module, so advisory locks cannot coordinate between clients of a network file system. Suggestion: an optional lock-operations handler. FB24419979: no ACL or security descriptor operations. ls -le, chmod +a, acl_get_file(3) and cp -p with ACLs cannot work on any FSKit volume; a network server's real ACLs are invisible behind synthesized mode bits. The nearest surface, FSVolumeAccessCheckHandler, can only be asked yes/no questions about a descriptor the module has no way to provide. Suggestion: an optional ACL-operations protocol. If any of these are biting you too, duplicate feedbacks referencing the FB numbers above genuinely help with prioritization.

Hello, I’m trying to make a payment for a 1-year subscription, but the payment keeps being declined. I have tried both my Visa and Maestro cards, and neither of them is accepted. I have already checked with my bank/card provider, and there is no issue or restriction on my cards. Both cards work normally for other online payments. It therefore appears to be a payment system issue on your side rather than an issue with my cards. Could you please check why my payments are being rejected and help me complete the payment for the 1-year subscription? Thank you.

PLEASE ADDRESS ASAP: Muse is #1 on the App Store and Facebook is one of the most blocked apps for Screen Time. This is affecting a vast number of people. Description: When a user blocks the Facebook app in any screen time app, iOS automatically blocks Meta's Muse app too. Every single time. There is no way for the user or the developer to prevent it, allowlist it, or even detect that it happened. Muse shows Apple's generic blocked-app "Restricted" screen instead of the screen time app's own design, so the user cannot tell who blocked it or why. This is the worst possible combination of apps: Facebook is one of the most-blocked app across screen time apps. Muse ("Muse from Meta") is currently the #1 app on the App Store. A huge and fast-growing number of users block Facebook and silently lose the world's most popular new app. Muse launched Sept 8, 2026 and adoption is still climbing -- the affected population grows every day. There is NO workaround whatsoever: Users cannot allowlist Muse: it does not appear in Settings > Screen Time > Always Allowed. Developers cannot prevent it: the Screen Time API offers no opt-out; the extra block is applied by iOS itself. Developers cannot detect it: Muse's token (listed separately in FamilyActivityPicker) corresponds to no real identity anywhere else. Developers cannot customize it: their ShieldConfiguration is never consulted -- Muse gets Apple's generic shield UI. Users cannot even block Muse on purpose: shielding Muse's own token is a silent no-op. Screen Time usage statistics are also wrong -- Muse usage is recorded as "Facebook." This Screen Time bug renders screen time apps effectively unusable if users want to block Facebook and use Muse, which is extremely common. How can we get this addressed as soon as possible? Feedback Assistant ticket: https://feedbackassistant.apple.com/feedback/25019832

After updating my Apple Watch Series 10 to the public release of watchOS 27, Environmental Sound Level measurements became extremely sparse. Before watchOS 27, with Environmental Sound Measurements enabled, my watch recorded environmental sound data approximately every 30 seconds and the coverage was nearly continuous throughout the day. After updating the same Apple Watch to watchOS 27, the behavior changed significantly: Environmental Sound Level samples are much less frequent Large gaps appear between measurements Overall daily temporal coverage is dramatically reduced The same change is visible both in the Health app and through HealthKit using HKQuantityTypeIdentifier.environmentalAudioExposure No relevant settings were changed, and Environmental Sound Measurements are still enabled. This is important for apps that use Environmental Audio Exposure data for time-based analysis. In my case, I use this data for sleep and nap environment analysis. With the much sparser sampling on watchOS 27, it is difficult to reliably evaluate the acoustic environment during a specific sleep period. I have also seen other watchOS 27 users reporting similar behavior: https://www.reddit.com/r/watchOSBeta/comments/1wjrdaq/watchos_27_broke_the_noise_monitoring_app/ I submitted a Feedback Assistant report: FB24837491 Has anyone else observed the same change on watchOS 27? I’m especially interested in whether this is: an intentional change to the sampling or aggregation strategy, a HealthKit write-frequency change, or a regression in watchOS 27. If anyone has compared HKQuantitySample.startDate, endDate, sample duration, and sample interval before and after the watchOS 27 update, that data would be very useful for comparison.

We depend on the Export PDF button in previous Apple Health apps and it seems to have disappeared in 27.2 beta. Merging FHIR results from multiple hospitals, pharmacies and other patient portals is complex. Apple does an excellent job of merging, categorizing, and displaying this information in the app and it used to generate a great human-readable PDF export. Exporting individual categories as a PDF would be fussy and unreliable for a typical user. Is this regression in the beta an oversight or a strategic shift on the part of Apple to deprive users of an easy to use combined patient summary?

On iOS 27, an app of mine that plays both its own audio and Apple Music tracks has two Now Playing clients in MediaRemote, as any app using ApplicationMusicPlayer.shared does: its own process's MPNowPlayingInfoCenter.default(), and MusicKit's player hosted out of process by com.apple.MediaPlayer.RemotePlayerService. MediaRemote elects between them correctly - the client whose process is making sound becomes active - and both the Lock Screen and the CarPlay dashboard follow the change. My CPNowPlayingTemplate does not. It stays on whichever client it was on when the change happened, so during an Apple Music track the car shows my own (now stale) entry with the clock frozen and a play glyph while music is audible; in some sessions the reverse, where my own audio after a track gets a blank template whose play presses are delivered to MusicKit's empty player and interrupt playback. From mediaremoted on iOS 27, handlePlaybackQueueRequest from CarPlayTemplateUIHost returns for (pid) > default throughout a track, and no contentItemChange for the RemotePlayerService path is ever posted to CarPlayTemplateUIHost, though it is posted to springboard, CarPlayApp and MediaRemoteUI. On iOS 26.6.1 with the same build, the same template host reads and commands RemotePlayerService/ during the track and > default afterwards. So the routing of commands to the active client is not what changed - what the template reads and sends to is. Filed as FB24840951 with mediaremoted captures from both OS versions, full sysdiagnose archives and screen recordings of the car screen beside the Lock Screen. Two questions: Is there a supported way for an audio app to tell CPNowPlayingTemplate which of its Now Playing clients to display? MPNowPlayingSession looks like the intended mechanism but accepts only AVPlayer instances, so it cannot represent either an AVAudioEngine graph or MusicKit's player; tested with a dormant AVPlayer it reported isActive == true every time and moved the template on some tracks and not others. Does the new MiniPlayer affect this? WWDC26's "Rev up your CarPlay app" says the MiniPlayer is new in iOS 27 and appears automatically for every app that shows now playing. Since the template was reworked in the same release this regressed in, does CPNowPlayingTemplate.shared.allowsMiniPlayer = false change which client is read? I have not tested it yet and will report back either way. Meanwhile the only thing that moves the car is republishing my own entry once a second as a new content item, which the template does re-read, so the clock steps instead of freezing. That ships in PodMelody 1.1.4, a workaround for an OS bug rather than a fix - and it doesn't resolve the mismatched play/pause glyph. If you have an audio app using ApplicationMusicPlayer and CarPlay, I would be glad to know whether you see the same thing, and in which car - duplicates on the Feedback are what get these prioritised.

I'm working on an FSKit module for EdenFS, a source control virtual filesystem. A teammate of mine asked about FSKit here a couple of years ago before its first public release. Since then, FSKit's feature development has made it feasible for our use case, so we're looking at FSKit again as a replacement for our current NFSv3 solution. The cache coherency API makes FSKit especially appealing to us, since we need a way to invalidate the kernel's caches after a checkout/goto operation. In another thread, an Apple engineer described it as "designed to manage cache coherency for network file systems and other kinds of file systems where an outside actor might modify the data outside of the kernel's normal data flow," which fits this case. As I understand it, there are two caching modes we could use: Negotiated caching, where FSKit calls the volume's open with the requested cache mode on every open of a file that isn't already open, and the volume replies with the coherency type it grants. FSKit then calls close once all references are released. That results in two extra round trips per file access, which is measurable on a workload that touches many thousands of files. Unilateral caching, where the volume sets isDataCacheInhibited = true, and FSKit stops calling the protocol's methods. The kernel then caches on its own, meaning those extra round trips are eliminated. As far as I can tell, setCacheState(for:cacheMode:coherencyType:action: .revoke) is the only invalidation mechanism FSKit gives a volume. With isDataCacheInhibited = true, that call returns ENOTSUP (NSPOSIXErrorDomain code 45) and the kernel keeps serving the old contents. I reproduced this on a minimal in-memory module and filed it as FB24996000 with the example attached, tested on macOS 27.2 (26B5091g). Is this ENOTSUP intended? The setCacheState documentation says it returns ENOTSUP for volumes that don't conform to FSVolume.DataCacheHandler, and my sample does conform. However, the isDataCacheInhibited documentation says it "instructs FSKit not to call this protocol's methods, even if the volume conforms to it". Is FSKit intentionally treating an inhibited volume as if it doesn't conform? If so, is there any other way to tell the kernel that cached data is stale in this mode? The documentation also states that the property is only read at loadResource, so we can't switch to negotiated caching just to serve a goto command either. For a source control filesystem like ours, we'd at least need to invalidate the kernel cache at specific points (after a goto) for correctness. If per-item invalidation is unsupported in this mode on purpose, would Apple consider a way to invalidate a whole volume's cache at once? Linux FUSE added FUSE_NOTIFY_INC_EPOCH (https://lists.openwall.net/linux-kernel/2025/02/20/1523) for a similar reason, so a server can invalidate every cached lookup in one call instead of one entry at a time. Negotiated caching does work (setCacheState(.revoke) succeeds in that mode) but unilateral caching is ideal for us due to the performance improvement and simpler implementation.

Short version: we run a sandboxed helper as a hidden service account, started at boot by an SMAppService daemon. It works, even before login. But when the user turns our app off in Background App Activity, only the daemon stops. The helper keeps running. Is this setup supported, and what's the right way to manage the helper? What we want A Developer ID signed, notarized app (not Mac App Store) with a helper that parses untrusted input. The helper should: run as a dedicated, hidden, non-login local account; use App Sandbox, with its own container; be available before anyone logs in (after FileVault unlock). What we built An unsandboxed root LaunchDaemon, registered with SMAppService.daemon, runs this at boot: launchctl bootstrap user/<serviceUID> <fixed-agent-plist> The agent plist uses LimitLoadToSessionType=Background. The helper is a nested app in the same bundle, with com.apple.security.app-sandbox=true. We don't create a GUI session, change UID after the sandbox starts, or use private APIs. What we measured macOS 27.0 (26A428), arm64, dummy data only: Register and approve: the daemon starts. The helper starts as UID 60000, its container works, and reads outside it are denied. Turn the app off in Background App Activity: the daemon gets SIGTERM and stops. The helper keeps running (same PID). Turn it back on: the daemon starts again. Its bootstrap returns exit 5, because the old helper is still loaded. Call unregister(): the daemon stops. The helper keeps running. Cold boot (tested with a plain /Library/LaunchDaemons job, not yet SMAppService): the helper started and worked before login finished. For comparison, running the same sandboxed helper as a system daemon with UserName set to this account fails before main: Incoming message euid:60000 does not match secinitd uid:0. Questions Is this setup supported for shipping, including the sandbox starting before anyone logs in? Does the approval for daemon-bundled helpers cover a helper bootstrapped into another account's domain? Our plan: when the daemon gets SIGTERM, it runs bootout on the helper and its domain, and it treats bootstrap exit 5 as "already loaded". Is that the intended pattern, or is there a supported way for the helper to follow the app's Background App Activity setting? If this setup isn't supported, what public mechanism gives a sandboxed helper its own non-root identity before login? I can share the plists, entitlements and logs from a minimal reproducer.

Hello, I’m currently working on a project that implements Bluetooth Low Energy (BLE) 5 Extended Advertising. We are experiencing an issue specifically on iOS 18.6.2. The device is visible/scannable, but we are unable to establish a connection with it. Initially, our advertising interval was set to 2 seconds. We suspected that this interval might be too long for reliable discovery on iOS, so we reduced it to 100 ms. With the same firmware and advertising configuration: iOS 26.5.2: the device is discovered and a connection can be established successfully. iOS 18.6.2: the device can be detected/scanned, but the connection cannot be established. Could you please clarify whether there are any known limitations, restrictions, or differences in the handling of Bluetooth 5 Extended Advertising between iOS 18.6.2 and newer iOS versions? In particular, we would like to know whether iOS 18.6.2 has any specific requirements regarding: BLE Extended Advertising / LE Extended Advertising Primary and secondary advertising channels Advertising intervals PHY configuration (1M / 2M / Coded PHY) Connectable Extended Advertising We would also appreciate any documentation or known issues related to Extended Advertising on iOS that could explain why the same device and configuration works correctly on iOS 26.5.2. Thank you in advance for your help.