General: Forums subtopic: App & System Services > Networking TN3151 Choosing the right networking API Networking Overview document — Despite the fact that this is in the archive, this is still really useful. TLS for App Developers forums post Choosing a Network Debugging Tool documentation WWDC 2019 Session 712 Advances in Networking, Part 1 — This explains the concept of constrained networking, which is Apple’s preferred solution to questions like How do I check whether I’m on Wi-Fi? TN3135 Low-level networking on watchOS TN3179 Understanding local network privacy Adapt to changing network conditions tech talk TCP and UDP ports used by Apple software products support article Understanding Also-Ran Connections forums post Extra-ordinary Networking forums post Foundation networking: Forums tags: Foundation, CFNetwork URL Loading System documentation — NSURLSession, or URLSession in Swift, is the recommended API for HTTP[S] on Apple platforms. Moving to Fewer, Larger Transfers forums post Testing Background Session Code forums post Network framework: Forums tag: Network Network framework documentation — Network framework is the recommended API for TCP, UDP, and QUIC on Apple platforms. Building a custom peer-to-peer protocol sample code (aka TicTacToe) Implementing netcat with Network Framework sample code (aka nwcat) Configuring a Wi-Fi accessory to join a network sample code Moving from Multipeer Connectivity to Network Framework forums post NWEndpoint History and Advice forums post Wi-Fi (general): How to modernize your captive network developer news post Wi-Fi Fundamentals forums post Filing a Wi-Fi Bug Report forums post Working with a Wi-Fi Accessory forums post — This is part of the Extra-ordinary Networking series. Wi-Fi (iOS): TN3111 iOS Wi-Fi API overview technote Wi-Fi Aware framework documentation WirelessInsights framework documentation iOS Network Signal Strength forums post Network Extension Resources Wi-Fi on macOS: Forums tag: Core WLAN Core WLAN framework documentation Secure networking: Forums tags: Security Apple Platform Security support document Preventing Insecure Network Connections documentation — This is all about App Transport Security (ATS). WWDC 2017 Session 701 Your Apps and Evolving Network Security Standards [1] — This is generally interesting, but the section starting at 17:40 is, AFAIK, the best information from Apple about how certificate revocation works on modern systems. WWDC 2025 Session 314 Get ahead with quantum-secure cryptography Available trusted root certificates for Apple operating systems support article Requirements for trusted certificates in iOS 13 and macOS 10.15 support article About upcoming limits on trusted certificates support article Apple’s Certificate Transparency policy support article What’s new for enterprise in iOS 18 support article — This discusses new key usage requirements. Prepare your network environment for stricter security requirements support article — This is primarily of interest to folks developing management software, for example, an MDM server. Technote 2232 HTTPS Server Trust Evaluation Technote 2326 Creating Certificates for TLS Testing QA1948 HTTPS and Test Servers Miscellaneous: More network-related forums tags: 5G, QUIC, Bonjour On FTP forums post Using the Multicast Networking Additional Capability forums post Investigating Network Latency Problems forums post Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] This video is no longer available from Apple, but the URL should help you locate other sources of this info.

