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.

There isn't a valid initializer for AVAudioPlayer that has no parameters. Use one of the documented ones:https://developer.apple.com/documentation/avfoundation/avaudioplayer

In principle, nothing stops you using library built with ARC with your own code that uses manual memory ref-counting (MMR). If you properly handle the ownership of objects used by the SDK, there should be no leaks (apart from bugs in the SDK!).It's worth putting some effort into trying to work out why the leaks are happening. For example, if you create an object in an SDK class using alloc/init, it's returned with a +1 ownership count, and your code must release it when your reference goes out of scope. In other words, it should make no difference to your code whether the SDK uses ARC or not.You can also look at the old transition guide:https://developer.apple.com/library/archive/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.htmlfor guidance on specific issues, if you're being affected by an odd case.Finally, you can use the Allocations tool in Instruments to capture and examine the allocation history of leaked objects, to try to find out where unmatched retains are coming from. (You can try the memory graph debugger in Xcode, but it has a reputation for being unreliable.)