Also, I do not really understand why this solution is working at all? Why does implementing that delegate call enable the swipe down to dismiss? Did you find it out by accident?

It seems to me that, no matter which of the two variants posted above I'm using, the very first presentation does not look smooth. On the very first presentation I briefly get a white screen (when using the empty UIView) or a transparent screen (when using controller.view) before the presentation.

It's fixed in iOS 18 Beta 5.

Did anyone ever find a solution for this? I'd like to present a UIMenu from a UIView as a result of a gesture recognizer firing... is that possible?

Did you ever get an answer for this question?

This issue is still present in iOS 16. Did anyone ever find a better solution other than reloading?

Exactly right on both points. Thank you for taking the time to guide me to the solution.

Ok, I got it. Thanks guys! I somehow was under the impression that globally turned on auto-capitalization was a feature that should be working by default on any text entry field.

Unfortunately there was no solution, I'm still running with the try/catch workaround as shown above.

I do have the same issue. It somewhat randomly happens on copy/paste in UITextFields in UITableViewCells. I can also catch it in the debugger and I get the following: *** Assertion failure in -[_UITextKitTextPosition compare:], UITextKitTextViewEditingSupport.m:43. This does seem to be an iOS issue and not an issue in my code. Others have also written about this issue: https://varun04tomar.medium.com/invalid-parameter-not-satisfying-po-crash-on-ios-15-while-pasting-text-onto-uitextview-57e94bbca113 https://stackoverflow.com/questions/69568511/ios15-uitextview-after-dragging-the-view-it-causes-a-crash-invalid-parameter-n Some people are suggesting to implement UITextPasteDelegate to work around the issue. In a large app implementing UITextPasteDelegate on all textfields is very cumbersome and I don't think that this is really the solution to this problem. Has anyone found a better solution for this issue? Will it eventually be fixed in a future iOS update?

Fixed? Not really, rather just “worked around”. Ok, I agree. I’m presume that you chose the latitude property just as an example?  Exactly. Do you have a way to export that DLog to your analytics system? If so, that should be sufficient to tell you which property is causing problems. Yes, I will add some mechanism to have that DLog output sent to me by the users. But that output is not really telling me which property was causing the issue, is it? Its output is just: invalid JSON payload, ignoring (Invalid number value (NaN) in JSON write) Am I missing something?

Ok, I've figured out that I can use something like @"latitude": @(nan("0x12345")) to replace @"latitude": @(locationObject.location.coordinate.latitude)in order to reproduce the exception. The modified code from above is now:     NSMutableDictionary *body = [NSMutableDictionary new];     [body setObject:Utils.deviceDict forKey:@"device"];     NSMutableArray *trackingQueueCopy = trackingQueue.copy;     NSMutableArray *locationObjects = [NSMutableArray new];     NSError *error;     for(LocationObject *locationObject in trackingQueueCopy) {         NSDictionary *locationDict = @{@"latitude": @(locationObject.location.coordinate.latitude),                                        @"longitude": @(locationObject.location.coordinate.longitude),                                        @"locationTimestamp": @(round(locationObject.location.timestamp.timeIntervalSince1970)),                                        @"altitude": @(locationObject.location.altitude),                                        @"horizontalAccuracy": @(locationObject.location.horizontalAccuracy),                                        @"verticalAccuracy": @(locationObject.location.verticalAccuracy),                                        @"clientTimestamp": @(round(locationObject.dataTimestamp.timeIntervalSince1970)),                                        @"battery": @(round(locationObject.batteryLevel*100)/100),                                        @"speed": @(locationObject.location.speed),                                        @"course": @(locationObject.location.course)                                        };         @try {             [NSJSONSerialization dataWithJSONObject:locationDict options:NSJSONWritingPrettyPrinted error:&error];             [locationObjects addObject:locationDict];         } @catch(NSException *exception) {             DLog(@"invalid JSON payload, ignoring (%@)", exception);         }     } That's sufficient enough for me to have this bug fixed. Figuring out what exactly is actually causing the NaN would be a different story though, and I'm currently not sure how I could approach that...

Thank you very much for the explanation, it totally makes sense. Also, the pattern in the backtrace gives you a rough idea of the nesting, namely dictionary > array > dictionary > number. Yes, that does indeed exactly match the structure as seen in the code snippet above. Now in order to reproduct the issue, I wonder how I can generate a NaN or infinite value? The potential candidates in the locationDictfrom above are CLLocationDegrees, CLLocationDistance, CLLocationAccuracy, CLLocationSpeed, CLLocationDirection, NSTimeInterval, float. So basically we have double or float.

Right. Well, it’s possible for +new to fail and return nil, but that can only happen if malloc fails, meaning that you’ve exhausted your address space. That’s unlikely to result in a consistent crash like this. Ok, I agree. But I also agree that it's very unlikely. The crash report is attached. Thank you very much for your support! crash.txt

Thank you very much for taking the time to write such a detailed explanation. It is much appreciated! Here's the code where the crash is happening:     NSMutableDictionary *body = [NSMutableDictionary new];     [body setObject:Utils.deviceDict forKey:@"device"];     NSMutableArray *trackingQueueCopy = trackingQueue.copy;     NSMutableArray *locationObjects = [NSMutableArray new];     for(LocationObject *locationObject in trackingQueueCopy) {         NSDictionary *locationDict = @{@"latitude": @(locationObject.location.coordinate.latitude),                                        @"longitude": @(locationObject.location.coordinate.longitude),                                        @"locationTimestamp": @(round(locationObject.location.timestamp.timeIntervalSince1970)),                                        @"altitude": @(locationObject.location.altitude),                                        @"horizontalAccuracy": @(locationObject.location.horizontalAccuracy),                                        @"verticalAccuracy": @(locationObject.location.verticalAccuracy),                                        @"clientTimestamp": @(round(locationObject.dataTimestamp.timeIntervalSince1970)),                                        @"battery": @(round(locationObject.batteryLevel*100)/100),                                        @"speed": @(locationObject.location.speed),                                        @"course": @(locationObject.location.course)                                        };         [locationObjects addObject:locationDict];     }     [body setObject:locationObjects forKey:@"locations"];     NSError *error;     NSData *jsonData = [NSJSONSerialization dataWithJSONObject:body options:NSJSONWritingPrettyPrinted error:&error]; The crash occurs in fact on the very last line. But as can be seen on the first line of that snipped, body cannot be nil (at least to my understanding). My guess is that somehow the content of body cannot be converted into JSON which is causing the crash but I have not been able to figure how how that can happen. Unfortunately I don't have a specific user who can send a sysdiagnose so I would like to go by your suggestion of reproducing the crash and comparing the offset to the crash reports. But the thing is, I still have no clue where it could happen and therefore how to reproduce. By looking a this snippet of code, do you see anything suspicious?