This is still an issue now on physical device running iOS 13.3.1. I see in the Xcode console an error stating that:

`UserInfo={_kCFStreamErrorCodeKey=8, _kCFStreamErrorDomainKey=12}}, NSErrorFailingURLStringKey=https://firebasedynamiclinks-ipv6.googleapis.com/v1/installAttribution?key=AIzaSyCfE70N7kHMaBbDAJeO75kDJ8MS3pmcsiQ, NSErrorFailingURLKey=https://firebasedynamiclinks-ipv6.googleapis.com/v1/installAttribution?key=AIzaSyCfE70N7kHMaBbDAJeO75kDJ8MS3pmcsiQ, _kCFStreamErrorDomainKey=12, _kCFStreamErrorCodeKey=8, NSLocalizedDescription=A server with the specified hostname could not be found.}`

Which might be causing the app not to launch with Dynamic Link

I created a thumbnail version of it as animated GIF: https://postimg.cc/cKPMSZ3X

My fix for this was accepted in WebKit and released in iOS 13.4

At some point the status changed to:

Resolution: Potential fix identified - For a future OS update

But Apple didn't post a comment on my report.

I noticed that it has just been fixed with the release of Xcode 11.4 with iOS Simulator 13.4

Filed FB7649434

Confirmed - disabling Automatic Proxy Configuration allows ssh to work properly again. I have updated my Apple bug report with this information - thank you, mfelliott, for identifying that!

I see this behavior on newer phones as well.

Hmm. I can't replicate this on my work Mac.

% ssh -vvv -p 8822 hostname OpenSSH_8.1p1, LibreSSL 2.7.3 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 47: Applying options for * debug1: Connecting to hostname port 8822. ssh: Could not resolve hostname hostname: nodename nor servname provided, or not known

% sw_vers ProductName: Mac OS X ProductVersion: 10.15.4 BuildVersion: 19E266

We do have a DNS proxy in place for work stuff via Umbrella.

On a personal Mac running the same OS I have the same behavior. No errors. I did notice that the DNS lookup that pops in and out of nettop is an IPv6 one.

This line is being added because the system is asking for "Add More Information"

In my case, tuning off my Automatic Proxy Configuration with PAC file stops this weird behavior. Even running with a completely empty .pac file causes this issue.

Go to Device > Screenshot

🎉

This still happens on iOS 12.

But, It seems that this doesn't happen on iOS 13.

What was the word from Apple about this issue upon closure?

Easy steps to reproduce: 
1) Open keyboard settings and enable predictive text and auto-correction features. It’s necessary for reproducing the crash. 2) Run Bumble app and open any chat with another user. 3) Type something till the moment when text replacement variants appear, and the text you entered becomes selected. 4) Switch to the application launcher and kill the Bumble application as fast as possible.

The crash happens whilst the application is terminating.

Solution: setting WKSnapshotConfiguration’s afterScreenUpdates property to NO

WKSnapshotConfiguration *configuration = [WKSnapshotConfiguration new];
if (@available(iOS 13.0, *)) {
configuration.afterScreenUpdates = NO;
}

Having one machine to handle everything would be fantastic. eGPU support in Boot Camp is important to working in a lot of CAD/engineering software in Windows due to needing to use a certified graphics card. Ideally some of this software would have macOS versions, but that seems unlikely. Having eGPU support would at least allow us to use one computer to run all macOS software as well as all Windows software.

I am not too sure about the #available macro-looking thing resolves, but more relevantly, CIPerspectiveCorrection is an obj-c protocol, not a class.

Also this exception cant be handled with @try{}@catch

Mentioned here:

https://stackoverflow.com/questions/47474127/catching-exceptions-generated-within-dispatch-once-blocks

cell.layer.opaque = true; cell.layer.hidden = false;

I made a small investigation with Hopper and found interesting stuff. Within [UIPredictionViewController isVisibleForInputDelegate:inputViews:] call there is check against the bitmask 0b100100110000. Each bit in this mask corresponds to a value of UIKeyboardType. Thus predictions are disabled for the following types: UIKeyboardTypeNumberPad UIKeyboardTypePhonePad UIKeyboardTypeDecimalPad UIKeyboardTypeASCIICapableNumberPad Obviously, predictions were disabled for all numerical keyboards and I guess phone pad was added accidentally too. Everything works fine when I swizzle initial function to return "true" in case of phone keyboard, as expected I'm having my phone suggested above the keyboard.