"In-App Purchases and Subscriptions" will be back when you get your current submission accepted and then create a new software update submission. In other words, it won't be back until you get your current submission approved, I guess.

What happens if she deletes the app and then tries purchasing a subscription plan again?

If a previous reviewer could access the IAP screen, why would the current reviewer claim it doesn't exist? I had my apps rejected for the same reason at least twice last year. (1) A reviewer may not have scrolled all the way to the bottom to see a list of IAP products. In this case, I laid a button at the very top of the store sheet that was labeled 'Jump to in-app purchases' to make sure that the reviewer can go directly to the product list. (2) Right after the company introduced iOS 26, I submitted a new app to the review. And it was rejected. Initially, I tested the app with actual devices running iOS 17.x and iOS 18.x. When I installed iOS 26.0 on my iPhone 14, I found out that all toolbar buttons with asset images were shrunken to 2 px times 2 px dots. And I somehow managed to stabilize the toolbar image size. While I was working on a workaround, the company had introduced iOS 26.0.1 to the public. These are 2 reasons I can think of for inconsistent results for now.

By saying "I guess," I mean that I'm not the one to make the final decision when it comes to somebody else's system since I am not referring to a specific, written set of instructions by the company. Then where does my 'guess' come from, you may ask. I submitted a new app to the review at the end of the last year. Initially, I was going to have subscription plans. But 'Prepare for submission' didn't disappear, as chronicled in this thread. So I decided to release it as a free app with no IAPs. While waiting for the review, I realized that the "In-App Purchases and Subscriptions" section disappeared. Yesterday, I prepared a software update, and the same section was back. Soon after I clicked on the submission button, this section disappeared once again. In all, it doesn't bother me if you don't listen to me. I don't work for Apple, Inc.

A local support person from the company says that my subscription plans are ready for submission even though the status for both localization options are Prepare for Submission. He or she says the following is written somewhere although I don't see it. You uploaded all the metadata needed, but you have not yet sent it to Apple for review. He or she says that the Prepare for Submission status for the localization options only suggests that the subscription group isn't submitted for the review and isn't approved. That's a terribly bad design.

The app includes meaningful native iOS functionality beyond web content, including: • Native Core Location access (with permission handling) • Native reverse geocoding using CLGeocoder via a custom Swift Capacitor plugin • Native clipboard integration • Native iOS share sheet integration • Apple Maps deep linking • Custom CAPBridgeViewController with explicit plugin registration Are reviewers supposed to know what CLGeocoder is? I don't know what Swift Capacitor is. CAPBridgeViewController? I have never heard of it. If you say "Our app uses CAPBridgeViewController," regular app users would most likely to say... "So what!?" My point is that I'm sure you know what you are talking about, which doesn't mean those features are commonly known to reviewers and app users at all ages. Perhaps, you should use the language that people at your grandparents' age understand.

If you didn't, you should have written those 5 key points in the App Review Information section before you click on the Submit button though you probably want to make it more concise. Back in 2011, I had a desktop application whose name contains the word 'Rip.' The reviewer rejected by saying Illegal file sharing The app doesn't even read DVD or VOD files. I never said anywhere that the software title had anything to do with DVD or VOD file format. Since then, I give quick steps for them to take and some points to reduce confusion and misunderstanding before they start reviewing my submissions in the App Review Information section.

The Appeals Board was quite neutral till 15 years. Then they started to side with reviewers some 7 or 8 years ago even when the reviewer was totally out of line. That was a dark age. I don't deal with the Appeals Board now only because they are typically 2 or 3 weeks behind. By the time I hear from them, I often manage to convince the reviewer that they are wrong. That being said, unless you are confident that you can change reviewer's mind, you don't want to take the case to the Appeals Board. Now, I'm afraid you are at the end of the rope. There is no way around it once the Appeals Board rejects your case. You probably don't want to hear it, but if I were you, I wouldn't waste any more time on this case, accepting a financial loss and moving on to a next project.

It looks to me that the icon above is a result of the iOS 26 glass effect.

Where does that file extension (.icon) come from? I have never heard of it. The macOS system traditionally uses 'icns' as an icon file format. But not really any more...

I submitted my first app to approval process last week. Within couple days it was accepted and state changed to 'Ready for Distribution'. It has been in that state for a week. So what's the issue? Are you saying that the status is 'Ready for Distribution' but that the app is not being distributed? Or are you suggesting that there should be another status after 'Ready for Distribution'?

Is it realistic to expect App Store review approval when requesting Full Disk Access? Under what conditions or use cases is such permission typically accepted by Apple? You haven't really said how you intend to implement what you call 'Full Disk Access.' I currently have two desktop applications with the 'Full Disk Access' capability with read/write permissions. If that's what you are talking about, your application is allowed to have read and write permissions, as opposed to just 'read' if the application is designed to save files to the disk. So, again, Is it realistic to expect App Store review approval when requesting Full Disk Access? Under what conditions or use cases is such permission typically accepted by Apple? I would say 'Yes.' But reviewers are not predictable. I had one desktop application rejected by a reviewer 6 or 7 years ago. His or her reason was, as I recall, the application did not write files to the disk when in fact the application did use NSSavePanel to let the user save files to the disk. I had the rejection reversed soon, but you know... That's how the review process works. Actually, I may be wrong in my earlier statement. I am not certain how one of my desktop applications has gained the Full Disk Access' status although it has read/write permissions. I have a lot of home-brewed desktop applications with read/write permissions, but they aren't listed in Full Disk Access.

I use custom app icons on my Home Screen, and the entire reason they work visually is because they do not have borders. What are custom app icons? Toolbar button images, maybe? a design choice that many users did not ask for and cannot customize. How do you know? Who are they? I like the glass effect, though, to some extent. Please consider making the icon borders optional or allowing users to revert to the previous borderless icon behavior. Make them optional to whom? To the app developer? If so, what if the user wants them?

I am afraid your statement is quite confusing. You first talked about what happened in 2012. You talked about it again in the middle. You talk about whatever happened in 2019. You then talk about having purchased iPhone 17. Yet, I can hardly tell where you are having difficulty. Are you having difficulty creating an Apple ID? Or are you having difficulty enrolling yourself in the developer program? If it's the former, this isn't the right place to ask your question as Apple people often explain that this place is intended for software developers. If it's the latter, where does your iPhone 17 come into play? As long as I watch the YouTube video titled 'How to Enroll in Apple Developer Program (Step-by-Step)' with a British accent, I don't see the button you refer to as 'the registration button.' The following is a list of buttons I see in the video. Start your enrollment Continue Purchase Meanwhile, I had to create several new Apple accounts in order to test a new iPhone app that uses iCloud accounts in November and December. I remember that creating an each account required me to authenticate my ID with an iPhone. That being said, it sounds like you haven't reached a point where you are trying to enroll yourself in the developer program.

the system (iOS) will/should then vend to my app the previously tapped cloudKitShareMetadata (or share url) The verb 'to vend' means to sell (something). So what do you mean by that? Isn't it just the matter of having the app access the CloudKit record type and then create a new record when it starts up for the first time? I would stay away from it, but if use of the CKShare object works, that's good for you. I was forced to change my plans twice after I didn't get the result I wanted with it in December.