In one of My Apps I want have a "tip" option for users, so they can support the developer if they like the App. As a small tank you, "tipping" will unlock a small bonus feature (nothing essential, but nevertheless nice to have). According to the Guidelines this is perfectly fine and explicitly allowed. So a created a few IAP options with different prices as non-consumable one-time purchases and the same number of consumable one-time-purchases with the same prices (so no subscriptions at all). The idea is: users should be able to tip multiple times if they want to (actually many users of the old App version have asked for this) Non-consumable IAP items can only be purchased once, but these can be restored (for example when switching to a new device). Consumable IAP items can not be restored, but these can be purchased multiple times. The idea is to combine both, so it is possible to tip multiple times (via consumable IAPs) and to allow the restore of previous purchases (to unlock the bonus feature). To do this, the App would at first only offer the non-consumable IAP items in its "tipping" screen. Only after these were purchased, the App would then only offer the consumable IAP items. Users tipping only once would always purchase the non-consumable item that can be restored. Users who have tipped multiple times would also have purchased the non-consumable IAP once and in addition the consumable item, so they all can restore and unlock the bonus feature. And no one is confused about any internal differences (consumable vs non-consumable), because the users will always see only one tipping option. I've created these IAP items and send them to Apple for review together with this explanation. All the non-consumable items got approved, all the consumable items got rejected with the following bizarre and unhelpful note from the review board: 3.1.1 - new IAP type New type: Consumable Previous type: Non-Consumable Recommend: Download The binary of the app is new (more than 14 days). What exactly does this mean? I've read section 3.1.1 of the guidelines and nothing indicates anything which would allow any rejection here. And what does "the binary of the app is new" mean? Sure the App is new (currently the new version is tested via TestFlight), but what does this have to do with the IAP? With normal "Appstore rejections" there was always a link provided which allowed to contact the review team. But there's absolutely nothing available here. Just this bizarre note which doesn't give any clue what's wrong. Does anyone have an idea what's wrong, or what I need to do to get this approved? How can I contact the review team that is responsible for this IAP review? BTW: I've tried to get this approved again after changing the description/names of the localization a bit (because these are the only things which are marked in red), but the same strange note came back. And the localization title and description can not have a long text, so there're not that many possible variations available which describe the IAP correctly.

I've watched some of the WWDC session videos about this topic and read the documentation and header files, but it is still confusing... Because I change the pricing model of my iOS App (it was a paid App and now it will be a free App with an In-App purchase), I want to check if a user of my App purchased the App in the past. So user who have already paid in the past will get the full access without the need to pay the IAP, while new users would have to do this. In one of the WWDC videos exactly this topic was covered and the solution would be to check out AppTransaction.originalAppVersion. This would be a simple and easy solution... ...Unless I read the information from the header file and documentation for this API. Here it says: The string value contains the original value of the CFBundleShortVersionString for apps running in macOS, and the original value of the CFBundleVersion for apps running on all other platforms. The problem here is that when I check the Info.plist of iOS Apps, the CFBundleShortVersionString is used for the main App version and CFBundleVersion is used for the "build" number. According to the cited documentation from above, AppTransaction.originalAppVersion would be totally uselesss on the iOS platform, because it would only return the build number and not the version number. So I'm confused. Can I use AppTransaction.originalAppVersion to get the original version that was purchased for iOS Apps? If yes, the documentation must be wrong and misleading. If no, how can I do this? I'm currently in testing and I only get "1.0" as originalAppVersion within the beta release. This could be either because I really only get the useless build number, or I get the "real" version because the App is on the device since version "1.0" on my device, or it is just a limitation of XCode while testing that it is returning version "1.0" but would return the correct version when the App was installed from the AppStore.... Can someone bring some light into this topic? Am I missing something or did I understand something wrong?

How exactly am I supposed to implement the following delegate method of WKWebView? func webView(_ webView: WKWebView, showLockdownModeFirstUseMessage message: String, completionHandler: @escaping (WKDialogResult) -> Void) The problem: the delegate method is defined to be available since iOS 13. But "WKDialogResult" in the completion handler is declared to be available since iOS 16. So this is already very odd and probably a bug in the API declaration. When I make the delegate method available since iOS 16 (via @available (iOS 16.0,*)) then Xcode gives me an error stating that this method must be provides for iOS 14 and later. But when it is made available since iOS 14 (or 13), then I get the error that WKDialogResult is only available since iOS 16. So this looks like a big messy bug in the API declaration, or did I miss something here? It would not the first bug in the API declaration of the WKWebView where the availability is wrong (for example the property "upgradeKnownHostsToHTTPS" is declared to available since iOS 14.5, but in reality it is only available since iOS 16 and would crash when used under iOS 14.5)

