Overview

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

We need guidance regarding the Python runtime bundled with Apple Command Line Tools. Environment: macOS Tahoe 26.5.2 (25F84) Xcode 26.6 (17F113) Device type: Mac Command Line Tools Python path: /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/ Version confirmed locally with: /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/bin/python3 --version Output: Python 3.9.6 Our vulnerability-management platform, Qualys, reports this Apple Command Line Tools Python runtime as vulnerable under QID 387170, referencing CVE-2022-4303 and CVE-2023-0286. The detection points to: /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/Resources/Python.app My understanding is that this runtime is bundled and managed by Apple as part of Command Line Tools, and that manually replacing or modifying this framework is not a supported remediation path. Installing a separate standalone Python version also does not remediate the finding at this Apple-managed path. Could Apple or the community confirm the supported approach for this scenario? Specifically: Is Python 3.9.6 intentionally bundled with the current Command Line Tools release for this macOS/Xcode version? Has Apple applied security fixes or backports to this bundled Python runtime that are not reflected in the upstream Python version number? Is updating Command Line Tools/Xcode the only supported remediation method for this component? Is manually replacing or modifying the bundled Python framework unsupported? Is there any known mitigation or official guidance for vulnerability-management exceptions while waiting for an Apple-provided update? I have also filed this through Feedback Assistant: FB23893693. Any official Apple guidance or reference to existing documentation would be very helpful, as we need to provide an auditable response to our internal security and audit teams.

I’m seeing a major change in reported memory usage (and eventual termination due to memory pressure) when running a Core ML workload built with Xcode 27 on iOS/iPadOS 27. The source code, model files, and MLModelConfiguration are unchanged. Only the Xcode/SDK version used to build the app differs. On the same iPad running iPadOS 27: Xcode 26 build: model loading and prediction complete normally, with a relatively small reported application footprint. Xcode 27 build: the application footprint grows continuously as models are loaded and can exceed 5 GB. The app is eventually terminated unless models are unloaded very aggressively or the increased-memory-limit entitlement is used. I also tested an Xcode 27 build on a device running iOS 26. Its reported peak was only around 300 MB. This suggests the change requires both an Xcode 27-linked binary and the iOS 27 runtime. The workload consists of several compiled Core ML models using .cpuAndNeuralEngine. Loading models sequentially instead of concurrently does not materially change the final footprint. Releasing each MLModel after use does reduce it, so this appears to be model or Neural Engine residency being charged to the application rather than a conventional heap leak. I noticed that the iOS 27 release notes mention Neural Engine memory now being attributed to the application instead of the system. However, I’m unclear about the practical consequences of that change. If the same Neural Engine resources were already physically resident on iOS 26, I would have expected them to contribute to system memory pressure even when they were not attributed directly to the application. Instead, the older configuration runs comfortably, while the Xcode 27/iOS 27 combination approaches or crosses the application’s per-process memory limit. A few additional observations: The problem is more likely to occur after Core ML has already compiled and specialized the models. Cached model loading is much faster and the footprint grows quickly. The first uncached run can survive model preparation because specialization spaces the loads farther apart. Under Instruments, the app often does not terminate, presumably because profiling slows the workload enough to change the peak. os_proc_available_memory() decreases in line with the newly reported footprint. With the increased-memory-limit entitlement, the workload completes, but the reported footprint still reaches several gigabytes. Has anyone else observed a large Core ML memory increase specifically with an Xcode 27 build running on iOS 27? In particular, I’m trying to understand: Is this purely a change in how existing Neural Engine memory is accounted for, or does the new runtime also retain or allocate more memory? Is the new accounting used for the application’s jetsam/per-process memory limit? Is this behavior intentionally gated by the linked SDK version? That would explain why an Xcode 26 build behaves differently on the same iOS 27 device. Should applications now treat the Neural Engine residency of every loaded MLModel as part of their process-memory budget and unload models accordingly? Are there recommended APIs or Core ML loading strategies for controlling this residency? Any confirmation that others are seeing the same Xcode 27/iOS 27 behavior—or clarification of the intended memory-accounting model—would be very helpful.

