“4.3”

Precedent & Fairness in Enforcement Rove is an intentional, safety-forward dating product. It is neither spammy, low-effort, nor duplicative — and yet we continue to face rejections under Guideline 4.3(b). This raises serious concerns about selective enforcement of App Store policy. In the past 60 days, Apple has approved a wide range of new dating apps, including: • Ready: Dating & Relationships – Launched June 3, 2025. Marketed as a native app for “intentional dating,” with a thematic approach directly comparable to Rove. • Meetline – Launched May 15, 2025. A transit-based connection app that limits conversations, just like Rove limits user visibility to avoid overload. • Yuzu – Asian Dating & Friends – A non-swipe app tailored to a specific community — proof that niche dating concepts are not inherently duplicative. • Metya / DateGuard – Two safety-first apps that use community filters and moderation-centric design. These are directionally aligned with Rove’s own innovation in safety a

Excellent points raised. I believe that the problem with 4.3 rule is that Apple does not evaluate at what point the difference in content justifies the existence of a separate app.We are developing theory test apps for the UK market and were contacted last year demanding some consolidation. We've been able to resolve it with Apple by removing all our paid apps from sale and instead using in-app purchases. I thought that it was a great solution as it indeed reduced the number of apps while allowing us to keep one app per each vehicle category (Car, Motorcycle, etc.) Recently, we've been contacted by App Review, and they now demand that we make further consolidations.From a marketing point of view, further consolidation makes no sense. Users are accustomed to seeing learning materials being separated by a vehicle category and would be puzzled if such a real-life model did not exist on the App Store. Imagine if you search for Motorcycle Theory Test and all you see are a list of Driving Theory Tests.The

Oh my.... and I thought I was the only one having this problem with AppleI have four AppsPoolAppLive, DartsAppLive, SnookerAppLive and LeagueAppLive, all have different features, logos, text and all are marketed brands.All use a core scoring feature (obviously)All these were on the App Store before this 4.3 policy was introduced or changed.Now Apple wants me to produce one App that has an initial menu to pick one of the sportsCoding this is easy enough, but why would I want to do this?Each App has it's own identity and brand by design. Each is linked to a customer website , for example mktpl.poolapplive.com each has been advertised seperately at cost to myself. I want customers to find my App by simply typing in the brand name as they already do on both Android and iOSI am not spamming. I find this really quite insulting, if it wasn't for developers like myself Apple would be selling their devicesWe also pay for this service (unlike other app stores)I agree spamming should not be allowed, but this is

