Team-scoped keys introduce the ability to restrict your token authentication keys to either development or production environments. Topic-specific keys in addition to environment isolation allow you to associate each key with a specific Bundle ID streamlining key management. For detailed instructions on accessing these features, read our updated documentation on establishing a token-based connection to APNs.

Hello developers! Thank you for your dedication to creating apps with great performance. We’re excited to kick off another year of partnering with you on improving power and performance in your apps. At WWDC26, check out the following new things in the latest platform SDKs and Xcode 27 beta for performance. You can also join us online for a Power and Performance Group Lab on Tuesday, June 9 at 11 AM Pacific. Meet State Reporting and the new MetricKit State reporting: The new StateReporting framework lets your application express its state to downstream tools like Instruments and MetricKit. Make your telemetry and traces much more useful by adopting this simple API. MetricKit: In the 27 releases, the Swift-first MetricManager API replaces the MXMetricManager API. Combined with State Reporting, the new MetricKit provides more granular metrics to isolate performance problems faster. It also provides a more expressive API that is great to use in Swift, with improved Swift concurrency and Codable support. With this year’s releases, the MXMetricManager API is considered legacy. ▶️ To learn more, watch Meet the new MetricKit. Discover new features in Xcode organizer Metric goals: Xcode organizer now provides a goal metric for Battery Usage, Disk Writes, Hang Rate, Hitches, Memory, and Storage metrics, allowing you to prioritize performance engineering across more areas. Generate recommendations: Quickly resolve the highest impact performance issues in your app by using Generate Recommendations for Crash, Energy, Disk Write, Hang and Launch diagnostics. Insights overview: The new insights overview in Xcode organizer summarizes high-impact performance regressions for metrics and diagnostic reports, helping you plan and prioritize performance engineering work. Storage metrics: Storage metrics are now available in Xcode organizer, allowing you to monitor your app's Documents & Data and App Size across releases and catch regressions in cache usage and bundle size. Hitches metric: The new Hitches metric replaces the Scrolling metric in the organizer and now displays hitches for all animations in your app, giving you a comprehensive view of animation performance. ▶️ To learn more about other advancements in Xcode, watch What’s new in Xcode 27. Improve app responsiveness with Instruments Foundation Models: The Foundation Models instrument is redesigned with a tree view that lets you drill into individual requests, inspecting tool call arguments and results, inference prompts and responses, and token statistics. Use it to understand caching behavior, measure latency, and optimize throughput. System Trace: System calls, VM faults, and thread states are now unified into a single plot, with a new blending algorithm that stays readable even at high density. Once you spot something worth investigating, left/right key navigation lets you follow a thread's activity step by step, and the inspector provides quick actions like pinning the thread that made another thread runnable. System Trace now also draws thread priority and QoS over time, making it easier to identify priority inversions and unexpected QoS degradations that affect responsiveness. Swift Concurrency: New Main Actor and Global Concurrent Executor tracks let you visualize running tasks and executor queue depth over time, making it easier to spot task scheduling delays and actor contention. Tasks are now grouped into collections for faster navigation. Swift Tasks, Actors, and Executors instruments can now surface Call Trees, Flame Graphs, and Top Functions scoped to each entity — so you can pinpoint exactly where concurrency overhead lives. Top Functions: Helper functions and runtime internals can be expensive but hard to spot in a standard call tree. The new aggregation mode in Top Functions surfaces any function's total execution time across the entire call stack, making it easy to identify and prioritize hidden hotspots. Run Comparison: Compare call tree data across builds to identify regressions and performance wins. Results can be explored as an outline, flame graph, or top functions — choose whichever view best fits your workflow. ▶️ To learn more about profiling your app with Instruments, watch “Profile, fix, and verify: Improve app responsiveness with Instruments” ▶️ To learn about Foundation Models optimization, watch “Debug and profile agentic app experiences with Instruments”. If you have any questions about using State Reporting or the new MetricKit, create a post on the forums. For help creating a post, see Tips on writing a forum posts.

