Dear Experts, We are required to remove our NSFilePresenters from the NSFileCoordinator when the app goes to the background and re-add them when it returns to the foreground. Does this mean that when we foreground, we need to manually check if our files have been modified, deleted, or moved in the meantime? Or is there some mechanism in NSFilePresenter/NSFileCoordinator that will report any such changes to us? Detecting that a file has been modified or deleted is not difficult, but I don't think it's possible to detect that it has moved. Changes to directories are also difficult. Any advice? What does UIDocument do in this case?

Dear All, Does anyone have any suggestions for an iPad text editor app that is well-behaved with respect to NSFileCoordinator / NSFilePresenter / UIDocument etc.? Specifically, I'd like something that I can run in iPad split screen mode alongside my test app. I'd like to be able to make changes to files using the text editor and see my test app pick them up, and vice-versa. I am currently trying an app called "Quick Text" which mostly works but it doesn't seem to pick up changes that I make in my test app unless I close and re-open the file at its end. I'm also soon going to reach its limit of "10 edits per week"! I have a couple of others to try, but maybe someone here has a suggestion?

I believe that if I rename a file, I'm supposed to do that inside a coordinated write on the parent directory - right? So say I have a file /path/to/folder/f1 and I want to rename it (in the same directory) as /path/to/folder/f2. I do a coordinated write (with the forMoving option) on the directory /path/to/folder. That passes me a possibly different path to the directory, right? Say I get /path/to/different. Question: what rename should I actually do? Do I need to construct from and to paths based on the different path that is passed to the accessor? I.e. do I rename from /path/to/folder/f1 to /path/to/folder/f2 or rename from /path/to/different/f1 to /path/to/different/f2 or some other combination? Do NSFileManager's renaming methods do anything special in this regard? Can I use e.g. std::filesystem::rename()? I am interested in both local documents that are visible e.g. in the Files app, and iCloud Drive documents, if that makes any difference. Thanks!

Dear Experts, What is the current best practice for build numbering? I ask because I am aware that when exporting an archived app for upload I am now asked if I want Xcode to manage the build number for me. In the past I have set a build number in the Info.plist, often based on the date, e.g. 2.4.20230218. Now, I am asked if I want that to be replaced by something like 2.4.7 (if I recall correctly). So far I've answered No. Previously I have searched for automatic build numbering and I've found web pages that suggest adding a script to the build process that automatically increments the build number in the info.plist, or similar. I've not tried to implement that myself. In some of my apps, I have code that needs to know the full version at compile time (e.g. app receipt validation). How would that interact with the new feature? Thanks, Phil.

Dear Experts, PHAsset.creationDate is an NSDate, which does not have a timezone associated with it, right? Consider a photo viewer app. If I take a photo of the sunrise at 0600 local time while I am away, when I get home and view the photo in the app, I believe I want the timestamp shown with the photo to be 0600. Do you agree? But NSDate is just a time-point, and I don't think Foundation (or anything else in iOS) has a type that combines a time-point with a time zone. Nor does PHAsset have any other useful attributes - unless I were to determine the time zone from the location! Am I missing anything?

I've just been looking at this list of APIs for which we will be soon be required to declare a "required reason" in the app's privacy manifest: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api One of the listed functions is stat(). The rationale seems to be that a malicious app can use stat to get the timestamps of files outside the app container, thereby "fingerprinting" the device. The allowed reasons that we can declare are : To get timestamps that are displayed to the user. To get timestamps of files that are within the app's container. To get timestamps of files that the user has granted access to. I am concerned that this does not include many of the legitimate non-timestamp uses of stat(). For example, it can be used simply to test if a file exists, or to test whether a path refers to a file or a directory, or to check if two paths refer to the same file (e.g. via different symlinks), or to get the size of a file. Some of these things can be achieved in other ways; for example, I can check if a file exists by trying to open() it and checking for an error, and I can get the file size by opening it and calling lseek(SEEK_END). Maybe I can check if two paths are equivalent by using readlink() to form canonical paths for both and comparing them. But I bet there are other things that can't be done. I could probably fix all of my code to not call stat() for non-timestamp reasons in a few hours. It would be more difficult to fix the various open-source libraries that I use. What do you think we should all be doing?: "File a bug" asking for an additional reason for using stat(), i.e. to get non-timestamp information about files in the app's container. Deliberately mis-read allowed reason C617.1, "to access the timestamps of files inside the app container", as " to access the timestamps and other metadata of files inside the app container", and declare that in the privacy manifest. Change code to not call stat(). Any other suggestions? P.S. I guess that libc++ std::filesystem calls stat(). What is the status of using that? The std::filesystem functions that access file timestamps are not listed on the page linked above. If I call std::exists() to check if a file exists, and assuming that is implemented using stat(), will that trigger the new filter?