Related feedback: FB16995719 This is an old one, that has not been solved in iOS 27. This is very annoying since iOS 27 brings new AI stuff to Spotlight, that can't be used because of this bug. Jennifer has acknowledged this bug during a one-on-one session last year (WWDC25) where we carefully reviewed my code. I simply would like that the app documents content to be indexed. It's simple text that I pass to textContent. ------- try await CSSearchableIndex.default().indexAppEntities([entity]) // How the indexing is called ------- @available(iOS 18, *) /// The IndexedEntity struct DocumentEntity: IndexedEntity, Identifiable { static var typeDisplayRepresentation: TypeDisplayRepresentation { TypeDisplayRepresentation(name: LocalizedStringResource("INTENT_DOCUMENT_DISPLAY_REP")) } static let defaultQuery = DocumentQuery() // A unique identifier for each document let id: NSManagedObjectID let title: String? let thumbnailData: Data? // The document's text to be indexed let textContent: String? let pageCount: Int // A display representation for UI purposes. var displayRepresentation: DisplayRepresentation { DisplayRepresentation( title: "\(title ?? "")", image: thumbnailData == nil ? nil : .init(data: thumbnailData!) // INDEXED successfully through the use of @available(iOS 18, *) struct DocumentEntity: IndexedEntity, Identifiable { static var typeDisplayRepresentation: TypeDisplayRepresentation { TypeDisplayRepresentation(name: LocalizedStringResource("INTENT_DOCUMENT_DISPLAY_REP")) } static let defaultQuery = DocumentQuery() // A unique identifier for each document (for example, your NSManagedObject's objectID). let id: NSManagedObjectID let title: String? let thumbnailData: Data? // The OCR text to be indexed let textContent: String? let pageCount: Int // A display representation for UI purposes. var displayRepresentation: DisplayRepresentation { DisplayRepresentation( title: "\(title ?? "")", image: thumbnailData == nil ? nil : .init(data: thumbnailData!) ) } } ) } } @available(iOS 18, *) extension DocumentEntity { // The attributeSet for Spotlight var attributeSet: CSSearchableItemAttributeSet { let attributeSet = defaultAttributeSet attributeSet.title = title attributeSet.displayName = title // THIS ONE IS INDEXED attributeSet.contentType = UTType.plainText.identifier attributeSet.textContent = textContent // THIS ONE IS **NOT** INDEXED attributeSet.pageCount = NSNumber(integerLiteral: pageCount) // THIS ONE IS INDEXED attributeSet.thumbnailData = thumbnailData attributeSet.creator = Constants.APP_NAME return attributeSet } } Related: https://discussions.apple.com/thread/256061571

Hi All - I'm a bit confused about setting environment variables in Mac Terminal when testing archive builds. In Terminal, if I do something like export DYLD_PRINT_LIBRARIES=1, it works great for Debug builds. When I open my Debug binary, I can see all the dylibs and Frameworks getting loaded. However, my Archive build doesn't show me anything when I try opening it from Terminal. I did some Googling and I guess SIP may be doing something to prevent environment vars from affecting Archive builds. This made sense to me until I tried creating a simple Test app. If I Archive my Test app and open the binary in Terminal, I see all the dylibs and frameworks. So why would an Archive build for a simple test project work with DYLD_PRINT_LIBRARIES, but my production app's Archive build won't? Related question: I've run into a situation where I may have to set LSEnvironment in my app's Info.plist to work around a problem in 10.15 Catalina and 11 Big Sur. Setting LSEnvironment works great in my Debug and Release builds. But just like using setting DYLD_PRINT_LIBRARIES in Terminal, my Archive build ignores the LSEnvironment settings. So... is there a way to create an Archive build that doesn't ignore Environment Variables in Terminal, or LSEnviroment in Info.plist? Hoping that there's a simple Build Setting that I can enable or disable in my Target to do this. Thanks.

