Please add support. I’ve wasted hours trying to get this to work and it’s been painful.

Following up with the comment of tfonfara, we had that same problem. By investigating more we could conclude the exact details of the problem:

Product version: iOS 13.0 GM

Summary: When accessing the system font via UIFont.systemFont(ofSize:weight:), the font will often be rendered in Times New Roman instead of the expected SF font face. This occur for UITextView that render HTML as an attributed text.

Setting a CSS inside the HTML with the font family from the system font does not work either. It preserves the information about the font size, but not the family name. For all previous iOS versions (< iOS 13) is working as expected and the rendered font is San Francisco.

Failing case

1. Create a textView

1.1.Optional (set a default system font)

2.Set as its text a NSAttributedString with HTML document type.

3.Check the font family. (This is Times New Roman)

Overriding font after setting text:

1. Create a textView.

2. Set as its text a NSAttributedString with HTML document type.

3. Set UITextView's font to be UIFont.systemFont(ofSize:)

4. Check the font family. (This is .AppleSystemUIFont)

---

It looks like setting an attributed text is causing the font to be changed to Times New Roman when it does not include a NSAttributedString.Key.font. If the attributed text includes this key, the given font is used when rendering the text.

Expected Result: The font returned is in the SF system typeface, or the correct default type font (Same as for any UILabel).

Actual Result: The font returned is Times New Roman in a size that matches the size passed in.

TLDR: This is a bug, but there is not a recognizer leak, but a whole scene leak. Workaround: create another one SCNView instance.

1. That run-time check could not verify the leak because according to the internal calls there can be a lot of autoreleases triggered by a specific run loop. Please, use the Instruments to verify memory leaks.
2. What is more interesting is that I've checked this code in Instruments and the Foo was destructed, but the SCNView scene stays alive. So, your real problem is probably the whole scene, which keeps alive everything it's own.
3. What is much more interesting: this leaked scene finally deallocated (gesture recognizer deallocated too, of course) when another SCNView instance created. Just like that – you create new SCNView instance and the old one dies. Treat it as a workaround.

Adding my voice to this. Apple, please facilitate eGPUs in Windows through boot camp. I love my Mac but some software is only available on Windows and requires powerful GPUs.

https://github.com/tomaskraina/feedbackassistant.apple.com/tree/master/FB7250982-UIDocumentBrowserViewController-vs-iOS13Simulator

Any updates?

See https://github.com/rmaddy/SplitTest for the sample project that demonstrates the issue.

My guess is that the web view is updating its colors, but that this happens asynchronously and not in time for the snapshot to be saved.

Still happen on iOS 12. Any update on this?

The issue still reproduce in Xcode 10.3 (10G8)

This is an issue from the new Feedback assistant. The reference number is FB7192051

The workaround shown here proved problematic for me. An alternative workaround is to move the drawing code into drawRect and trigger a draw by setting needsDisplay to true in animateOneFrame.

Resolved in iOS 13.0 beta 8

Resolved in 11b6

+1 The problem is still there.. no sign of life?

This bug still exists as of the latest stable version of iOS/Xcode.

Reproduced using a vanilla tabbarcontroller, tabbar, and tabbar items. Just adding an image and insets. Tapping the same tabbaritem multiple times applies the inset every time (resulting in an ever smaller image)

I develop software for supercomputers, linux clusters, MacOS X and Windows. Because of the requirements of such a diverse set of targets and the fact that I write CUDA GPU code for our research, I continue to need support for NVIDIA hardware. Using a eGPU is one way to streamline our workflow to develop and test new algorithms across platforms while using my beautiful 2018 MacBook Pro. Because of the lack of support for NVIDIA and the technical requirements of getting a eGPU set up in Mojave I am strongly considering purchasing non-Apple products in the future (and I have been using Apple products since my Apple IIe in 1981). Doing so would also lead to considering changing from the entire Apple eco-system as well (iPhone, watch etc.) as technology is fine but I can't spend every waking moment tending to it's needs and lack of compatibility.

Engineering has the following feedback for you:

Thank you for you feedback. This issue has been resolved.

We are now closing this bug report.

If you have questions or comments about the resolution, please update your bug report with that information so we can respond.

https://openradar.appspot.com/27201529

Further investigation made me realize that the file attachment from Mail was failing to be imported into my app because (as the attachment was a file of the document type associated with my app) Mail had already imported it into my app's container-- specifically, into the user's Documents/Inbox directory-- when the file was shared with my app from Mail. This behavior, I found out, is described in https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW2.

Unfortunately, that "mail attachment importing into Documents/Inbox" behavior is not mentioned in any of the places that developers are initially likely to look when they add functionality for importing urls into a document-based app using UIDocumentBrowserViewController. In particular, it is not mentioned in...

(1) The "Enabling Document Sharing" article (https://developer.apple.com/documentation/uikit/view_controllers/adding_a_document_browser_to_your_app/enabling_document_sharing)

(2) The documentation for either UIApplication's openURL:options:completionHandler: method or UIDocumentBrowserViewController's revealDocumentAtURL:importIfNeeded:completion: method.

It would be good for the documentation for (1) and (2) to be updated to reflect the Documents/Inbox directory storage of files from outside the app (specifically, mail attachments) shared with the app. (It would also be good to mention in the (1) and (2) documentation that if the files at the imported urls are to be edited, they need to be moved out of the Documents/Inbox directory first.)