Apple Mail compose field becomes uneditable after using Apple Intelligence rewriting tools on macOS 27 Developer Beta 1 I am seeing a reproducible issue in Apple Mail on macOS 27 Developer Beta 1 where the compose body becomes locked/uneditable after using Apple Intelligence writing tools. Environment Mac: macOS: macOS 27.0 Developer Beta 1 Build: 26A5353q Device: MacBook Pro with Apple Silicon shouldSwitchToCampoMode: false (isEnhancedSiriAvailable=false) App: Apple Mail Compose window Apple Intelligence Writing Tools Summary When composing an email in Apple Mail, if I write some text and then use Apple Intelligence to rewrite it — for example using Friendly, Professional, or Concise — Mail replaces the original text with the rewritten version. After the rewritten text is inserted, the message body becomes unresponsive. I cannot continue typing, edit the rewritten text, delete text, select text normally, or add new content inside the email body. The Apple Intelligence button also becomes unresponsive after this happens. The only actions that still seem to work are sending the email, discarding the draft, or using some toolbar actions such as emoji insertion. Steps to Reproduce Open Apple Mail on macOS 27 Developer Beta 1. Create a new email. Type any text into the email body. Use Apple Intelligence Writing Tools. Choose a rewrite option such as: Friendly Professional Concise Let Apple Intelligence replace/update the email body text. Try to click back into the message body and continue typing or editing. Expected Result After Apple Intelligence rewrites the email body, the compose field should remain fully editable. The user should be able to: Continue typing after the rewritten text Edit or delete the rewritten text Select and modify text Use Apple Intelligence again on the updated content Continue composing the email normally Actual Result After Apple Intelligence inserts the rewritten text: The email body becomes uneditable. Typing no longer works inside the message body. Clicking inside the body does not restore normal editing. Existing text cannot be edited or changed. Apple Intelligence controls become unresponsive. The compose window itself does not fully crash, but the body editor appears stuck. Send and discard still appear to work. Reproducibility This appears to be reproducible after using Apple Intelligence rewriting tools inside Apple Mail’s compose window. It was working before, so this appears to be a regression in macOS 27 Developer Beta 1.

Hello everyone, I have developed an app that is a local networking monitor app for a specific building automation protocol. I have searched the forum and I think I have found some older posts regarding this topic but I could not figure out if my issue falls under the same category. So my app allows the user to connect to local protocol devices, and start a monitor session where they can see incoming/outgoing packets. The connections are UDP or TCP and require opening a socket. Currently, backgrounding the app will make the OS terminate the socket connection, therefore ending the monitor, even if the app is backgrounded by user, to let's say, perform some other task in their phone. I have several requests from users to improve the app by allowing the monitor to continue while the app is backgrounded. However, by reading the relevant documents, I have found this to be almost impossible in iOS app. I have considered: Remote Push Notifications (APNs): The app operates on LAN so this is not an option, since I do not have an infrastructure to somehow send notifications to keep app process alive. Background Tasks (BGTaskScheduler): Not my case, since I do not want periodic execution. The app requires continuous socket listening. VoIP, VPN, or Audio Background Modes: My app does not fall under any of these categories, even though this would solve my situation. By searching around a bit more, I might be able to use either BGProcessingTask, which would allow my app at least to run for some minutes and show the user that they have to foreground it in order to not stop the monitor process, or maybe even App Intents framework. Has anyone faced similar requirement for their app? Any tip or point to a direction I should investigate more? Thanks, Nikos

