iOS 11 and macOS High Sierra added support for Ogg Opus audio codec, but in the CAF container format.

Thanks for contacting us. This behaves as expected currently.

More time is needed to resume playback if the AirPods switched over to the iPhone. 100-200ms delay in playing the video + 150-200ms audio device latency + rerouting to MacBook lines up with this.

We will continue to look into improvements in this area

Please close this feedback report, or let us know if this is still an issue for you. Thank you.

apple, please fix this

It's been, oh 6 years. I know that you mentioned your ticket was closed due to it being a duplicate of another reported issue. Do you know where to find the original ticket? I would like to know what happened. I am coming from https://macmule.com/2015/11/08/ditto-operation-not-permitted-from-sip-protected-locations-on-el-capitan/

Thanks!

While not mentioned in macOS 11.3 release notes, I've retested this issue on macOS 11.3 and it has been fixed.

It looks like Apple finally fixed this in 11.4 Beta 1 20F5046g:

• (Beta 1) Setup Assistant no longer skips Location Services when account creation is skipped.

From limited testing I can confirm this. I am going to continue testing until 11.4 final release. If the problem doesn't come back I will consider issue resolved.

The problem also occurs with derived attributes whose derivation expressions are different from now() (i.e. @count)

Looks like 11.3 RC (20E232) doesn't fix DSC either :(

"Potential fix identified - For a future OS update"

No news from Apple. Apple is aware of a total of affected 7 users now.

iOS 13.5 Simulator (iPhone 11 Pro) - works. iOS 12.1 Simulator (iPhone SE 1st gen) - works.

This problem appearing only when I start UITests, but UnitTests work fine...

How do you provide access to Example app classes if you: - Remove following line from the generated unit test "@testable import Example"

@Thomas.DDelgado - I thought of a workaround that doesn't use #if DEBUG and answered the question on StackOverflow: https://stackoverflow.com/questions/63078880/why-does-archive-fail-if-there-is-code-for-swiftui-previews-in-the-preview-conte

Apple has responded fairly quickly, asking me to provide device logs when this issue occurs. As it does not happen on my own devices, I am asking my users for their permission to share their email with Apple so they can get in touch with them to investigate.

(Of course I could try to make the users gather the logs myself but it wouldn't make sense to have a conversations with 3 nodes in series when I'd merely forward emails back and forth between the user and Apple instead of them talking directly to each other)

On April 4 I have provided them with the first contact and haven't heard back from Apple yet. Today another user gave their permission so Apple is now aware of 2 users with affected devices.

I will keep this issue updated.

Also seeing this in the latest Xcode

iterm2 Build 3.4.4, Big Sur 11.2.3 (20D91) The problem still happens, and very annoying. I can't imagine Apple allows this bug to exist for such a long time. It doesn't help your users to have confidence in Apple product's quality.

This issue was resolved roughly 18 hours after I first noticed it. Apple responded to my open radar yesterday (7 days after the report) asking for more information, but I told them the issue was resolved already.

Not reproducible in 11.3.

How to replicate

1. Spin up a VM running 11.0 -> 11.2.2
2. Install https://support.apple.com/kb/DL2020?viewlocale=en_US&locale=en_US
3. Open Terminal and run softwareupdate --list and confirm you have a Pro Video Format update and Big Sur update available
4. Open another terminal window and run man softwareupdate
5. Open Safari
6. Run softwareupdate --download --all

Once softwareupdate has finished downloading the updates, safari will be closed but your vi session has prevented the force reboot

You can re-open Safari and rerun softwareupdate --download --all to reliably recreate the attempted force reboot

If you would like to see the forced reboot, skip step 4

1) On-the-fly encryption of received files is a magnitude faster than awaiting initial data-on-disk encryption!

2) Not only on bootable volumes, but also when choosing "Encrypt" after right-clicking an externally mounted APFS volume.

Tested a TOSHIBA DT01ACA300 3.5" SATA HDD connected via a Delock USB-C DiskStation (Item No. 64090, USB 3.2 Gen 1).

Again the data-on-disk initial encryption was only at a crippling slow 7-8 MB/sec write speed, far below what's possible I/O and CPU wise. The same HDD in both Finder and BlackMagicSpeedTest consistently achieved:

~ 170 MB/s seq. write to APFS unencrypted.

~105 MB/s seq. write to APFS encrypted.

As I still had the data source (a SD Card with up to 90 MB/s for reading sequential data) I wanted to shorten my wait time. Hence I aborted the initial encryption progress on the HDD, reformatted right to APFS encrypted, and then copied to it from the SD card at an average of 70 MB/s over the lifespan of copying 490 GB of data in files of various sizes. On-the-fly encryption was 10 times faster than had I awaited the data-on-disk encryption!

And with a different source it could even be faster, as further tests showed. I do not understand why encryption on/to the very same 3.5" SATA HDD differs:

~ 105 MB/s when receiving files from the internal SSD whose read maximum is far above that it could ever be the bottleneck.

~ 70 MB/s when receiving mixed-filesize-data from a SD card, whose maximum for sequential read I measured at ca. 90 MB/s.

~ 7 MB/s when performing encryption of on-disk-data. Why so much slower than on-the-fly encryption?