The for loop starts by calling your makeIterator() under the covers and then mutates that iterator, leaving your original box instance unchanged. The while loop is doing basically the same thing, except the makeIterator() call is explicit. If you changed that loop to print fib.currentIndex instead of iter.currentIndex then you would get the same output as the for loop.

That status means you (the “developer” here) need to release it manually. See Manually release a version.

It’s safe. Note this line in the documentation: You can call this method at any point in your app’s execution.

Is there a more direct way to do this? Definitely. Currently it’s doing all this: calling datetime() within SQLite to convert a stored Julian value to a string; using one DateFormatter to parse that string into a Date value; using a second DateFormatter to convert that Date value back to a string. You can eliminate 1 and 2. Just project the raw Julian value in your query (fetching it via sqlite3_column_double) and then construct your Date value directly using init(timeIntervalSinceReferenceDate:). It just requires simple math to convert from Julian (days since 4713 BC) to Apple reference date (seconds since 2001). Also this will help your ORDER BY clause a little, since now it will be sorting by a number rather than a string. And (basic “code review” comment) you can construct mediumDateFormatter just once, before the loop. No need to do it inside the loop.

Also check out this video tech talk: Write clear purpose strings.

why did it need to be changed in the last update[? ...] why doesn't iOS give us the fixed MAC address? Trust me, it’s not productive to ask (or worry about) why Apple does anything the way they do. ;-) I have never seen this UUID change in any update (just as it should). You may have gotten bit by unintentionally relying on undefined behavior. Maybe it used to be the same across devices because it was just (for example) based on a hash of the peripheral's MAC address. And maybe now it’s generated differently. (Why? See comment above.) But either way conforms to the documentation, which doesn’t define this behavior at all. I think iOS also needs to provide this uniqueID to us developers. You should submit a feedback requesting this feature.

I use the MAC address (RemoteId / UUID) of the bluetooth device Note that the CBPeer.identifier (link) property is not the MAC address (or any other intrinsic property) of the peripheral. It’s just a random UUID assigned by Core Bluetooth. Searching the web turns up other cases of developers reporting that this identifier doesn’t always stay the same. And if you parse that documentation very carefully, it doesn’t actually promise that the identifier won’t change at some point. It’s probably safest to treat the identifier as a key for caching local state, but where such caching isn’t critical to your functionality. If you need a truly persistent identifier, consider your peripheral’s Serial Number String characteristic.

What are you trying to accomplish? Indeed most of CTTelephonyNetworkInfo is deprecated as of iOS 17 (and actually stopped returning useful info around iOS 16.4) so even determining that the service provider changed won’t tell you anything about the new provider.

Update: in Xcode 15 beta 5 (release notes) they added a Quick Actions feature which is exactly what you are looking for.

Pro tip: when posting code, use the “code block” formatting feature to make it readable, like this: void Bt_Status (esp_spp_cb_event_t event, esp_spp_cb_param_t *param) { if (event == ESP_SPP_SRV_OPEN_EVT) { Serial.println ("Bluetooth: Connected"); /* ... */ } } That doesn't look promising. Indeed. That code is using Bluetooth as a plain old serial port, which isn’t compatible with Core Bluetooth on iOS.

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.

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.

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.

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

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.