I am seeing serious issues with iPhone Mirroring on macOS 27 Developer Beta 1. Environment Mac: MacBook Pro, Apple M4 Pro Model: Mac16,7 RAM: 24 GB macOS: macOS 27.0 Developer Beta 1 Build: 26A5353q SIP: Enabled Developer Mode: Enabled iPhone: iPhone 15 Pro Max Previously tested on: iOS 27 Beta 1 Currently restored to: iOS 26.5 Issue 1: iPhone Mirroring does not connect on iOS 27 Beta 1 and can leave the iPhone unusable When my iPhone 15 Pro Max was running iOS 27 Beta 1, iPhone Mirroring on macOS 27 Developer Beta 1 did not connect properly. I tried connecting multiple times. The iPhone appeared to think that the mirroring session had started successfully, because the iPhone screen turned off as expected for iPhone Mirroring. However, the Mac never actually completed the connection and never displayed the mirrored iPhone session. After this happened, the iPhone became completely stuck and unresponsive. The phone did not respond normally, and even force restart attempts were not working. The device remained unusable until the battery fully drained, which took about two days. After the battery was fully depleted, I was able to put the iPhone into DFU mode and restore it back to iOS 26.5. This suggests that something may be broken in the iPhone Mirroring / Continuity connection state between macOS 27 Developer Beta 1 and iOS 27 Beta 1. The iPhone seems to enter a state where it believes it is connected for mirroring, while the Mac never actually establishes the session. Issue 2: iPhone Mirroring crashes on macOS 27 Developer Beta 1 when used with iOS 26.5 After restoring the iPhone 15 Pro Max back to iOS 26.5, I was able to get a crash report from the Mac side. The iPhone Mirroring app crashed on macOS 27 Developer Beta 1 with the following details: Process: iPhone Mirroring Identifier: com.apple.ScreenContinuity Version: 2.0 Build Version: 114.38.15.1 OS Version: macOS 27.0 (26A5353q) Hardware Model: Mac16,7 Exception Type: EXC_BREAKPOINT (SIGTRAP) Termination Reason: Namespace SIGNAL, Code 5, Trace/BPT trap: 5 Triggered by Thread: 2 Dispatch Queue: com.apple.root.user-initiated-qos.cooperative The crashed thread shows a Swift assertion failure inside ScreenSharingKit.framework: Thread 2 Crashed: 0 libswiftCore.dylib assertionFailure(:_:file:line:flags:) + 216 1 ScreenSharingKit 0x29fbb60e0 2 libswiftCore.dylib _swift_release_dealloc + 64 3 libswiftCore.dylib RefCounts::doDecrementSlow 4 ScreenSharingKit 0x29fa894c0 5 ScreenSharingKit 0x29fb484d8 6 ScreenSharingKit 0x29fb48614 ... 15 libswift_Concurrency.dylib completeTaskWithClosure Relevant binary image: /System/Library/PrivateFrameworks/ScreenSharingKit.framework/Versions/A/ScreenSharingKit CFBundleIdentifier: com.apple.screensharing.ScreenSharingKit CFBundleVersion: 114.38.15.1 Crash interpretation The crash appears to be a first-party Apple framework crash inside ScreenSharingKit, caused by a Swift assertion failure. It does not appear to be caused by memory pressure, Rosetta, or third-party code injection. Relevant crash report details: External Modification Summary: task_for_pid: 0 thread_create: 0 thread_set_state: 0 System Integrity Protection: enabled Memory usage also does not look excessive: Writable regions: Total=251.0M MALLOC: 128.4M Expected behavior iPhone Mirroring should either connect successfully or fail gracefully. It should not: Leave the iPhone in a stuck/unresponsive state. Put the iPhone screen into mirroring mode while the Mac never completes the connection. Require the iPhone battery to fully drain before DFU restore is possible. Crash on macOS with an internal ScreenSharingKit Swift assertion failure. Actual behavior On iOS 27 Beta 1: iPhone Mirroring never completed the connection on the Mac. The iPhone behaved as if the session started. The iPhone screen turned off. The iPhone became completely unresponsive. Force restart did not work. Device only became recoverable after battery fully drained. I then restored the iPhone to iOS 26.5 via DFU. On iOS 26.5: iPhone Mirroring was able to run, but the Mac-side app later crashed. The crash occurred inside Apple’s ScreenSharingKit.framework. The crash type was EXC_BREAKPOINT (SIGTRAP) from Swift _assertionFailure. Reproducibility Partially reproducible. iOS 27 Beta 1 + macOS 27 Developer Beta 1: connection repeatedly failed and eventually left the iPhone stuck. iOS 26.5 + macOS 27 Developer Beta 1: iPhone Mirroring can connect, but the Mac app crashed with the attached report. Crash identifiers Incident Identifier: B6D4D86D-03C4-4466-B9D6-4CF70DF0B46F Crash Reporter Key: 8BD85D40-8AC8-E771-2D80-153D7C4C5366 Process: iPhone Mirroring [11429] Bundle ID: com.apple.ScreenContinuity The crash report points to ScreenSharingKit.framework, so this looks like a possible beta regression in the iPhone Mirroring / Continuity stack.