Same here. Can`t solve it. Getting this problem during the upload to ITC after a successful build. A collegue of mine can upload the exact same app but gets than an email with the following help:Invalid Binary Architecture - iOS 3.0 introduced support for multiple binary architectures. If your binary is built for multiple architectures, your Info.plist must have a MinimumOSVersion key with a value of at least 3.0. Additionally, if your app is intended to support earlier iPhone and iPod touch models, your app must contain at least an armv6 binary; thin armv7-only binaries will not be accepted unless the armv7required device capability is also present in the Info.plist UIRequiredDeviceCapabilities key or the MinimumOSVersion key has a value of 4.3 or higher.- our deployment targets are iOS 11 and watchOS 4- the Build Setting Valid Architectures for iOS is arm64- the Build Setting Valid Architectures for watchOS is arm64_32 armv7kIn the iOS info.plist we have in the Required device capabilities with arm

Hi meaton, Thanks for your reply. IANA has defined a well-known range, 192.0.0.0/29, in [RFC6333], which is dedicated for DS-Lite. Android implement CLAT since 4.3 version, i will got a 192.0.0.x ip address as expected when i connect to the NAT64 WIFI . iOS 15 /macOS 12 will not got a 192.0.0.x IP assigned on the same NAT64 WIFI. The same issue was found on https://www.reddit.com/r/ipv6/comments/10dylht/ipv6_ipad/. so, I think that 192.0.0.x is not vend back by the AP, but assigned by iOS 16/macOS 13. I doubt the latest macOS/IOS implement CLAT. Can you confirm it with the apple engineer？ ========================= https://www.rfc-editor.org/rfc/rfc7335.html https://www.rfc-editor.org/rfc/rfc6333 https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/uid/TP40010220-CH213-SW1 https://www.reddit.com/r/ipv6/comments/10dylht/ipv6_ipad/

Running Xcode 6 or Xcode 7 on OS X 10.10 or 10.11, is there a way to test my app on iOS 4/5/6? Xcode 6 supports building for iOS 4.3 and laterXcode 7 supports building for iOS 6.0 and later Can older simulators work in these newer versions of Xcode? No. If no to both, is there a way to make old versions of Xcode run on 10.10 and 10.11? Will they work? The earliest version of Xcode supported on 10.10 is Xcode 6The earliest version of Xcode supported on 10.11 is Xcode 7 I'm working on a project which has contractual requirements for supporting super old iOS versions. The app also has some users on those versions, so dropping support for them isn't an option at the moment. It is not possible to build an iOS app that supports iOS 4.2 with tools that are capable of building for the App Store.If/when Xcode 7 is required, it will not be possible to build an app that supports iOS 5.x.

You could create a single app for a single school. You might then be able to create a second, almost identical app for a second school but the AppStore might point to 4.3 and require that you generate a general app that can be individualized to any school. But think about it. If your app, say you titled it My Elementary School Info ,was available nationwide, and any school could create their own version, wouldn't that be cool? You could create a lite version that allowed anyone to explore how it would work. If they purchased an IAP then they could secure their school's name/location and become the administrator for entering the information for that school. Imagine 100's of school's doing that across the US. You could create a version in French for schools in St. Marteen or France.Any single user (i.e. parent of student) would only need to individualize the app once. They could select from a dropdown list or use a map - or the administrator of theior school could send them an automated email with a li

The ASRGS have recently been updated to say this:4.2.6 Apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app’s content. These services should not submit apps on behalf of their clients and should offer tools that let their clients create customized, innovative apps that provide unique customer experiences. Another acceptable option for template providers is to create a single binary to host all client content in an aggregated or “picker” model, for example as a restaurant finder app with separate customized entries or pages for each client restaurant, or as an event app with separate entries for each client event.And for reference:4.3 Spam Don’t create multiple Bundle IDs of the same app. If your app has different versions for specific locations, sports teams, universities, etc., consider submitting a single app and provide the variations using in-app purchase. Also avoid piling on to a category that is alr

I would try appealing the app rejection notice. Have you tried that yet? Explain the situation, and let them know that you deleted the other apps. Hopefully they allow that one in.The guidelines are very unclear. 4.3 Design - Spam has to do with not creating similar apps, but they also can delete apps they deem as low quality or a saturated category. It's a very broad spectrum, guideline, and it seems to only judge developers on a case by case basis. There doesn't seem to be any clear, black and white rules regarding the guideline. It's at the discretion of the reviewer's subjective opinion on the app submission.We've encountered both scenarios with our apps, and heard other stories from other developers too.I also believe that this guideline is a very slippery slope for Apple. How many developers that supported Apple by purchasing products will cease doing so? How many customers of legitimate developers, snagged by this new guideline, will drive consumers to other platforms, and in turn, other devic

The app guideline you mentioned specifically mentions dating apps so I'd assume the reviewer is applying this blanket guidance. It mentions the app must provide a unique, high-quality experience. I think you need to specifically explain to Apple why your app is different from the other dating apps. Also, I'd make sure the first run experience demonstrates these unique capabilities. If the Apple reviewer had a poor impression on the first run, that may have impacted their decision. 4.3 Spam Don’t create multiple Bundle IDs of the same app. If your app has different versions for specific locations, sports teams, universities, etc., consider submitting a single app and provide the variations using in-app purchase. Also avoid piling on to a category that is already saturated; the App Store has enough fart, burp, flashlight, fortune telling, dating, drinking games, and Kama Sutra apps, etc. already. We will reject these apps unless they provide a unique, high-quality experience. Spamming the store may lea

The same problem `Guideline 4.3 - Design - Spam Your app primarily features astrology, horoscopes, palm reading, fortune telling or zodiac reports. As such, it duplicates the content and functionality of many other similar apps currently available on the App Store. While these app features may be useful, informative or entertaining, we simply have enough of these types of apps on the App Store, and they are considered a form of spam. Next Steps We encourage you to review your app concept and incorporate different content and features that are in compliance with the App Store Review Guidelines.` I spent many days working with Apple, even changing and removing the horoscope, numerology,... functions, leaving only the features related to Tarot cards, but the results remained unchanged, Apple Guys did not care about the content of our application, they simply think that there are too many applications of this type on their store, it's unfair but we can't do anything else, even if our application is bette

I had chats with a few people from the review team.These are considered to be spams according to the guideline 4.3.- No similar app is allowed under your account. When they say similar, it simply means its appearance are alike. Even if targeted users are different, no similar app is allowed. Also they may say they are made using the same frameworks, it's nothing to do with the frameworks we think. It simply means they look similar. Even if the two apps are built upon completely diffrent codes (not built from a template), they are categorised as spams if they have similar user interface.- Releasing a free Lite version and a paid version is no longer accepted. Must use in-app purchase in one app instead of releasing an independent paid app. Otherwise they are rejected as spams.- Releasing upgraded new version as an independent app (like MY APP and MY APP 2) is not allowed. Old version must be removed from the store to release a new app as a different app. Otherwise they are rejected as spams.

Hello everyone, I’m reaching out to seek advice and support regarding a confusing issue I’m experiencing with my app’s review process. App ID: 6744330283 Here’s the situation: Versions 1.0 and 1.1 of my app were approved and successfully published on the App Store. However, updates 1.2 and 2.0 have both been rejected for Guideline 4.3 – Spam. The rejection happens extremely fast – less than 10 seconds after the app goes “In Review”, it gets rejected. There is no indication that the reviewer even launched the app. This is very frustrating because: The app has real user reviews, In-App Purchases, and active paying users. My app is 100% original – it is not a copy or template-based app. Even worse, the review process for versions 1.2 and 2.0 took over 7 days before even starting, and then they were rejected instantly, again without being opened. I’m happy to cooperate and improve my app further, but I feel like this may be a misunderstanding or a mistaken flag by an automated process. Has anyone experie

We are facing also the same issue with games for kids. All new games get rejected forGuideline 4.3 - DesignWe noticed that your app provides the same feature set as other apps that have been submitted to the App Store (either under your own account or across multiple developer accounts) and simply varies in content or language.Apps that simply duplicate content or functionality create clutter, diminish the overall experience for the end user, and reduce the ability of developers to market their apps.We encourage you to review your app concept and incorporate different content and features that are in compliance with the App Store Review Guidelines.Creating a container app for kids games seems crazy too. Kids cosume apps more like TV episodes (fast) so we create new app with new content, new topic and release as a sequel. It does not make sense to have one huge app (2-6 Gb) that combines all content inside. I really don't understand Apple vision for this kind of content. The worst part is, they do not