While running my application on macOS 27 today, it crashed in a strange way. The backtrace for the thread that crashed looks like it was some kind of Spotlight search indexing thread. The strange part is that my app makes no use of Spotlight and is not mentioned anywhere in the Spotlight section of System Prefs. Here is the backtrace, maybe something in here is enough of a clue as to what happened and why my App was running a Spotlight-related thread. This was on 27 beta 1 (26A5353q), and the app is a video streaming app that uses both Qt 6.11.1 and SDL 3 and was rendering some frames with Metal at the time. The most unusual thing in the backtrace is the existence of ObjC params spelled both updatingDonationProgress as well as updatingDonationProgres. Thread 8 Crashed:: Dispatch queue: com.apple.root.user-initiated-qos 0 libobjcMsgSend.dylib 0x19e7f0808 objc_msgSend + 8 1 CoreFoundation 0x1970fe300 __NSSetM_new + 368 2 CoreFoundation 0x19711cd64 -[NSSet initWithArray:range:copyItems:] + 304 3 LaunchServices 0x1976bc144 -[_LSLocalizedStringRecord _missingBundleLocsWithContext:tableID:unitID:unitBytes:] + 104 4 LaunchServices 0x197700628 objc_object* __strong __LSRECORD_GETTER__<objc_object* __strong>(LSRecord*, objc_selector*, objc_selector*) + 288 5 LaunchServices 0x1976bc854 -[_LSLocalizedStringRecord _detachFromContext:tableID:unitID:unitBytes:] + 68 6 LaunchServices 0x197701cac -[LSRecord detach] + 240 7 LaunchServices 0x197773720 -[UTTypeRecord _detachFromContext:tableID:unitID:unitBytes:] + 68 8 LaunchServices 0x1977756fc -[_UTDeclaredTypeRecord _detachFromContext:tableID:unitID:unitBytes:] + 52 9 LaunchServices 0x197701cac -[LSRecord detach] + 240 10 LaunchServices 0x197702c74 +[LSRecord(LSDetachable) resolveAllPropertiesOfRecords:count:andDetachOnQueue:] + 392 11 UniformTypeIdentifiers 0x19cd1bc80 +[UTType _typeWithTypeRecord:detachTypeRecord:findConstant:installInConstant:] + 232 12 UniformTypeIdentifiers 0x19cd19d38 _UTTypeGetForIdentifier(NSString*, bool) + 148 13 SpotlightKnowledge 0x2a7596adc -[SKGProcessor(EmbeddingsUtils) needsEmbeddingsForRecord:bundleID:] + 604 14 SpotlightKnowledge 0x2a7590bd4 -[SKGAttributeProcessor processorAttributesForRecord:bundleID:protectionClass:isUpdate:] + 500 15 CoreSpotlight 0x1a79bfa84 -[CSSearchableItemAttributeSet(CSPrivateAttributes) _standardizeProcessorAttributesForBundle:protectionClass:isUpdate:] + 292 16 CoreSpotlight 0x1a79b11a4 -[CSSearchableItem(Internal) standardizeAttributesForBundle:protectionClass:] + 780 17 CoreSpotlight 0x1a799f218 __39-[CSSearchableIndex _standardizeItems:]_block_invoke + 248 18 CoreFoundation 0x19712e56c __NSARRAY_IS_CALLING_OUT_TO_A_BLOCK__ + 24 19 CoreFoundation 0x197277604 ____NSCollectionHandleConcurrentEnumerationIfSpecified_block_invoke + 116 20 libdispatch.dylib 0x196ed45d4 _dispatch_client_callout2 + 16 21 libdispatch.dylib 0x196ecf2d4 _dispatch_apply_invoke3 + 336 22 libdispatch.dylib 0x196ed45bc _dispatch_client_callout + 16 23 libdispatch.dylib 0x196ebd624 _dispatch_once_callout + 32 24 libdispatch.dylib 0x196ecf974 _dispatch_apply_invoke_and_wait + 364 25 libdispatch.dylib 0x196ecea70 _dispatch_apply_with_attr_f + 1312 26 libdispatch.dylib 0x196ecebf4 dispatch_apply + 96 27 CoreFoundation 0x197277548 __NSCollectionHandleConcurrentEnumerationIfSpecified + 184 28 CoreFoundation 0x19712e350 -[__NSArrayM enumerateObjectsWithOptions:usingBlock:] + 188 29 CoreSpotlight 0x1a78d99b4 -[CSSearchableIndex _standardizeItems:] + 144 30 CoreSpotlight 0x1a799d4b0 -[CSSearchableIndex indexSearchableItems:deleteSearchableItemsWithIdentifiers:clientState:expectedClientState:clientStateName:updatingDonationProgress:protectionClass:forBundleID:options:reason:completionHandler:] + 824 31 CoreSpotlight 0x1a799d024 -[CSSearchableIndex indexSearchableItems:deleteSearchableItemsWithIdentifiers:clientState:expectedClientState:updatingDonationProgress:protectionClass:forBundleID:options:reason:completionHandler:] + 52 32 CoreSpotlight 0x1a799ca64 __131-[CSSearchableIndex endIndexBatchWithExpectedClientState:newClientState:critical:reason:updatingDonationProgres:completionHandler:]_block_invoke + 188 33 libsystem_trace.dylib 0x196d957e8 _os_activity_initiate_impl + 64 34 CoreSpotlight 0x1a799c91c -[CSSearchableIndex endIndexBatchWithExpectedClientState:newClientState:critical:reason:updatingDonationProgres:completionHandler:] + 448 35 AppKit 0x19c7a3568 0x19b5b6000 + 18797928 36 AppKit 0x19c4d8584 0x19b5b6000 + 15869316 37 libdispatch.dylib 0x196ebaa30 _dispatch_call_block_and_release + 32 38 libdispatch.dylib 0x196ed45bc _dispatch_client_callout + 16 39 libdispatch.dylib 0x196ec3018 _dispatch_lane_serial_drain + 744 40 libdispatch.dylib 0x196ec3b4c _dispatch_lane_invoke + 448 41 libdispatch.dylib 0x196ecdf70 _dispatch_root_queue_drain_deferred_wlh + 284 42 libdispatch.dylib 0x196ecd874 _dispatch_workloop_worker_thread + 720 43 libsystem_pthread.dylib 0x197076f78 _pthread_wqthread + 292 44 libsystem_pthread.dylib 0x197075cc4 start_wqthread + 8

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.