The on-demand economy has transformed how businesses operate, and fuel delivery services are no exception. From mobile fueling for commercial fleets to doorstep fuel delivery for consumers, companies are investing heavily in advanced mobile applications to streamline operations, improve customer experiences, and optimize logistics. New York City is home to several leading app development firms that specialize in building innovative fuel delivery platforms. These companies offer expertise in mobile app development, route optimization, GPS tracking, payment integrations, fleet management, and real-time analytics. Choosing the right development partner can significantly impact the success of your fuel delivery business. This guide highlights the best fuel delivery app development companies in NYC, their strengths, key services, and reasons they stand out in the competitive app development market. 1. Suffescom Solutions Suffescom Solutions is a renowned mobile app development company offering custom on-demand fuel delivery solutions. Their team develops scalable applications equipped with real-time tracking, secure payments, and fleet management capabilities. Why They’re Selected Extensive experience in on-demand app development Expertise in fuel delivery and logistics platforms Strong portfolio across multiple industries Scalable and secure application architecture End-to-end development and maintenance support Key Services Fuel delivery app development Fleet management solutions GPS tracking integration Payment gateway integration UI/UX design App maintenance and support 2. BitsWits BitsWits specializes in creating innovative mobile applications for startups and enterprises. Their fuel delivery solutions emphasize user-friendly interfaces, automation, and advanced operational management features. Why They’re Selected Strong mobile-first development approach Custom-built applications tailored to business needs Agile development methodology Focus on performance and scalability Experienced development team Key Services Custom app development Fuel delivery application development Android and iOS app development Backend development API integrations Quality assurance testing 3. Fueled Fueled is a well-established digital product agency known for developing premium mobile applications. The company delivers high-performing fuel delivery platforms with intuitive customer experiences and advanced functionality. Why They’re Selected Strong reputation in mobile app development Expertise in enterprise-grade applications Innovative design capabilities Proven project delivery record Focus on user engagement Key Services Mobile app development Product strategy UX/UI design Backend engineering Cloud integration Digital transformation solutions 4. FuGenX Technologies FuGenX Technologies provides comprehensive app development services for businesses seeking digital transformation. Their fuel delivery solutions incorporate advanced technologies to improve operational efficiency and customer convenience. Why They’re Selected Global experience across industries Skilled development professionals Advanced technology adoption Cost-effective development solutions Strong support services Key Services Fuel delivery app development Enterprise mobility solutions Cross-platform app development AI-powered integrations Cloud solutions Maintenance and upgrades 5. Nectarbits Nectarbits delivers innovative mobile and web applications designed for on-demand service industries. Their expertise helps fuel delivery businesses streamline logistics and improve customer satisfaction. Why They’re Selected Specialized in on-demand applications Strong technical expertise Customized development approach Reliable project management Excellent customer support Key Services Mobile app development Fuel delivery platform development Fleet tracking systems Web application development API development Technical consulting 6. Apps Chopper Apps Chopper focuses on building custom mobile applications that help businesses achieve operational excellence. Their fuel delivery solutions support seamless fuel ordering and real-time service management. Why They’re Selected Extensive mobile development expertise User-focused design philosophy Strong development framework Transparent project execution Reliable post-launch support Key Services iOS app development Android app development Fuel delivery app solutions UI/UX design App testing App modernization services 7. Hyperlocal Cloud Hyperlocal Cloud is recognized for developing hyperlocal and on-demand delivery solutions. The company offers feature-rich fuel delivery applications that enable businesses to manage operations efficiently. Why They’re Selected Specialization in hyperlocal delivery models Advanced logistics management expertise Quick deployment capabilities Scalable application infrastructure Industry-focused development approach Key Services Hyperlocal app development Fuel delivery platform development Route optimization solutions Real-time tracking integration Dispatch management systems Cloud-based solutions 8. Konstant Infosolutions Konstant Infosolutions is a leading app development company serving startups and enterprises worldwide. Their fuel delivery solutions combine innovative technology with scalable business-focused functionality. Why They’re Selected Over a decade of development experience Strong international client base Comprehensive development services Flexible engagement models Proven success across industries Key Services Mobile application development Fuel Delivery App Development Company solutions Cross-platform development Cloud integration Enterprise software development Ongoing support and maintenance Conclusion The demand for on-demand fuel delivery services continues to rise as businesses and consumers seek greater convenience and efficiency. Partnering with an experienced app development company can help you build a reliable, scalable, and feature-rich platform that meets market expectations. The companies listed above have demonstrated expertise in developing advanced mobile applications and on-demand solutions. By carefully evaluating your business requirements and development goals, you can select the right technology partner to bring your fuel delivery app vision to life.

Hey guys, can everyone share how long an estimated time range it took to get the new siri AI

