我是开发者，日常工作会同时打开大量终端（tmux、多项目、自动化脚本、node‑pty 等）。在这种现代开发场景下，511 的 PTY 上限明显过低，而且这个默认值对顶配机器（128GB RAM）和低配机器是一样的，没有随硬件规格调整，这不合理。 我尝试过使用 tmux control mode 来减少 PTY 占用，但它会导致终端输出对齐错乱，影响可用性，所以必须继续使用 PTY 模式。这意味着只要终端数量稍多，就很容易触及 511 上限，导致系统层面无法创建新终端，影响全局稳定性。 总结： 511 作为默认值在过去或许合理，但对现代开发者明显不足； 顶配机器和低配机器同一上限不合理； control mode 有输出对齐问题，无法作为现实替代方案。 谢谢！ Apple 支持社区工作人员

Some mobile phones frequently report an error "bad URL" with the domain set to NSURLErrorDomain and the code set to -1000. However, I never encounter this error, and I'm not sure what's going wrong，The error log is as follows: HttpInterceptor:81 didReceive(_:target:): moya error: underlying(Alamofire.AFError.sessionTaskFailed(error: Error Domain=NSURLErrorDomain Code=-1000 "bad URL" UserInfo={_kCFStreamErrorCodeKey=22, NSUnderlyingError=0x1119f91d0 {Error Domain=kCFErrorDomainCFNetwork Code=-1000 "(null)" UserInfo={_NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: utun4[endc_sub6], ipv4, dns, uses cell, LQM: unknown, _kCFStreamErrorCodeKey=22, _kCFStreamErrorDomainKey=1}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <7FF86D00-1379-43D4-9F9B-0C300AEC57C8>.<4>, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <7FF86D00-1379-43D4-9F9B-0C300AEC57C8>.<4>" ), NSLocalizedDescription=bad URL, NSErrorFailingURLStringKey=https://update.flashforge.com/api/updates/check?app_id=46&entity_id=9E8D3B0C-2E61-46AF-91B9-B4AFFACF2788&platform=23&version=v1.3.4, NSErrorFailingURLKey=https://update.flashforge.com/api/updates/check?app_id=46&entity_id=9E8D3B0C-2E61-46AF-91B9-B4AFFACF2788&platform=23&version=v1.3.4, _kCFStreamErrorDomainKey=1}), nil)

Our business interface requests require disabling HTTP(s) proxies. We configured URLSessionConfiguration.connectionProxyDictionary as before, but found that it does not work on iOS 16.2 and 16.3.1. 1.Core code: let configuration = URLSessionConfiguration.default configuration.connectionProxyDictionary = [ "HTTPEnable": false, "HTTPSEnable": false, "SOCKSEnable": false, ] let session = URLSession(configuration: configuration) let request = URLRequest(url: URL(string: "https://www.baidu.com")!,timeoutInterval: Double.infinity) // 发送请求 let task = session.dataTask(with: request) { data, response, error in if let error = error { print("网络请求失败: \(error)") } if let data = data { print("网络请求成功，返回数据长度: \(data.count)") if let responseString = String(data: data, encoding: .utf8) { print("返回数据: \(responseString.prefix(100))...") } } } task.resume() 2.Specific steps: We captured traffic using Proxyman and Charles. With the same code, requests cannot be captured on iOS 18 and iOS 16.1, but can be captured on iOS 26.2 and 26.1. Conclusion:Therefore, we suspect there is a bug with URLSessionConfiguration.connectionProxyDictionary on iOS 26.x. Please let us know whether this is a bug. If not, how should we properly disable HTTP(s) proxies? Note: We need to exclude PAC proxies, which are commonly used in corporate internal networks. 3.Devices & Soft Xcode 16.4 iPhone 26.2、Simulator 26.1 Proxyman、Charles

Hi, We are the developers of Morning Call (https://morningcall.info), and we believe we may have identified an AlarmKit / system UI bug on iPhone. We can reproduce the same behavior not only in our app, but also in Apple’s official AlarmKit sample app, which strongly suggests this is a framework or system-level issue rather than an app-specific bug. Demonstration Video of producing zombie Live Activity https://www.youtube.com/watch?v=cZdF3oc8dVI Related Thread https://developer.apple.com/forums/thread/812006 https://developer.apple.com/forums/thread/817305 https://developer.apple.com/forums/thread/807335 Environment iPhone with Dynamic Island Alarm created using AlarmKit Device is unlocked when the alarm begins alerting Steps to reproduce Schedule an AlarmKit alarm. Wait for the alarm to alert while the device is unlocked. The alarm appears in Dynamic Island. Instead of tapping the intended stop or dismiss button, swipe the Dynamic Island presentation away. Expected result The alarm should be fully dismissed. The Live Activity should be removed. No empty UI should remain in Dynamic Island. Actual result The assigned AppIntent runs successfully. Our app code executes as expected. AlarmKit appears to stop the alarm correctly. However, an empty “zombie” Live Activity remains in Dynamic Island indefinitely. The user cannot clear it through normal interaction. Why this is a serious user-facing issue This is not just a cosmetic issue for us. From the user’s perspective, it looks like a Live Activity is permanently stuck in Dynamic Island. More importantly: Force-quitting the app does not remove it Deleting the app does not remove it In practice, many users conclude that our app has left a broken Live Activity running forever We receive repeated user complaints saying that the Live Activity “won’t go away” Because the remaining UI appears to be system-owned, users often do not realize that the only reliable recovery is to restart the phone. Most users do not discover that workaround on their own, so they instead assume the app is severely broken. Cases where the zombie state disappears Rebooting the phone Waiting for the next AlarmKit alert, then pressing the proper stop button on that alert Additional observations Inside our LiveActivityIntent, calling AlarmManager.shared.stop(id:) reports that the alarm has already been stopped by the system. We also tried inspecting Activity<AlarmAttributes<...>>.activities and calling end(..., dismissalPolicy: .immediate), but in this state no matching activity is exposed to the app. This suggests that the alarm itself has already been stopped, but the system-owned Live Activity UI is not being cleaned up correctly after the swipe-dismiss path. Why this does not appear to be an app logic issue The intent is invoked successfully. The alarm stop path is reached. The alarm is already considered stopped by the system. The remaining UI appears to be system-owned. The stuck UI persists even after our own cleanup logic has run. The stuck UI also survives app force-quit and app deletion.

We’re using a private database with a custom zone. Record types and related schema are created programmatically rather than through the dashboard. When running the app in the development environment, I can see that data is saved and can be retrieved successfully. However, in the iCloud console, I don’t see any record types or even the custom zone. Additionally, I’m unable to deploy any schema to production because no changes are detected. Do you have any ideas on what we might be missing? Installing the app from TestFlight when trying to upload a record CloudKit reports this error: <CKError 0x13f40bb10: "Invalid Arguments" (12/2006); server message = "Cannot create new type MyType in production schema" ...>

Hi there, I’m curious to understand how the system determines which language to use for an app. The system is currently set to en-IN (English - India). My app supports the following languages: en (the default development language) en-GB (United Kingdom) en-IE (Ireland) en-US (United States) When I run the app, the Bundle.main.preferredLanguages returns [„en-GB“, „en“], which causes the app to be set to en-GB. However, when the app doesn’t support the preferred system language, I would expect it to default to the en language. Surprisingly, this is not the case. This behavior is precisely described in Technical Note TN2418. Unfortunately, there’s no explanation provided. Is this behavior related to the CLDR Linguistic Distance? I also attempted to replace the default development language en with en-001 (English - world), but it had no effect.

Hello everyone, my app A now supports iOS Widget C under the same Xcode project. Now I have another app B under this project, and I hope it can also support this Widget C. What should be done? How should the app group be configured? I have found some solutions: for example, add this key under the info.plist corresponding to app B: NSExtension NSExtensionPointIdentifier com.apple.widgetkit-extension NSExtensionPrincipalClass $(PRODUCT_MODULE_NAME).WidgetEntryView However, when I configured it and started running, not only could I not see the support Widget C, but the screen also went black. Thank you all.

Overview I'm developing a document-based app for macOS using SwiftData. When I undo/redo changes using Command-Z/Command-Shift-Z, the app reliably crashes with the following error: SwiftData/ModelSnapshot.swift:46: Fatal error: Unexpected backing data for snapshot creation: SwiftData._FullFutureBackingData<DocumentTest.ChildItem> And before the app crashes, what always happens is that UndoManager stops removing/restoring instances of ChildItem (but continues to remove/restore instances of ParentItem). The issue goes away when I enclose the relevant code in ModelContext.transaction(block:). However, this shouldn't be necessary, as ModelContext.autosaveEnabled is true by default. The issues are occurring with Xcode 26.4 (17E192) and macOS Tahoe 26.4 (25E246). I have modified the macOS Document App project template to showcase the issue. The sample project, along with a screen recording of the crash, can be downloaded from here: https://drive.google.com/drive/folders/13bCB1qRZ6273BI81zW2zUUBraSvv6p5w?usp=share_link Is this expected behavior or should I file a bug report in Feedback Assistant? Steps to Reproduce To recreate the issue, follow these steps: Download and extract the "Xcode Project.zip" file linked above. Open the extracted "DocumentTest" project in Xcode. Build and run the "DocumentTest" app. In the document selection window, click "New Document" at the bottom-left. In the app, click the "+" button at the top-right to add a ParentItem with ChildItems. Click on the added ParentItem's button to add another ChildItem to it. Repeat steps 5–6 until you have 5 ParentItems with an additional ChildItem. Press Command-Z 10 times to undo all the changes. Press Command-Shift-Z 10 times to redo all the changes. Repeat steps 8–9 until UndoManager stops removing/restoring the additional ChildItem, and continue repeating them until the app eventually crashes (you may have to repeat them 5–10 times before the issue occurs). If you uncomment the ModelContext.transaction(block:) at line 13 of ContentView.swift and repeat the same steps above, no ChildItems will go missing and the app will not crash. Code ParentItem Model @Model final class ParentItem { var timestamp: Date @Relationship( deleteRule: .cascade, inverse: \ChildItem.parentItem ) var childItems: [ChildItem] = [] init(timestamp: Date) { self.timestamp = timestamp } } ChildItem Model @Model final class ChildItem { var index: Int var parentItem: ParentItem? init(index: Int) { self.index = index } } Creating, Inserting, and Linking ParentItem and ChildItem // Create and insert ParentItem let newParentItem = ParentItem( timestamp: Date() ) modelContext.insert(newParentItem) // Create and insert ChildItems var newChildItems: [ChildItem] = [] for index in 0..<Int.random(in: 2...8) { let newChildItem = ChildItem(index: index) newChildItems.append(newChildItem) modelContext.insert(newChildItem) } /* Establish relationship between ParentItem and ChildItems */ for newChildItem in newChildItems { newParentItem.childItems.append( newChildItem ) newChildItem.parentItem = newParentItem } Adding an Additional ChildItem to ParentItem // Uncommenting this block fixes the crash // try! modelContext.transaction { // Create and insert the new ChildItem let newChildItem = ChildItem( index: parentItem.childItems.count ) modelContext.insert(newChildItem) // Establish relationship to parentItem parentItem.childItems.append(newChildItem) newChildItem.parentItem = parentItem // }

Hello, I'm seeing an inconsistency in how HKAnchoredObjectQuery applies predicates between its initial results handler and its update handler. Specifically, predicates that filter quantity samples by correlation membership - using either HKQuery.predicateForObjectsWithNoCorrelation() or NSPredicate(format: "%K == nil", HKPredicateKeyPathCorrelation) - are respected in the resultsHandler but silently ignored in the updateHandler. Setup I have three long-running HKAnchoredObjectQuery instances: One for HKCorrelationType(.bloodPressure) - no predicate One for HKQuantityType(.bloodPressureSystolic) - predicate: HKQuery.predicateForObjectsWithNoCorrelation() One for HKQuantityType(.bloodPressureDiastolic) - predicate: HKQuery.predicateForObjectsWithNoCorrelation() The intent of the predicate on the systolic/diastolic queries is to capture only standalone quantity samples written directly by third-party apps - not the constituent sub-samples of an HKCorrelation. The correlation query handles correlated samples. Expected behavior When a BloodPressure correlation is saved to the store, only the correlation query's updateHandler should fire, with 1 new sample. The systolic and diastolic updateHandlers should not fire, since those samples have correlation != nil which is excluded by the predicate. Actual behavior After saving one BloodPressure correlation, all three updateHandlers fire with 1 new object each. The systolic and diastolic update handlers receive the correlated sub-samples despite the predicateForObjectsWithNoCorrelation() predicate. The same predicate correctly filters those kinds of samples out of the initial resultsHandler. Additionally, the same predicate applied in a one-shot HKSampleQuery for the systolic or diastolic type correctly returns 0 results when only correlated readings exist. The problem is only experienced in updateHandler of a long-running HKAnchoredObjectQuery. Tested iOS versions iOS 26.3 iOS 18.7.6 Workaround When an HKAnchoredObjectQuery updateHandler fires with systolic or diastolic samples, I fire a one-shot HKSampleQuery with a compound predicate using the sample UUIDs and predicateForObjectsWithNoCorrelation. Any samples that are part of a correlation are not returned in the HKSampleQuery resultsHandler.

Hi Team, We are implementing HealthKit data sync using HKObserverQuery along with enableBackgroundDelivery and BGTaskScheduler for fallback processing. However, we are observing inconsistent behavior and would like clarification on expected system behavior: For HKObserverQuery: When using enableBackgroundDelivery with frequency .immediate, we sometimes receive updates promptly, but other times we do not receive any trigger at all. Similarly, when using .hourly, our expectation was that updates would be delivered approximately once per hour, but in practice, triggers are delayed, batched, or skipped. For BGTaskScheduler: We are scheduling BGAppRefreshTask with earliestBeginDate set (e.g., 1 hour), but tasks are sometimes delayed by several hours or not triggered predictably. In some cases, tasks are not executed even after extended periods. We would like to understand: Are HKObserverQuery delivery frequencies (.immediate, .hourly, .daily) strictly best-effort hints rather than guaranteed intervals? Under what conditions can observer updates be skipped or significantly delayed? Is there any recommended approach to ensure more reliable periodic syncing of HealthKit data? For BGTaskScheduler, what factors most strongly influence scheduling delays or missed executions? Our goal is to design a reliable sync mechanism, but the lack of deterministic behavior is making it difficult to define expected system behavior. Any clarification or recommended best practices would be greatly appreciated. Thanks in advance!

I am developing a USB MTP device for use with macOS. When the device is connected while Preview is running, I observe the host send OpenSession, then GetDeviceInfo, and then no further MTP commands. I do not see a later CloseSession. Problem is that once this happens, exclusive access to the USB interface is retained, so another application cannot connect to the device. From the device side, there is no obvious way to recover except forcing a USB disconnect/reset or shutting down the USB interface. My questions are: Is this expected behavior for Preview, or for a Preview-related macOS helper? Is it expected on macOS that a client may open an MTP session and then leave it idle without sending CloseSession? I am mainly trying to understand whether this is expected macOS behavior, or whether this should be considered a bug.

I'm developing a watchOS nap app that detects when the user falls asleep by monitoring heart rate changes. == Technical Implementation == HKWorkoutSession (.mindAndBody) for background execution HKAnchoredObjectQuery for real-time heart rate data CoreMotion for movement detection == Battery Considerations == Heart rate monitoring ONLY active when user explicitly starts a session Monitoring continues until user is awakened OR 60-minute limit is reached If no sleep detected within 60 minutes, session auto-ends (user may have abandoned or forgotten to stop) App displays clear UI indicating monitoring is active Typical session: 15-30 minutes, keeping battery usage minimal == The Problem == HKWorkoutSession affects Activity Rings during the session. Users receive "Exercise goal reached" notifications while resting — confusing. == What I've Tried == Not using HKLiveWorkoutBuilder → Activity Rings still affected Using builder but not calling finishWorkout() (per https://developer.apple.com/forums/thread/780220) → Activity Rings still affected WKExtendedRuntimeSession (self-care type) (per https://developer.apple.com/forums/thread/721077) → Only ~10 min runtime, need up to 60 min HKObserverQuery + enableBackgroundDelivery (per https://developer.apple.com/forums/thread/779101) → ~4 updates/hour, too slow for real-time detection Audio background session for continuous processing (suggested in https://developer.apple.com/forums/thread/130287) → Concerned about App Store rejection for non-audio app; if official approves this technical route, I can implement in this direction Some online resources mention "Health Monitoring Entitlement" from WWDC 2019 Session 251, but I could not find any official documentation for this entitlement. Apple Developer Support also confirmed they cannot locate it? == My Question == Is there any supported way to: Monitor heart rate in background for up to 60 minutes WITHOUT affecting Activity Rings or creating workout records? If this requires a special entitlement or API access, please advise on the application process. Or allow me to submit a code-level support request. Any guidance would be greatly appreciated. Thank you!

when we launch the application and change the language from german/french to english or any other language then in also it is changing app language, but bluetooth connection screen with pair or cancel alert is showing on previous selected language. Since that alert is system alert, is there any wayto debug/resolve that issue.

On iOS 26.4, I set a Screen Time passcode. However, when I go to Settings > Apps > [Our App] and turn off Screen Time Access for the app, the system asks for Face ID instead of the Screen Time passcode. As a result, Screen Time access can be disabled without entering the Screen Time passcode. Steps to Reproduce 1. Set a Screen Time passcode on iOS 26.4. 2. Open Settings > Apps > [Our App]. 3. Turn off Screen Time Access for the app. Expected Result The system should require the Screen Time passcode before allowing Screen Time access to be disabled. Actual Result The system asks for Face ID instead of the Screen Time passcode, and Screen Time access is disabled.

Given a directory path (or NSURL) I need to get the total number of files/documents in that directory - recursively - as fast and light as possible. I don't need to list the files, and not filter them. All the APIs I found so far (NSFileManger, NSURL, NSDirectoryEnumerator) collect too much information, and those who are recursive - are aggregating the whole hierarchy before returning. If applied to large directory - this both implies a high CPU peak and slow action, and a huge memory impact - even if transient. My question: What API is best to use to accomplish this count, must I scan recursively the hierarchy? Is there a "lower level" API I could use that is below NSFileManager that provides better performance? One time in the middle-ages, I used old MacOS 8 (before MacOS X) file-system APIs that were immensely fast and allowed doing this without aggregating anything. I write my code in Objective-C, using latest Xcode and MacOS and of course ARC.

Hi, I am trying to build a very simple iOS app in Xcode that starts an NFCNDEFReaderSession when I press a button. My goal right now is only to verify that the NFC reading process starts correctly on a real iPhone. I am not trying to publish the app on the App Store. When I try to start the session, I get this error in the console: -[NFCHardwareManager areFeaturesSupported:outError:]:435 XPC Error: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.nfcd.service.corenfc was invalidated: Connection init failed at lookup with error 159 - Sandbox restriction." UserInfo={NSDebugDescription=The connection to service named com.apple.nfcd.service.corenfc was invalidated: Connection init failed at lookup with error 159 - Sandbox restriction.} and then my app reports that NFC is not available on this device. Important details: I added Near Field Communication Tag Reading in Signing & Capabilities. I added the NFC privacy usage description in the target settings. I am using automatic signing. I am not using an Apple Developer Program paid account. I am using a Personal Team / free account. I should also mention that I am not experienced with Swift/iOS development, so I may be missing something basic in the setup. My question is: Is this expected when using a Personal Team / free account, or is there some configuration issue I should still check? I am happy to provide any additional information needed

How does Associated Domains Development work on watchOS? In comparison, on iOS we have Diagnostics menu that allows to input a link and test the setup. How to achieve the same on a watch? watchOS: iOS:

Hello, I am working on a DLP solution for macOS that relies on the Network Extension (NETransparentProxyProvider) for network traffic analysis. Could you please clarify: is it technically possible and officially supported to use a LaunchAgent as the container app to install and manage the Network Extension? If not, what is the recommended approach in case of GUI less application? Thank you in advance.

Context I'm building a study-timer feature for an iOS app (Flutter + native ActivityKit) that displays a Live Activity on the Lock Screen / Dynamic Island while a session is running. When the user force-quits the app by swiping it up from the App Switcher, I want the Live Activity to disappear as quickly as possible. I have already confirmed (from on-device testing and Apple Developer Forums thread 732418) that: applicationWillTerminate is not called on swipe-up force-kill, only on OS-initiated termination or crash. So synchronous Activity.end(...) from the app itself is not a solution for the force-kill path. Shortening staleDate does not visually dismiss the Live Activity once the app process is gone — the Widget Extension keeps rendering the last fresh snapshot and there is no body-reevaluation trigger on the stale transition post-app-death. (I implemented and verified this, then rolled it back.) The only Apple-official reliable mechanism is APNs push-to-end (Activity.request(pushType: .token) + server sends event: end via APNs). Current architecture I have APNs push-to-end working end-to-end. Structure: Client: Activity.request(pushType: .token), subscribe to Activity.pushTokenUpdates, forward each new token to the backend. Backend: On every client heartbeat, upsert (user_id, la_apns_token, la_activity_id, last_heartbeat) into Postgres. A separate scheduler polls for rows whose last_heartbeat < now() - grace_ttl and sends APNs event: end to the stored token. Parameters I am currently running with: Parameter Value Client heartbeat interval 60 s Orphan grace TTL (server) 135 s (heartbeat × 2.25, to absorb network jitter) Scheduler poll interval 30 s The observation End-to-end latency from "user force-kills the app" to "Live Activity disappears from Lock Screen" is: Worst case: 60 + 135 + 30 = ~225 s (~3.75 min) Typical: ~3 min (as consistently measured on iOS 26.4.1, iPhone 17 Pro Max) Theoretical minimum (if the kill happens exactly at a heartbeat boundary): ~135 s Users perceive 3 minutes as broken — the timer clearly stopped (no ticking), but the Live Activity "ghost" is still visible on the Lock Screen. My question Is there any Apple-supported mechanism to reliably tear down a Live Activity faster than ~2 minutes after the owning app's process is gone, given that applicationWillTerminate does not fire on swipe-kill? Specifically: Is there any practical lower bound below ~60 s for this scenario using the current ActivityKit + APNs model, assuming we are not willing to spam heartbeats every few seconds? I can push heartbeat to 20–30 s, but the server cost grows linearly with active sessions. Does BGAppRefreshTask / BGProcessingTask have any documented lifecycle hook that fires on user-initiated swipe-kill specifically, so that I could do a "last-heartbeat flush" just before the process dies? My understanding is that background tasks are scheduled for later and do not fire synchronously at termination. Is there any signal from APNs/ActivityKit to my server (e.g. a feedback-service-like mechanism) that indicates "this Live Activity's owning app was force-killed", which would let the server short-circuit the heartbeat-based orphan detection? Are there any new APIs in iOS 18.x or the upcoming release that address this specific force-kill → LA-dismissal latency? I could not find anything in the 18.x release notes, but I may have missed it. What I am NOT asking I am not asking how to implement APNs push-to-end (that works). I am not asking about applicationWillTerminate (I already confirmed it does not fire on swipe-kill). I am not asking about shortening staleDate as a visual workaround (I already verified it does not trigger body reevaluation post-kill). Environment iOS 26.4.1 (also reproducible on 18.x devices I have on hand) iPhone 17 Pro Max, iPhone 15 Pro, iPad Air 11-inch (M3) Xcode 26.x Activity.request(pushType: .token) with ActivityContent + custom stalenessInterval = 120s APNs HTTP/2 via token auth (.p8), targeting api.push.apple.com in production apns-push-type: liveactivity, apns-priority: 10, payload includes event: end What I have tried (for the record, to avoid "did you try" responses) applicationWillTerminate with DispatchSemaphore 3.5 s sync wait + dismissalPolicy: .immediate — works only for OS-terminate, not swipe-kill. stalenessInterval = 30s + 15 s refresh cadence + override to 5 s on AppLifecycleState.paused — verified not to dismiss the LA after app death. Cold-start reconciliation via Activity<...>.activities on next app launch — works, but that only helps if the user relaunches. Current APNs push-to-end with 60 s / 135 s / 30 s configuration — works, but latency is the complaint. Any guidance, even "no, ~2 minutes is the floor by design" with a pointer to the relevant doc, would be very helpful. Thank you.

I've added NFC support for my app. So, my UIRequiredDeviceCapabilities were extended from "armv7" to "armv7 nfc". This means I've prevented this application from running on devices supported by previous versions. Now I've received a message from Apple: ITMS-90109: This bundle is invalid - The key UIRequiredDeviceCapabilities in the Info.plist may not contain values that would prevent this application from running on devices that were supported by previous versions. What is the right way to add new functions?