Post not yet marked as solved
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?
Post not yet marked as solved
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.
Post not yet marked as solved
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
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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
Post not yet marked as solved
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.)
Post not yet marked as solved
What is the actual type of the value that you're putting into the dictionary? If you set the value of key "points" to (for example) an UInt8 value, retrieving it as an Int will fail exactly as you've shown.That's because Swift doesn't do implicit numeric conversions for you.
Post not yet marked as solved
Sounds like you have exactly what you need for a bug report.It's possible that it's the documentation is wrong, rather than the APIs. Most of those authorization APIs expect your code to ask for authorization explicitly, if the current state is "not determined".Either way, a bug report should be your next step.
1. Why is it illegal in Swift to write a substring expression using integers, i.e. string[1..<10]?There is no simple Int-based subscripting for String because in Swift, by design, String is a Collection, and types conforming to Collection are required to make performance *guarantees* for many of their methods.Subscripting, for *all* types conforming to Collection, must be constant-time — it should take about the same length of time to look up any element, and the lookup mustn't depend on the number of elements in the collection. String can't provide this guarantee for Int indexes without a lookup table (from Int indexes to character positions, basically), and that would dramatically increase the memory used, as well as slowing down operations that change a string's contents.There is currently a proposal that will allow Int-offset-based subscripting with a more verbose structure. This is a compromise to provide a better syntax, but which avoids implying random access. If this proposal is accepted (it probably will be), then your example would be written string[.start + 1 ..< .start + 10]. You can also offset relative to the end of the string, too.2. Why does a substring operation return a Substring object instead of a String object?Claude already gave you one of the answers (because substrings use the same String.Index values as the underlying String). The other reason is that it's too expensive to create a separate String for all substring operations, because that would require part of the underlying data to be copied. That would likely cause memory allocations as well as copying overhead. Substrings share the underlying string storage, so its trivially cheap to construct a Substring.If you want to create a separate string, you can easily do that by writing String(someSubstring), but in many use cases you won't need to do that.>>Apple saw fit to release something as a finished product but then make major breaking changes to it every year for four years in a rowI really wish people wouldn't say things like this. It's not really true. Apple never presented Swift as a "finished product", and told developers it would change. In most cases, the year-by-year changes were accompanied by converters that updated your code for you.It is true that for several years in a row (until Swift 4), Apple made changes that required developers to spend time converting their code every year, and that was certainly painful, just not as dire as you suggest. FWIW, the bar for source-breaking changes in Swift is currently *very* high, in some cases to the detriment of the language's future.>>I worked as a C and C++ developer for more than 20 years, and never in that time (or since, as far as I know) has anyone changed the languages in a way that breaks older codeC has been around since the 1970s, and *of course* the C standard has changed in source-breaking ways in the last 20 years. It hasn't changed *much*, because the churn and standardization in the language happened *more than* 20 years ago, when it was new. Kinda like Swift is now. C++ has been around since the late 1980s, and there was lot of change there too, also more than 20 years ago.
Post not yet marked as solved
What is the value of recordingSession.recordPermission? The documentation for requestRecordPermission says that it doesn't prompt if it doesn't need to, so maybe it doesn't need to. (Maybe it never needed to, if permission was granted on the iPhone. I don't know if the watch and phone permissions are coordinated like that, but maybe they are.)
Post not yet marked as solved
I agree the documentation is kinda bad.On the Mac, the app is installed, but tucked away. KMT gave you the path, but the easiest way to find it is to use Spotlight (Command-Space, type "feedback"). If you've ever installed a macOS beta (from this page: https://developer.apple.com/download/), then an alias to the app will be in your Applications/Utilities subfolder, and the icon will also be put in your dock.On iOS, the app isn't installed at all unless you install an iOS beta (same page as above).In one way, it's easier just to use the web page, except that the apps capture a sysdiagnose for you. Getting a sysdiagnose on iOS is a bit hard to get right, so it helps to use the app to get it.
In a way, it seems to be an architecture mismatch between macOS and iOS audio. On iOS, there can be multiple audio routes (that is, possible paths from input to output ports). On macOS, there is only one audio route, from the user's selected input device to the user's selected output device. There's no system reason to switch port on macOS, unlike iOS, where the system switches between ports a lot.In a way, that's fine on the macOS side as far as it goes — it makes sure the defaults that are actually used are the defaults that the user chose. However, it would be helpful if individual inputs and output devices were also available as input and output ports in Catalyst. There's a similar problem with AVAudioEngine's input and output nodes under Catalyst.I think this mainly represents a lack of foresight (or perhaps time ran out before these niceties could be added). File a bug report. It does no harm to nudge the audio engineers in the right direction. 🙂
Post not yet marked as solved
How did you decide that it was the first line of that method where the crash happened? Are you sure this was line 714 of GroupTableViewController.swift when you built the version of the app that this user has?The backtrace is showing the error at byte offset 272. That seems kinda big for any machine-level instructions in such a simple line of code. Of course, there may be more going on than is obvious from the limited information shown here.