Hello, I am developing a cross-platform mobile app that communicates with an external accessory over a serial (UART) link. HARDWARE : The accessory is an optical reading probe that connects to the phone via USB. Inside the cable there is a standard FTDI USB-to-serial chip (similar to common FTDI/CP210x USB-serial adapters). WHAT WORKS On Android, our app: Detects the USB device Opens the serial port Reads and writes raw bytes successfully This wired FTDI path is fully implemented and working. WHAT DOES NOT WORK On iPhone, using the same wired FTDI USB accessory: We connect via Lightning or USB-C adapter The app never sees the FTDI device We cannot find a public iOS API to open a generic USB-serial port MY QUESTION : Is there any supported way for a third-party iOS app to communicate with a generic FTDI USB-serial device over a wired USB connection? Specifically, am I missing: A public Apple framework for USB serial? An Info.plist key or entitlement? A system driver on iOS similar to macOS AppleUSBFTDI (TN2315)? Or is wired USB-serial on iPhone only possible with MFi-certified accessories (External Accessory framework) or another transport such as Bluetooth LE? WHAT I HAVE ALREADY CHECKED External Accessory: seems to require MFi hardware and a registered protocol string. Our FTDI probe is not MFi. TN2315 (AppleUSBFTDI): appears to be macOS only, not iOS. Physical USB connection: cable fits, but no serial API is exposed to the app. ENVIRONMENT Platform: iOS (iPhone) Language: C# / .NET-iOS Need: transparent byte-level serial read/write SUMMARY: Android USB-serial works with our FTDI wired accessory. iOS does not. Am I missing something on iOS, or is generic FTDI USB-serial simply not supported for third-party iPhone apps? Thank you for any guidance.

I have the following code - you can see where I had to comment out the code on the simulator. Is this expected? The code works perfectly fine on a physical iPad device. Is it documented somewhere that NSFileVersion doesn't work with non-local versions in the simulator? func loadPreviewDirectly( from version: NSFileVersion, completion: @escaping (CIImage?) -> Void ) { let versionURL = version.url let access = versionURL.startAccessingSecurityScopedResource() defer { if access { versionURL.stopAccessingSecurityScopedResource() } } print("Loading version: \(version.persistentIdentifier) | Local: \(version.hasLocalContents)") // 1. SIMULATOR CATCH: If running in simulator and the file is missing, it will never download. #if targetEnvironment(simulator) if !version.hasLocalContents { print("⚠️ iOS Simulator cannot materialize remote NSFileVersions. Fallback triggered.") // You cannot test remote versions here. For testing on the simulator, // test with a version where version.hasLocalContents == true (created locally in this session). DispatchQueue.main.async { completion(nil) } return } #endif let coordinator = NSFileCoordinator() var coordinationError: NSError? // 2. Wrap everything in a sequential reading coordination coordinator.coordinate(readingItemAt: versionURL, options: [], error: &coordinationError) { readURL in let image = CIImage(contentsOf: readURL) DispatchQueue.main.async { completion(image) } } if let error = coordinationError { DispatchQueue.main.async { self.errorMessage = error.localizedDescription completion(nil) } } }

