In the image that you linked to in your comment, the orange shape is not convex. Its bottom edge is concave.

triple w dot ime.usp.br/~pf/sedgewick-wayne/algs4 then add GrahamScan dot java at the end of the url. It actually says right at the top of that code: "May be floating-point issues if x- and y-coordinates are not integers." This is exactly the numerical stability issue that I am referring to.

yes it is wifi only ipad The wifi-only iPad doesn't have GPS hardware, so the only location updates you will get are based on nearby WiFi networks. It will not be able to calculate useful speed numbers from that. If you're lucky, you'll find that the reported speed accuracy is < 0, meaning that the speed value is unknown.

It's actually more likely that a file will be modified by another app while I'm in the background Suspended in the background? Or running in background? This question is about the case where my app is running in the background to receive location updates.

NSURLSession does not have any logic that changes based on the size of the incoming file.  Does the cache?

I'm only interested in continuous location updates. my expectation is that the file coordination system should work fine in the background as long as you’re not suspended. Thanks. A quick check finds that indeed I can leave the NSFilePresenter in place and I do get a notification if another process (e.g. the Files app) deletes the file while I am running in the background. I do get a warning in the console: File presenter <....> with presentedItemURL .... was still registered at the time this application was suspended, and implements one or more NSFilePresenter messages requiring a response. For NSFilePresenters for file system locations that are accessible to other processes (e.g. iCloud or group containers), you should either call removeFilePresenter: when the process is backgrounded, or remove any implementations of NSFilePresenter methods requiring a response. Otherwise, the system will kill your process instead of risking deadlock. I can't do this unconditionally though - sometimes the app will be recording locations and so will be running in the background, but other times it will not be recording locations and will be suspended. I guess I can track whether I am getting location updates and remove the file presenter if I'm not. Or, is there some other e.g. UIApplicationDelegate method that I should use rather than applicationWill/DidEnterBackground? Or can I ask iOS, from the will/didEnterBackground method, whether or not I will be suspended?

Looking at the metadata from the album, the focal length is 13mm for the apple default camera, while it is 16mm for the one I created. Do you actually see a difference in the captured image, or is the difference only in the metadata?

I don't know what would be worse - using an AI chatbot for support, or having human support that seems like it's an AI chatbot. I have certainly received those messages that look like they are canned, i.e. they are made up from boilerplate sentences combined with "answers" that are copied-and-pasted from the documentation that you've already read a hundred times. I don't think this is unique to Apple. I've certainly had similar experiences with Amazon Web Services support. The difference is that I have only needed to get support from AWS about 2 or 3 times in the >10 years I've been a customer, because they have better documentation and fewer bugs than Apple.

Thanks. This all feels a bit fragile but I think I can make it work. I'm cautious though, because I don't want to discover that in some future iOS version the behaviour changes and I get terminated because I've not removed the NSFilePresenter when I background. Users would be unhappy to find that their track recording had stopped when they put their phone in their backpack.

It's a different app. Why do you think the IAP will transfer to the other app? (Is there now some way to make the iOS and Mac apps use the same IAPs? Maybe there is something new to make this work.)

please submit an update within two weeks You've done that. It doesn't say "submit an update and get it approved", it just says "submit an update".

The documentation for CGColorRef (https://developer.apple.com/documentation/coregraphics/cgcolorref?language=objc) clearly shows that it is a struct.  Right, that should surely say typedef struct CGColor* CGColorRef; The same issue seems to appear here: https://developer.apple.com/documentation/coregraphics/cgcolorspaceref?language=objc https://developer.apple.com/documentation/coregraphics/cgcontextref?language=objc https://developer.apple.com/documentation/coregraphics/cgfontref?language=objc etc. etc. Presumably this is something gone wrong with the tool that extracts the documentation from the header files. File a bug?

Settings -> General -> Legal & Regulatory -> Licence

FB11718776

The threads you've linked to are fairly comprehensive - it's difficult. As a "thought experiment", here is how I would do it: Create a UIView that implements UIKeyInput (in objC or Swift). https://developer.apple.com/documentation/uikit/uikeyinput?language=objc Draw *s as the user types characters. (The fact that you're not displaying the password as it is typed is a great help!). As you receive characters one-at-a-time, pass them to some C code that appends them to a C char array. Compute your hash of the C array, and then zero it. Or, maybe your hash function can process the characters as they are received, so there is never a copy of the partial password in memory. This does make backspace more difficult though! So what will you see in memory if you dump it after that? It's likely that you'll find the NSStrings for the individual insertText calls. If you're lucky, they will be out of order and mixed up amongst lots of other NSStrings. If you're unlucky, they will be stored contiguously next to some obvious clue about what they are.