Recent Comments

Open Radar 25087688: Calling setHidden:NO on a subview of UIStackView does not always show it

Still not fixed in iOS 13.

isHidden seems to be cumulative in UIStackViews, so we have to ensure to not set it the same value twice.

By martinpittenauer at May 25, 2020, 8:47 a.m.

Open Radar 33564090: Embedded images break layouts due to wrong dimensions

Problem still persists in macOS Catalina and Mail 13.4

I think I'm facing the same issue in Mail Version 13.4 (3608. on macOS Catalina 10.15.4 (19E287).

Here is a screenshot of an email that uses an embedded GIF to display a purple arrow.

As in OPs case, this embedded arrow GIF also has quite a width of 1800px so it can be scaled down with CSS. As you can see the image unexpectedly overflows its parent container to the left.

If however I link the image from an external URL instead of embedding it, the layout comes out correctly:

I too have noticed that if I keep increasing the Mail window width enough, probably so that Mail thinks its viewport is now large enough to fit the arrow GIF, the embedded image snaps in place. For this particular email and GIF, this happens at a window width of 3600px.

By davidknezic at May 24, 2020, 1:44 p.m.

Open Radar 15459068: UITextView crashes on a combination of Unicode characters

@JBernal possibly seeing the same issue, but unable to get the suspect text. It looks like the original attachment has expired; are you able to re-upload the sample? Thanks!

By jsalvador at May 5, 2020, 11:57 p.m.

Open Radar 36129961: Documentation for the NSProgress indeterminate property is incorrect

Additional clarifications

To clarify the behavior at totalUnitCount = 0, completedUnitCount = 0.


let progress = Progress(totalUnitCount: 0) progress.completedUnitCount = 0 // default print("totalUnitCount: (progress.totalUnitCount)") print("completedUnitCount: (progress.completedUnitCount)") print("isIndeterminate: (progress.isIndeterminate)") print("fractionCompleted: (progress.fractionCompleted)") print("isFinished: (progress.isFinished)")


totalUnitCount: 0 completedUnitCount: 0 isIndeterminate: true fractionCompleted: 0.0 isFinished: false

So the header (NSProgress.h) documentation is correct, except for for "Setting both totalUnitCount and completedUnitCount properties to zero indicates that there is no progress to track; in this case, the isIndeterminate property returns false". This part actually matches the generated documentation.

Some other cases of indeterminate progress:

totalUnitCount: -1 completedUnitCount: -1 isIndeterminate: true fractionCompleted: 0.0 isFinished: false

totalUnitCount: -1 completedUnitCount: 0 isIndeterminate: true fractionCompleted: 0.0 isFinished: false

totalUnitCount: -1 completedUnitCount: 1 isIndeterminate: true fractionCompleted: 0.0 isFinished: false

totalUnitCount: 1 completedUnitCount: -1 isIndeterminate: true fractionCompleted: 0.0 isFinished: false

Some cases of progress that is NOT indeterminate:

totalUnitCount: 1 completedUnitCount: 0 isIndeterminate: false fractionCompleted: 0.0 isFinished: false

totalUnitCount: 1 completedUnitCount: 1 isIndeterminate: false fractionCompleted: 1.0 isFinished: true

In summary, here's the documentation that would correctly reflect the current behavior (as of iOS 13.4.1):

Whether the progress being made is indeterminate. -isIndeterminate returns YES when the value of the totalUnitCount or completedUnitCount property is less than zero, as well as if both values are zero. When progress is indeterminate -fractionCompleted returns 0.0 and isFinished returns false. NSProgress is by default KVO-compliant for these properties, with the notifications always being sent on the thread which updates the property.

Open Radar 46977998: No audio from iMac Target Display mode

Did you ever get a fix for this? Driving me mad that I can't get audio to play through my iMac in TDM since the update to Mojave on my 2019 MacBook Pro 15". Please let me know if there was ever a solution given - did upgrading to Catalina fix this for you?

Open Radar 15209345: Please open DeviceColor / DeviceEnclosureColor

Updated Device Colors