Overview Using NotificationCenter's messages NSPersistentCloudKitContainer.EventChangedMessage (AsyncMessage) causes crash When the this project is run on iOS 27 simulator, app crashes Environment macOS: 26.5.1 (25F80) Xcode: Version 27.0 beta (27A5194q) Simulator: iPhone 17 Pro Simulator OS: iOS 27 Code causing the crash: let messages = NotificationCenter.default.messages( of: NSPersistentCloudKitContainer.self, for: .eventChanged ) Looks like the symbol is not even present Feedback: FB23220378 Logs dyld[31078]: Symbol not found: _$sSo29NSPersistentCloudKitContainerC8CoreDataE19EventChangedMessageVSo20NSNotificationCenterC10FoundationE05AsyncI0ACMc Referenced from: <488D9AA6-ED4C-3189-9A08-044D576D498D> /Users/username/Library/Developer/CoreSimulator/Devices/331ADE41-8F3A-4EBE-9E3B-B335B29224D3/data/Containers/Bundle/Application/573DF3FC-E202-4D47-A85F-E5D4D1421EAC/NotificationMessageDemo.app/NotificationMessageDemo.debug.dylib Expected in: <483D9879-24DB-3695-AFE5-B14E2D673F36> /private/var/run/com.apple.security.cryptexd/mnt/com.apple.iPhoneOS.SimulatorRuntime-v24.1.5355.16.mnzElK/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 27.0.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/CoreData.framework/CoreData Symbol not found: _$sSo29NSPersistentCloudKitContainerC8CoreDataE19EventChangedMessageVSo20NSNotificationCenterC10FoundationE05AsyncI0ACMc Referenced from: <488D9AA6-ED4C-3189-9A08-044D576D498D> /Users/username/Library/Developer/CoreSimulator/Devices/331ADE41-8F3A-4EBE-9E3B-B335B29224D3/data/Containers/Bundle/Application/573DF3FC-E202-4D47-A85F-E5D4D1421EAC/NotificationMessageDemo.app/NotificationMessageDemo.debug.dylib Expected in: <483D9879-24DB-3695-AFE5-B14E2D673F36> /private/var/run/com.apple.security.cryptexd/mnt/com.apple.iPhoneOS.SimulatorRuntime-v24.1.5355.16.mnzElK/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 27.0.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/CoreData.framework/CoreData dyld config: DYLD_SHARED_CACHE_DIR=/Library/Developer/CoreSimulator/Caches/dyld/25F80/com.apple.CoreSimulator.SimRuntime.iOS-27-0.24A5355p/ DYLD_ROOT_PATH=/private/var/run/com.apple.security.cryptexd/mnt/com.apple.iPhoneOS.SimulatorRuntime-v24.1.5355.16.mnzElK/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 27.0.simruntime/Contents/Resources/RuntimeRoot DYLD_LIBRARY_PATH=/Users/username/Library/Developer/Xcode/DerivedData/NotificationMessageDemo-gungjtytarzeijdspglltylscocj/Build/Products/Debug-iphonesimulator DYLD_INSERT_LIBRARIES=/private/var/run/com.apple.security.cryptexd/mnt/com.apple.iPhoneOS.SimulatorRuntime-v24.1.5355.16.mnzElK/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 27.0.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libLogRedirect.dylib:/private/var/run/com.apple.security.cryptexd/mnt/com.apple.iPhoneOS.SimulatorRuntime-v24.1.5355.16.mnzElK/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 27.0.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libMainThreadChecker.dylib:/usr/lib/libRPAC.dylib:/private/var/run/com.apple.security.cryptexd/mnt/com.apple.iPhoneOS.SimulatorRuntime-v24.1.5355.16.mnzElK/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 27.0.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libViewDebuggerSupport.dylib DYLD_FRAMEWORK_PATH=/Users/username/Library/Developer/Xcode/DerivedData/NotificationMessageDemo-gungjtytarzeijdspglltylscocj/Build/Products/Debug-iphonesimulator DYLD_FALLBACK_FRAMEWORK_PATH=/private/var/run/com.apple.security.cryptexd/mnt/com.apple.iPhoneOS.SimulatorRuntime-v24.1.5355.16.mnzElK/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 27.0.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks DYLD_FALLBACK_LIBRARY_PATH=/private/var/run/com.apple.security.cryptexd/mnt/com.apple.iPhoneOS.SimulatorRuntime-v24.1.5355.16.mnzElK/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 27.0.simruntime/Contents/Resources/RuntimeRoot/usr/lib Debug session ended with code 9: killed

