Does anyone know how battery state notification (UIDevice.batteryStateDidChangeNotification) is supposed to work regarding app foreground/background state? Assume there is no other reason why the app is running in the background. I have enabled UIDevice.current.isBatteryMonitoringEnabled when the app was in the foreground. What should happen if the external power is later connected or removed when the app is in the background? The docs don't mention this. Possibilities include I don't get a notification, so I should check the state myself when the app next comes to the foreground. I'll get a notification when the app next comes to the foreground, if the state changed while it was in the background. The app will be woken up in the background to receive the notification. The app will be kept running in the background while isBatteryMonitoringEnabled is true. It looks as if it's doing either 3 or 4, which I find a bit surprising. But is this influenced by the fact that it's connected (wirelessly) to the debugger?

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?

I'm using CMMotionManager startDeviceMotionUpdatesUsingReferenceFrame: CMAttitudeReferenceFrameXTrueNorthZVertical and have set the NSMotionUsageDescription ("Privacy - Motion Usage Description") property in the info.plist. But I don't see a permissions popup. I also don't see any mention of this in the app's section of the Settings app. When is this usage description string used? I wonder if there is some connection between the motion permission and the location permission, which I also use?

Dear Experts, When I use PHImageManager's requestImageDataAndOrientationForAsset method I always seem to get JPEG data, even when the original items in the photo library are PNGs (such as screenshots) or HEICs. Have I missed a setting somewhere that determines whether or not a "most compatible" format is used in this API? Thanks.

Does anyone else use the "Download CSV" button on the Search Ads website's billing page? I used to use this successfully to download files that I could import into my accounts database. But when I tried it today, the file it returned was an XLSX. Has anyone else seen this? Any work-arounds?

I am experimenting with drag-and-drop on iPadOS. If I drag a JPEG image from a webpage in Safari to my app, I get items of types public.jpeg and public.url. Typically, the URL is the URL of the image. If, however, the image is itself a link, then the URL seems to be the target of the link. Is there some way that I can always get the URL of the image itself? Is there some way that I can determine whether the URL I have received is the URL of the image or of a link?

Dear Experts, My app is observing UIPasteboardChangeNotification in order to enable/disable its paste button. I do not seem to be getting any notifications when other apps copy to the clipboard. For example, if I have my app and Safari in split-screen on my iPad and I copy something in Safari, I don't see the notification. Similarly if I switch to Safari, copy something, and switch back to my app, I do not get the notification either when I'm in the background or when I return to the foreground. The only time that I see UIPasteboardChangedNotification is when the clipboard is modified by my app itself. Is this supposed to work? Is there some other way to get notified when the clipboard is changed by another app? Thanks.

Dear Experts, In "limited access" photos mode, I present a PHPickerViewController. It shows the entire photo library, with a note at the top saying that the app can only access the items that I select. I select a photo. In the delegate method, I get a PHPickerResult containing a plausible-looking string for the assetIdentifier. It's the same string that I get for that photo in "full access" mode. Should this photo now be accessible, or do I need to do something else at this point? When I call fetchAssetsWithLocalIdentifiers using this assetIdentifier, I get no results. When I call cloudIdentifierMappingsForLocalIdentifiers, I get error PHPhotosErrorIdentifierNotFound. In "full access" mode, both work OK. What am I missing? Thanks.

Does anyone have recent experience of what App Review consider acceptable for location purpose strings these days? My map apps simply display a blue spot on the map showing your current location when you turn on the app's location button. That data doesn't leave the app; I'm not selling it to anyone, or doing anything nefarious. For years, I've had concise location purpose strings such as "Your location will be shown on the map". Now, App Review seem to find that inadequate. They say: "One or more purpose strings in the app do not sufficiently explain the use of protected resources. Purpose strings must clearly and completely describe the app's use of data and, in most cases, provide an example of how the data will be used. Next steps: Update the ... location purpose string to explain how the app will use the requested information and provide an example of how the data will be used. " I've just look at what Apple Maps uses as its purpose string, and it's just "Your location is used to show your position on the map, get directions, estimate travel times, and improve search results." I'm only doing the first of those things, so surely "Your location is used to show your position on the map" would get approved, right? Wrong! I have similar issues with the photos purpose string.