I’m trying to create complications für the Watch using the new WidgetKit. While the complications do show up fine in the preview in Xcode and also in the Simulator, on a real device the complications do never shown anything. The complications are listed and can be selected in the watch face settings, but the preview is always black, and when added to a watch face, it shows nothing. I can tap on this „nothing“ and the App launches, so the complication is actually there. But it doesn’t show anything. This is also true for the Watch App on the iPhone, which lets me add the complications to a watch face, but it also shows nothing. But in the Simulator everything works as expected, the complications show their content just fine. So it looks like the code is fine. The iPhone runs the iOS 16.1, and the watch runs watchOS 9.1 (right now the latest public releases) Does anyone having the same issue and maybe a solution or a hint, what exactly I should check?

On my iPhone 14 Pro I can observe that each day several (2-6) new logs appear in the "analytics" section of the system settings (I do have several hundreds already). Normally logs will be moved to the Mac when syncing the device to the Mac. But these "awdd" logs do not sync. I just get more and more on the device. It looks like this is going on from the start (when I purchased the device). Is something wrong with the device? How can I fix this, and how can I get rid of all these logs? It's almost impossible to find crash logs and other logs I'm interested in among all these awdd logs. The iPhone was always running the latest iOS releases. At the same time, my iPad did not create these logs multiple times a day (it also has a few, but only approx 2 per month).

The iCloud has the iCloud Drive (a could storage where the user can store any files and which Apps can access and share) and files in an "UbiquityContainer", which will be synced and only accessible to the App itself, not visible/accessible to other Apps. The information about the new Advanced Data Protection (ADP) only mentions iCloud Drive to be covered by ADP. Are the synced files within the UbiquityContainer also protected by ADP? If not, how can these be included?

Is this a bug or and intentional behavior of iOS 16.1: whenever I connect the device to my Mac and the Mac starts to create local backup of the device, I now have to enter the code of my iPhone on my device to confirm that I trust this computer? In the past this was only necessary once and after I confirmed that I trust the computer, the Mac would silently create a backup whenever the device was connected. Now this is no longer possible. Every single time a backup should be created (even when clicking on the "create backup now" button directly after a backup has just finished - so the device was not disconnected and connected again - I have to enter the code again). And the issue only affects the backup, all other data (music, podcasts, photos, contacts etc) do sync fine without entering the code (the bad thing is that I have to manually skip the backup otherwise the Finder would simply wait forever for the code to be entered on the device). Also Xcode accepts the device and installs/debugs Apps without any issues. This means it is not impossible to simply connect the device to the computer to let it sync. I always have to confirm that I trust the computer otherwise the whole syncing process stops just because of the backup... So what is wrong with the local backup feature? Is this broken now in iOS 16.1? Or is this intentional? BTW: This happens on 2 iPhones (both run iOS 14.1 RC), so it doesn't seem anything "damaged" on the device...

I'm trying to make my Live Activity (dynamic Island, lock screen) accessible for blind users as well. This does work, but not as I would expect it. The problem is that VoiceOver reads all the texts multiple times (at least 2 times, sometimes even 3 or 4 times) Even this simple example...       ActivityConfiguration(for: LiveAttributes.self) { context in Text("aaa")         } dynamicIsland: { context in             DynamicIsland {                 DynamicIslandExpandedRegion(.leading) { Text("bbb")                 }                 DynamicIslandExpandedRegion(.trailing) { Text("ccc")                 }                 DynamicIslandExpandedRegion(.center) { Text("ddd")                 }             } compactLeading: {                 Text("www")             } compactTrailing: {                 Text("yyy")             } minimal: {                 Text("zzz")             } will read "www www yyy yyy" just by tapping the dynamic island (not expanded) when VoiceOver is enabled. I would expect that all text would be read only once ("www yyy"). Is this a bug? Can I prevent that the text is read multiple times? Anyone having similar problems and maybe a solution?