Hello there, Sorry if it's not an appropriate place to ask but I saw the latest sheet of device colors list which only includes up until the iPhone XR. Since a lot has changed with the release of iPhone 11 Pro's, I kinly want to ask if you have the deviceEncloserColor value of the new Midnight Green color. Thanks.

By isa.gms192 at May 2, 2020, 12:03 a.m.

Open Radar 4999496467480576: iOS 11.2 sometimes AASA file is not updated after app installation/reinstallation


Same issue - it made sign in with magic link very difficult on our users. We were able to get a workaround using our web site and custom schemes to complete the login in the app. But, it provides a much worse experience when the links don't work as intended.

Open Radar 32830264: Enable eGPU Device Support in Boot Camp

Please add support for EGPU in boot camp

This is a problem that just seems to get worse with every windows release. Unfortunately this forces my next computer purchase to be a windows laptop not another macbook just so I can continue to run windows.

By greg.pringle at April 29, 2020, 3:02 p.m.

Open Radar FB7677561: AVAudioRecorder init crash

Code snippet demonstrating the problem

    let invalidUrlCausingCrash = URL(string: "")!
    let recorder = try? AVAudioRecorder(url: invalidUrlCausingCrash, settings: [:])

// Causing crash: *** CFEqual() called with NULL first argument ***
// in CFEqual.cold.1 ()
// Expecting throw error instead of a crash

Open Radar FB7663947: ImageCaptureCore: ICCameraFile requestReadData(atOffset:length:completion:) always passes empty Data object to completion block

My response to Apple:

Thank you for letting me know about the change in read size limits. I’m able to successfully read data in 4 MB chunks.

Can you confirm if the fastest way to read the entire file is to request the next chunk in the completion handler, thus ensuring that there’s at most one 4MB request in flight at a time?

Using that approach (requesting the next chunk in the completion handler), I can read a 50 MB raw image in ~0.9 seconds. [Hardware details included below.]

In comparison, when picking the same SD card using UIDocumentPicker and manually traversing the filesystem to find images, I can read the same ~50 MB raw image in ~0.002 seconds (but, with memory mapped I/O: Data(contentsOf: urlToRawImageFileOnSDCard, options: [.alwaysMapped])).

Is there a way to approximate the performance of using memory mapped I/O with ImageCaptureCore? This is important for my use case: my app is not “importing” images into a library; instead, it’s using the Vision framework to analyze images on a connected camera device, and is greatly improved by the ability to get underlying data into a UIImage as quickly as possible (regardless of where the bytes actually live).

The several-orders-of-magnitude speed difference between UIDocumentPicker and ImageCaptureCore is very significant to app responsiveness and overall utility. Unfortunately, UIDocumentPicker presents user experience challenges (it’s confusing for the user to know what files/folders to select, and it is unreliable: occasionally, enumerating the files/folders on an SD card returns no results, among other issues). ImageCaptureCore has direct camera support, notifications for added/removed devices, etc., but the performance is prohibitive for this use case.

For reference, hardware details:

  • iPad Pro (11”, 1st Generation)
  • Apple USB-C to SD Card Reader (UHS-II)
  • SanDisk 64GB Extreme Pro SDXC (UHS-I, 170 MB/s)

For posterity, when using UIDocumentPicker to read raw images from the filesystem without using memory mapping, it takes ~0.8 seconds, which is close to the performance of ImageCaptureCore’s requestReadData(atOffset:length:completion:).)

Open Radar FB7663947: ImageCaptureCore: ICCameraFile requestReadData(atOffset:length:completion:) always passes empty Data object to completion block

Response from Apple:

"Please limit read size requests to < 4MB. We will be documenting this shortly."

Open Radar 6153065: System font renders as Times New Roman in certain contexts

Found a fix!

I finally found a fix for that, at least for my use case (NSAttributedString with options [.documentType: NSAttributedString.DocumentType.html] and css)

If I set "-apple-system" it seems to use SF font:

<style type="text/css">body { font-family: '-apple-system', '\(font.fontName)', '\(font.familyName)'; font-size: \(font.pointSize)px; }</style>