Mac Phone（简称M Phone）完整产品方案+全套宣传文案 一、产品核心定位（苹果救泄密舆论+开辟全新赛道双重奇招） 推出背景 iPhone 18全套硬件图纸、尺寸、芯片A20全部泄露，秋季发布会毫无新鲜感，常规迭代讲稿无法制造热度。苹果跳出十几年iPhone固有框架，推出独立全新产品线Mac Phone，仅在9月发布会放出概念短片预告，2027年初单独线上发布，不冲击iPhone18全年销量。 硬件核心配置（精简优化M架构，非粗暴阉割） 屏幕：直板超大尺寸，尺寸全面大于iPhone 18 Pro Max，无折叠折痕，满足大屏追剧、游戏、办公需求； 芯片：基于Mac M系列架构重新优化定制手机专用芯片，全新命名，算力、AI性能全方位碾压A20；机身更大，散热、电池空间充足，能稳定释放高性能； 外观：跳脱现有iPhone设计，无传统灵动岛，全新一体化机身，全套研发资料仅留存苹果总部，全程无泄密； 定位分层 • iPhone数字系列（18/19）：A系列芯片，均衡轻薄，面向大众日常用户； • Mac Phone：M同源高性能芯片+超大直板大屏，面向剪辑创作者、手游玩家、移动办公人群。 命名巧思 官方名：Mac Phone，日常简写M Phone； 官方含义：Mac桌面级算力下放手机；iPhone=我的日常手机，M Phone=面向创作人群的高性能设备； 民间自发谐音梗：读音近似“麦克风”，自带趣味传播话题，免费带动全网热度。 战略价值 短期：转移全网讨论焦点，彻底掩盖iPhone18泄密的尴尬，发布会直接翻盘； 长期：开辟苹果手机全新高性能赛道，打通Mac与手机生态，弥补超大屏旗舰空白，挽回因屏幕、性能流失到安卓的用户。 二、品牌核心宣传主题 解放你的设备包袱，让Mac的力量，握于掌心 三、分场景完整文案 2026年9月发布会收尾官方口播文案 过去多年，我们依靠A系列芯片打造日常iPhone，服务每一个普通人。 但创作者、游戏爱好者、常年移动办公的人，始终被有限性能、偏小屏幕束缚，出门总要背负手机、平板、笔记本多台设备。 今天，我们打破沿用多年的手机固有框架，带来全新独立产品线——Mac Phone。 它拥有比Pro Max更大的纯直板大屏，不做折叠妥协；搭载基于M系列架构深度重构的专属芯片，不是简单缩减核心，而是专为手持设备平衡能效与爆发算力，性能全面超越A20。 不必再随身携带厚重电脑，一台手机，就能承载完整桌面级生产力，解放所有设备包袱。 Mac Phone，将于2027年初正式与大家见面。 品牌主海报短句（极简苹果人文风） 卸下电脑包袱，掌心拥有Mac之力 Mac Phone，更大屏幕，更强性能 一台设备，兼顾生活与创作 不妥协的大屏，不缩水的算力 线上/线下广告短片旁白（温柔人文叙事） 我们总被设备困住脚步。 沉重的笔记本，局促的手机屏幕，有限的运算能力，都是随身携带的负担。 现在，Mac Phone到来。 源自Mac M架构的强劲核心，一块无妥协超大直板大屏。 不用背负多台设备，不用牺牲性能，不用忍受折叠瑕疵。 把电脑的全部力量，装进你的掌心。 Mac Phone，卸下所有包袱。 短视频传播短标语（适合数码平台、社交平台） Mac芯片下放入手机，这才是真正的性能旗舰 比Pro Max更大的直板大屏，Mac Phone来了 一机替代手机、平板、轻薄本 民间趣味玩梗：这款“麦克风”手机，性能碾压所有iPhone 四、整套方案核心优势总结 公关救场：全新无泄密底牌，话题热度远超折叠屏，完美化解iPhone18泄密负面； 技术创新：M架构移动端专属芯片，区别传统A系列，形成行业差异化； 市场补缺：超大直板大屏，抓住大屏需求用户，挽回流失客户； 商业低风险：仅远期预告，不分流今年iPhone销量，预留充足周期打磨成品； 长期布局：独立M Phone赛道，完善苹果手机产品矩阵，打通跨设备生态。

