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.

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?

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

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.

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

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

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

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?

The beta documentation isn’t super helpful on this (yet) but notice that the UITrait type is defined like this: typedef Class<UITraitDefinition> UITrait API_AVAILABLE(ios(17.0), tvos(17.0), watchos(10.0)); So -registerForTraitChanges:withTarget:action: takes an array of Classes, not instances of those classes. You can make it like this: NSArray<UITrait> *traits = @[UITraitUserInterfaceStyle.self]; Note that if you had declared your array type as NSArray<UITrait> * then the compiler would warn about the type error. [traits release]; [style release]; Also, if you’re working on cleaning up deprecated code, I’d vote to start by converting your app to use ARC. Manual -release has been obsolete for many years.

Your math is fine; it’s the format string that isn’t doing what you expect. The character X in your "0x%016X" means to format a 32-bit value, so it’s truncating the top half. For 64 bits use lX (that’s a lowercase L character, as in “long”).

It is my understanding that the SELECT statement returns a 0 if the table does not exist and 1 if it does. Actually that statement will return a result row if the table exists, and no result rows if it doesn’t exist. If you really want a result row containing a number every time, then you could use: SELECT COUNT(*) FROM sqlite_master WHERE type = 'table' AND name = 'Contact' But this would require you to fetch the column value to check the number. Your original query actually makes this task easier by letting you simply check if a row was returned or not. the API step statement returns 101 (SQLITE_Done) if the table does not exist. That means sqlite3_step has finished stepping through all the result rows, of which there are none. But if the table does exist it does not return 101. That would be SQLITE_ROW which means it got a result row. If you were to call sqlite3_step once again (or in a loop) you would get SQLITE_DONE the next time.

What exactly are you trying to accomplish? That sample code and video shows how Core Bluetooth supports GATT over Classic, which means basically the same capabilities as GATT over LE. But Classic-only profiles (such as, for example, profiles built on the Serial Port Profile) are not supported.

but my customer want me to make code with Bluetooth classic the reason of this demand is many phone use rather bluetooth classic phones than bluetooth low energy phones Not clear what you mean. All iPhones support Bluetooth LE. Or is your goal to receive data from non-Apple phones? How does your ESP32 module fit into this? i already made this code with Bluetooth Low energy Then your iOS-side code is basically done. You need to implement a GATT server on the peripheral side that it can talk to, regardless of the transport.