If I use SubscriptionStoreView.init(groupID), it seems to be able to look up all the Products that have that subscription group ID. But I don't see any public method for doing that myself. Am I missing something, or is SubscriptionStoreView using a private method to do this lookup? I know that historically it has always been necessary to know the product IDs of all the products you want to sell; you have never been able to ask Store Kit to give you a list. SubscriptionStoreView doesn't seem to have this limitation, which is a bit surprising.

I am looking at StoreKit Views, new in iOS 17. In a SubscriptionStoreView, is it possible to show the user their current subscription's renewal/expiry date, or to present a cancel button? According to https://developer.apple.com/documentation/storekit/storebuttonkind/4203108-cancellation , storeButton for: .cancellation is "A type of button for canceling a subscription.", but actually it just shows a (X) button at the top right to dismiss the view - and this is what the WWDC video presenter (2023 session 10013) seems to believe it should do (around 28:30, "The cancellation button shows a platform-appropriate button to dismiss the view"). Is that a documentation bug? It seems that I can show renewal/expiry dates and a cancellation button if I use AppStore.showManageSubscriptions(...). But this is rather disjointed. Shouldn't I be able to show all of this in one place? Does my UI need two separate buttons for these overlapping features? Or am I missing something?

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 All, I have a paid app which has in-app purchases to unlock additional content. In my App Store screenshots and preview videos, I used to indicate which content was paid and which was free with labels superimposed over the screen captures. App store review guideline 2.3.2 supports doing this - in fact, it seems to require it: 2.3.2 If your app includes in-app purchases, make sure your app description, screenshots, and previews clearly indicate whether any featured items, levels, subscriptions, etc. require additional purchases. But App Review don't like it. Some years ago they complained about the labels on the screenshots, which I removed. Now they are complaining about the preview videos. They cite guideline 2.3.7, which says (in part, my emphasis): 2.3.7 ... Metadata such as app names, subtitles, screenshots, and previews should not include prices, terms, or descriptions that are not specific to the metadata type. ... So these guidelines seem to be contradictory. If I label a screenshot as "free" or "paid", they consider that to violate 2.3.7. (I'm not showing an actual "$1.23" price, just "free" or "paid".) But I need to indicate whether the content shown is "free" or "paid" in order to comply with 2.3.2. (And I want to label it as such, because I don't want users to misunderstand what is included with their initial purchase.) Has anyone else had this problem? I wonder if there is some particular wording that they require, e.g. "Requires in-app purchase" rather than "Paid". Or something rather than "free". There is a limit to how much text I can legibly add without obscuring the actual content, so I have tried to keep it brief. I did refer to 2.3.2 in my reply to App Review, but they haven't addressed that; they've accepted the update as a bug fix. Ultimately I'll just do what they want - it always seems easiest - but I do have real concern that my customers are worse off without these annotations.

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

6.7-inch screenshots have become compulsory at some point since I last created an app update, and I will need to purchase a new device to satisfy this requirement. The App Store Connect media manager says that 6.7-inch screenshots must be 1290 x 2796 pixels. Looking at device specs (e.g. at everymac.com), it seems that this is the size of the iPhone 15 Pro Max, iPhone 15 Plus and iPhone 14 Pro Max. However the iPhone 14 Plus and older are fractionally smaller at 1284 x 2778, despite also being described as "6.7-inch". Does anyone know if App Store Connect will accept 1284 x 2778 screenshots for the "6.7 inch" category? A refurbished iPhone 12 Pro Max is about half the price of an iPhone 15....

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?

Dear Experts, When I try to use Address Sanitizer on my iOS app, it reports "attempting free on address which was not malloc()-ed" whenever a C++ exception is caught. If first saw it inside Apple's libFontParser and filed FB13271831, but I now see it in my own code. The Address Sanitizer stack trace always starts like this: #1 0x215766ae8 in __cxa_decrement_exception_refcount+0x40 (/usr/lib/libc++abi.dylib:arm64e+0x13ae8) Having looked up __cxa_decrement_exception_refcount in the C++ ABI docs, my guess is that the C++ runtime is creating and destroying the exception objects in some way that Address Sanitizer doesn't properly understand, causing it to think that they are being freed without having been allocated by malloc. This is only really a problem because it does not seem possible to continue after ASan has reported this error; the app is terminated. Question: is there a way to tell Address Sanitiser to ignore errors in this function? And/or, is there a way to continue after the error? Thanks.

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'm confused by the stats on the TestFlight "builds" screen. See below. There are more crashes than sessions. So the definition of "session" can't quite be what I thought. Does a session have to last more than a certain amount of time to be included? Do sessions that end in a crash not count as sessions? Do multiple invocations within a short period of time count as a single session? The number of sessions falls over time. I.e. once I have released a new version, the reported "Sessions" numbers for older versions slowly fall. Maybe as soon as a user has used version N+1, all their sessions for version N are removed from the stats? The "invites" column is clearly the same for every version, while it should have been slowly increasing. Is there any value in these numbers?

In TestFlight crash reports, all I see is the stack trace. Is there any other information hidden in there, such as the specific signal (etc) that caused the app to terminate? Thanks.

I've just downloaded Xcode 15 (3.18 GB), and when I start it it downloads "additional components". It's currently downloading "iOS 17.0 Simulator" (7.56 GB). I don't need the simulator, but I do need to compile for iOS and run on devices. Do I need this "simulator" download? I note that while the small download progress window says "iOS 17.0 Simulator (21A328)", the main Xcode window won't let me compile/run the project because it is "Downloading iOS 17.0..." - though I'm not sure if the "..." at the end of that is a truncation eliding the word "Simulator".

Dear experts, I get glyphs from the system font using CTFontGetGlyphsForCharacters, something like this: UIFont* uifont = [UIFont monospacedDigitSystemFontOfSize: s weight: w]; CTFontRef font = (__bridge CTFontRef)uifont; CTFontGetGlyphsForCharacters(font, ....); The characters that I ask for are basically latin-1 plus a few others. The app is not localised for Chinese. When I change the phone's default language to Chinese, this code gets glyphs for most characters OK but it fails for a few punctuation symbols: 91 = [ 93 = ] 183 = middle dot 8220 = left double curly quote 8221 = right double curly quote Can anyone guess what's going on here? What's special about those characters? Thanks, Phil.

Has anyone paid a graphics designer to produce custom SF Symbols for them? Would you care to share your experiences? I paid for some custom graphics a decade ago; the results were OK but not amazing. I forget how I found that guy. No doubt everything has changed since then.