Hello, I am exploring an iPadOS product idea for Apple Pencil users and would like to understand the current public API boundary. The user need is a temporary, user-controlled Apple Pencil annotation layer while the user is working in another app or workspace. For example, a student may be reading in Books, Safari, a PDF app, or another educational app and want to write quick Pencil notes directly over the visible material without taking a screenshot or exporting the content first. I understand that PencilKit works inside an app's own UI, and I also understand that iPadOS sandboxing prevents third-party apps from inspecting or modifying other apps. I am not trying to bypass that model. What I am trying to determine is: Is there any current public API, extension point, or entitlement that allows a user-initiated Apple Pencil overlay session across the current iPadOS workspace? If not, is Feedback Assistant the right place to request a new PencilKit / iPadOS entitlement for this use case? Are there existing Apple-recommended patterns for this workflow beyond Quick Note, Screenshot Markup, Split View, Stage Manager, or importing content into the developer's own app? The privacy model I have in mind would be strict: The overlay is user initiated only. A visible system indicator is shown while active. The developer app receives Pencil stroke data only by default. The app cannot inspect the underlying app's view hierarchy, documents, text, or private data. Screen pixels are not captured unless the user grants separate explicit permission. The user can close or clear the overlay at any time. The closest mental model is a system-mediated Pencil annotation layer, not a background screen recorder or a way to control another app. If this is not possible today with public APIs, I would appreciate confirmation so I can file a clear enhancement request through Feedback Assistant. I also filed this as Feedback Assistant report FB23067750. Thank you.

I previously attempted to apply for the hotspot-provider entitlement but was rejected. I no longer require this entitlement. I need to remove the hotspot-provider permission although the Network Extensions capability is checked. However, the generated provisioning profile still includes the hotspot-provider permission, which causes error 409 when I upload the IPA file. I only need the Network Extensions entitlement. Could you please advise how to remove hotspot-provider from the provisioning profile?

Description of the Issue: We are experiencing intermittent, severe latency spikes during cellular data transmission (specifically with MQTT Publish) on iPhone 17 devices. Through internal testing and cross-referencing with similar user reports online, we suspect this is caused by an aggressive power-saving or sleep mechanism in the cellular modem/iOS network stack when traffic is sporadic or low-frequency. Steps to Reproduce / Observations: Establish an MQTT connection over a cellular network (5G/LTE) on an iPhone 17. Publish messages at irregular or low-frequency intervals (e.g., sporadic IoT data transmission). Result: Severe latency spikes occur intermittently during transmission. Diagnostic Findings & Documented Workarounds: Workaround 1 (Constant Traffic): If we connect a secondary device (e.g., a PC) to the iPhone 17's Personal Hotspot and run a continuous background ping (with a 10ms interval), the MQTT latency spikes disappear completely. This high-frequency traffic prevents the device/modem from dropping into power-save mode. Workaround 2 (VPN Tunnel): Utilizing a VPN profile (such as Cloudflare's 1.1.1.1 app) significantly mitigates the issue. We suspect this is due to either the VPN's background keep-alive packets maintaining the active state of the modem, or iOS applying a less aggressive power-saving policy to active VPN interfaces. System Environment: Device: iPhone 17 series OS: iOS 19 (or specify your current version) Network: Cellular (5G/LTE) Questions Regarding Temporary Workarounds & Mitigations: To unblock our current development and ensure a reliable user experience before an official OS-level fix is deployed, we would highly appreciate Apple's technical guidance on the following questions: Recommended Keep-Alive Mechanism: Since higher frequency traffic effectively prevents the modem from entering power-save mode, does iOS have a recommended, power-efficient way for an application to maintain an active cellular network state (e.g., recommended TCP/MQTT keep-alive intervals or NWPathEvaluator configurations) without being suspended or penalized by the system? Network Optimization APIs: Are there specific Network Framework APIs (Network.framework) or socket configuration flags (such as Multipath TCP, or Quality of Service (QoS) flags like Background vs Default) that can signal to the iOS kernel to apply a less aggressive power-saving policy on the active cellular interface? Background Execution Policy: For IoT applications that need to publish MQTT data seamlessly while running in the background, what is the best practice to prevent the cellular link from dropping into deep sleep mode? We would appreciate it if the Apple Network/CoreOS engineering team could look into this cellular power management behavior. Thank you for your support.