BloomComponent (RealityKit 27) lags behind the geometry that produces it while the camera moves. The halo trails the emissive geometry by roughly one to three frames (eyeballed) and snaps back once the camera stops. Video attached — it's obvious at normal playback speed. visionOS renders the identical scene correctly. Only iOS and macOS / Mac Catalyst lag, which points at the non-visionOS compositing path rather than the effect itself. Filed as FB23960052. This should be fixed before 27 ships — bloom is unusable for anything with a moving camera in its current state on those platforms. Ruled out: Scope. Identical with BloomComponent(scope: .hierarchical) and .unbounded. .unbounded computes no per-entity screen-space bounds, so stale bounds are not the cause. Input handling. The camera is RealityKit's own .realityViewCameraControls(.orbit) — no gesture code of mine involved. Per-frame component writes. BloomOptionsComponent is set once and untouched during the drag. Geometry and camera transform. Both track perfectly; only the glow lags. Reproducer is ~130 lines, no assets — five emissive spheres inside a large inward-facing dark sphere: var material = PhysicallyBasedMaterial() material.baseColor = .init(tint: .black) material.emissiveColor = .init(color: .cyan) material.emissiveIntensity = 4 // ... root.components.set(BloomComponent(scope: .unbounded)) var options = BloomOptionsComponent() options.strength = 1 options.threshold = 1 options.blurRadius = 1 root.components.set(options) shown in: RealityView { content in content.camera = .virtual content.add(root) } .realityViewCameraControls(.orbit) Xcode 27.0 beta 4, iOS 27.0 SDK, Apple Silicon. Affected: iOS 27, macOS 27 / Mac Catalyst 27. Not affected: visionOS 27 (immersive space). Full project and screen recording attached to my radar.

I’m using MFMailComposeViewController to send emails from my app. Since updating to iPadOS 26.4, there is no way to cancel the mail composer because the “X” button in the top-left corner has disappeared. On iPhone with iOS 26.4, everything still seems to work as expected. Is this a known issue, or am I missing something? Has anyone else experienced this, or found a workaround?

This happens with my own code as well as with the Apple example code here: Supporting Drag and Drop Through File Promises When dragging a file promise, the above example code will fail if the destination is in /tmp. It will print out the following message to the console: An error occurred while attempting to get a unique promise file URL. Error: Did not receive a valid URL. It doesn't seem to fail if you create a directory inside /tmp and drop into that. But dropping in /tmp fails 100% of the time. And it fails for MacOS Versions from Sequoia all the way up to the most recent Golden Gate beta. Using /tmp as a destination should most certainly be allowed, but if for some reason it isn't, is there any way in my own code to detect the drop destination and perhaps warn the user that they need to drop somewhere else? To reproduce this error, use the following steps: Download the Apple example code from the link above Open the project in Xcode, build it, and run it Drag any image into the example app's main window Open a Finder window and navigate to /tmp Drag the image from the example app into the /tmp directory in the Finder window. You will see the above error in the Xcode console and the drop will fail.

I want to know the right way/API/usage to use NWConnectionGroup to send both datagram and non-datagram stream. I am currently working on an P2P video streaming app. I want to leverage NWConnectionGroup over QUIC to handle both message channel (traditionally handled by a TCP connection) and media channel (traditionally handled by sth. over UDP) to transmit SRT packets back and forth. I created a NWConnectionGroup and it worked fine on non-datagram parts. The problems are with datagram part. I tried extracting a connection with datagram = true either from the group or from message, doesn't and in some cases it breaks other non-datagram connections. I currently send datagram directly using the NWConnectionGroup.send(content:completion). It kinda works but I keep seeing it canceled a lot of messages, which breaks SRT shortly after start. The warnings belong flooded my console. (Seems like want me to create a connection to transmit datagram, how?) nw_connection_create_with_connection [C1600] Original connection not yet connected nw_connection_group_create_connection_for_endpoint_and_parameters [G1] failed to create connection with parameters quic, local: fe80::439:68b4:6ec2:694%en0.60517, definite, attribution: developer, server I must use it in wrong way. What should I do to fix it?

