This is still the situation in latest Sequoia I think. I just started playing around with both push notifications and shared records this week, as I wanted to add collaborative features to my app. At first, I was wondering if I'm doing something wrong, because I don't get any notifications – not from my database subscriptions or even manually sent push notifications. In some cases some notifications do come through after waiting for 5-40 minutes, but it feels a little fragile and unusable for collaborating on records. However, here's the weird part: Restarting apsn from CLI or changing the network adapter will successfully transfer all of the subscriptions and manual test notifications, so it seems they are kind of working, but just won't get delivered. I'm creating a CRDT-based app and I don't want to be polling constantly, but it looks like there's no other hope.

The exact issue persists to this day. Trying to remove a localization causes an error, and changes can't be saved. This is somewhat irritating, as while my app is localized to numerous languages, updating the texts on App Store Connect for each version is an unneeded hassle.

Oh well. Here's a simple way to render a UITextView as real text into a PDF using TextKit 2. It currently supports only one text attachment per paragraph, because you apparently can't use fragment.draw(at:origin:) to display attachments. let renderer = UIGraphicsPDFRenderer(bounds: pageRect, format: format) let data = renderer.pdfData { (context) in let cgContext = context.cgContext textView.textLayoutManager.enumerateTextLayoutFragments(from: location, options: [.ensuresLayout, .estimatesSize, .ensuresExtraLineFragment], using: { fragment in let frame = fragment.layoutFragmentFrame let origin = page.textView?.frame.origin ?? CGPointZero var actualFrame = frame actualFrame.origin.x += origin.x actualFrame.origin.y += origin.y if let provider = fragment.textAttachmentViewProviders.first, let view = provider.view { // Draw a text attachment let attachmentFrame = fragment.frameForTextAttachment(at: fragment.rangeInElement.location) actualFrame.origin.y += attachmentFrame.origin.y cgContext.saveGState() cgContext.translateBy(x: actualFrame.origin.x, y: actualFrame.origin.y) view.layer.render(in: cgContext) cgContext.restoreGState() return true } else { // Draw a normal paragraph fragment.draw(at: origin, in: cgContext) } return true }) } I have no idea why Apple decided make this the default behavior in UITextView, I doubt most people would want their text views to be rasterized in PDFs.

The issue was [printOperation runOperation] / printOperation.runOperation(), which simply does not work. Instead, you need to call the strangely named runOperationModalForWindow. Although the method name refers to a modal window, you don't need to display the modal. This method makes the print operation run asynchronously (?) which modern WebKit likes more. Apple, please, please, please document this somewhere. // Create print operation NSPrintOperation *printOperation = [webView printOperationWithPrintInfo:printInfo]; // Set web view bounds - without this, the operation will crash printOperation.view.frame = NSMakeRect(0,0, printInfo.paperSize.width, printInfo.paperSize.height); // Print it out [printOperation runOperationModalForWindow:self.window delegate:self didRunSelector:@selector(printOperationDidRun:success:contextInfo:) contextInfo:nil]; You also need to have a handler method to catch the results: - (void)printOperationDidRun:(id)operation success:(bool)success contextInfo:(nullable void *)contextInfo { // Do something with your print }

Sample project: https://www.dropbox.com/s/t220cn8orooorwb/WebkitPDFTest.zip?dl=1

To anyone wondering about this: Something in view layout pipeline was changed in Big Sur or Monterey so that setting the frame of document view will cause NSClipView to invalidate its layout. I had overridden setFrame in my NSTextView, and as the frame was set, NSClipView would cause an infinite loop by calling setFrame again.

A trick which fixes this crash on all systems is to subclass NSClipView, override its layout method and never call super methods. Just don't layout the NSClipView. I'm not sure if this will cause further damage along the way, but works as a quick and dirty fix to crashes. Mileage may vary.

It appears that this is related to scaled resolution. On some systems, default scaling causes the issue, while on others you can set any scaling and never experience a crash.

Similar issue is discussed here: https://developer.apple.com/forums/thread/114579 It hints to something about changes in layer backing, but no further information is available.