PDFKit in macOS 27 renders unwanted comment bubble icons alongside text markup annotations (highlights)

Hi everyone,

Following the update to macOS 27, we have observed a regression/behavioral change in PDFKit regarding how markup annotations (particularly highlights, underlines, and strike-outs) are drawn.

Issue Description Whenever a markup annotation (PDFAnnotationSubtypeHighlight / PDFAnnotation) has associated text or contents, PDFKit now automatically renders a yellow speech-bubble / comment note icon directly adjacent to the highlighted region in the margins.

Visual Symptom: Instead of a clean text highlight overlay, the document margin is immediately cluttered with comment bubble icons for every single highlighted passage or line.

Impact across applications: Because this rendering occurs within the native PDFKit.framework rendering layer, rolling back host applications to earlier releases does not alleviate the issue. It affects both system PDF rendering and third-party PDFKit-based viewers (such as Skim).

Expected Behavior: Standard highlight and markup annotations should display their color fill over the text without forcing an external comment icon unless an explicit pop-up / sticky note annotation is requested.

Third-Party Tracker Reference This issue is actively being investigated and tracked in the Skim open-source project here:

https://sourceforge.net/p/skim-app/bugs/1617/

Questions for DTS / Community: Is there an undocumented flag, preference, or API attribute on PDFAnnotation / PDFView in macOS 27 to disable or hide these automatic markup pop-up icons globally or per annotation?

Is this change intentional as part of a redesigned annotation interaction model, or is it an unintended side effect of internal note rendering changes?

Any workarounds or insights would be greatly appreciated.

Answered by DTS Engineer in 906870022

Thanks for the report. Your description of the symptom was specific enough to rebuild here from scratch.

There is one public control and it is not selective. PDFPage.displaysAnnotations is documented as turning "on or off the display of annotations when the page is drawn", which suppresses every annotation on the page rather than just the icon. I did not find any per-annotation property, or any setting on PDFView, that targets the icon on its own.

Measured on macOS 27.0 (26A428), the icon appears as soon as contents is set. I tried highlight, underline, and strikeOut annotations. Each one carrying contents drew an icon, and the ones with contents left nil did not. An empty string still counts: a highlight with contents set to "" drew the icon anyway, so it tracks the property being set rather than there being any comment text.

Two details may help you check this against your own documents. The icon takes the annotation's own color. Setting yellow, magenta, green, and orange across those subtypes produced icons that matched each annotation. That places the drawing in the markup annotation itself rather than in a separate note annotation in the file. Separately, setting shouldDisplay to false on a popup annotation linked to the highlight did not suppress the icon.

Please consider filing a bug report about this so our engineering teams can investigate this issue. A resolution may involve changes to Apple's software. If you post the Feedback number here I'll check the status next time I do a sweep of forums posts where I've suggested bug reports.

Bug Reporting: How and Why? has tips on creating your bug report.

Thanks for the report. Your description of the symptom was specific enough to rebuild here from scratch.

There is one public control and it is not selective. PDFPage.displaysAnnotations is documented as turning "on or off the display of annotations when the page is drawn", which suppresses every annotation on the page rather than just the icon. I did not find any per-annotation property, or any setting on PDFView, that targets the icon on its own.

Measured on macOS 27.0 (26A428), the icon appears as soon as contents is set. I tried highlight, underline, and strikeOut annotations. Each one carrying contents drew an icon, and the ones with contents left nil did not. An empty string still counts: a highlight with contents set to "" drew the icon anyway, so it tracks the property being set rather than there being any comment text.

Two details may help you check this against your own documents. The icon takes the annotation's own color. Setting yellow, magenta, green, and orange across those subtypes produced icons that matched each annotation. That places the drawing in the markup annotation itself rather than in a separate note annotation in the file. Separately, setting shouldDisplay to false on a popup annotation linked to the highlight did not suppress the icon.

Please consider filing a bug report about this so our engineering teams can investigate this issue. A resolution may involve changes to Apple's software. If you post the Feedback number here I'll check the status next time I do a sweep of forums posts where I've suggested bug reports.

Bug Reporting: How and Why? has tips on creating your bug report.

PDFKit in macOS 27 renders unwanted comment bubble icons alongside text markup annotations (highlights)
 
 
Q