MoltenVK is interesting. I've looked at it but never tried to deploy it. A few years ago, we could write code using C++ and OpenGL ES and it would run on iOS, Android, on the web (using Emscripten and WebGL), and even on desktop Linux and likely Windows. I have a largish demo that does most of that. But since then there has been some unhappy divergence: iOS has deprecated OpenGL ES and invented Metal, and the replacement of ObjC with Swift has made C++ more difficult to use; Android now has Vulkan. So it is tempting to look for tools like MoltenVK that might help to re-unify the platforms. Right now, my feeling is that the more promising technology medium-term is webgpu.h. WebGPU is a replacement for WebGL that is more "modern" like Metal and Vulkan (but is different from both), and webgpu.h is a native API for it. So you can use it, with C++, on the web (where webgpu.h is a thin wrapper over JS WebGPU), and on native platforms with a library that translates webgpu.h calls to Metal or Vulkan (e.g. Dawn). This doesn't seem to be ready to use quite yet but it's coming soon enough that it's worth considering if you're about to start on a new project. I would be interested to know if anyone here has any experience with any of these things.

that requires active cooperation on behalf of the user What happens if someone steals the phone? I'm curious as to whether the phone would need to be cracked in advance in order to dump the RAM in this way, or whether it can be done afterwards. You need to think carefully about your threat model I think the main threat model is probably "we have this list of security best practices and I'll get fired if we don't comply with them".

No.

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.

FB11718776

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

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?

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".

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

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.

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.

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'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?

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

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.