I don't really understand what you're trying to do in doLoad:controller:. It looks like your MyViewController instance was created as an object in MainMenu.xib, so it's not going to be in a window, and doesn't have well-defined geometry. Setting its root view width and height probably has no effect. Or am I completely missing something?

You have to think of the order of execution, when you use asynchronous patterns. The order of execution here is:a. Line 3b. Line 5, which causes line 7-12 to be executed "later", continuing on for "now" with…c. lines 15-23d. (later) lines 7-12What you'll need to do, basically, is move lines 15-23 inside a closure that's dispatch back to a background queue/thread after the stuff on th main thread is done.

I have no idea what the diagram in that hapticSharpness link means, but from what I remember of the WWDC video, sharpness represents the rapidity of the transition between onset and decay. You can get an idea from the graphic in the video here:https://developer.apple.com/videos/play/wwdc2019/223/?time=359

Because Xcode 11.3.1 only has the iOS 13.2 SDK, not 13.3. It's not clear if that was an oversight, or if there weren't any SDK changes in 13.3.So, just set your deployment target to 13.2, and you should be good to go.

This isn't the way to do it. For a start, what you've done is more or less exactly the same as executing the code in the closure on the main thread, simply: self.functionA() self.functionB()Dispatching them asynchronously just delays the start of functionA slightly, and nothing else.Presumably, functionA actually has some asynchonous effect of its own. If it didn't it would do all its works synchronously, which would block the main thread, and you'd be raising that issue instead. So, currently, you're starting functionB after functionA has begun its work, but not finished. That means functionB has no data to work with, and so does nothing. (There's some guesswork in all of that, so the details might not be right).Therefore, I'm guessing, what you really want is to start functionB after functionA's incomplete work has actually finished. For that, you need an asynchronous pattern, where (for example) functionA takes a completion handler closure, which it executes it when its work is done: self.functionA(completionHandler: { self.functionB() })or, a bit more attractively, with trailing closure syntax: self.functionA { self.functionB() }Again, I'm guessing at things you didn't give any details on, but an asynchronous pattern sounds like the sort of thing you need.

It throws an Obj-C exception (NSException), which is a kind of app crash, not a Swift exception, which is a kind of error.You can't handle NSExceptions in Swift, and (current best practice) you shouldn't try. It's generally correct to let the app crash. Note that segue identifiers are static in a storyboard, so it shouldn't be necessary to test for the existence of a segue at run time.