The WWDC video "What’s new in App Store Connect" describes a new feature to nominate your apps for app store features. Does anyone know when this is expected to be available to use? I don't see it immediately, and I don't think the video mentioned a timeline for its general availability.

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?

If I use UIEditMenuInteraction to present an edit menu, it has a dismissMenu method that I can call to remove the menu when necessary. When I use UITextInteraction, I get an edit menu automatically that is normally presented and dismissed at appropriate times. But sometimes I want to dismiss the menu myself, and I can't find a way to do that. Am I missing something? I was hoping to find that UITextInteraction inherited from UIEditMenuInteraction, or had some other way to access the underlying menu in order to dismiss it. But it seems that the menu must be a private part of the UITextInteraction implementation. The particular case that I need to deal with is when I call resignFirstResponder. This seems to cause the keyboard to close and the insertion point and any selection to be hidden, but if an edit menu was shown then it remains visible (a ghost!). If anyone knows of an alternative to resignFirstResponder that will make UITextInteraction tidy up properly, that would also be useful to know. Thanks for any suggestions!

I am attempting to use UITextSelectionDisplayInteraction. It basically works, but I'm unsure how the selection handles are supposed to work. The documentation is minimal and the WWDC video (2023 session 10058) doesn't say much either. As the name suggests, it seems that this interaction only displays the cursor, selection background, and handles. As I change the selection, it updates these views. So if I want the user to be able to drag the selection handles I need to implement that, right? OK, so I add a gesture recognizer to each selection handle. But this doesn't seem to do anything, i.e. the gesture recognizer action never seems to be invoked. Maybe I'm doing something wrong - but I'd like to understand what is supposed to happen. Is adding a pan gesture recognizer to each selection handle the right approach? P.S. I wanted to tag this "WWDC2023-10058", but the per-session tags seem to have disappeared. Is this a forum bug, or deliberate?

Dear Experts, I've just received the exciting new email from App Store Connect telling me that I'm using a "required reason" API call and need to declare it in my privacy manifest. Of course this is easy to fix, I'll just add the code to my privacy manifest - but I thought I'd at least go through the motions of trying to work out what function I am calling and from where. First issue is that the email just tells me that the app "references one or more APIs that require reasons ... including NSPrivacyAcceeedAPICategoryFileTimestamp". Dear Apple, why on earth can't you actually tell me the specific function that I am calling? (FB13689896). So let's see if I can work out what has been detected. I look at the app binary: % objdump --syms App.app I think that is probably more or less what App Review must get from their scan, right? So I can see _stat in there but it doesn't know the corresponding source file. So I go to the build directory with the object files and extract symbols from them all individually, using objdump --syms. Provided that I've not enabled link-time optimisation that works and I can find ... zero calls to stat(). Which tells me that my C++ std::filesystem calls have not been detected! Interesting. So if you want to bypass this amazing new privacy technology, I guess that's the way to go. Anyway if there's a call to stat() in the binary but not in the object files, it must be coming from one of my .a files. That's a bit more difficult to track down as (1) my .a files are not in a convenient single directory, and (2) they may have calls to stat() in archive members that aren't needed and aren't included in this binary. So the question: is there some convenient way to take the binary and identify which object files or static library archive members resulted in which of its UND symbols?

I visit https://appstoreconnect.apple.com/apps A banner at the top of the screen tells me that I need to "provide and verify information regarding your account" for DSA compliance. I click on the "complete compliance requirements" link. The address shown for my business on this page is correct. I click on "Complete Compliance Requirements for (business)" near the top of this page. The address is also correct here. I click on "Complete Compliance Requirements" near the top of this page. This presents an "are you a trader?" popup; I select "This is a trader-provided account" and click Next. This shows a popup headed "Contact Information Verification". This page shows the wrong address. It shows an old personal address, pre-dating the establishment of my business. This popup tells me to contact Dun & Bradstreet to update my address. I click on the "Learn More" link. I follow the instructions to find my business on the D&B website. Of course Dun & Bradstreet already know the correct address for the business, so I am unable to change it. The result is that I am unable to complete DSA compliance. I think the root cause is that I had a personal developer account which Apple transferred to my business when I established it in 2018. Anyone else seeing problems like this? FB13687820