Hi everyone, I am developing a macOS virtualization manager (VirtualProg) using the Virtualization.framework. The application is distributed via the Mac App Store, so it operates strictly within the App Store Sandbox. I am looking for a reliable, programmatic way to discover the IP address assigned to a guest (both macOS and Linux). Is there a recommended "Sandbox-safe" API or pattern within the Virtualization framework—or a lower-level networking entitlement—that allows a host application to retrieve the guest's assigned IP address? Ideally, I am looking for a solution that does not require the user to manually install a non-sandboxed helper tool. Thanks in advance for any insights or guidance!

One thing I wanted to confirm, suppose i submit one request to onboard OHTTP relay for one organisation app and it gets approved, so can I re submit the request with different bundle ID for other organisation and same PIR server, same OHTTP server ? Or do we need different domain name ?

We had noticed “paymentCredentialsAvailable” is getting returned more from apple pay capabilities for some unexpected devices (our example is windows + chrome). Based off the documentation this should only be returning if this is linked to a wallet account w/ valid payment. From some investigation this appears to have changed from apple pay js v1.3.7 to v1.3.8 (latest). Previously the above windows + chrome example would return “paymentCredentialStatusUnknown” which is what would be expected in this case. Tried running chrome in icognito mode and clearing cookies just in case this check had some linkage to the apple account via QR code usage, but did not appear to affect the returned response. Unsure if this is a bug or a change to the logic, but doesn’t appear to be appropriately reflected in the documentation, also a change like this should not be appearing in a patch version. Has anyone else experienced this?

Hello, I have a question about App Intents and the Action button on iPhone. I have an App Intent that opens the app and navigates to a specific entity, conforming to OpenIntent with a single AppEntity parameter. The entity conforms to EnumerableEntityQuery, and the intent is registered as an App Shortcut via the AppShortcutsProvider. When assigning this shortcut to the Action button in Settings, the system doesn’t prompt the user to select a default entity upfront. Instead, it prompts on every activation, creating friction. In contrast, shortcuts like “Open Note…” and other third-party ones prompt the user for a note to open when setting up the Action button, and its title also includes three dots, indicating a pre-configurable parameter. My shortcut’s title shows no dots. What’s required to make an App Shortcut prompt for a default parameter during Action button setup? Sincerely, Holger

I submitted the app for review. They reviewed it the first time, provided feedback, I fixed the issues, and resubmitted it. Three weeks have passed, and they didn’t even accept the app with the fixes for a second review. This isn’t normal But at the same time, they charged me 99 euros for developer status in just 3 minutes It’s unclear what to expect and how long it will take