Howdy, I've noticed a strange behavior recently on my macos (26.5.1) when using my System Extension-hosted Network Extension with a Packet Tunnel Provider inside: let dnsSettings = NEDNSOverHTTPSSettings(servers: ["8.8.8.8", "8.8.4.4"]) dnsSettings.serverURL = URL(string: "https://dns.google/dns-query") settings.dnsSettings = dnsSettings I have always expected this block to not need any DNS resolution, since IPs for dns.google are preconfigured, however not sure it's been the case lately. I see normal DNS requests to the addresses above to :53. Once resolved, no more DNS traffic, just :443 via TUN. Is it possible that some changes were introduced in the past months that would make macos to have to resolve dns.google with regular DNS before switching over to DoH?

Hi, I'm working on a trip detection and recording app that relies on CLLiveLocationUpdates for the location tracking. We've observed a recurring issue where trip recording eventually stops working if the app is not opened for an extended period of time (approximately 2–3 weeks). What we observe The app continues to be installed on the device. The user does not manually open the app during this period. Eventually, trip detection and recording stop. Location diagnostics indicate: Service Session Required At this point, CLLiveLocationUpdates no longer appears to deliver location events. Recovery attempts We've tried several ways to recover without launching the app: Turning Location Services off/on Rebooting the device Changing location permissions None of these restore location updates. The only reliable recovery method we've found is: Open the app manually. Leave it running for some time. Kill the app again. After doing this, location tracking resumes and works normally for 4-5 days before eventually failing again with the same "Service Session Required" diagnostic. Questions Why would a valid location setup eventually transition into a "Service Session Required" state after the app has not been launched for several weeks? Are there any documented conditions under which an existing CLServiceSession expires, becomes invalid, or requires recreation? Is there a recommended way to recover from this state programmatically without requiring the user to manually launch the app? Is this expected behavior or a potential issue with CLLiveLocationUpdates / CLServiceSession? Additional details iOS version: 26 App uses: CLLiveLocationUpdates, Beacon Ranging & Beacon Monitoring, SLC updates, Motion Activity Updates Background location enabled: Yes Authorization type: Always Device models tested: iPhone 14 Pro Max Service session creation code: private var serviceSession: CLServiceSession? serviceSession = CLServiceSession( authorization: .always, fullAccuracyPurposeKey: "Trip" ) Has anyone else encountered a similar issue after long periods where the app is not launched? Thanks.

Since macOS 26 (Tahoe), getaddrinfo() with AF_UNSPEC for a hostname whose DNS answer contains only A records (no AAAA) fails in forked child processes when the parent performed DNS resolution, or otherwise initialized os_log, before forking. This is a regression: the same code works on macOS 15.x and earlier. The child crashes with EXC_BAD_ACCESS (KERN_INVALID_ADDRESS) inside the NAT64 synthesis path: _os_log_preferences_refresh (libsystem_trace.dylib) <- faulting frame os_log_type_enabled (libsystem_trace.dylib) nw_path_access_agent_cache (Network) _nw_path_update_is_viableTm / nw_path_snapshot_path / nw_path_evaluator_evaluate nw_nat64_v4_address_requires_synthesis _gai_nat64_second_pass (libsystem_info.dylib) si_addrinfo -> getaddrinfo Runtimes that install a SIGSEGV handler (Ruby, Python) do not die; instead the DNS helper thread spins at 100% CPU and the process hangs. We have also captured a parent-side variant where a later fork() deadlocks in the atfork prepare path itself: libSystem_atfork_prepare -> nw_path_prepare_fork -> _os_unfair_lock_lock_slow. Minimal trigger in C: os_log_t log = os_log_create("com.example.repro", "repro"); os_log(log, "init"); struct addrinfo hints = { .ai_family = AF_UNSPEC, .ai_socktype = SOCK_STREAM }, *res; getaddrinfo("api.stripe.com", "443", &hints, &res); // parent: IPv4-only host if (fork() == 0) { getaddrinfo("api.stripe.com", "443", &hints, &res); // child: crashes in _os_log_preferences_refresh _exit(0); } Observed behavior and boundaries: Reproduces on 26.1 through 26.5.1 (25F80). Not reproducible on macOS 15.x. Only AF_UNSPEC lookups of IPv4-only hostnames are affected. AF_INET hints, IPv6-capable hostnames (for example google.com), numeric literals, and localhost are all immune. AF_INET6-only lookups neither trigger nor prevent it. The failure is all-or-nothing per parent process: once a parent is in the affected state, every forked child fails. On 26.5.1 it reproduces most reliably when the process was exec'd over a prior os_log-using image (for example Ruby launched via bundle exec, where the bundler Ruby execs the target Ruby in the same process), and intermittently from a bare shell. On 26.1 even bare runs reproduced readily. This is consistent with per-process logging state surviving exec and then being inherited invalid across fork. I understand that officially only async-signal-safe calls are supported between fork and exec. But this worked through macOS 15, and it breaks the pre-forking worker model used by major Ruby and Python frameworks (Resque, Unicorn, multiprocessing) on developer machines. Filed as FB21364061 in December 2025, no response so far. Is this a known issue, and is a fix present or planned in macOS 26.6 or the macOS 27 beta?