d by an agency, instrumentality or department of the federal government of the United States, then this Agreement shall be governed in accordance with the laws of the United States of America, and in the absence of applicable federal law, the laws of the State of California will apply. Further, and notwithstanding anything to the contrary in this Agreement, all claims, demands, complaints and disputes will be subject to the Contract Disputes Act (41 U.S.C. §§601-613), the Tucker Act (28 U.S.C. §01346(a) and §31491), or the Federal Tort Claims Act (28 U.S.C. §§91346(b), 2401-2402, 2671-2672, 2674-2680), as applicable, or other applicable governing authority. For the avoidance of doubt, if You are an agency, instrumentality, or department of the federal, state or local government of the U.S. or a U.S. public and accredited educational institution, then Your indemnification obligations are only applicable to the extent they would not cause You to violate any applicable law (e.g., the Anti-Deficiency Act), and You have any legally required authorization or authorizing statute; If You are employed by a U.S. public and accredited educational institution or an agency, instrumentality, or department of a state or local government within the United States, then (a) this Agreement will be governed and construed in accordance with the laws of the state (within the U.S.) in which Your entity is domiciled, except that body of state law concerning conflicts of law; and (b) any litigation or other dispute resolution between You and Apple arising out of or rela

Hi There, My app is a legacy project built with Objective C. The host app shared data with the service extension by using NSUserDefaults *userDefault = [[NSUserDefaults alloc] initWithSuiteName:@"group.com.myapp.project"]; and it worked until a customer recently reported a bug (iOS 18.6). After debugging, I found that data sharing from the host app to the service extension was not working correctly. The host app updated a field's value, but the service still used the old or stale value, causing the issue. HostApp saved info 2026-06-01 13:44:07.020 [INFO] (VMP)(ThreadID: 0x10a85c000): "Saved Vomo information { "EXT_AP_IP" = 1c28af0f9d73; "EXT_PING_DND" = 0; "EXT_PING_USER_NAME" = aaa08AA541F8; "EXT_SERIAL_ACK_TIME" = "2026-06-01 20:44:07 +0000"; "EXT_SERIAL_NO" = 689; "EXT_SERVER_NAME" = "10.xxx.xxx.182"; "EXT_VOICE_LOGIN" = 1; }" Service extension read value: 2026-06-01 13:46:09.678 [INFO] (VMP) - (EXTENSION)(ThreadID: 0x1050a41d0): "start Vomo with Server: [10.xxx.xxx.79] and userName [aaa08AA541F8]" I can see the value shared from host app is: 10.xxx.xxx.182, but service extension still took the stale value 10.xxx.xxx.79 First I thought it is synchronized issue, however, apple deprecated those API, CFPreferencesAppSynchronize((__bridge CFStringRef)@"group.com.myexample.project"); How to ensure the shared value successfully delivered to service extension? Thanks.

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

With the 27 OSes using UserDefaults.standard.integer(forKey: ) can cause a crash with EXC_BAD_ACCESS (code=1, address=0x0) It has been seen on a Multiplatform app, up to now tested on iOS/iPadOS and visionOS 27 Beta 1. In our code we use UserDefaults.standard.integer(forKey: ) from a singleton called during the SwiftUI app init(), and we don't know yet if this is the only moment there is a crash as we can't go farther. The API should return 0 if it can't get a value. There is no reason the app should crash if the API conforms to its contract. Running the same code from Xcode on iOS 26 runs it without issue. FeedBack FB23310748

