I often get questions about third-party crash reporting. These usually show up in one of two contexts: Folks are trying to implement their own crash reporter. Folks have implemented their own crash reporter and are trying to debug a problem based on the report it generated. This is a complex issue and this post is my attempt to untangle some of that complexity. IMPORTANT iOS 27, currently in beta, introduced support for out-of-process crash reporting using the CrashReportExtension framework. I haven’t yet had time to update this post to cover that technology. However, if you’re planning to implement your own crash reporter on iOS, you should start there. (The documentation currently states that this feature is available on macOS 27, also currently in beta, but that’s not true (r. 180425854) and I’ve no info to share as to when that’ll change.) If you have a follow-up question about anything I've raised here, please put it in a new thread with the Debugging tag. IMPORTANT All of the following is my own direct experience. None of it should be considered official DTS policy. If you have a specific question that needs a direct answer — perhaps you’re trying to convince your boss that implementing your own crash reporter is a very bad idea — start a dedicated thread here on the forums and we can discuss the details there. Use whatever subtopic is appropriate for your issue, but make sure to add the Debugging tag so that I see it go by. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Scope First, I can only speak to the technical side of this issue. There are other aspects that are beyond my remit: I don’t work for App Review, and only they can give definitive answers about what will or won’t be allowed on the store. Implementing your own crash reporter has significant privacy implications. IMPORTANT If you implement your own crash reporter, discuss the privacy impact with a lawyer. This post assumes that you are implementing your own crash reporter. A lot of folks use a crash reporter from another third party. From my perspective these are the same thing. If you use a custom crash reporter, you are responsible for its behaviour, both good and bad, regardless of where the actual code came from. Note If you use a crash reporter from another third party, run the tests outlined in Preserve the Apple Crash Report to verify that it’s working well. General Advice I strongly advise against implementing your own crash reporter. It’s very easy to create a basic crash reporter that works well enough to debug simple problems. It’s impossible to implement a good crash reporter, one that’s reliable, binary compatible, and sufficient to debug complex problems. The bulk of this post is a low-level explanation of that impossibility. Rather than attempting the impossible, I recommend that you lean in to Apple’s crash reporter. In recent years it’s acquired some really cool new features: If you’re creating an App Store app, the Xcode organiser gives you easy, interactive access to Apple crash reports. If you’re an enterprise developer, consider switching to Custom App Distribution. This yields all the benefits of App Store distribution without your app being generally available on the store. iOS 14 and macOS 12 report crashes in MetricKit. This is a very cool feature, and I’m surprised by how few people use it effectively. If you previously dismissed Apple crash reports as insufficient, I encourage you to reconsider that decision. Why Is This Impossible? Earlier I said “It’s impossible to implement a good crash reporter”, and I want to explain why I’m confident enough in my conclusions to use that specific word. There are two fundamental problems here: On iOS (and the other iOS-based platforms, watchOS and tvOS) your crash reporter must run inside the crashed process. That means it can never be 100% reliable. If the process is crashing then, by definition, it’s in an undefined state. Attempting to do real work in that state is just asking for problems [1]. To get good results your crash reporter must be intimately tied to system implementation details. These can change from release to release, which invalidates the assumptions made by your crash reporter. This isn’t a problem for the Apple crash reporter because it ships with the system. However, a crash reporter that’s built in to your product is always going to be brittle. I’m speaking from hard-won experience here. I worked for DTS during the PowerPC-to-Intel transition, and saw a lot of folks with custom crash reporters struggle through that process. Still, this post exists because lots of folks ignore this reality, so the subsequent sections contain advice about specific technical issues. WARNING Do not interpret any of the following as encouragement to implement your own crash reporter. I strongly advise against that. However, if you ignore my advice then you should at least try to minimise the risk, which is what the rest of this document is about. [1] On macOS it’s possible for your crash reporter to run out of process, just like the Apple crash reporter. However, possible is not the same as easy. In fact, running out of process can make things worse: It prevents you from geting critical state for the crashed process without being tightly bound to OS implementation details. It would be nice if Apple provided APIs for this sort of thing, but that’s currently not the case. Preserve the Apple Crash Report You must ensure that your crash reporter doesn’t disrupt the Apple crash reporter. This is important for three reasons: Some fraction of your crashes will not be caused by your code but by problems in framework code, and accurate Apple crash reports are critical in diagnosing such issues. When dealing with really hard-to-debug problems, you need the more obscure info that’s shown in the Apple crash report. If you’re working with someone from Apple (here on the forums, via a bug report, or a DTS case, or whatever), they’re going to want an accurate Apple crash report. If your crash reporter is disrupting the Apple crash reporter — either preventing it from generating crash reports entirely [1], or distorting those crash reports — that limits how much they can help you. IMPORTANT This is not a theoretical concern. The forums have many threads where I’ve been unable to help folks debug a gnarly problem because their third-party crash reporter didn’t preserve the Apple crash report (see here, here, and here for some examples). To avoid these issues I recommend that you test your crash reporter’s impact on the Apple crash reporter. The basic idea is: Create a program that generates a set of specific crashes. Run through each crash. Verify that your crash reporter produces sensible results. Verify that the Apple crash reporter produces the same results as it does without your crash reporter With regards step 1, your test suite should include: An un-handled language exception thrown by your code An un-handled language exception thrown by the OS (accessing an NSArray out of bounds is an easy way to get this) Various machine exceptions (at a minimum, memory access, illegal instruction, and breakpoint exceptions) Stack overflow Make sure to test all of these cases on both the main thread and a secondary thread. With regards step 4, check that the resulting Apple crash report includes correct values for: The exception info The crashed thread That thread’s state Any application-specific info, and especially the last exception backtrace [1] A particularly pathological behaviour here is to end your crash reporter by calling exit. This completely suppresses the Apple crash report. Some third-party language runtimes ‘helpfully’ include such a crash reporter, which makes it very hard to debug problems that occur within your process but outside of that language. Signals Many third-party crash reporters use UNIX signals to catch the crash. This is a shame because using Mach exception handling, the mechanism used by the Apple crash reporter, is generally a better option. However, there are two reasons to favour UNIX signals over Mach exception handling: On iOS-based platforms your crash reporter must run in-process, and doing in-process Mach exception handling is not feasible. Folks are a lot more familiar with UNIX signals. Mach exception handling, and Mach messaging in general, is pretty darned obscure. If you use UNIX signals for your crash reporter, be aware that this API has some gaping pitfalls. First and foremost, your signal handler can only use async signal safe functions [1]. You can find a list of these functions in sigaction man page [2] [3]. WARNING This list does not include malloc. This means that a crash reporter’s signal handler cannot use Objective-C or Swift, as there’s no way to constrain how those language runtimes allocate memory [4]. That means you’re stuck with C or C++, but even there you have to be careful to comply with this constraint. The Operative: It’s worse than you know. Captain Malcolm Reynolds: It usually is. Many crash reports use functions like backtrace (see its man page) to get a backtrace from their signal handler. There’s two problems with this: backtrace is not an async signal safe function. backtrace uses a naïve algorithm that doesn’t deal well with cross signal handler stack frames [5]. The latter point is particularly worrying, because it hides the identity of the stack frame that triggered the signal. If you’re going to backtrace out of a signal, you must use the crashed thread’s state (accessible via the handlers uap parameter) to start your backtrace. Apropos that, if your crash reporter wants to log the state of the crashed thread, that’s the place to get it. Your signal handler must be prepared to be called by multiple threads. A typical crashing signal (like SIGSEGV) is delivered to the thread that triggered the machine exception. While your signal handler is running on that thread, other threads in your process continue to run. One of these threads could crash, causing it to call your signal handler. It’s a good idea to suspend all threads in your process early in your signal handler. However, there’s no way to completely eliminate this window. Note The need to suspend all the other threads in your process is further evidence that sticking to async signal safe functions is required. An unsafe function might depend on a thread you’ve suspended. A typical crashing signal is delivered on the thread that triggered the machine exception. If the machine exception was caused by a stack overflow, the system won’t have enough stack space to call your signal handler. You can tell the system to switch to an alternative stack (see the discussion of SA_ONSTACK in the sigaction man page) but that isn’t a complete solution (because of the thread issue discussed immediately above). Finally, there’s the question of how to exit from your signal handler. You must not call exit. There’s two problems with doing that: exit is not async signal safe. In fact, exit can run arbitrary code via handlers registered with atexit. If you want to exit the process, call _exit. Exiting the process is a bad idea anyway, because it will prevent the Apple crash reporter from running. This is very poor form. For an explanation as to why, see Preserve the Apple Crash Report (above). A better solution is to unregister your signal handler (set it to SIG_DFL) and then return. This will cause the crashed process to continue execution, crash again, and generate a crash report via the Apple crash reporter. [1] While the common signals caught by a crash reporter are not technically async signals (except SIGABRT), you still have to treat them as async signals because they can occur on any thread at any time. [2] It’s reasonable to extend this list to other routines that are implemented as thin shims on a system call. For example, I have no qualms about calling vm_read (see below) from a signal handler. [3] Be aware, however, that even this list has caveats. See my Async Signal Safe Functions vs Dyld Lazy Binding post for details. [4] I expect that it’ll eventually be possible to write signal handlers in Swift, possibly using some facility that evolves from the the existing, but unsupported, @_noAllocation and @_noLocks attributes. If you’d like to get involved with that effort, I recommend that engage with the Swift Evolution process. [5] Cross signal handler stack frames are pushed on to the stack by the kernel when it runs a signal handler on a thread. As there’s no API to learn about the structure of these frames, there’s no way to backtrace across one of these frames in isolation. I’m happy to go into details but it’s really not relevant to this discussion [6]. If you’re interested, start a new thread with the Debugging tag and we can chat there. [6] (Arg, my footnotes have footnotes!) The exception to this is where your trying to generate a crash report for code running in a signal handler. That’s not easy, and frankly you’re better off avoiding signal handlers in general. Where possible, handle signals via a Dispatch event source. Reading Memory A signal handler must be very careful about the memory it touches, because the contents of that memory might have been corrupted by the crash that triggered the signal. My general rule here is that the signal handler can safely access: Its code Its stack (subject to the constraints discussed earlier) Its arguments Immutable global state In the last point, I’m using immutable to mean immutable after startup. It’s reasonable to set up some global state when the process starts, before installing your signal handler, and then rely on it in your signal handler. Changing any global state after the signal handler is installed is dangerous, and if you need to do that you must be careful to ensure that your signal handler sees consistent state, even though a crash might occur halfway through your change. You can’t protect this global state with a mutex because mutexes are not async signal safe (and even if they were you’d deadlock if the mutex was held by the thread that crashed). You should be able to use atomic operations for this, but atomic operations are notoriously hard to use correctly (if I had a dollar for every time I’ve pointed out to a developer they’re using atomic operations incorrectly, I’d be very badly paid (-: but that’s still a lot of developers!). If your signal handler reads other memory, it must take care to avoid crashing while doing that read. There’s no BSD-level API for this [1], so I recommend that you use vm_read. [1] The traditional UNIX approach for doing this is to install a signal handler to catch any memory access exceptions triggered by the read, but now we’re talking signal handling within a signal handler and that’s just silly. Writing Files If your want to write a crash report from your signal handler, you must use low-level UNIX APIs (open, write, close) because only those low-level APIs are documented to be async signal safe. You must also set up the path in advance because the standard APIs for determining where to write the file (NSFileManager, for example) are not async signal safe. Offline Symbolication Do not attempt to do symbolication from your signal handler. Rather, write enough information to your crash report to support offline symbolication. Specifically: The addresses to symbolicate For each Mach-O image in the process: The image’s path The image’s build UUID [1] The image’s load address You can get most of the Mach-O image information using the APIs in <mach-o/dyld.h> [2]. Be aware, however, that these APIs are not async signal safe. You’ll need to get this information in advance and cache it for your signal handler to record. This is complicated by the fact that the list of Mach-O images can change as you process loads and unloads code. This requires you to share mutable state with your signal handler, which is exactly what I recommend against in Reading Memory. Note You can learn about images loading and unloading using _dyld_register_func_for_add_image and _dyld_register_func_for_remove_image respectively. [1] If you’re unfamiliar with that term, see TN3178 Checking for and resolving build UUID problems and the documents it links to. [2] I believe you’ll need to parse the Mach-O load commands to get the build UUID. What to Include When deciding what to include in a crash report, there’s a three-way balance to be struck: The more information you include, the easier it is to diagnose problems. Some information is hard to obtain, either because there’s no public API to get that information, or because the API is not available to your crash reporter. Some information is so privacy-sensitive that it has no place in a crash report. Apple’s crash reporter strikes its own balance here, and I recommend that you try to include everything that it includes, subject to the limitations described in the second point. Here’s what I’d considered to be a minimal list: Information about the machine exception that triggered the crash For memory access exceptions, the address of the access that triggered the crash Backtraces of all the threads (sometimes the backtrace of a non-crashing thread can yield critical information about the crash) The crashed thread Its thread state A list of Mach-O images, as discussed in the Offline Symbolication section IMPORTANT Make sure you report the thread backtraces in a consistent order. Without that it’s hard to correlate information across crash reports. Revision History 2026-06-30 Updated the note about the CrashReportExtension framework with some critical info about the supported platforms. 2026-06-09 Added a quick note about CrashReportExtension framework to the preamble. 2025-08-25 Added some links to examples of third-party crash reports not preserving the Apple crash report. Added a link to TN3178. Made other minor editorial changes. 2022-05-16 Fixed a broken link. 2021-09-10 Expanded the General Advice section to include pointers to Apple crash report resources, including MetricKit. Split the second half of that section out in to a new Why Is This Impossible? section. Made minor editoral changes. 2021-02-27 Fixed the formatting. Made minor editoral changes. 2019-05-13 Added a reference to my Async Signal Safe Functions vs Dyld Lazy Binding post. 2019-02-15 Expanded the introduction to the Preserve the Apple Crash Report section. 2019-02-14 Clarified the complexities of an out-of-process crash reporter. Added the What to Include section. Enhanced the Signals section to cover reentrancy and stack overflow. Made minor editoral changes. 2019-02-13 Made minor editoral changes. Added a new footnote to the Signals section. 2019-02-12 First posted.