I have a swift app which I'm running via a LaunchAgent. It sends a video feed via multicast UDP. While it works if I manually allow via Privacy & Security - Local Network (allowing the app to find devices on local network), I cannot get AllowedEthernetLocalNetworkAddresses to work. I have attempted to do so with my app and with ffmpeg (installed via homebrew). Neither seems to respect the AllowedEthernetLocalNetworkAddresses setting outlined in TN3179: Understanding local network privacy | Apple Developer Documentation. I have attempted allowing 239.0.0.0/8, 224.0.0.0/4, 239.255.0.0/16, 239.255.1.1/32. I see no change after a reboot with any of these values in the array: sudo defaults write com.apple.network.local-network AllowedEthernetLocalNetworkAddresses -array "239.0.0.0/8" This is on macOS 26.5.1, and I am only connected via ethernet. Am I missing a configuration piece? Thanks!

When entering the following command in macOS 27 beta: lvbojie@Mac ~ % netstat -I nan0 1 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll nan0* 1500 <Link#25> 66:31:00:4c:3c:b5 0 0 41 0 0 nan0* 1500 fe80::6431: fe80:19::6431:ff: 0 - 41 - - liushicong@Mac ~ % netstat -I nan0 1 The nan0 network interface is displayed. Does this indicate that macOS will support Wi-Fi Aware in the near future?

WeatherService fails on every request with: WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" hourly forecast fetch failed: … Code=2 I've verified the entire setup and the error persists, which points to the App ID's WeatherKit token generation not being provisioned on Apple's backend: Team ID: 2LWCLD2636 Bundle ID: com.hoagiecorps.poppit WeatherKit capability and App Service both enabled on the App ID. com.apple.developer.weatherkit entitlement present in the signed binary and the embedded provisioning profile (verified via codesign -d --entitlements). A TestFlight build carrying the entitlement has been processed (VALID). Location authorized (When-In-Use); valid coordinates are obtained — the failure is purely the JWT auth step. Tried: device reboot, VPN off, iCloud Private Relay off, cycling the WeatherKit capability off/on plus regenerating the profile and clean rebuild, and waiting several days. Physical device, iOS 26. Could someone from the WeatherKit team please check the status for Team 2LWCLD2636, Bundle ID com.hoagiecorps.poppit, and enable WeatherKit token generation for this App ID? It looks like a backend entitlement sync is needed. Thanks!

Hi Apple Developer Support / WeatherKit team, I’m seeing WeatherKit fail on a physical iPhone with what appears to be a JWT / permission issue, even though the app appears to be correctly configured and signed with the WeatherKit entitlement. App / project context: App name: Signals Platform: iOS Framework: SwiftUI WeatherKit usage: Native WeatherKit framework, using WeatherService.shared.weather(for:) Purpose: Showing a small morning weather summary inside the app What I have already verified: Active Apple Developer Program membership WeatherKit capability enabled for the App ID in Apple Developer Portal WeatherKit capability enabled in the App Capabilities tab WeatherKit capability added in Xcode Signing & Capabilities Automatic signing enabled Built and tested on a physical iPhone device Location permission is requested and granted The app binary appears to include the WeatherKit entitlement The embedded provisioning profile appears to include the WeatherKit entitlement Issue: WeatherKit still fails at runtime with a JWT / permission-related error. Could you please help verify whether: The WeatherKit entitlement is correctly attached to my App ID and provisioning profile My Team ID / App ID has WeatherKit access fully enabled on Apple’s backend There are any backend propagation delays or stuck entitlement states WeatherDaemon has permission to generate JWTs for this app There is anything else I need to reset or regenerate, such as provisioning profiles, certificates, or App ID capabilities I can provide: Team ID Bundle ID provisioning profile UUID entitlement output from codesign device logs / WeatherKit error logs screenshots of App ID capability settings Thank you.

When scheduling a local notification, it can be delayed by up to 5 seconds. On iOS 26, the notification appears instantly at the scheduled time. Feedback ID: FB23218437