I am developing a large iOS application with an extensive UI test suite (hundreds of UI test scenarios). After upgrading our CI runners to macOS Tahoe 26, we started observing an intermittent issue where an iOS Simulator may operate normally for many successful application launches before unexpectedly entering a persistent degraded state. Once this occurs, every subsequent application launch crashes inside dyld before reaching our application’s main(). The degraded state persists until the simulator device is reset This causes UI tests to hang and eventually timeout. Business impact CI/CD jobs frequently timeout (90+ minutes per failed run) Significant loss of CI capacity Difficult to maintain reliable quality gates At our scale, this has become a serious issue affecting release confidence and overall engineering productivity. Technical details Crash report MyProject-2026-07-13-125307.ips — a crash report from a CI Demo project dyld_crash_demo — a minimal reproducible project demonstrating the relevant dyld execution path. The project intentionally returns errors from system functions along the shared cache initialization path to demonstrate that dyld continues execution until DyldSharedCache::getUUID(), where it subsequently crashes. Simply open the project and run it in iOS Simulator 26.2. Environment Component Version macOS Tahoe 26.x Xcode 26.2, 26.5 iOS Simulator 26.2, 26.5, 26.6 Architecture Apple Silicon dyld 1378 dyld_sim 1335 What we have ruled out multiple Xcode versions multiple macOS 26.x releases multiple iOS Simulator runtimes multiple simulator devices UI tests with parallel execution disabled deleting the simulator dyld shared cache recreating simulator devices application-specific issues (the crash happens before main()) The issue is still reproducible. Investigation The earliest observable failure sequence is consistently: shared_region_check_np() → "Cannot allocate memory" (ENOMEM) Shared cache mmap(0x180000000, ...) → EACCES The shared cache region remains unmapped DyldSharedCache::getUUID() reads 0x180000058 EXC_BAD_ACCESS (Translation fault) The crash occurs before any application code executes. The first faulting instruction belongs to DyldSharedCache::getUUID(), while the shared-cache region is still unmapped. Published dyld source analysis Relevant execution path: loadDyldCache() ↓ mapSplitCachePrivate() ↓ preflightCacheFile() Based on the published sources of dyld-1378, this appears to be the execution path leading to the observed failure. After the loadDyldCache() function failed to load the cache, dyld continued execution anyway and moved on to calling the DyldSharedCache::getUUID() function, where it subsequently failed. Additional observations Once the simulator enters the degraded state: simctl spawn succeeds. simctl launch crashes inside dyld before reaching main(). During our experiments, both processes were created by the same launchd_sim instance Before dyld::_dyld_start, both processes expose the same virtual address layout, including an unmapped shared-cache region (0x180000000–0x300000000). Current workaround As a temporary mitigation, we launch the application with DYLD_SHARED_REGION=avoid In our environment, this completely avoids the launch failures. However, this mode appears to be undocumented and intended primarily for debugging. We are concerned that it may change or stop working in future macOS or Xcode releases, so we are reluctant to depend on it in our production CI infrastructure. Questions 1. dyld Is it expected for dyld to continue dereferencing the shared-cache header after both the shared-region initialization and the shared-cache mapping have already failed? Execution appears to continue into: loadInfo.loadAddress->getUUID(cacheUuid) which results in an access to an unmapped address. The attached demo project reproduces this behavior by simulating failures from the shared-cache initialization path. Is there an expected fallback behavior for this situation or is continuing into DyldSharedCache::getUUID() the intended behavior ? 2. Simulator state Why does a simulator that initially launches applications successfully eventually enter a state where every subsequent launch fails while the shared cache can no longer be mapper? The earliest related system log we have found is: vm_shared_region_start_address() returned 0x1 Is this a known CoreSimulator or macOS Tahoe issue? If so, is there a supported workaround or recommended long-term solution besides DYLD_SHARED_REGION=avoid? Any guidance would be greatly appreciated.

