Post not yet marked as solved
If I use the code super.init(league: league, homeTeam: homeTeam, guestTeam: guestTeam) within the required init()
The other init (init(league: String, homeTeam: String, guestTeam: String, startTime: Date)) works because it receives the information such as league via parameters, which are effectively local variables in that initializer.
In this init, there are no such local variables, so super.init(league: league, homeTeam: homeTeam, guestTeam: guestTeam) would actually mean:
super.init(league: self.league, homeTeam: self.homeTeam, guestTeam: self.guestTeam)
That doesn't work, because those three properties are not initialized to anything yet — that's what the super call is for.
If you can decode this information directly from the decoder, like you do for startTime, then you can pass those decoded values into init(league: String, homeTeam: String, guestTeam: String, startTime: Date).
Does that explanation make sense?
Post not yet marked as solved
I don't know what's going on here, but a couple of things to look at:
— If you're running the 15.3-built project on simulators or devices that you've previously tested on, try deleting the previous installation of that app before running it from Xcode. It's possible there are installation artifacts left from previously debugging cycles, which might not be deleted via the Xcode installation cycle.
— It's possible your plist has some keys that were (for example) added manually in the long-forgotten past, which are not relevant and are now being rejected by the latest Xcode version.
Is there some text at the end of that very long error message that gives some clues as to the "underlying" error? Maybe you could post a redacted version of the entire error message?
Also, is this an Xcode project that you created directly, or is it perhaps a project generated by some other development environment?
Take a look at your settings in the System Settings app -> Desktop & Dock section -> Windows control group.
"Ask to keep changes when closing documents"
"Close windows when quitting an application"
One or other of these may have been accidentally changed, result in the behavior you're seeing.
Post not yet marked as solved
I'm not sure I follow your reasoning here.
In the first screenshot, the highlighted item is a 4MB memory block that was last resized in the delegate method, suggesting it's the memory block associated with your _data object reference. There's nothing to suggest that it's leaked there at all.
In the second screenshot, it looks like a leak of only 16 bytes was detected. That suggests it's the local data variable reference's memory, not _data and there's no evidence there that it's leaking every time.
I think in this scenario, the Leaks instrument isn't doing you any favors, because you have no insight into why it thinks this memory is being leaked. It'd probably be more productive to focus on the Allocations instrument (within the Allocations template), then use the "Mark Generation" button to isolate the allocations that remain after a specific download session:
https://developer.apple.com/documentation/xcode/gathering-information-about-memory-use/#Profile-your-app-using-the-Allocations-instrument
That should give you a clearer idea of which memory (if any) is actually being leaked.
Post not yet marked as solved
The error message is correct. Your code:
protocol B: A { }
class BClass: AClass<B> { }
by definition means:
protocol B: A { }
class BClass: AClass<any B> { }
That says that BClass is a subclass of a specialization of AClass<T> where T is the existential type any B. However, your definition of A is:
protocol A { }
class AClass<T: A> { }
This by definition means that T is a concrete type that conforms to A. any B is an existential type, not.a concrete type, so it's can't work for classA.
To get around this, you can do this:
protocol B: A { }
class BClass<U: B>: AClass<U> { }
In other words, make BClass also generic, taking a concrete type U that conforms to B and hence conforms to A.
However, if you need BClass to really be specialized on any B, you'll have to do something to AClass to let it take an existential type as a parameter.
Post not yet marked as solved
Also see the last parameter in this initializer:
https://developer.apple.com/documentation/dispatch/dispatchqueue/2300059-init
and see this function:
https://developer.apple.com/documentation/dispatch/dispatchobject/1452989-settarget
The concept of "the target queue for this queue" is well-defined, but I agree the documentation could be clearer here. Note that the parameter to dispatch_apply is "just" a queue, not a target queue in this sense used above.
Post not yet marked as solved
See also the discussion on your question in the Swift forums.
Post not yet marked as solved
As well as the possibilities mentioned by Quinn, this could also be a side effect of the clipsToBounds change in Sonoma:
https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-14#NSView
If that's what is going on here, the issue is likely not with the text fields themselves, but with some other view in your window that's drawing over the text in the text fields.
Since public.plain-text is a system-defined UTType, and you want a standard extension (.txt), you don't need to declare either an imported or exported type identifier. You can just specify your document type as public.plain-text directly.
You could use a more specific system-defined type to limit your app to UTF8, but it's probably a better user experience if your plist allows anything that appears to be a text file, then validate the data when you first open the file, to make sure it's a format your can read. Keep in mind that many files end being given the "wrong" extension, and trying to enforce a format precondition may result in obscurely unhelpful errors being presented to the user.
Post not yet marked as solved
It's complicated, I think. What does "exit" mean to the user of the app? iOS and tvOS apps typically don't have this concept.
One UI-level problem with the Cancel/Exit approach is that it's modal. Maybe the user didn't really want to stop using your app but wanted to jump out for a moment to do something in another app then come back. Having an alert takes away that option.
At the other end of the scale, your app's process can be terminated if (for example) your app goes into the background, due to some other system-level behavior. If your app had necessary things to do at "exit" time, how would you ensure that happens? (You do have some control of what your app does shortly after it goes into the background, but I'm asking more of a conceptual question at a higher level.)
How would you feel about doing both of the following things, instead of trying to introduce a concept of "exiting" into your app:
Implement full state restoration (starting documentation here for UIKit or here for SwiftUI), so that from the user's point of view your app always maintains its state. This more or less looks to the user like your app is running continuously, even in the background, though that's not what is going on under the hood.
When your enters the inactive or background state, suspend or pause activities that your app is carrying out, when they're inappropriate for a non-foreground app, such as pausing playback. When your app re-enters the foreground, either resume the suspended activities automatically, or provide UI that the user can use after deciding whether to resume. Mode-less UI is better than modal UI here, in that case. (Choosing whether to deal with this at inactivation or backgrounding depends on the activity, to some extent.)
My guess is that you're asking your question because your app doesn't currently implement state restoration, or at least doesn't implement it completely enough. Exploring this direction might make the question unnecessary.
Post not yet marked as solved
Could you start with a bug report via Feedback Assistant, and post the feedback number here, please? Make sure you include sample date ranges and locations in your problem description.
Post not yet marked as solved
I'd suggest you ask this question over on the Swift Forums, since this a question about back-deployment of Swift Concurrency features, and it's important for the answer to get the details right.
Can you post an updated code fragment for us to look at?
The updated version of scanCharacters is:
public func scanCharacters(from set: CharacterSet) -> String?
https://developer.apple.com/documentation/foundation/scanner/3200281-scancharacters/
Incidentally, to check all this out, I used "Jump to Definition" on scanDouble in Xcode, from the right-click context menu. That took me to a "generated" Swift header that showed all of the relevant function declarations together, and from there I was able to see the deprecations and the new functions.
For example, though it's not directly relevant to your question, I figured out there are no replacements for the older scanHex… functions because they're subsumed by the scan…(representation:) functions where the parameter distinguishes between decimal and hex input.
Those functions do seem to be deprecated in current macOS versions. It's unclear why the documentation is out of date.
The solution is to use the newer versions of these functions such as scanDouble(representation: .decimal). The differ in that they return the scanned value, rather than taking a pointer to memory to store the value. Failure is indicated by a nil result instead of a false return value.