Summary On an M2 Max (macOS 26.5.1, 25F80), WindowServer intermittently stops checking in with the userspace watchdog ("hung 40/80 seconds since last successful checkin") and the machine resets. The part I'm asking about: since ~2026-06-17 the wedge no longer ends in a normal panic-reboot — it escalates to recoveryOS and forces a full Mac reactivation (local password + iCloud). Four times in 55 hours. The most recent was captured live and fired on a machine that was idle, memory-clean (1.2 GB free, flat swap, no Jetsam), with the underlying IOKit power-assertion count plateaued — so this is not resource exhaustion at the moment of the wedge. It reproduces under a heavy third-party workload (an Electron app's per-session process fan-out, tracked separately by the vendor). I'm not asking Apple to fix that app — I'm asking about the OS behaviors that turn "an app uses a lot over many hours" into "the owner is locked out pending iCloud reactivation." Apple-side vs app-side (so this isn't dismissed as a third-party issue) Apple's — and these should hold regardless of any app, because no userspace workload should be able to cause them: A userspace WindowServer watchdog timeout escalating to a firmware/recoveryOS reset that invalidates the boot policy and demands iCloud reactivation. On disk, the four 06-18→06-20 events have the WindowServer watchdog .spin/.ips but no panic-full and no ResetCounter — they did not take the normal panic-reboot path. The watchdog resetting the whole machine instead of restarting the wedged compositor ("WindowServer has not exited since first loaded"). WindowServer/SkyLight degrading cumulatively under sustained use so the wedge fires even when the machine is currently idle and memory-clean (below). IOKit never reclaiming RootDomainUserClient (IOPMrootDomain) registrations — they accumulate unbounded and clear only on reboot, and the dominant holders are Apple's own daemons (apsd, WebThumbnailExtension), not the app. App-side (separate tracker): unbounded per-session MCP process fan-out + an Electron footprint + a held NoIdleSleep assertion forcing sustained display-on operation. That controls how fast you reach the degraded state; the OS controls whether reaching it is a graceful degrade or an owner-lockout. Event 4 shows the OS failure with no resource exhaustion present at all. System MacBook Pro 14" (Mac14,5), M2 Max (T6020), 38-core GPU, 32 GB — a high-end, fully capable machine I had essentially never needed to reboot before this; it now forces a reactivation roughly once per day of use. macOS 26.5.1 (25F80), kernel xnu-12377.121.6~2 (Darwin 25.5.0). FileVault on, no third-party kexts, 161 GB free disk. Same kernel build as 25F71 — the update didn't change it. Signature userspace watchdog timeout: no successful checkins from WindowServer (0 induced crashes) in 120 seconds WindowServer has not exited since first loaded service: logd / opendirectoryd / configd — last checkin: 0 seconds ago service: WindowServer — last checkin: 120 seconds ago Panicked task ... watchdogd; KEXT backtrace: AppleARMWatchdogTimer -> AppleARMPlatform Compressor Info: NN% (OK) ... 0 swapfiles <-- memory-clean Only WindowServer is stuck; logd/opendirectoryd/configd check in normally. Pre-reset spindumps show ws_main_thread off-CPU ~59 s, wedged in SkyLight → QuartzCore CA::Transaction::commit / CALayer render-commit. Two spindumps per event (the 40 s/80 s checkpoints before the 120 s reset). Timeline & the escalation point (verifiable on disk by panic-full/ResetCounter presence) Normal panic-reboots (panic-full + ResetCounter written): 06-15 22:24 (~6.2 h uptime), 06-16 11:39 (~13.2 h), plus 06-14 / 06-15 16:07 / 06-16 20:08. Latest panic-full on disk = 06-16 20:08. Escalated to recoveryOS reactivation (NO panic-full, NO ResetCounter): # When WindowServer uptime at wedge state R1 06-18 01:23 ~27.6 h (99,278 s) R2 06-18 19:53 ~18.4 h (66,201 s) + Jetsam pressure R3 06-19 15:30 ~19.2 h (68,991 s) R4 06-20 08:19 ~16.7 h (60,180 s) idle, 1.2 GB free, leak plateaued 583 Uptime = WindowServer-process uptime from the .ips "M checkins since K seconds ago" field (the coarse uptime JSON field — 99000/66000/69000/60000 — corroborates). Time-to-wedge is not a fixed interval — it ranges ~6–28 h and scales inversely with GPU/compositor load; the invariant is sustained use, not a clock value. After 06-16 there are zero panic-full and zero ResetCounter on disk — the fingerprint of the recoveryOS escalation. Decisive evidence — R4, captured live A monitor sampling every 2.5 min when WindowServer wedged (08:19, 16.7 h): 08:14 iopm=581 free=1833MB swap=3732MB load=2.88 08:19 iopm=583 free=1192MB swap=3724MB load=3.03 <-- watchdog spindump written Idle (load ~3), 1.2 GB free, flat swap, no Jetsam, the IOKit power-assertion count plateaued at 583. Nothing to exhaust — it still wedged and escalated to reactivation. The trigger is cumulative WindowServer/SkyLight state, not the resource level. The leak (an aggravator) RootDomainUserClient/IOPMrootDomain clients climb without bound (baseline ~120 → 583–923 here). Dominant holders are Apple daemons (live ioreg walk 2 min pre-panic: apsd 228/596, then Safari/WindowServer/powerd/loginwindow). Killing the top creating process does not reclaim them (ioclasscount 526→526) — kernel-orphaned, reboot-only. Per R4 the leak is an aggravator, not the threshold (583 wedged; 923 had not earlier). Ruled out Hardware (survived 25F71→25F80, same kernel; peripheral + driver removal); memory exhaustion (R4 and others memory-clean); a fixed clock (load-dependent, 6–28 h); an iopm threshold (R4 plateaued at 583). Questions for Apple engineering Why does a userspace WindowServer watchdog timeout escalate to recoveryOS + forced reactivation (boot-policy re-verification) instead of a normal panic-reboot? What invalidates LocalPolicy / triggers Activation-Lock re-verification on this path? What in WindowServer/SkyLight degrades cumulatively over sustained use so a render-commit can't complete within the watchdog window even on an idle, memory-clean machine? Can the watchdog restart the wedged WindowServer ("has not exited since first loaded") instead of resetting the whole machine into a reactivation lockout? Can IOKit lifecycle-bound RootDomainUserClient (IOPMrootDomain) registrations so they don't accumulate unreclaimable? Dominant creators are Apple daemons (apsd, WebThumbnailExtension). Apple Feedback FB22947849 has the per-event spindumps, .ips, the live monitor log, and a sysdiagnose. I'd most appreciate a pointer on #1 — the reactivation escalation is what turns a recoverable crash into a repeated owner-lockout.

This issue is particularly noticeable in Electron-based apps (such as VS Code, Termius and so on), where an abnormal white line appears at the very top of the window when macOS is in Light Mode. Interestingly, it behaves normal when macOS switches to Dark Mode (I have attached screenshot examples). It would be more apparent with a dark background and app is in dark theme. This bug seems to persist across multiple macOS versions. For additional context, this widespread behavior has also been documented in a VS Code GitHub issue: https://github.com/microsoft/vscode/issues/144389. Since this flaw impacts a wide range of applications, it is highly likely a systemic issue that needs to be addressed by the macOS team, rather than individual app developers. This visual glitch is quite distracting during daily use, I have submitted this issue to Apple team. I hope more people could feedback this to Apple to fix it.

We are facing an issue with Apple Pay address details while customers are placing orders on our production site. By default, the following values are being passed during checkout: First Name: ApplePay Last Name: Express Address: ApplePay Street When we manually enter these same details, our validation correctly prevents the order from being placed and displays an appropriate error message. However, on our production site, real customers are still able to successfully place orders with these exact details. Could you please help us understand: How these orders are being allowed to proceed despite the validation? Is this behaviour expected from Apple Pay ? How can we prevent orders from being placed with such placeholder address details? Please let us know if you need any additional information from our side. We have also attached an image showing the address details and the corresponding order number for reference. Thanks in advance for your support.

Hi, On iOS 26 I'm seeing a behavior with the new Liquid Glass tab bar in SwiftUI and I can't tell if it's expected or if there's a supported workaround. When I switch tabs in a TabView, the floating Liquid Glass tab bar keeps the glass appearance it derived from the previous tab's content. It only refreshes to match the newly selected tab once I scroll the new tab's scroll view — even by a single point. In Apple's own apps (e.g. Home) the bar updates immediately on tab change, which makes me think this isn't intended. I reduced it to a minimal example — no images, no glassEffect, no NavigationStack, just gradients: struct ContentView: View { enum TabID: Hashable { case blue, green, dark } @State private var selection: TabID = .blue var body: some View { TabView(selection: $selection) { Tab("Blue", systemImage: "drop.fill", value: .blue) { Page(colors: [.blue, .indigo]) } Tab("Green", systemImage: "leaf.fill", value: .green) { Page(colors: [.green, .teal]) } Tab("Dark", systemImage: "moon.fill", value: .dark) { Page(colors: [.gray, .black]) } } } } struct Page: View { let colors: [Color] var body: some View { ZStack { LinearGradient(colors: colors, startPoint: .top, endPoint: .bottom) .ignoresSafeArea() ScrollView { ForEach(0..<40, id: \.self) { Text("Row \($0)") .foregroundStyle(.white) .frame(maxWidth: .infinity, alignment: .leading) .padding() } } } } } Steps to reproduce: Run on a real device (iPhone 17 Pro Max, iOS 26.5.1, Xcode 26). Switch between the three tabs without scrolling. Expected: the tab bar's glass tint adapts to the destination tab's gradient immediately on switch. Actual: the bar keeps the previous tab's tint until I scroll the new view ~1pt. What I've already tried (no luck): Both the modern Tab API and the legacy .tabItem / .tag style — same behavior. Faking a scroll with setContentOffset (animated and non-animated) — doesn't reliably trigger the refresh; only a genuine user scroll does. toolbarBackgroundVisibility(...) and forcing a color scheme — no effect. Questions: Is this a known issue / expected behavior in iOS 26? Is there a supported way to make the tab bar re-sample its Liquid Glass backdrop when the selected tab changes (without requiring a user scroll)? I've also filed it via Feedback Assistant. Thanks! Configuration: iPhone 17 Pro Max, iOS 26.5.1, Xcode 26.

Hello, Safari on iOS is showing a “Fraudulent Website Warning” for our domain: https://doobler.ru/ We are trying to understand how to properly diagnose this and request a re-evaluation. The website has a valid HTTPS certificate and does not currently appear to be flagged by the reputation tools we checked, including Google Safe Browsing / Search Console / VirusTotal. However, some iPhone users still see the Safari warning, while others do not. What we have checked so far: HTTPS certificate is valid No mixed-content or obvious redirect issues found Google Safe Browsing does not show the domain as unsafe Google Search Console does not show security issues VirusTotal does not show active malware/phishing detections The warning appears only for some users/devices We submitted a review request through Apple’s Website Review form, but have not received any response yet We would like to know: Is there any way to confirm whether the warning comes from Apple’s own reputation system, Google Safe Browsing, or another provider used by Safari? How long does Apple Website Review usually take for Safari fraudulent website warnings? Is there a recommended process for requesting re-evaluation if the warning appears to be a false positive? Are there specific technical signals Safari checks that we should verify, such as redirects, third-party scripts, domain reputation, or brand/phishing heuristics? This is affecting real users, so any guidance on the correct escalation or diagnostic path would be appreciated. Thank you.

When working on a multi-window AppKit app, how do you identify which window instance is associated with the current breakpoint? The same question applies when using LLDB. If execution stops inside an object that can exist in more than one window, such as a shared NSViewController subclass, how do you know which window’s object you are currently inspecting? Does Xcode provide a mechanism for showing the NSWindow associated with the current view, view controller or responder while debugging? My current approach is to print object identities and compare them manually. For example, if several identical windows are open, I might print the current object and its window: print(self, #function) Then I interact with one window, make a note of the printed memory addresses in the console, switch to another window and compare the output. This works, but it feels manual. I am not dealing with different window subclasses. The windows may be instances of the same class and may contain instances of the same view controller classes. I simply want an easier way to distinguish which window instance I am debugging. Is there a recommended Xcode, LLDB or AppKit workflow for this?

What are the best practices for a painless physical watchOS debugging loop in Xcode? Debugging a standalone or companion watchOS app on a physical Apple Watch is arguably the slowest feedback loop in Apple development. Every minor code change often results in Xcode getting stuck on "Installing to Apple Watch" for minutes, or throwing a "Failed to attach" LLDB error after a long timeout. The biggest bottlenecks seem to be: The initial Symbol Copying / dyld shared cache sync: This takes forever whenever watchOS gets updated. Can these symbols be pre-cached or manually downloaded on the Mac via an internet connection rather than pulling them byte-by-byte from the watch? Slow Installation over Bluetooth: The watch often defaults to a sluggish Bluetooth link with the iPhone instead of leveraging local Wi-Fi or the direct Mac-to-Watch network tunnel. Debugger Connection Timeouts: Xcode routinely loses track of the target process before the app finishes launching on the watch. My Question: What are your recommended workflows, hidden Xcode flags, build settings, or networking setups to make physical watchOS debugging as close to the simulator experience as possible? Specifically, how do we handle symbol caching and force faster deployment pipelines?

I'm trying to track identified objects in realtime with bounding rects, with no 3D integration, but still has poor update performance. I'm trying to understand how to optimize frame updates. (I'm a new programmer) Using: Foundation, AVFoundation, ARKit, CoreVideo, Vision, CoreImage, CoreVideo with YOLOE-11s object detection currently throttled to 2fps. (target iOS, testing on 16pro) YOLOE-11S CoreML model detects objects with class labels + bounding boxes Labels are matched against ObjectCatalog.json for relevance Matched objects are promoted from blue (detected) to green (identified) Log warnings: ARSession <0x110afdb80>: The delegate of ARSession is retaining 13 ARFrames. The camera will stop delivering camera images if the delegate keeps holding on to too many ARFrames. This could be a threading or memory management issue in the delegate and should be fixed. Skipping integration due to poor slam at time: 619447.208339 vio_initialized(1) map_size(0) tracking_state_is_nominal(0) is_3dof(0) reinitialize_attempts(6) slam_mode(RegularSLAM)

In my app, I implemented a screen recording functionality. But there was an unexpected crash. 0 CoreFoundation _CFRelease.cold.1 + 16 1 CoreFoundation ___CFTypeCollectionRelease 2 ReplayKit ___56-[RPScreenRecorder captureHandlerWithSample:timingData:]_block_invoke + 148 3 libdispatch.dylib __dispatch_call_block_and_release + 32 4 libdispatch.dylib __dispatch_client_callout + 16 5 libdispatch.dylib __dispatch_lane_serial_drain + 740 6 libdispatch.dylib __dispatch_lane_invoke + 388 7 libdispatch.dylib __dispatch_root_queue_drain_deferred_wlh + 292 8 libdispatch.dylib __dispatch_workloop_worker_thread + 540 9 libsystem_pthread.dylib __pthread_wqthread + 292

There are many situations where debug breaking points are not the right tool. What I often need is a log that shows what gets called, with how much frequency, and in which order. There are so many times where I have to add print statements, re compile, re run, see that I didn't include all the print statements I needed, and repeat a couple of times. My proposal (with zero knowledge of technical feasibility), is that much like we have break points, add "print break points" for logging without modifying code. It would be nice too, if I could also, add a "timer break point", where I can tag a function definition, and every time it gets called, it's are timed. Again, no idea if this is possible, but it would be extremely helpful for me, and I'm guessing to many other devs as well. Thoughts?

open FB22712056

Hello, For the past few days I have been working on integrating a Crash Reporter called "BugSplat" to our macOS desktop app and it got me thinking, how do crash reporters work on macOS ? After days of trial and error (and claude's help) I managed to integrate it but with a different behavior than windows. On Windows: When the app crashes, the BugSplat crash report window opens and allows you to write your details and message to be sent with the crash report (along with a log file) On macOS: It displays the normal macOS' "App exit unexpectedly", to which I click dismiss. But then when I re-open the app the BugSplat crash report window appears. I asked claude if I can avoid the normal macOS dialog entirely, to which it replied: "This is by design — BugSplat macOS is a next-launch crash reporter, not an in-process one. Here's why that's intentional and unavoidable: When a process crashes (SIGSEGV, SIGBUS, etc.), macOS's ReportCrash daemon independently monitors all processes and shows the "quit unexpectedly" dialog — there's no API to suppress it. Meanwhile, BugSplat's Mach exception handler captures the crash data to disk. On the next launch, BugSplat finds that crash data and shows its dialog. This is the same model used by every macOS crash reporter (PLCrashReporter, Firebase Crashlytics on macOS, etc.). The process heap is in a corrupted state at crash time, so showing UI from inside the crashed process is unreliable." LLMs sometimes speak confidently even when they're wrong so that's why I'm asking: Is it really true that that's the normal behavior for every crash reporter? And is it really that huge of a change to overwrite the macOS dialog entirely ? Thank you in advance and sorry for the long paragraph

I want to address the missing or incomplete DirectX calls from D3DMetal and Game Porting Toolkit 3. These missing calls have in part caused issue with our porting process and we are reconsidering. Missing or Incomplete Calls DXGI_FEATURE_PRESENT_ALLOW_TEARING — IDXGIFactory5::CheckFeatureSupport — this calls has to do with how VSync is handled and some modern games require it to initialize. Currently D3DMetal return 0 maybe by design but most likely because it’s not integrated. Adding a stub that returns 1 can fix this. I’m my use case I simply Noped the check and forced it to continue. D3D12_FEATURE_D3D12_OPTIONS2.DepthBoundsTestSupported — this call is also not present. Which causes games to not initialize rendering. Thankfully this was fixed by once again skipping the check. But this is essential for water rendering. This could be one reason currently water is not rendering in our game. IDXGIOutput6::GetDesc1().ColorSpace — returns DXGI_COLOR_SPACE_RGB_FULL_G22_NONE_P709 (SDR) on external HDR compatible displays. We were able to fix this by forcing HDR to be enabled. It should return HDR support. These calls may exist but they need to be updated to return the correct values. Specifically for depth bound test you can reference MoltenVK which sets it up on top of Metal since it’s not a native feature. The water issue could be also an issue with how the shaders are compiled. But I’m unable to check because of the closed source nature of GPTK and its debuggers. What is a better way we can debug our game to see why the water isn’t rendering. Does D3DMetal have some debug options or something similar? Feedback Number FB22330617 - Missing DirectX Calls for Tearing and Depth Bound Test in D3DMetal and GPTK 3 We hope these issues are resolved quickly because we were thinking of a simultaneous release with our Windows version, but we can't ship with such large bugs.

Explanation Currently, D3DMetal’s GPU synchronization approach introduces significant compute overhead on the CPU. This specifically affects D3D12 games that use modern rendering pipelines on Apple Silicon. Specifically, I’ve tested Death Stranding 2 On the Beach for how it handles its rendering. And the results are extreme: frame times are suffering from a 42% decrease from synchronization. Although there are obviously other effects at play, such as the overhead introduced by Rosetta and Wine, both of them don’t introduce as much overhead as D3DMetal. This issue isn’t just specific to Death Stranding 2 On the Beach; most games running through D3DMetal suffer from this. Most games still seem to force synchronization to ~30 ms to reach the 30 fps amount. But it could be better with better synchronization, such as how DXMT handles it. Instead of doubling the work, it allows Metal to single-handedly track resource dependencies internally. This is in part due to the unfortunate bad mapping of D3D12 calls onto shared logic between D3D11 and D3D12. System M2 Max Mac Studio — 32 GBs — 30-core GPU macOS 26.4 Tahoe CrossOver 26.1 RC Death Stranding 2 On the Beach — Steam Assassin’s Creed Valhalla — Steam & Ubisoft Connect Thank you for your commitment. Another game that I recommend testing to really see this swell is Assassin’s Creed Valhalla. Feedback FB22426600 - D3DMetal Extereme Over Syncranization Issues

When I use Xcode 26 (0.1, 1) for debugging and hit a breakpoint, using "step over" causes the debugger to freeze at a random line of code. Clicking "Pause program execution" indicates that the line is being executed, but the breakpoint never exits, seemingly causing a freeze. The application on the simulator also becomes unresponsive. However, when I do not use breakpoints, my program runs smoothly, and debugging on a physical device does not cause any freezes. This issue only occurs with the simulator. I am using Xcode on Apple Silicon, and due to some third-party SDKs that depend on Rosetta, our app can only run on the Rosetta simulator. We did not encounter this issue when using Xcode 16.x for simulator debugging. The current situation with Xcode 26.x significantly reduces our development efficiency. What could be causing this, and is there a solution?

Hello community, I am implementing a Live Activity for my existing App Store app. The Live Activity works perfectly on the iOS Simulator, but it completely fails to appear on the physical device's lock screen. When I call Activity.request, it succeeds and returns a valid Activity ID, but the physical device's console immediately outputs the following errors from liveactivitiesd: liveactivitiesd is not entitled to specify a scene target. Defaulting containingProcess target to liveactivitiesd No asset provider bundle ID provided I have spent days debugging this and have tried every known workaround. Here is the comprehensive list of what I have already verified and attempted: Environment: Xcode: 16.4 iOS Device: iPhone 13 mini, iOS 26.3.1 macOS: Sequoia 15.6 What I have verified/tried (to avoid duplicate suggestions): NSSupportsLiveActivities: It is set to YES in the main app's Info.plist. I also tried adding it to the Widget Extension's Info.plist just in case. App Icons: The main app has a valid AppIcon set in Assets.xcassets. The Primary App Icon Set Name in Build Settings is correctly set to AppIcon. Bundle IDs: They match perfectly (com.mycompany.app and com.mycompany.app.MyWidget). Version & Build Numbers: The main app and the Widget Extension have exactly the same Version and Build numbers. App Groups & Entitlements: Checked and perfectly synced between the main app and the extension. Dummy Widget: Since it's a Live-Activity-only extension, I added a standard static DummyWidget to the WidgetBundle to prevent the known iOS 17 bug where the system ignores extensions without home screen widgets. Memory/Sanitizers: Ensured Address Sanitizer and Zombie Objects are completely disabled in the Scheme to prevent the 30MB memory limit crash on the device. Nuclear Option: Completely deleted the Widget Extension target, wiped DerivedData, restarted the Mac and iPhone, and recreated the extension from scratch. Minimal UI Test: Replaced the widget's UI with a simple Text("Test") to rule out any SwiftUI rendering crashes. Device Settings: Verified that "Live Activities" is enabled under "Face ID & Passcode" settings on the physical iPhone. Despite all of this, the Simulator works flawlessy, while the device throws No asset provider bundle ID provided and shows nothing. Does anyone know what specific condition causes liveactivitiesd to fail to find the asset provider (the parent app) on a physical device for an existing app? Are there any undocumented provisioning profile quirks or obscure Build Settings I might be missing? Any insights would be deeply appreciated. Thank you!

I have been using this block of Swift code for weeks with no problems. Then, today, every time I invoke it it fails: let openPanel = NSOpenPanel() openPanel.canChooseFiles = true openPanel.allowsMultipleSelection = false openPanel.canChooseDirectories = true openPanel.canCreateDirectories = false openPanel.title = NSLocalizedString("Open a CSV file", comment: "Open a CSV File") var result = NSApplication.ModalResponse.OK do { try result = openPanel.runModal() } catch { print("Open Panel failed: \(error)") return } if result == .OK { CSVFile = openPanel.url!.path } else { openPanel.close() print("No CSV file selected.") return } I get this message pointing to the .openModal expression: "Thread 1: Fatal error: Unexpectedly found nil while unwrapping an Optional value" It's a real head-scratcher!

Hi everyone! I’m building Delta — an app designed to rethink time, because time is literally our most valuable currency. So the core mechanic involves earning time in useful apps and then spending it on apps that are a distraction. I already have a prototype that’s being actively tested in a closed beta, but I’ve started noticing that more and more testers are reporting the same bug. “Time is being counted even when I'm not in the app I marked as useful.” I suspect that Screen Time is also tracking background time, although this behavior isn't correct for my app. Does anyone know how to track specifically those moments when an app marked as useful and used for “time-earning” is in the foreground? Additionally, I hit a wall with Screen Time and had to accept that I can’t force a user away from another app if they’re active there, nor redirect them to my app to trigger the lock screen. Because of this, I had to resort to a penalty system, which is equal to the time the user spent additionally after their time ran out. And here, I run into the same problem I described at the beginning of the post. I can’t track the background status of another app, even though I’m trying really hard... Can anyone suggest any ways I can get out of this situation, or should I keep looking for a solution, or shift toward explaining this to the user?.. (However, I’m holding out until the very end before giving up on finding a solution)

Hello, I released a new build for my app but it fails to run on iOS 12.5.8 (tested on iPad Air, iPhone 6, iPhone 5s). The launch storybard is shown, then the app stops abruptly. There is no crash log. It runs fine on iOS 13 or higher. Xcode 26.3 was showing a call stack (something with UIView) that did not include any app code. Now with Xcode 26.4 (and its new command line tools) there is an info popup with a debug metadata dump. However, I don’t intend to focus on Xcode here because it officially does not support iOS 12. It’s ok if I cannot debug, I just want the app to run on the device like the previous build did. Since there is no crash log, and the console is showing a bootstrap error, I believe my app code has not been executed and is therefore not at fault. Build 674 released on 23-Mar-2026: worked fine on iOS 12, built with Xcode 26.3 Build 675 released on 29-Mar-2026: Bootstrap error as described, with both Xcode 26.3 and 26.4 Deployment target = 12.4 Tried Instruments but it fails as soon as I hit record. In the console I found BKSProcessErrorDomain code 1. Here on the forum I found a post where the cause was no internet access but my device does have internet access. I made only very little code changes to my app between 674 and 675, no storyboard updates. I get the impression the loader does not even begin to execute my code. At this point I wonder if: some certificate has expired (see release dates above), or if something is incompatible in my main storyboard (though I did not change anything there), or the device ran out of memory (1 GB) Note: The app has 4 targets: main app target framework AU app extension intents app extension Thanks, Sven PS: Misclicked subtopic which should have been General (sorry). Here’s the redacted console excerpt: standard 22:21:13.187990+0200 SpringBoard Evaluate: making new window key: <SBMainSwitcherWindow: 0x159e5f640>, for reason: push standard 22:21:13.188303+0200 SpringBoard Removed: <FBUIApplicationSceneDeactivationAssertion: 0x283c9dfe0; reason: systemAnimation; all scene levels; hasPredicate: NO> standard 22:21:13.198299+0200 assertiond Submitting new job for "com.example.app" on behalf of <BKProcess: 0x141d15d50; SpringBoard; com.apple.springboard; pid: 48; agency: SystemShell; visibility: foreground; task: running> standard 22:21:13.198867+0200 SpringBoard Bootstrapping com.example.app with intent foreground-interactive standard 22:21:13.201136+0200 assertiond Submitted job with label: UIKitApplication:com.example.app[0x1d9f][58] standard 22:21:13.201244+0200 SpringBoard Icon touch canceled (tap gesture may still succeed): <private> fehler 22:21:13.201329+0200 SpringBoard [com.example.app] Bootstrap failed with error: <NSError: 0x283e4cd80; domain: BKSProcessErrorDomain; code: 1 (bootstrap-failed); reason: "Failed to start job"> fehler 22:21:13.201421+0200 SpringBoard Bootstrapping failed for <FBApplicationProcess: 0x15d13b3e0; com.example.app; pid: -1> with error: Error Domain=BKSProcessErrorDomain Code=1 "Unable to bootstrap process with bundleID com.example.app" UserInfo={NSLocalizedDescription=Unable to bootstrap process with bundleID com.example.app, BKSProcessExitReason=0, NSLocalizedFailureReason=Failed to start job, NSUnderlyingError=0x283e4c5d0 {Error Domain=NSPOSIXErrorDomain Code=3 "No such process" UserInfo={BKLaunchdOperation=launch_get_running_pid_4SB, NSLocalizedDescription=Unable to get pid for label UIKitApplication:com.example.app[0x1d9f][58], BKLaunchdJobLabel=UIKitApplication:com.example.app[0x1d9f][58], NSLocalizedFailureReason=No such process}}, BKSProcessJobLabel=UIKitApplication:com.example.app[0x1d9f][58], BSErrorCodeDescription=bootstrap-failed} standard 22:21:13.201507+0200 SpringBoard Adding: <FBApplicationProcess: 0x15d13b3e0; com.example.app; pid: -1> standard 22:21:13.201606+0200 SpringBoard <FBApplicationProcess: 0x15d13b3e0; com.example.app; pid: -1> exited. standard 22:21:13.202002+0200 assertiond Unable to get pid for 'UIKitApplication:com.example.app[0x1d9f][58]': No such process (3) fehler 22:21:13.202145+0200 assertiond Failed to start job with error <NSError: 0x141e1aba0; domain: NSPOSIXErrorDomain; code: 3; reason: "No such process"> { description = "Unable to get pid for label UIKitApplication:com.example.app[0x1d9f][58]"; failureReason = "No such process"; userInfo = { BKLaunchdJobLabel = UIKitApplication:com.example.app[0x1d9f][58]; BKLaunchdOperation = launch_get_running_pid_4SB; } } standard 22:21:13.202238+0200 assertiond Deleted job with label: UIKitApplication:com.example.app[0x1d9f][58] standard 22:21:13.202804+0200 SpringBoard Removing: <FBApplicationProcess: 0x15d13b3e0; com.example.app; pid: -1> standard 22:21:13.221231+0200 SpringBoard Application process state changed for com.example.app: <SBApplicationProcessState: 0x28336f0a0; pid: -1; taskState: Not Running; visibility: Unknown> standard 22:21:13.221566+0200 SpringBoard Process exited: <FBApplicationProcess: 0x15d13b3e0; com.example.app; pid: -1> -> <FBApplicationProcessExitContext: 0x283e37b10; exitReason: (none); terminationReason: (none)> { stateAtExit = <FBProcessState: 0x28337c760; pid: -1; taskState: Unknown; visibility: Unknown>; }