I am planning an iOS security and content-blocking app for unmanaged consumer iPhones. The app would not provide a traditional VPN service. It would not offer: Remote VPN servers Geographic location switching Access to a private corporate network IP-address masking as a service Anonymous browsing Instead, the app would allow the user to: View destination domains contacted by the device Classify destinations such as trackers, advertising, analytics, or potentially malicious domains Manually block selected domains Keep connection history and filtering decisions on the device I understand that NEFilterDataProvider and NEFilterControlProvider are the APIs intended for network content filtering. However, according to TN3134, these providers are not generally deployable for an unmanaged adult consumer iPhone. I also understand that TN3120 says NEPacketTunnelProvider should not be used as a general-purpose local content filter. This appears to leave a gap for an unmanaged consumer security app whose core feature is user-controlled, system-wide domain blocking. I am considering whether NETunnelProviderManager with an NEPacketTunnelProvider could support the feature, but I do not want to use the packet-tunnel API outside its supported purpose. My questions are: Is there currently a supported Network Extension architecture for system-wide, user-controlled domain blocking on an unmanaged adult consumer iPhone? Can an app with this purpose use NEPacketTunnelProvider, or would that necessarily be considered the unsupported general-purpose filtering use described in TN3120? If such an architecture is supported, could an app with this purpose be treated as an approved security or content-blocking provider under Guideline 5.4 rather than as an app offering a traditional VPN service? App Review Guideline 5.4 states that apps offering VPN services must be submitted by developers enrolled as organizations. It also states that parental-control, content-blocking, and security apps from approved providers may use NEVPNManager. For an app that does not provide a remote VPN service but uses Apple’s VPN configuration infrastructure only for local security and user-controlled blocking, must the developer still enroll as an organization, or may an individual Apple Developer Program member submit it?

Hello Apple Developer Technical Support / Engineering Team, We are currently developing an iOS application that utilizes Wi-Fi Aware (NAN) for peer-to-peer data transfer between iOS devices. We are in the process of optimizing our data transmission performance and are evaluating the different data path configurations available. Specifically, we would like to understand the performance characteristics and throughput differences between the Real-Time mode and the Bulk mode in the iOS Wi-Fi Aware implementation. Could you please provide clarification on the following points? Maximum Throughput: Between Real-Time mode and Bulk mode, which one is designed to provide a higher maximum throughput for continuous data transfer?

Hi, I'm very interested in bringing TrustInsights to our mobile banking app but I'm unable to get it working in Xcode 27 beta 1 and 2. When adding an import I get "Unable to resolve module dependency: 'TrustInsights'" and I don't see TrustInsights in the list of Capabilities to add in the settings of the target. best regards Stefan

We're preparing our SDK and host applications for iOS 27 and would like to understand the mandatory requirements for supporting the new Liquid Glass design. Beyond building with the iOS 27 SDK, are there any required implementation or migration steps (UIKit or SwiftUI) that developers must adopt to ensure full compatibility? Are there any behaviors or APIs that require explicit changes, or does the system automatically handle Liquid Glass for standard controls? We're specifically interested in the minimum required changes for compliance and compatibility, rather than optional design enhancements. Thanks in advance for any guidance.

