“Popping Sound”

It sounds like you're encountering an issue with the ReLU activation function on the Mac M4 using TensorFlow-Metal. Let's go through a few steps to troubleshoot and potentially resolve this issue: Potential Causes and Solutions TensorFlow-Metal Version Compatibility: Ensure that you are using the latest compatible version of TensorFlow-Metal. Sometimes, bugs are fixed in newer releases. Check for updates via pip: pip install --upgrade tensorflow-macos tensorflow-metal ReLU Implementation in Metal: TensorFlow-Metal might have a different implementation of ReLU that doesn't handle edge cases like floating-point precision issues with exactly zero values. You could try a workaround by slightly offsetting zero values before applying ReLU: def custom_relu(x): return tf.maximum(x, 1e-10) model = tf.keras.Sequential([ tf.keras.layers.Input(shape=(10,)), tf.keras.layers.Dense(5, activation=custom_relu) ]) Environment and Configuration: Double-check that TensorFlow is correctly configured to use Metal. You can

Based on the error messages you're encountering in Xcode, it seems like there are two main issues to address: nwprotocolinstancesetoutputhandler Not calling removeinput_handler: This error typically indicates a problem with how network connections are being managed using Apple's Network framework. Specifically, it suggests that an output handler was set on a network protocol instance without a corresponding removal of the input handler, which could lead to resource leaks or crashes. Steps to Resolve: Ensure that every call to nw_protocol_instance_set_output_handler is matched with a call to nw_protocol_instance_remove_input_handler when you're done with the connection or when the connection is closed. Review the lifecycle of your network connections to ensure handlers are properly managed, especially in asynchronous or error-prone paths. Check if there are any closures or network operations that might inadvertently leave handlers dangling. com.apple.modelcatalog.catalog sync: connection error: This error poin

We do not use CallKit. The call is handled entirely using a custom in-app call UI. This is a bad idea. It's going to significantly complicate your app’s audio logic and, most practically, it means that ANY other incoming call from ANY CallKit app will IMMEDIATELY interrupt your app’s audio. It's also going to allow a variety of other odd edge cases which will be similarly disruptive (for example, now playing activity can interrupt your calls). The PRIMARY reason CallKit was originally created was so the system could properly arbitrate and manage the audio of VoIP apps, preventing all those edge cases. However, the exact rules and thresholds for these violations are not clearly documented, so I’d like to ask a few questions to better understand the expected behavior. The basic policy rule is that your app is not required to report a call if it either: Is already on a call. Is in the foreground. However, in practice, both of those criteria are much harder to implement than they seem.

I actually don't have a strong opinion about file reference URLs vs. file path URLs, but from my perspective in the sample, it is clear after the second call to createDirectoryAtURL:..., Yes, and to be clear, that is very much a bug. More specifically, every URL should either be a file reference URL (in which case you'd reference the object in the trash) or a file path URL (in which case you'd reference the original path). You're ending up with a URL which is a mix of both, which is simply wrong. I'd need to test on older OS's, but I suspect this is actually a new bug, possibly introduced in Swift Foundation[1] [1] Much of the Objective C version of Foundation is actually written in Swift now. Yeah. You can't even create a file without a path, so there is that. Unfortunately, yes. I'm not claiming my radical idea is something that will ever be (again) implemented. Keep in mind that I'm not claiming that macOS is wrong about paths; I think EVERY operating system is wrong about paths. Well, every operating syst

[quote='817887021, kappie, /thread/817887, /profile/kappie'] Both produce: Warning: unable to build chain to self-signed root [/quote] Hmmm, that doesn’t sound good. Have you tried testing the cross-over cases? That is: Building on macOS 26.3 and trying to install on macOS 26.2 Building on macOS 26.2 and trying to install on macOS 26.3 Those will let you determine whether this is a build problem or an install problem. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hello, @TimDeWachter! I’m glad that you were able to make progress. By default, asset packs work differently for App Review than for App Store and TestFlight users. Specifically, pre-launch downloads are disabled for App Review, which mirrors the experience that an App Store or TestFlight user would see if they previously disabled background downloads on their device by going to Settings > Apps > App Store and turning off In-App Content. The setting is on by default, but users can turn it off if they choose. It sounds like you’re correctly handling that case by showing a fallback screen, but you still need to display the download size on that screen per App Review Guideline 4.2.3 (ii): If your app needs to download additional resources in order to function on initial launch, disclose the size of the download and prompt users before doing so. The easiest way to determine the download size is to look at an asset pack’s downloadSize property’s value, which is available in both Swift and Objective-

Thanks again! I think very fast actually understates how significant the performance difference is. Ha, true. In practice it seems “instant”, to the extent that on APFS, updating huge zip files is not much slower than in-place saving into a package. I don't know if anyone has ever shipped a solution that worked like this, but... it might be worth thinking about using DiskImages as a file format. Interesting! Although cross-platform compatibility might be an issue here. The replaceItem(at:...) documentation actually answers this… Sorry, I should have been more clear, although thinking about it I have been tying myself up in knots and the solution was indeed here all along. I was referring to the circumstances we were discussing before, where we don’t want to do the temp work on the same volume as the destination because the destination volume is slow. In other words, we have deliberately created the temp folder for updating our file on another volume (e.g. one that supports APFS), because the one created using

Can you share more details about your audio setup and what you're trying to investigate? It would be helpful to know what type of audio processing your app is doing, if you're experiencing any audio-related issues (like glitches or latency), and the context around when these 'Zero Time Stamp' events appear. Also, are these events occurring frequently or only in specific circumstances? Screenshots of the Instruments trace might also help us better understand what you're seeing.