Hi everyone, I'd like to raise a concern about the transparency and fairness of Guideline 4.3 reviews. A rejection that says an app duplicates existing functionality or is indistinguishable from widely available apps should explain what specifically led to that conclusion. General categories, followed by an instruction to make substantial improvements, do not give developers an actionable path forward. Which functionality is the problem? Which aspects need to change? What standard would satisfy the reviewer? Without concrete examples or a clear threshold, the assessment feels highly subjective. Developers can spend significant time building a product and still be left guessing what would make it acceptable. In my view, independently developed apps should be able to compete in existing categories. Products naturally share basic functionality when they solve the same problem. Competition can come from a better workflow, a clearer interface, privacy, pricing, accessibility or serving a different audience. It should not require every developer to invent an entirely new category. If similar functionality alone is enough to reject a new entrant, that risks protecting established apps from competition. That feels unfair to independent developers and limits users' choice. The first app to enter a category should not effectively own that category. I support preventing copied apps, repetitive submissions and low-quality template spam. But there needs to be a clear, consistently applied distinction between spam and legitimate alternatives. A developer should be able to understand the reasoning behind a rejection and respond to specific concerns. Could Apple clarify: What specific evidence should reviewers provide when rejecting an app under 4.3? How is ordinary competition within a category distinguished from unacceptable duplication? What concrete criteria establish sufficient differentiation, and how are they applied consistently? When 4.2.6 is mentioned alongside 4.3, can the reviewer explain whether there is an actual template-related finding and what supports it? What is the best process for obtaining an actionable explanation when the rejection only lists general possibilities? Asking developers to make substantial changes is reasonable when the issue is clearly identified. Asking them to guess at an unstated standard is not. Clear reasons and consistent criteria would help developers improve their products while giving new entrants a fair opportunity to compete. Has anyone successfully obtained specific, useful clarification in this situation?

I’d like to suggest an improvement to the App Review process, particularly around Guideline 2.1 – Information Needed for new app submissions. Recently, I submitted a new app and received a request asking for a screen recording demonstrating the app’s core functionality, along with information about tested devices, target audience, external services, regional differences, and other details. The problem is that I had already uploaded a screen recording when submitting the app. This makes the process frustrating and inefficient for both developers and Apple. If the information has already been provided, reviewers should ideally check the submitted materials before requesting them again. Otherwise, developers have to spend additional time responding, and Apple reviewers also spend additional time handling unnecessary back-and-forth. If a screen recording and these additional details are now effectively required for most new app submissions, I think Apple should make this part of the App Store Connect submission workflow. For example, App Store Connect could provide dedicated fields for: App demonstration video Tested devices and OS versions App purpose and target audience Test/login instructions External services and AI services used Regional differences Regulatory or licensing information, where applicable This would be much clearer than putting everything into a general “App Review Notes” field. In the AI era, the number of apps being created and submitted is likely to increase significantly. Apple’s App Review process needs to evolve alongside this. Repeatedly requesting information that developers have already supplied wastes time on both sides and creates unnecessary hurdles for developers trying to bring new ideas and innovations to the iOS ecosystem. I hope Apple can consider making these requirements more structured, transparent, and automated within App Store Connect. The goal should be to make App Review both more thorough and more efficient — for Apple reviewers as well as developers.

Download failed. Domain: DVTDownloadableErrorDomain Code: 41 User Info: { DVTErrorCreationDateKey = "2025-10-26 06:59:38 +0000"; } Download failed. Domain: DVTDownloadableErrorDomain Code: 41 Failed fetching catalog for assetType (com.apple.MobileAsset.iOSSimulatorRuntime), serverParameters ({ RequestedBuild = 23A8464; }) Domain: DVTDownloadsUtilitiesErrorDomain Code: -1 Download failed due to a bad URL. (Catalog download for com.apple.MobileAsset.iOSSimulatorRuntime) Domain: com.apple.MobileAssetError.Download Code: 49 User Info: { checkConfiguration = 1; } System Information macOS Version 26.0.1 (Build 25A362) Xcode 26.0.1 (24229) (Build 17A400) Timestamp: 2025-10-26T17:59:38+11:00

Cannot download 18.5 simulator Download failed. Domain: DVTDownloadableErrorDomain Code: 41 User Info: { DVTErrorCreationDateKey = "2025-07-12 08:12:00 +0000"; } Download failed. Domain: DVTDownloadableErrorDomain Code: 41 Failed fetching catalog for assetType (com.apple.MobileAsset.iOSSimulatorRuntime), serverParameters ({ RequestedBuild = 22F77; }) Domain: DVTDownloadsUtilitiesErrorDomain Code: -1 Download failed due to a bad URL. (Catalog download for com.apple.MobileAsset.iOSSimulatorRuntime) Domain: com.apple.MobileAssetError.Download Code: 49 User Info: { checkConfiguration = 1; } System Information macOS Version 15.5 (Build 24F74) Xcode 16.4 (23792) (Build 16F6) Timestamp: 2025-07-12T18:12:00+10:00