The notary service requires that all Mach-O images be linked against the macOS 10.9 SDK or later. This isn’t an arbitrary limitation. The hardened runtime, another notarisation requirement, relies on code signing features that were introduced along with macOS 10.9 and it uses the SDK version to check for their presence. Specifically, it checks the SDK version using the sdk field in the LC_BUILD_VERSION Mach-O load command (or the older LC_VERSION_MIN_MACOSX command). There are three common symptoms of this problem: When notarising your product, the notary service rejects a Mach-O image with the error The binary uses an SDK older than the 10.9 SDK. When loading a dynamic library, the system fails with the error mapped file has no cdhash, completely unsigned?. When displaying the code signature of a library, codesign prints this warning: % codesign -d vvv /path/to/your.dylib … Library validation warning=OS X SDK version before 10.9 does not support Library Validation … If you see any of these errors, read on… The best way to avoid this problem is to rebuild your code with modern tools. However, in some cases that’s not possible. Imagine if your app relies on the closed source libDodo.dylib library. That library’s vendor went out of business 10 years ago, and so the library hasn’t been updated since then. Indeed, the library was linked against the macOS 10.6 SDK. What can you do? The first thing to do is come up with a medium-term plan for breaking your dependency on libDodo.dylib. Relying on an unmaintained library is not something that’s sustainable in the long term. The history of the Mac is one of architecture transitions — 68K to PowerPC to Intel, 32- to 64-bit, and so on — and this unmaintained library will make it much harder to deal with the next transition. IMPORTANT I wrote the above prior to the announcement of the latest Apple architecture transition, Apple silicon. When you update your product to a universal binary, you might as well fix this problem on the Intel side as well. Do not delay that any further: While Apple silicon Macs are currently able to run Intel code using Rosetta 2, that support is going away soon. About the Rosetta Translation Environment says: Rosetta … will be available through macOS 27 … Beyond this timeframe, we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles But what about the short term? Well, I’m glad you asked! Xcode includes a command-line tool, vtool, that can change the LC_BUILD_VERSION and LC_VERSION_MIN_MACOSX commands in a Mach-O. You can use this to change the sdk field of these commands, and thus make your Mach-O image ‘compatible’ with notarisation and the hardened runtime. Before doing this, consider these caveats: Any given Mach-O image has only a limited amount of space for load commands. When you use vtool to set or modify the SDK version, the Mach-O could run out of load command space. The tool will fail cleanly in this case but, if it that happens, this technique simply won’t work. Changing a Mach-O image’s load commands will break the seal on its code signature. If the image is signed, remove the signature before doing that. To do this run codesign with the --remove-signature argument. You must then re-sign the library as part of your normal development and distribution process. Remember that a Mach-O image might contain multiple architectures. All of the tools discussed here have an option to work with a specific architecture (usually -arch or --architecture). Keep in mind, however, that macOS 10.7 and later do not run on 32-bit Macs, so if your deployment target is 10.7 or later then it’s safe to drop any 32-bit code. If you’re dealing with a Mach-O image that includes 32-bit Intel code, or indeed PowerPC code, make your life simpler by removing it from the image. Use lipo for this; see its man page for details. It’s possible that changing a Mach-O image’s SDK version could break something. Indeed, many system components use the main executable’s SDK version as part of their backwards compatibility story. If you change a main executable’s SDK version, you might run into hard-to-debug compatibility problems. Test such a change extensively. It’s also possible, but much less likely, that changing the SDK version of a non-main executable Mach-O image might break something. Again, this is something you should test extensively. This list of caveats should make it clear that this is a technique of last resort. I strongly recommend that you build your code with modern tools, and work with your vendors to ensure that they do the same. Only use this technique as part of a short-term compatibility measure while you implement a proper solution in the medium term. For more details on vtool, read its man page. Also familiarise yourself with otool, and specifically the -l option which dumps a Mach-O image’s load commands. Read its man page for details. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Revision history: 2026-07-24 — Updated to reference Apple’s publicly announced plans for Rosetta 2. 2025-04-03 — Added a discussion of common symptoms. Made other minor editorial changes. 2022-05-09 — Updated with a note about Apple silicon. 2020-09-11 — First posted.

This issue is happening from some time only on MacOS Big Sur (11.0 and 11.6 specifically) machines in our environment. Other higher OS versions or even lower versions like Mojave do not have this issue. I can confirm that earlier software version was working fine here. Could this be an issue with any recent changes in the code signature process? In the codes signature details below, I'm concerned about VersionSDK being 0 and RuntimeVersion property not being present, when comparing to working setups. Also, there is a warning about library validation. Could that be causing an issue? Kindly requesting for a resolution here. Crash report: Library not loaded: @executable_path/../<Masked>.dylib Referenced from: /opt/../<Masked> Reason: no suitable image found. Did find: /opt/..<Masked>.dylib: code signing blocked mmap() of '/opt/..<Masked>.dylib' Code signature details: codesign -dv --verbose=4 : Executable=/opt/...dylib Identifier=.dylib Format=Mach-O thin (arm64) CodeDirectory v=20200 size=11314 flags=0x10000(runtime) hashes=349+2 location=embedded Library validation warning=OS X SDK version before 10.9 does not support Library Validation VersionPlatform=1 VersionMin=721920 **VersionSDK=0 ** Hash type=sha256 size=32 CandidateCDHash CandidateCDHashFull Hash choices=sha256 CMSDigest= CMSDigestType=2 Page size=4096 CDHash= Signature size=8988 Authority=Developer ID Application: Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=26-Jun-2026 at 10:48:54 PM Info.plist=not bound TeamIdentifier= Sealed Resources=none Internal requirements count=1 size=180

I have a personal iOS project that I also compile for macOS with Catalyst. When built with Xcode 26.x, everything is linked correctly. When built with Xcode 27 betas, the following runtime error occurs: Termination Reason: Namespace DYLD, Code 4, Symbol missing Symbol not found: _UIFontTextStyleCallout Referenced from: <046ED276-F81A-31B4-82FF-6DC82E9041BC> /Applications/Photo Library.app/Contents/MacOS/Photo Library Expected in: <298B64F6-9BC0-3BFB-BE72-EBDC2BE0FF19> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit Any assistance? Thanks

