i want to test iphone 13 mini communicating with other device with bluetooth classic mode only. What functionality do you want to test, exactly? If we’re still talking about the ESP32 device running Serial Port Profile (from your other question) then it’s not going to work. The OS can connect to certain types of devices via Bluetooth Classic (headphones, keyboards, etc.) but your device isn’t one of them. And apps can connect to devices running GATT profiles (which generally means running Bluetooth LE) but it sounded like yours isn’t one of those either. but i can't find the setting menu that change the bluetooth communication mode. There is no such setting. There is just the Bluetooth on/off setting. And when Bluetooth is on, then apps can use Core Bluetooth to communicate with compatible devices. Study the Core Bluetooth API carefully. Note how it works in terms of GATT entities: services, characteristics, and descriptors. If you want to build a device to communicate with an iOS app that you write, then the device must implement GATT services, characteristics, and descriptors. Then Core Bluetooth can work with it. ESP32 does support GATT. The API for this is a lot more complex than the simple serial port functionality you’ve already tried, but it’s doable.

Start with this old WWDC video: Developing CarPlay Systems, Part 1. Then you can decide if “little project” is still the right term. :wink:

The error message is saying checkPermission is a global function rather than a method, and global functions have no concept of self. As the error message suggests, did you intend for those functions to be methods within your Notification type?

First, in the future be sure to use code block formatting, like this: let dateFormatter = DateFormatter() dateFormatter.dateFormat = "yyyy-MM-dd'T'hh:mm:ss a" dateFormatter.locale = Locale(identifier: "en_US_POSIX") dateFormatter.timeZone = TimeZone.current if let date = dateFormatter.date(from: dateString) { let formattedDateString = dateFormatter.string(from: date) print(formattedDateString) } else { print("Invalid date format") } Then look closely at Technical Q&A QA1480: NSDateFormatter and Internet Dates. This point is important: Once you've set "en_US_POSIX" as the locale of the date formatter, you can then set the date format string So you should set the formatter’s locale before you set dateFormat. i am getting date format 2023-08-25T7:07:00 pm Just curious, what is generating dates in that format? It sort of resembles ISO 8601 format, but isn’t. If you are the one designing the wire format for dates in your system (between your back end and your app, for example) then ISO 8601 is the way to go.

If the goal is to actually throw the error out of the setter, that’s not supported. You can throw from a read-only property getter, but that’s about it. SE-0310 has some discussion of why throwing setters would be tricky to define and implement. For the example given, one solution would be to change it from a property to explicit getter/setter methods, and those can throw. For example, endpoint() and setEndpoint(_:). But also reconsider why the property is declared as an implicitly unwrapped optional: String!. That’s still just an optional, so a user may expect that passing nil would be perfectly legal. Should the property actually be declared as non-optional?

Maybe reconsider why those specific error situations arise, and see if the Swift language can help avoid them. Do any of these apply? — Invalid null parameter If a method or function requires a parameter to be non-nil, then don’t declare it as optional. Parameter value out of range If this is for some sort of indexed collection, note how the same thing in Swift collections (like arrays) is a programmer error and thus causes a runtime error (crash). Property value (of T!) not set Not sure what this means, but again may be addressed by defining a property precisely as optional or non-optional. There are some well-defined use cases for implicitly unwrapped optionals, but otherwise they can get you into trouble. If you’re thinking of an analog to Java’s unchecked exceptions, which represent programmer errors, then Swift’s equivalent generally is to crash the app. That’s a good thing.

Since the app was killed prior to performing the notification action, I expect the app to be killed/terminated after calling completionHandler(). Why do you expect that? Nothing in the documentation (either for notifications or for the other things that launch an app into the background) actually says that. The OS keeps its own counsel about when to kill background apps. Maybe your app got killed earlier due to memory pressure, but now after handling the notification response there happens to be less memory pressure. Or maybe the OS figures the user may want to resume your app soon and keeps it around a little longer. Or maybe it prioritizes background apps alphabetically according to height. It doesn’t really matter because you can’t do anything about it. Just make sure your app behaves correctly in all cases.

Or try just removing this line: decoder.keyDecodingStrategy = .convertFromSnakeCase // Configure snake case decoding You are already supplying an explicit enum CodingKeys that defines the key conversion, so asking for additional conversion produces unexpected results.

Can you narrow down where it goes wrong? Does it take the expected branch in filterAndSortPoems()? If so, is the filter call not working correct? Or is something going wrong earlier?

As of Xcode 14.3, running under Rosetta isn’t supported. See Xcode 14.3 Release Notes.

Well that’s weird. Your test case is working correctly for me here in Xcode 15.0 (15A240d) on a Mac with M1 Max. Does the behavior change if you format the literal as @(-1) with parentheses? Can you format the key via some code (like a number formatter) to confirm the issue is really the compiler, vs just an issue in the debugger? That value 18446744073709551615 happens to be 2^64-1, the same bit pattern as -1 in a 64-bit signed integer. Maybe that’s a clue.

The fine print on the iPadOS 17 product page says this: Available in English (Australia, Canada, United Kingdom, U.S.) on iPad and on AirPods Pro (2nd generation). Does this match your setup?

It was my 2nd time already, I am frustrated. I asked [App Review] to give suggestion and it refuses. Right. They mostly just review apps and apply the guidelines. But someone from App Review did make an excellent tech talk video on this topic: Write clear purpose strings.

The code in that article is still correct. It’s this line in the test which is going wrong: print(s?.isBlank) This unwraps the optional s and then calls isBlank only if s was non-nil. If s was nil then the result of the entire expression is nil. Note this isBlank method is defined in an extension on String, which is given in the article but not shown here. To test this correctly, the line should be this: print(s.isBlank) This calls the isBlank method which is defined in the extension on Optional<String>. It’s totally separate from the other isBlank.

I haven't received the latest Beta Software version which is 17.0.1. There was no beta for 17.0.1. You need Settings → General → Software Update → Beta Updates: Off in order to see it.