NSString* fmt = [NSDateFormatter dateFormatFromTemplate: @"yyyy-MM-dd HH:mm:ss" options: 0 locale: [NSLocale currentLocale]]; My understanding is that this should rewrite the format string to something that reflects the users current settings. When I run it, it does seem to reflect the "24-Hour Time" setting under General -> Date & Time. But it doesn't reflect the "Date Format" setting under General -> Language & Region. It seems that the date format is always the default for the region set in General -> Language & Region -> Region. It also seems to insert an unexpected comma. Specifically: Region=US, fmt="MM/dd/yyyy, h:mm:ss a" Region=UK, fmt="dd/MM/yyyy, h:mm:ss a" irrespective of the "Date Format" setting. What's going on?

I have been trying to tidy up my Mac's storage which is getting full. (See also my other question about "bridgeOS".) In Settings -> General -> Storage -> Developer there were numerous multi-gigabyte items for different versions of iOS. Most of them were for point releases that I no longer have on my devices, which auto-update. For example I think I had 17.0, 17.1.1 and 17.1.2; my dev iPad and iPhone are both now running 17.1.2, so I deleted the others. But now when I try to run, XCode complains that "iOS 17.0 is not installed". Does this mean that iOS 17.0 device support is required in addition to iOS 17.1.2, in order to run on a 17.1.2 device? This would make sense if it just said "iOS 17", rather than "iOS 17.0".

I am seeing DCErrorInvalidInput returned from DCAppAttestService generateAssertion: in production. Can anyone suggest what might cause this, and what I should do in response? The documentation says of this error code: "An error code that indicates when your app provides data that isn’t formatted correctly.: The only input to the method is the key ID and the data hash. I generate the hash with CC_SHA256() and then put the bytes in an NSData. I don't think much can go wrong with that, though I can't see exactly what is being passed in my diagnostics. There is another error response, DCErrorInvalidKey which I handle separately. I am wondering if problems with the key ID are being reported as "invalid input" rather than "invalid key". I can see the key ID in my diagnostics and it looks legitimate, i.e. it's 32 random-looking bytes, base64-encoded. Suggestions anyone?

Dear Experts, I have App Attest deployed in an app that is currently in TestFlight. Its works OK most of the time. For one particular user, however, attestKey fails with DCErrorInvalidKey for a new key that it has just created. I have some insight into what the app is doing because I send diagnostics to the server. It seems that for this user, the sequence of events is: Initially the app has no key ID saved. The user initiates an action that requires App Attest-signed communication with my server. The app calls generateKey which seems to succeed. The app fetches a challenge from the server. The app calls attestKey. attestKey returns DCErrorInvalidKey. The app doesn't save the key ID persistently, so next time the same thing happens. attestKey really shouldn't fail with the invalid key error for a key that it has just created, should it? What could be going on here?

Has anyone successfully completed DSA compliance phone number verification using the "receive a phone call" option? It seems that Apple first tries to send an SMS. You then have the option to resend another SMS, to receive a phone call, or to upload documents. When I choose to receive a phone call, it seems that the Apple system calls me but it hangs up without reading out a code. Has anyone got this to work?

I've added .storeButton(.visible, for:.policies) to my SubscriptionStoreView, and the buttons do appear, but when I tap on them I get a sheet that just says "Terms of Service Unavailable / Somethng went wrong. Try Again.". (similar for Privacy Policy). Is this expected in development? Will these start working correctly in production? (and, more importantly, in App Review?) The docs say that these use the values (i.e. URLs) set in App Store Connect, but that I can override those. This is a new app. Is that wrong, do I need to set the URLs explicitly? Edited to add: the console reports: Failed to fetch terms of service and privacy policy: Error Domain=NSURLErrorDomain Code=-1011 "(null)"

Dear All, I've recently released a new app with a subscription. It has a 3-day free trial and a 1-year subscription, and I've enabled a grace period of 16 days, but the grace period is enabled only for paid-to-paid renewals. As it's a new app, no-one has reached the end of their subscription yet; there will not have been any paid-to-paid renewals. Yet I see a small number of "enter grace period" and "renewal from grace period" events reported in App Store Connect. Can anyone explain why this could be?

Anyone else seeing this? I'm sometimes getting "too many redirects" errors from Safari when trying to view this forum: It goes away after a while, randomly. Also: this is hard to debug; the Network tab in the Safari Javascript Console only shows the final load of the error page, not the failure. Is there a way to see the actual redirect loop URLs?

Is this symbol, which Safari uses to the left of the address bar, in the public SF Symbols set? What's it called?