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.

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.

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?

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.

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?

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

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.

For the record block, let’s compare their signatures (adding some handy names and spacing for clarity): typealias OldRecordFetchedBlock = ( CKRecord ) -> Void typealias NewRecordMatchedBlock = (CKRecord.ID, Result<CKRecord, Error>) -> Void The main change is the CKRecord is now wrapped in a Result, so it can indicate that either a record was successfully fetched, or if an error occurred. You just need to unpack the record from the Result in order to use it: operation.recordMatchedBlock = { id, result in switch result { case .success(let record): self.saveToCoreData(record: record) case .failure(let error): // handle the error in some way } } The change from queryCompletionBlock to queryResultBlock is similar. The cursor and error are now wrapped in a Result rather than being separate parameters.

@eskimo For your suggestion box: a writeup on identifying and avoiding unsafe assumptions in general. Here are just a few varied examples I’ve collected on the forum: Random numbers UIKit layout Notification ordering Date formatting Object lifetimes Bluetooth identifier

In iOS 17, Data has changed how it performs equality. Actually what apparently changed is the behavior of JSON encoding, which now produces Data objects that are indeed different in your example. Remember that a Data object is just a blob of bytes with no concept of JSON keys. I've noticed if I modify the test case to use a JSONEncoder setting of encoder.outputFormatting = .sortedKeys, then it passes. That’s the crucial clue. If you don’t use .sortedKeys then the order of the keys after encoding is undefined. And it’s important to never make assumptions about undefined behavior. Unfortunately this test case makes such an assumption: that the undefined key order will happen to be the same if you perform the same encoding twice. So in iOS 16 and earlier it (apparently) just so happens that the keys are ordered the same when encoding twice in row, but in iOS 17 it just so happens that they are not. Both behaviors conform to the documented behavior. The bug is the test case’s unintentional reliance on the undefined key order. I noticed that in WWDC, Apple said they rewrote the entire JSONEncoder & JSONDecoder implementations [in Swift]. This may be the root of the behavior change. Swift's Dictionary can have different (undefined) key orderings even between dictionaries that have identical contents, whereas this may not be the case for Objective-C’s NSDictionary. And if the new JSONEncoder implementation in Swift uses Dictionary internally, well, there you go.

See reply in the other thread.

Is this an expected behavior in iPadOS 17 It would have to be a bug in Xamarin.iOS. It may be related to the original issue in this thread, but that’s not a bug in iOS per se. expected to be resolved in a future [...] Xamarin.iOS update? There’s not much Xamarin expertise in this Apple forum. But a quick web search suggests that Xamarin is at EOL with no iOS 17 support coming. You’ll need to migrate to .NET MAUI to support iOS 17 and later.

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.