NSJSONSerialization silently drops U+FEFF from JSON string content — keys merge, characters vanish TL;DR: NSJSONSerialization deletes U+FEFF (ZERO WIDTH NO-BREAK SPACE / BOM) from anywhere inside parsed JSON strings — not just a leading document BOM, and even when written as the \uFEFF escape (it's removed after unescaping). Distinct strings/keys silently collapse onto their U+FEFF-less twins. If you're seeing JSON keys mysteriously merge or a character disappear from a parsed value, this is probably why. It is not your code. Workaround and exhaustive scope below. The workaround Two options, depending on how attached you are to Foundation: A. Stay on NSJSONSerialization — swap U+FEFF for a private-use sentinel before parsing, restore after. You must handle both the raw bytes and the \uFEFF escape (the escape bites too, since deletion happens post-unescape): // 1. Pick a private-use scalar you've verified is absent from the source text. // 2. Replace every in-content U+FEFF (raw char AND \uFEFF escape) with it. // 3. Parse. NSJSONSerialization preserves the sentinel. // 4. Recursively restore the sentinel -> U+FEFF in the parsed tree. static id RestoreSentinel(id o, NSString *s, NSString *bom) { if ([o isKindOfClass:NSString.class]) return [o rangeOfString:s].location == NSNotFound ? o : [o stringByReplacingOccurrencesOfString:s withString:bom]; if ([o isKindOfClass:NSArray.class]) { NSMutableArray *a = [NSMutableArray arrayWithCapacity:[o count]]; for (id e in o) [a addObject:RestoreSentinel(e, s, bom)]; return a; } if ([o isKindOfClass:NSDictionary.class]) { NSMutableDictionary *d = [NSMutableDictionary dictionary]; [o enumerateKeysAndObjectsUsingBlock:^(id k, id v, BOOL *stop) { d[RestoreSentinel(k, s, bom)] = RestoreSentinel(v, s, bom); }]; return d; } return o; } Swap the escape form with a backslash-parity-aware regex so \uFEFF (escaped backslash + literal "uFEFF") is left intact: (?<!\\)((?:\\\\)*)\\u[Ff][Ee][Ff][Ff] -> $1<sentinel> B. Don't use Foundation for this file — a spec-compliant C parser like ++yyjson++ preserves U+FEFF and is faster on large files. (This is the route swift-transformers took for tokenizer.json.) Minimal repro // Object keys collapse: NSData *d1 = [@"{\"\\uFEFF#\":1,\"#\":2}" dataUsingEncoding:NSUTF8StringEncoding]; id o1 = [NSJSONSerialization JSONObjectWithData:d1 options:0 error:nil]; // EXPECTED: 2 keys ("\uFEFF#" and "#"); ACTUAL: 1 key ("#") — \uFEFF stripped, keys merged // String content lost: NSData *d2 = [@"[\"\\uFEFF\"]" dataUsingEncoding:NSUTF8StringEncoding]; id o2 = [NSJSONSerialization JSONObjectWithData:d2 options:0 error:nil]; // EXPECTED: ["\uFEFF"] (one code point); ACTUAL: [""] (empty string) Same outcome whether U+FEFF arrives as raw EF BB BF bytes or the \uFEFF escape. Why this is a bug, not a quirk Per RFC 8259 §7, a JSON string is a sequence of Unicode code points; U+FEFF is ordinary content and doesn't require escaping. Tolerating a leading document BOM is fine — deleting U+FEFF from string content is not. U+FEFF leads a double life (BOM signal vs. ZERO WIDTH NO-BREAK SPACE character); Foundation treats every occurrence as a stray BOM to scrub. Scope — exhaustive, not anecdotal I swept all 1,112,064 valid Unicode scalars (U+0000–U+10FFFF minus surrogates) through a parse round-trip, in both the \uFEFF-escape and raw-UTF-8 forms: U+FEFF is the only scalar altered. Every other scalar round-trips byte-identically — including the other zero-widths (U+200B, U+2060, U+00A0), which all survive. No Unicode normalization occurs (NFD stays decomposed, combining sequences and compatibility characters are preserved). So this is a deliberate BOM-stripping heuristic applied too broadly to string content — narrow and fixable, not general mangling. Why it's nasty in practice U+FEFF is zero-width, so the corruption is invisible — no trace in a diff or editor. Real-world hit: ML tokenizer vocabularies (e.g. Google's Gemma) legitimately contain U+FEFF-bearing tokens; loading tokenizer.json via NSJSONSerialization collapses those keys and assigns wrong token IDs, with zero visible symptom until output is subtly wrong. Filed as FB23271905 — please dupe if this has bitten you. More duplicates is what gets it triaged.

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

I'll try to ask a question that makes sense this time :) . I'm using the following method on NSFileManager: (BOOL) getRelationship:(NSURLRelationship *) outRelationship ofDirectoryAtURL:(NSURL *) directoryURL toItemAtURL:(NSURL *) otherURL error:(NSError * *) error; Sets 'outRelationship' to NSURLRelationshipContains if the directory at 'directoryURL' directly or indirectly contains the item at 'otherURL', meaning 'directoryURL' is found while enumerating parent URLs starting from 'otherURL'. Sets 'outRelationship' to NSURLRelationshipSame if 'directoryURL' and 'otherURL' locate the same item, meaning they have the same NSURLFileResourceIdentifierKey value. If 'directoryURL' is not a directory, or does not contain 'otherURL' and they do not locate the same file, then sets 'outRelationship' to NSURLRelationshipOther. If an error occurs, returns NO and sets 'error'. So this method falsely returns NSURLRelationshipSame for different directories. One is empty, one is not. Really weird behavior. Two file path urls pointing to two different file paths have the same NSURLFileResourceIdentifierKey? Could it be related to https://developer.apple.com/forums/thread/813641 ? One url in the check lived at the same file path as the other url at one time (but no longer does). No symlinks or anything going on. Just plain directory urls. And YES calling -removeCachedResourceValueForKey: with NSURLFileResourceIdentifierKey causes proper result of NSURLRelationshipOther to be returned. And I'm doing the check on a background queue.

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 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

There is an API in NSFilePresenter called primaryPresentedItemURL. It is implemented on macOS, but not iOS or Catalyst. I want to use it to write an XMP sidecar file next to original image files. However, because it’s not implemented on iOS or Catalyst, I cannot do this. The only workaround I have found is to ask the user for access to the whole folder. This, of course, is bad from a user privacy / security standpoint, especially as it gives the app access not only to the folder contents, but all subfolders. Can you give me a better workaround, or implement the API on iOS and Catalyst? Feedback Number is FB22771292

Repurposing my questions that weren't a good fit for the group lab to see how that goes :) I've been building a ScreenReader in Swift leveraging Structured Concurrency, actors, and recently distributed actors over XPC. https://codeberg.org/SpeakUp I have a number of questions I could ask (and would love to ask) but would start with asking for thoughts on my RunLoopExecutor project https://codeberg.org/SpeakUp/RunLoopExecutor/ All of the macOS Accessibility APIs are C/CoreFoundation/CFRunLoop based and I wanted to build something where actors would feel idiomatic for an experienced Swift developer but under the hood we're making sure that we're not contending with ourselves with all the IPC we're doing to get Accessibility data. I think so far it's been pretty successful as seen in the Controller types for the ScreenReader project: https://codeberg.org/SpeakUp/ScreenReader I'm currently using pretty naive pool implementations, one that is fixed width and one that is dynamic with a maximum width. Would love to hear different approaches to growing and shrinking the thread pool and handling things like marking a given executor as likely in a bad state (usually meaning the app it's talking to over AX API is blocking it's main thread) In the AccessibilityElement project https://codeberg.org/SpeakUp/AccessibilityElement for my HIServices Observer implementation I'm exposed to a race condition where axobserver doesn't flush it's notification queue on remove. I'm relying on pthread_specific currently to introduce thread local storage to work around this but it's quite clunky. In an ideal world the HIServices API would emit a done event to allow cleanup but so far that hasn't happened. I'll leave it there for now and do new posts with more requests for feedback if this one is well received.

What is URLResourceKey.documentIdentifierKey intended to identify compared with fileIdentifierKey? Is it expected to persist across save/replace operations, rename, move, app relaunch, or unmount/remount? Thanks!

In my sandboxed app, if a bookmarked network source is unavailable, is resolving the source/root security-scoped bookmark the recommended way to way to trigger a remount of the network volume? Thanks!

I’m trying to understand which storage capacity key is the correct one to use when deciding whether my app can start downloading offline video content. I read the documentation here: https://developer.apple.com/documentation/foundation/checking-volume-storage-capacity but I still don’t fully understand the intended usage difference between: volumeAvailableCapacityKey volumeAvailableCapacityForImportantUsageKey My app allows users to download videos for offline viewing. These downloads may remain on the device for a long time (days or even months), so they are not just temporary cache files. On one hand, this seems to match the description of “storing data based on a user request”, which suggests using volumeAvailableCapacityForImportantUsageKey. On the other hand, my understanding is that this value may assume the system is willing to aggressively purge caches and reclaim space for this “important usage”. I’m worried this could lead to unexpected or unpleasant side effects for the user if my app relies on that space. What confuses me even more is that the values are significantly different on my device: iPhone Settings reports about 142 GB free volumeAvailableCapacityKey returns only ~56 GB volumeAvailableCapacityForImportantUsageKey returns ~132 GB So my question is: For an app that downloads videos for offline playback — where the user explicitly requested the download, but the content may stay on device for a long time — which value is the recommended one to use when deciding whether there is enough free space to start the download? Should offline media downloads generally be treated as “important usage” in the sense intended by this API?

Model Name: MacBook Air Model Identifier: Mac17,3 I know it's possible to retrive model-identifier by running the command "sysctl hw.model", but is there another key to retrieve the model-name? ("MacBook Air" instead of "Mac17,3")

I'm trying to update the iCloud data handling in our app, and I'm running into an issue with a particular file on one particular device. This file never downloads & I haven't been able to pinpoint what's off about it. Right now we just have 2 iCloud accounts & a handful of devices, so I haven't been able to narrow it down yet, but in most cases, all the cloud files download as expected. However, whether or not the file eventually downloads, the NSURLUbiquitousItemDownloadRequestedKey key seems to be completely useless. For the following code: NSError *error = nil; BOOL success = [[NSFileManager defaultManager] startDownloadingUbiquitousItemAtURL:self.fileURL error:&error]; if (!success) { NSLog(@"error downloading %@ : %@", self.fileURL, error); } else { NSDictionary *resourceValues = [self.fileURL resourceValuesForKeys:@[NSURLUbiquitousItemDownloadRequestedKey, NSURLUbiquitousItemIsDownloadingKey, NSURLUbiquitousItemDownloadingErrorKey, NSURLUbiquitousItemDownloadingStatusKey] error:&error]; if (!error) { NSString *downloadStatus = resourceValues[NSURLUbiquitousItemDownloadingStatusKey]; bool downloadRequested = [resourceValues[NSURLUbiquitousItemDownloadRequestedKey] boolValue]; NSLog(@"download requested: %d", downloadRequested); } // ... } downloadRequested is always false, regardless of whether or not the cloud file eventually downloads. I have 2 questions: is there a way to actually check if a download has been requested for a file? what could be preventing this file from downloading? -startDownloadingUbiquitousItemAtURL:error: doesn't report an error, NSURLUbiquitousItemDownloadingErrorKey is always nil, and no error is reported in the NSMetadataQuery observer.

According to documentation, the URLSession background tasks continue even when the app is suspended. What is the lifespan of the URLSessionDownloadDelegate object when app is suspended or terminated? Will it get re-created and re-initialize properties when the app re-launches, or will it somehow restore the existing property values? Also, urlSessionDidFinishEvents not getting called, and what do we need to do there with the backgroundCompletionHandler? Any insights are much appreciated. We are getting ready to launch and this is a roadblock. (visionOS26.4) Thank you. @Observable class DownloadManager: NSObject, URLSessionDownloadDelegate { ... let config = URLSessionConfiguration.background(withIdentifier: "TestDL") config.sessionSendsLaunchEvents = true var urlSession = URLSession(configuration: config, delegate: self, delegateQueue: nil) func downloadFiles(... { // initiate multiple file downloads concurrently for url in urlList { let task = urlSession.downloadTask(with: url) task.resume() } } func urlSession(_ session: URLSession, downloadTask: URLSessionDownloadTask, didFinishDownloadingTo location: URL) { ... func urlSession(_ session: URLSession, downloadTask: URLSessionDownloadTask, didWriteData bytesWritten: Int64, totalBytesWritten: Int64, totalBytesExpectedToWrite: Int64) { ... func urlSession(_: URLSession, task: URLSessionTask, didCompleteWithError error: Error?) { ... // Not getting called ?? // Is this only called when app is suspended/terminated? func urlSessionDidFinishEvents(forBackgroundURLSession session: URLSession) { print("didFinishEvents") Task { @MainActor in //urlSession?.finishTasksAndInvalidate() //urlSession = nil // not sure what to do here: if let appDelegate = UIApplication.shared.delegate as? AppDelegate, let completionHandler = appDelegate.backgroundCompletionHandler { completionHandler() appDelegate.backgroundCompletionHandler = nil } } }

Summary We are seeing a recurring fatal NSInternalInconsistencyException on iOS 26.x devices. The crash originates entirely from system frameworks (Foundation / WebKit / Screen Time / NSXPCConnection) — there are no app frames in the stack. The exception is raised from an XPC reply on a worker thread, so the host app cannot wrap it in @try/@catch. The crash appears to be a KVO consistency check failing inside the platform's internal Screen Time observer (STScreenTimeConfigurationObserver) when it observes WKWebView's configuration.enforcesChildRestrictions key path. The exception message states the value of the intermediate key configuration changed without an appropriate KVO notification. Environment iOS versions: 26.2.1 (also seen on 26.0.x – 26.2.x) Devices: iPhone 13 (iPhone14,5), iPhone 16 Plus, others App orientation: portrait Process state at crash: BACKGROUND (most occurrences) App uses WKWebView in several screens (link preview, in-app web, 3rd-party SDK web views) Crash is recurring across multiple users on iOS 26.x and is reproducible at scale in production Exception Name: NSInternalInconsistencyException Reason: Cannot update for observer <WKScreenTimeConfigurationObserver 0x...> for the key path "configuration.enforcesChildRestrictions" from <STScreenTimeConfigurationObserver 0x...>, most likely because the value for the key "configuration" has changed without an appropriate KVO notification being sent. Check the KVO-compliance of the STScreenTimeConfigurationObserver class. Crashing thread (top frames) 0 CoreFoundation __exceptionPreprocess 1 libobjc.A.dylib objc_exception_throw 2 Foundation -[NSKeyValueNestedProperty object:withObservance:didChangeValueForKeyOrKeys:recurse:forwardingValues:] 3 Foundation NSKeyValueDidChange 4 Foundation -[NSObject(NSKeyValueObservingPrivate) _changeValueForKeys:count:maybeOldValuesDict:maybeNewValuesDict:usingBlock:] 5 Foundation -[NSObject(NSKeyValueObservingPrivate) _changeValueForKey:key:key:usingBlock:] 6 Foundation NSSetObjectValueAndNotify 7 CoreFoundation invoking 8 Foundation -[NSInvocation invoke] 9 Foundation 10 Foundation -[NSXPCConnection _decodeAndInvokeReplyBlockWithEvent:sequence:replyInfo:] 11 Foundation __88-[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:]_block_invoke_5 12 libxpc.dylib _xpc_connection_reply_callout 13 libxpc.dylib _xpc_connection_call_reply_async 14 libdispatch.dylib _dispatch_mach_msg_async_reply_invoke 15 libdispatch.dylib _dispatch_root_queue_drain_deferred_item 16 libdispatch.dylib _dispatch_kevent_worker_thread (Every frame above frame 0 lives in the system. No app frames are present.) What we observed Crash fires asynchronously on a libdispatch kevent worker thread, triggered by an XPC reply from the Screen Time service. The exception is thrown while the platform updates a chained KVO key path (configuration.enforcesChildRestrictions) on a WKWebView instance. The intermediate key configuration apparently changed without a paired willChange/didChange notification, which Foundation's KVO machinery then flags as inconsistency. Because the throw happens on the XPC reply path, there is no app-level synchronous frame we can wrap to recover. The exception unwinds straight into std::__terminate. What we tried (no effect) Confirmed all WKWebView creation and release happens on the main thread. Stop loading and nil out navigationDelegate before releasing the WKWebView. Avoided mutating WKWebViewConfiguration after the WKWebView is created. Checked for any custom KVO on WKWebView.configuration in app code — none exists. The crash still reproduces; we have no path to mitigate it from the application side. Questions for Apple / the community Is STScreenTimeConfigurationObserver expected to observe WKWebView.configuration.enforcesChildRestrictions under all conditions on iOS 26, or only when Screen Time / Communication Limits / Child Restrictions are enabled on the device? 2. Is there a public API (WKWebViewConfiguration option, Info.plist key, etc.) to opt a WKWebView out of Screen Time observation for hosts that do not need Screen Time integration for their web content? 3. Is this a known regression in iOS 26.x KVO chained-key-path notification posting inside WebKit's Screen Time integration? If so, is a fix slated for an upcoming 26.x release? 4. Is there any recommended workaround on the application side that does not rely on swizzling private Foundation / NSXPCConnection methods? Reproduction notes We do not have a deterministic local repro. Crashes are heavily concentrated on: iOS 26.2.1 Devices with Screen Time / Communication Limits / Child Restrictions configured at the OS level App entering the BACKGROUND state shortly after a WKWebView session If anyone has a reliable local repro on a developer device, please share — we would also like to file a Feedback Assistant report with steps. Filed Feedback Will attach FB number once filed. Thanks in advance.

I want to use AppStorage for a custom struct I am using struct Activities { var name: String var age: Int } struct ContentView: View { @AppStorage("key") private var activities: Activities = .init(name: "Albert", age: 42) var body: some View { VStack { TextField("Activity Name", text: $activities.name) } } } The above code generates a compiler warning, recommending I add RawRepresentable conformance. So I've added it like this: extension Activities: RawRepresentable { public init?(rawValue: String) { guard let data = rawValue.data(using: .utf8) else { return nil } do { let result = try JSONDecoder().decode(Activities.self, from: data) self = result } catch { print(error) return nil } } var rawValue: String { guard let data = try? JSONEncoder().encode(self), let result = String(data: data, encoding: .utf8) else { return "{}" } return result } } This leads to a stack overflow because calling encode from rawValue calls rawValue. :-( I overcame this by declaring Codable conformance and overriding the default Encodable implementation: extension Activities: Codable { enum CodingKeys: String, CodingKey { case name case age } func encode(to encoder: any Encoder) throws { var container = encoder.container(keyedBy: CodingKeys.self) try container.encode(name, forKey: .name) try container.encode(age, forKey: .age) } } This solves the stack overflow, but now init?(rawValue: String) is failing and I'm not sure why. When I set a breakpoint in my catch block I see the following: (lldb) po error ▿ DecodingError ▿ typeMismatch : 2 elements - .0 : Swift.String ▿ .1 : Context - codingPath : 0 elements - debugDescription : "Expected to decode String but found a dictionary instead." - underlyingError : nil (lldb) po rawValue {"name":"Albert2","age":42} (lldb) po data ▿ 27 bytes - count : 27 ▿ bytes : 27 elements - 0 : 123 - 1 : 34 - 2 : 110 - 3 : 97 - 4 : 109 - 5 : 101 - 6 : 34 - 7 : 58 - 8 : 34 (truncated to save space for posting :-)