High Power Mode setting is not applied by powerd (possibly related to migrateenergyprefs) Summary On a MacBook Pro (14-inch, M5 Max), enabling High Power Mode in System Settings has no effect on the actual power governor. The system continues to run at the default (Automatic-equivalent) power ceiling regardless of the High Power Mode setting. The same symptom has been reproduced on a different physical machine, a MacBook Pro (M4 Max), ruling out a single hardware defect. Environment Affected device: MacBook Pro 14-inch (Apple M5 Max, 12P+6S+40GPU, 128GB RAM) macOS version: macOS 26.5.1 (Build 25F80) Migration history: Intel Mac → MacBook Air (M2) → MacBook Pro (M4 Max) → MacBook Pro (M5 Max), using Migration Assistant at each step Same symptom also confirmed on the MacBook Pro (M4 Max), which had the same migration history Symptom Selecting "High Power" under System Settings → Battery → Power Mode has no effect on system_profiler SPPowerDataType, which always reports High Power Mode: No. pmset -g custom correctly shows powermode 2 (the High Power equivalent) for AC Power, confirming the user-facing setting is being written correctly. Low Power Mode in the same system_profiler output correctly toggles between Yes/No depending on the UI selection (Automatic / Low Power / High Power). Only High Power Mode fails to track the UI selection. Benchmarking with 3DMark Steel Nomad Stress Test (Metal API) reproduces the score pattern that third-party reviews report for High Power Mode OFF (stabilized score ~3100–3400), rather than the ON pattern reported for the same model (~3600+). This confirms the issue is not just cosmetic (a wrong status string) but reflects an actual difference in the power ceiling being enforced. Investigation steps taken 1. Preference file inspection Inspected /Library/Preferences/com.apple.PowerManagement.<UUID>.plist. Multiple UUID-keyed files exist, each corresponding to a previously used device (identified by battery serial number in the BatteryWarn key). All of them contained HighPowerMode = 0, including the file matching the current machine's serial number. The MacBook Air (M2) used earlier in this device's migration history does not support High Power Mode at all. It's suspected that HighPowerMode = 0 originated from that device and was carried forward through subsequent Migration Assistant transfers to devices that do support the feature, without ever being correctly re-evaluated. 2. Direct write test Used defaults write to directly set HighPowerMode = 1 in the relevant plist. system_profiler then reported High Power Mode: Yes, and this persisted across a reboot. However, a subsequent benchmark run showed no improvement — powermetrics Combined Power remained in the 27–30W range, and the Steel Nomad Stress Test stabilized score actually dropped slightly (~3134 average over the last 10 loops). This indicates the displayed value is decoupled from the actual power governor state. 3. File deletion / regeneration test Deleted the UUID-keyed plist (after backing it up) and let powerd regenerate it from scratch. The newly generated file still showed HighPowerMode stuck at No and unresponsive to UI changes, while LowPowerMode continued to track UI changes correctly. The same test was repeated with the non-UUID common file (com.apple.PowerManagement.plist), with no change in behavior. This rules out stale/corrupted preference data as the root cause. 4. Binary-level investigation Searched the system for files containing the string "HighPowerMode". Aside from unified logging symbol caches (uuidtext, not relevant), the following were found: /System/Library/CoreServices/powerd.bundle/powerd (Apple-signed, Signed Time: Apr 19, 2026, Platform identifier 26) /System/Library/CoreServices/powerd.bundle/migrateenergyprefs.bundle/ (com.apple.migrateenergyprefs, LSMinimumSystemVersion 26.5, built with Xcode 2630) /System/Library/SystemProfiler/SPPowerReporter.spreporter/ /System/Library/ExtensionKit/Extensions/BatterySettingsIntentsExtension.appex/ The presence of a dedicated com.apple.migrateenergyprefs component strongly suggests this is the code path responsible for carrying power preferences across device migrations. We suspect this migration logic fails to correctly initialize or re-evaluate HighPowerMode when migrating from a device that doesn't support the feature to one that does. Reproducibility Reproduced on two distinct physical machines (M4 Max and M5 Max), making a hardware fault unlikely. Reproduced after deleting and regenerating the preference files, ruling out simple cache corruption. Reproduced after a full reboot, ruling out a transient in-memory state issue alone. Impact Because High Power Mode is not actually engaged, sustained CPU/GPU performance under heavy load is capped at a lower power ceiling than intended, resulting in measurably lower benchmark scores and sustained performance compared to the documented behavior of the same hardware configuration. Questions for Apple Could the com.apple.migrateenergyprefs logic be reviewed for how it handles HighPowerMode when migrating from a device that does not support the feature (e.g., MacBook Air M2) to one that does? Is there a known issue with HighPowerMode specifically (as opposed to LowPowerMode, which behaves correctly) not being written back by powerd in response to UI changes? Are there other users with a similar multi-generation Migration Assistant history reporting the same symptom? Happy to provide a sysdiagnose or additional logs if useful.

LiveActivity using colorScheme to adapt to dark mode in iOS 26 system does not work The system keeps returning. mark, unable to switch

