What is the question? Assuming the feedback is accurate, you need to update your screenshot(s) and resubmit. One tip: if you launched your app from a 2nd app (even from TestFlight) so that there is a small back button in the status bar, don’t do that. Launch your app directly from Xcode or from the home screen.

This question is so popular, there’s a whole write-up on it: iOS Background Execution Limits.

The search bar at the top of the Help menu is basically the same thing, though it doesn’t seem to be mapped to a keystroke for instant access.

Look closer at these lines: menuTimer = nil menuTimer?.invalidate() When executed in that order, would they actually invalidate the timer?

How do I control the encoding process so that this number is 402.71 in the JSON string. Short answer: you can’t, for the Double type. There’s no equivalent of (for example) DateEncodingStrategy or DataEncodingStrategy for this type. Longer answer: You’re seeing that a floating point type like Double isn’t a great choice for representing money, because of the representation issues inherent in floating point. (There are probably at least 999.0001 explanations of this topic that you can find online.) Instead, consider using the Decimal type. This would be compatible with your existing JSON format that represents currency as numbers. Other solutions (but not compatible) could be to store them as strings ({"low": "402.71"}) or as integer cents with an implied decimal point ({"low": 40271}).

The point I am making is that this is a change in behavior Definitely, but it would be a change of undefined behavior, unless there really is documentation of this type having different lifespan behavior than the norm. (But I’d doubt that.) so is likely to catch people by surprise. Yep, sounds like a case of getting bit by accidentally relying on undefined behavior without realizing it. Just curious: in the old behavior, what was the lifespan of these objects that you never kept a strong reference to? Did they dealloc right after your perform() (which would defeat the attempt to cache them) or at some point much later? Was the caching actually effective?

Actually I think you are seeing correct behavior. The bug is in your code: it holds only a weak reference to the new object, so it is immediately eligible to get deallocated. It’s basically equivalent to this, which generates a compiler warning: weak var weakRef = NSObject() // warning: instance will be immediately deallocated because variable 'weakRef' is 'weak' In this simple example the compiler can issue the warning because it knows there are no strong references to the object. In your real code, the compiler can’t prove there aren’t any strong references being held somewhere else, so it can’t issue a warning. The real question is why the code worked (not deallocating the object immediately) in previous versions. Assuming your own makeSKAction() method never had any side-effect of storing a strong reference to it somewhere, then I’d suspect the change is in SpriteKit. If the previous logic for creating an SKMove object kept a strong reference to it within SpriteKit with a lifetime any longer than your perform() method (maybe just in the autorelease pool, or maybe a long-lived cache) then your code would work. But if the implementation has changed to return an SKMove that is eligible for deallocation immediately if not retained, then the bug is revealed.

Id be very thankful if anyone can help. Actually nobody can really help yet, because the try? in this line silently eats the thrown error: guard let loadedData = try? decoder.decode(T.self, from: data) else { You should move the decoding into a do / catch block, and then you can examine the error that gets thrown. What does it say?

add a subview in the keyboard, but it's hard to position correctly and has some side effects And note that in iOS 17, the keyboard runs outside your process. (See WWDC video Keep up with the keyboard.) So the unsupported technique of adding subviews to the keyboard may not even work at all any more.

Undocumented If a function happens to be visible to the compiler but is undocumented, then (1) why are you calling it?, and (2) what do you expect it to do? Swift? In this case, it’s not a function intended to be used from Swift programs, and especially not from SwiftUI. It’s actually an ancient C function in the underlying Darwin OS that happens to be available (maybe it could be useful to some types of program) but has no practical use. If you view the documentation (via man pause) then the manual page is dated 1993, and says the function first appeared in Version 6 AT&T UNIX which dates from 1975. Groovy! And the description in the manual page shows that what this function does is definitely not what you would want. Private API? Bug? Security flaw? I’d vote “not really” to all of those, but one could probably engage in a very nerdy discussion around that.

Did you get a deprecation warning when compiling? If so, it should include a helpful message. Or you can look in the SDK header file UITextView.h (the source of truth) where there is a new annotation that generates the message: API_DEPRECATED("Replaced by primaryActionForTextItem: and menuConfigurationForTextItem: for additional customization options.", ios(10.0, 17.0), xros(1.0, 1.0));

It sounds like you have encountered this behavior.

You almost have it. Note that JSONSerialization is all class methods, not instance methods, so you call it like this: let someArrayOrDictionary = try JSONSerialization.jsonObject(from: myDataObjectContainingJSON)

Yes, but... the corresponding page for tvOS (link) says: Please note that starting July 31, 2023, all tvOS apps submitted to the App Store must be built with Xcode 14.1 and tvOS 16.1 SDK or later.

Hmm, sounds like there aren’t great options for solving this. Is the MAC address at least printed somewhere on the accessory? One not-so-great idea would be to have the user “scan” the accessory’s printed MAC address for you using their eyeballs and fingers. The doc for NEHotspotConfiguration(ssidPrefix:) says the prefix must be 3 characters minimum, so you could get by with having them enter only the first 3 characters, or even just the first 2 if you know that the 3rd is (for example) always : or -. Or you could even try to scan a printed MAC address using the Vision framework. I’ve never used it but it sounds cool.