To reproduce: Create a new standard iOS project and add a Widget extension to it. Download an SVG from here: https://pixabay.com/vectors/flourish-decorative-ornamental-3166119/ Add the SVG asset into Assets.xcassets. Replace the line Text(entry.date, style: .time) with Image("flourish-3166119").frame(width: 20). When running the extension, I get Thread 1: EXC_RESOURCE RESOURCE_TYPE_MEMORY (limit=30 MB, unused=0x0). Notice that the asset is only 8k but something in the rendering of the SVG into bitmap cause a memory spike. I tested this with Xcode 13.0, iOS 14.4.1 Xs MAX device. Is there a way to overcome this, or should I dump SVG and pre render the images for x2 and x3 scale factors and call it a day? Edit: Just to clarify, the issue happens with only 1 entry as well. I attached the full source for reference. Demo convenience:

If the audio buffer is AVAudioPCMBuffer, it is possible to write it into a file using AVAudioFile's writeFromBuffer:error: method. How should plain AVAudioBuffer be handled? In my specific case, I get this buffer from the callback of AVSpeechSynthesizer's writeUtterance:toBufferCallback: In fact the documentation says: // Use this method to receive audio buffers that can be used to store or further process synthesized speech. // The dictionary provided by -[AVSpeechSynthesisVoice audioFileSettings] can be used to create an AVAudioFile. - (void)writeUtterance:(AVSpeechUtterance *)utterance toBufferCallback:(AVSpeechSynthesizerBufferCallback)bufferCallback API_AVAILABLE(ios(13.0), watchos(6.0), tvos(13.0), macos(10.15)) ; But I don't know how exactly AVAudioFile can be used if the buffer is not guaranteed to be an AVAudioPCMBuffer.

I downloaded Xcode 12.5 Beta and now an existing project does not compile with errors telling I can't use Class as a key in NSDictionary. Cannot initialize a parameter of type 'id<NSCopying>  _Nonnull const __unsafe_unretained' with an rvalue of type 'Class' I have assumes so far that while Class does not conform to NSCopying, it is safe to use as a dictionary key because it implements copy and copyWithZone:. Did anything change with that regard in the compiler/runtime shipped with Xcode 12.5? Is it safe (and endorsed practice) to cast to id<NSCopying> to silence these errors?