Hi! I have a few questions about the lifecycle and capabilities of the Crash Reporter Extension. Besides using the corpsePort to inspect the crashed process through Mach APIs, is it safe/supported/recommended for the extension to access files in a shared App Group container? Are there any caveats or exceptions we should be aware of, for example around memory-mapped files, file coordination, or filesystem access after the host app has crashed? Shall we use some particular APIs for this kind of shared resource or not? While debugging the extension, I noticed that when I trigger a crash in the app I am debugging, LLDB does not stop inside the extension (it also ends up stopping the debugging session). However, I can observe that the extension does run, because it writes data into a shared App Group directory related to the crash. Is this expected behavior? Is there a recommended way to debug the Crash Reporter Extension reliably (with lldb, or other way)? More generally, I would like to better understand the extension lifecycle: When exactly does the extension start running? How long can it live after the app crashes? Is there a time limit for operating on the corpse process? Is the extension subject to resource limits similar to other app extensions, such as memory, disk, CPU, watchdog, or jetsam constraints? If the Crash Reporter Extension itself crashes, how can we detect that? Would those crashes appear in Xcode Organizer, or is there another recommended way to observe them? Any clarification around the supported lifecycle, debugging model, and resource limits would be very useful.

I am porting a project from the now deprecated dns_util api to use the DNS Service Discovery api. With dns_util I am able to specify a DNS name server to use for resolving queries. This is useful for testing new servers or propogation when changes have been made to DNS records. Is it possible to specify the nameserver to use with DNS Service Discovery?

This post contains sensitive language. Please revise it in order to continue.Hello, We are working on digital key style application using custom communication with HCE (Host Card Emulation). We have a working solution but there is one issue - if our application is not selected as default NFC application our users may see Wallet popup when there's no active presentment intent in our application. I didn't find in documentation any information how to stop Wallet from activating. I found there's requestAutomaticPassPresentationSuppression method in PassKit, it requires special permission, however I am not sure if it can be used in this situation, as there's no information how it will impact HCE communication in our application. I'll be greatful for any advice. Regards, Valdemar

Hello, We are currently developing an application that uses the Host-based Card Emulation (HCE) entitlement to enable corporate access functionality. With this entitlement, we have successfully established HCE communication and can interact with our access control systems to unlock doors. Our question is related to improving the user experience: We would like this access functionality to work without requiring the app to be in the foreground, as this adds friction for users during entry. Specifically, we would like to know: Is it possible for our app to coexist with Apple Wallet as the default contactless app, so that: Our app handles NFC interactions for corporate access (e.g., opening doors). Apple Wallet remains the default for payments. If that coexistence is not possible, and our app is set as the default contactless app, Will the system still need to launch our app into the foreground to complete a transaction (e.g., to emulate the NFC card)? Or is there a way to trigger HCE responses in the background (e.g., using a background process or service extension)? Any guidance on how to configure the app for optimal background access behavior, while maintaining compatibility with Wallet, would be greatly appreciated. Thank you in advance.

When downloading a .zip file with a pass package, when trying to open a file it only appears as a file but is not added to the wallt.

We develop a healthcare emergency-alerting app with a native watchOS companion app. We've hit a network routing issue on watchOS that we cannot work around with any public API, and it breaks a safety-critical flow (triggering an emergency alarm from the watch). Environment watchOS 26.5 on Apple Watch SE3, paired with iPhone SE 2nd Gen on iOS 26.5 Watch app deployment target: watchOS 9.0 Plain URLSession (async/await), default configuration plus waitsForConnectivity = false, allowsExpensiveNetworkAccess = true, allowsConstrainedNetworkAccess = true HTTPS to our own backend (valid public TLS certificate, no pinning) Steps to reproduce Pair the watch with the iPhone. Both on the same known Wi-Fi network. On the iPhone: turn OFF Wi-Fi and cellular data. Keep Bluetooth ON. The watch remains connected to its known Wi-Fi network (or would be, if the system brought the radio up). Trigger any HTTPS request from the watch app (foreground). Expected Since the companion iPhone has no internet, the watch should satisfy the request over its own Wi-Fi. Actual The request is routed through the companion link (ipsec1, "companion preference: prefer" in the logs) and fails after the TLS handshake dies inside the tunnel: Error Domain=NSURLErrorDomain Code=-1200 "An SSL error has occurred and a secure connection to the server cannot be made." _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9816 (errSSLClosedNoNotify) The watch never fails over to its own Wi-Fi, no matter how many times we retry or how long we wait. The same request succeeds within seconds if the user disables Bluetooth on the iPhone (watch then joins Wi-Fi directly), or restores the iPhone's internet. What we already tried waitsForConnectivity = true doesn't help; a path exists (the tunnel), it just doesn't work. Fresh URLSession per retry, backoff retries still routed via the tunnel. Per TN3135 we understand low-level networking is not available to a normal app: we prototyped NWConnection with prohibitedInterfaceTypes = [.other], and indeed on device NWPathMonitor stays .unsatisfied even when the watch has working Wi-Fi, exactly as TN3135 describes. So Network framework is not an escape hatch for us, and we are not looking to abuse the audio-streaming/CallKit carve-outs. Questions Is the companion-preferred routing supposed to fail over to the watch's own Wi-Fi when the iPhone is reachable over Bluetooth but has no internet? If yes, on what timescale, and is there anything an app can do to help the system notice the dead path sooner? Is there ANY supported way for a foreground watchOS app to express "do not use the companion link for this request"? We found only the private _companionProxyPreference SPI, which we obviously can't ship. If the answer to both is "no", what is the recommended pattern for safety-critical requests in this state is failing fast and instructing the user to disable iPhone Bluetooth really the intended UX? Related earlier reports of the same behavior: https://developer.apple.com/forums/thread/759321 https://developer.apple.com/forums/thread/107964