I am seeing a weird crash from Xcode 27 Beta 3 when building a variadic type DynamicProperty that also needs SwiftUI.State. This does not crash from Xcode 26. Here is a repro: import SwiftUI struct Repeater<each Input>: DynamicProperty { @State private var storage = Storage() private var input: (repeat each Input) init(_ input: repeat each Input) { self.input = (repeat each input) } } extension Repeater { final class Storage { } } @main struct CrashDemoApp: App { private var repeater = Repeater(1) var body: some Scene { WindowGroup { EmptyView() } } } Here is the crash: Thread 1 Queue : com.apple.main-thread (serial) #0 0x000000019a93aec0 in swift::TargetMetadata<swift::InProcess>::isCanonicalStaticallySpecializedGenericMetadata () #1 0x000000019a946b38 in performOnMetadataCache<swift::MetadataResponse, swift_checkMetadataState::CheckStateCallbacks> () #2 0x000000019a8c85f0 in swift_checkMetadataState () #3 0x00000001004a2c78 in type metadata completion function for Repeater () #4 0x000000019a94cfe4 in swift::GenericCacheEntry::tryInitialize () #5 0x000000019a94c870 in swift::MetadataCacheEntryBase<swift::GenericCacheEntry, void const*>::doInitialization () #6 0x000000019a94f820 in swift::LockingConcurrentMap<swift::GenericCacheEntry, swift::LockingConcurrentMapStorage<swift::GenericCacheEntry, (unsigned short)14>>::getOrInsert<swift::MetadataCacheKey, swift::MetadataRequest&, swift::TargetTypeContextDescriptor<swift::InProcess> const*&, void const* const*&> () #7 0x000000019a93c714 in _swift_getGenericMetadata () #8 0x00000001004a4190 in __swift_instantiateGenericMetadata () #9 0x00000001004a2a5c in type metadata accessor for Repeater () #10 0x00000001004a5094 in type metadata accessor for Repeater<Pack{Int}> () #11 0x00000001004a4fcc in type metadata completion function for CrashDemoApp () #12 0x000000019a9543bc in swift::MetadataCacheEntryBase<(anonymous namespace)::SingletonMetadataCacheEntry, int>::doInitialization () #13 0x000000019a8d2ae0 in swift_getSingletonMetadata () #14 0x00000001004a479c in type metadata accessor for CrashDemoApp () #15 0x00000001004a473c in static CrashDemoApp.$main() () #16 0x00000001004a4a34 in main () #17 0x0000000186e47e00 in start () Here is a repo to demo: https://github.com/vanvoorden/2026-07-17 Please let me know if you have any ideas about that. Thanks!

Hi, We are integrating HKQuantityTypeIdentifierTimeInDaylight into a research application and have a few questions about how developers should interpret the data returned by HealthKit. Specifically: Should TimeInDaylight samples be treated as having a fixed minimum temporal granularity (for example, approximately 5-minute intervals), or is the sample duration implementation-dependent and subject to change? Is there any expected latency between a daylight exposure event and the corresponding TimeInDaylight sample becoming available through HealthKit? For example, are samples intended to appear shortly after exposure, or only after periodic processing and synchronization? In the Health app, each Time in Daylight sample displays a Maximum Light Intensity (lux). Is this value available through the public HealthKit API (e.g., metadata), or is it only used internally by the Health app? More generally, should developers consider TimeInDaylight to be a high-level derived metric rather than expecting a direct correspondence with underlying ambient light sensor observations? Thank you.

Hi everyone, I’m having an issue with my Apple Store Connect banking information. After updating my banking details, Apple showed this message: “Our banking updates are processing, and you should see the changes in 24 hours.” However, it has now been 12 days and the banking information is still showing as pending. I also contacted Apple Store Connect Support, but I have not received any clear reply or update yet. Has anyone experienced the same issue where banking information stayed pending much longer than 24 hours? If you had this issue before, how did you resolve it? Did you need to resubmit the bank information, contact a specific Apple support team, or simply wait longer? Any advice would be greatly appreciated. Thank you.