After upgrade to iOS 26.4, averagePowerLevel and peakHoldLevel are stuck -120

We're having the same issue with our camera app.

Hello Giroux, miamitwinz,

This is an issue we're aware of (FB22272504), but we're not aware of any recommended workaround so far. If you find something that helps you avoid the issue, please share it with the community by posting it here.

Even though we're aware of this issue, we still encourage you to open a bug report, and post the FB number here once you do. The specific info you include your bug report might help our investigation, and filing the bug report you to get notified when it is resolved.

Bug Reporting: How and Why? explains how you can open a bug report.

Thank you for reporting,

Richard Yeh  Developer Technical Support

Until this is fixed, one workaround that's worked for me in a similar situation: bypass AVAudioRecorder's metering entirely and compute levels from the raw PCM buffers using AVAudioEngine.

Install a tap on the input node and calculate RMS manually:

let inputNode = audioEngine.inputNode
let format = inputNode.outputFormat(forBus: 0)
inputNode.installTap(onBus: 0, bufferSize: 1024, format: format) { buffer, _ in
    guard let channelData = buffer.floatChannelData?[0] else { return }
    let frameLength = Int(buffer.frameLength)
    var rms: Float = 0
    vDSP_measqv(channelData, 1, &rms, vDSP_Length(frameLength))
    let avgPower = 10 * log10f(rms)
    // Use avgPower instead of averagePowerLevel
}

This gives you the same dB scale as averagePowerLevel without depending on the broken metering path. vDSP_measqv from Accelerate is efficient enough for real-time use — I've measured under 0.1ms per buffer on A14 and later.

One caveat: make sure you're calling audioEngine.prepare() before start() on 26.4 — I've seen cases where skipping prepare() causes the input node format to report 0 channels, which would also result in silent buffers.

I can confirm that this is impacting one of my apps that uses 'averagePowerLevel' to display audio meters to the user from an AVCaptureDevice. It worked perfectly fine in iPadOS 26.2, now in 26.4 it reports -120 dB all the time meaning the audio meters do not work. Still works okay on iOS 18.7.3.

I do hope Apple can push a fix in the 26.4.1 update or that this issue is addressed in 26.5. I don't really want to update my entire audio pipeline with an if #available(iOS 26.4, *) { } code block.

I already use the Audio Engine for a number of other things and don't want to break anything in the existing workflow, thus I am hesitant to implement @eddiewangyw's solution. It's likely best for user's to go without audio meters for the time being and wait for Apple to push a fix for this in a future software update.

We are experiencing the same issue too in our video recording app. We use the averagePowerLevel and peakHoldLevel to provide the user with volume meters and this aspect of the app is now broken.

Thanks for the possible workaround, eddiewangyw. However, I am not super keen on implementing a workaround - it might break other things since the audio and video capture aspects of our app are working fine.

It would be good to know if this issue is being considered for fixing in iOS 26.5 or earlier. It does not seem to have been fixed in the existing 26.5 beta.

I have raised a feedback report as FB22435501.

Thanks.

I just saw that iPadOS 26.4.1 came out, I upgraded and can confirm that this update does not fix the issue.

Handy to know that this has not been addressed in the 26.5 Beta either.

Currently I am advising people to stay on iOS 26.3 if they use or rely on the audio meters in any way.

Now that iPadOS 26.5 is available to the public I have tested this again.

Unfortunately this update did not fix the underlying issue with AVFoundation.

'averagePowerLevel' still returns -120 all of the time which breaks any audio meters that are built around that.

Since WWDC has just started and all focus will now shift to iOS 27, I am worried that this will remain broken in iOS 26.

We have implemented a workaround based on the sample code above, however it took a lot of work to make it behave like the original volume meters and even now it is only an approximate match and involved compromising some other parts of our app. I would like to keep this solution in place for the shortest time possible and return to the original API once fixed.

Can someone from Apple please confirm that this is being investigated with a view to fixing it in iOS 26, or share any other info you can on this issue. This breakage has real, negative affects on the usefulness of our app for our users, as well as being bad publicity for iOS and Apple in general.

Thanks

Thank you everyone for reporting this problem. It has been fixed in the seed build of iOS 27, and it will also be fixed in the next seed of the iOS 26 G release (23GXX).

Great. Thanks for the reply. That is good news.

Looking forward to the fixed version of iOS 26.