Is there any restriction in File system renaming using shove from sandboxed to runtime path?? failed _relinkFile(/Library/InstallerSandboxes/.PKInstallSandboxManager/EFFC026D-F5AD-4F2D-8EB1-E73B78E51E1A.activeSandbox/Root/Library/Application Support/McAfee/MSS/Applications/Trellix Agent Status Monitor.app/Contents/_CodeSignature/CodeResources, /Library/Application Support/McAfee/MSS/Applications/Trellix Agent Status Monitor.app/Contents/_CodeSignature/CodeResources): Operation not permitted 2026-05-27 12:20:37-04 OSX-CG46R0630R installd[8236]: PackageKit: releasing backupd 2026-05-27 12:20:37-04 OSX-CG46R0630R installd[8236]: PackageKit: allow user idle system sleep 2026-05-27 12:20:37-04 OSX-CG46R0630R installd[8236]: PackageKit: Install Failed: Error Domain=PKInstallErrorDomain Code=120 "An unexpected error occurred while moving files to the final destination." UserInfo={NSLocalizedDescription=An unexpected error occurred while moving files to the final destination., This is immediately followed by: PKInstallErrorDomain Code=120 NSPOSIXErrorDomain Code=1 "Operation not permitted" Based on the installer logs reviewed so far, the failure appears to occur during a PackageKit file relink operation and is accompanied by "Operation not permitted" errors, which suggests a permissions enforcement issue during installation.

Hi, I wanted to reach out about an issue we're seeing in PTT Framework. We have been investigating reports from some users that our app would run without issue for a day or so and then they would suddenly be unable to transmit audio but playback continued to work normally. After doing some digging and internal testing I was able to reproduce this by triggering a media services reset while PTT Framework was active (we had joined a channel). When this occurs everything appears to work correctly, all normal callbacks are received and the audio session is activated, but the data from the tap on the input node of our audio engine returns only silence regardless of whether the app is in the foreground or background. I'm able to reproduce this with 100% reliability using the following steps: Activate PTT Framework by joining a channel. Navigate to Settings -> Developer, tap Reset Media Services, and select Reset All Media Services. Return to the app and attempt to transmit. I've validated this behavior both in our app as well as in a separate minimal test app we use internally to validate interactions with the framework. Once we end up in this state it persists through tearing down and recreating our audio engine, deactivating and re-activating the audio session, killing the app and restarting it, etc. The only way we have found to recover from this state is to either reboot the device or leave the framework's channel and join again (basically toggle PTT Framework off and back on). Based on what I was able to find I believe this is the known CallKit issue (r.157725305) referenced in this forum post and does extend to PTT Framework. As mentioned above, we currently haven't found a good way to deal with this. Our current solution to this is to programmatically "toggle" PTT framework. This partially solves the problem but it has a couple issues: It causes the PTT Framework activation and deactivation sounds in quick succession. This is expected but not ideal UX. Because attempting to join a channel when the app is not in the foreground results in a failure with PTChannelError.appNotForeground we can only recover when in the foreground. The second issue is the more serious of the two as our users commonly rely on external wired or BLE devices to trigger PTT calls while the device is locked or the app is in the background. In this scenario we can't automatically recover so they won't know something is wrong until they realize they are only transmitting silence. We can identify when this occurs via the internal media services reset notification but again we only receive this while the app is active. Additionally, if the app was suspended when the reset occurred but then becomes active it is received after a 2-4 second delay so if the app wakes up to start a call, we commonly don't receive it until the user is already in the middle of a call trying to transmit. Is there anything we can do here other than posting a notification telling the user that there is an issue and they need to on-screen the app to resolve it? I've tried to provide as much information as possible but if there's anything else that would be helpful let me know.

Hello, I have a device like a gas meter or an electricity meter and it has: an optical interface IEC 62056-21 (IEC-1107) with support for speeds up to 115,200 Bd. On Windows and Android, we use a cable that has an optical interface and on the other end we connect USB A to the PC and to the Android via an OTG to USB adapter. The cable contains a chip from FTDI FT230XQ. I have an application in MAUI where I want to connect this cable to the 10th generation iPad and communicate similarly to, for example, via the COM5 port on the PC. When the port opens, I send a query and get a response. Is it possible, what should I do for this? What about Apple certification of cables? Is it possible to send a packet from MAUI via the USB C port via the cable and then receive and process the packet again? What about MFi? I found this: https://redpark.com/usb-c-serial-cable/ Please can you give me some idea or expert to this topic? Thanks, Roman