Smells like one of those many behaviors that is deliberately undocumented and could vary based on system conditions or across OS releases, so I’d be surprised if you get any specific official answer to this. Is there a way the extension can detect its the same or a new process? Your global countOfInvocations would restart at zero in a new process, right?

Or see this thread if you are using an app platform such as Flutter.

This is a popular question. Start by reading TN3111: iOS Wi-Fi API overview. I want to know if there are any other ways to get current wifi list from iPhone. There are not. But if you already know (or can, for example, scan from a barcode) the accessory’s SSID, or at least the first 3 characters of the SSID, then NEHotspotConfiguration’s init(ssid:) and init(ssidPrefix:) are designed for this case. If that’s not possible, then see this thread for recent discussion of the same issue and some ideas.

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?

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?

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}).

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.