I work for a company which develops as part of our product suite a System Extension implementing an Endpoint Security client. Our local developer workflow for testing and validating changes is to build locally with Developer certificates (not a legitimate/production Developer ID certificate) and deploy local builds in to a VM, where to get the System Extension to load and be accepted we need to disable SIP & AMFI. macOS 27 VM is refusing to allow me to disable SIP. Is there an alternate approach we can use for this workflow to allow macOS VMs to accept our software when signing with a (same teamID, but different certificate to the provisioningprofile) developer certificate for local validation?

We are looking to scale up our automated testing infrastructure for macOS development. Ideally, we want to create a large-scale testing farm capable of running parallel integration tests across multiple OS versions and configurations. However, we are running into a major roadblock with the Software License Agreement (SLA) limitation, which restricts the concurrent execution of macOS within virtualized environments to a maximum of two (2) instances per physical host. This restriction creates a massive bottleneck for high-end hardware. Investing in powerful machines like the Mac Studio or Mac Pro feels entirely inefficient for this use case; their massive core counts and memory capacities are effectively wasted if the host is legally throttled to just two concurrent VMs. Given this friction, we have a few questions for the community and any Apple engineers tuning in: are there any known plans, official updates, or historical precedents suggesting Apple might revise or remove this 2-VM limit for enterprise testing workflows? Any insights, policy updates, or architectural recommendations on building large-scale, compliant macOS test farms without underutilizing high-end hardware would be greatly appreciated. Thank you!

Hi, I am trying to use AAUSBAccessoryManager with mac os 27 to connect host usb device to guest vm. here is my code // // USBPassthroughManager.swift // VirtualProg import AccessoryAccess import Foundation import IOKit @available(macOS 27.0, *) class USBPassthroughManager: NSObject, ObservableObject, AAUSBAccessoryListener { static let shared = USBPassthroughManager() @Published var availableDevices: [AAUSBAccessory] = [] func startListening() async { do { let existing = try await AAUSBAccessoryManager.shared .registerListener(self, matchingCriteria: []) await MainActor.run { self.availableDevices = existing } } catch { LogManager.shared.log(vmName: AppConstants.logGeneral, type: .error, message: "USB passthrough listener failed: \(error.localizedDescription)") } } func usbAccessoryDidConnect(_ usbAccessory: AAUSBAccessory) { DispatchQueue.main.async { guard !self.availableDevices.contains(where: { $0.registryID == usbAccessory.registryID }) else { return } self.availableDevices.append(usbAccessory) print(self.displayName(for: usbAccessory)) } } The usb icon in status bar menu is displayed and i can select the the usb device to connect to my app. the usb device is connected to my app. it is shown in the status bar. but usbAccessoryDidConnect is not firing. i have the entitlement com.apple.developer.accessory-access.usb in the capabilities. i get this in the xcode console start failed ((iokit/common) not permitted) for plugin for .......... and also disconnect is also not firing. Not sure what i am doing wrong. How can i determine the name of the USB Device from AAUSBAccessory. Any help would be appreciated. Thanks