“4.3”

Update, August 23. Approved. The app has been approved and is live on the App Store. I want to be specific with my thanks, because a general thank you, Apple would miss the point. What changed the outcome was that someone on App Review actually read what I had written, instead of returning another template. Whoever that was, thank you. You did not just close a ticket; you made it possible to reach a person at all, and that is the whole difference between a process that works and one that does not. I am glad that fairness turned out to exist here, even if it took the better part of a month to find it. I have been candid in this thread about how the process looked from my side, so let me be equally candid now. Over twenty-three days, a first submission and a brand new account, I am certain I made mistakes of my own along the way. All's well that ends well. For anyone who lands here searching for a 4.3 thread, the honest summary is this. The specific element was never named to me, in any channel. What I

The wording change from “other developers” to “you or other developers” may be meaningful, but I would not treat it as proof by itself. The practical next step is to make your appeal evidence separate three possible issues: binary similarity, metadata similarity, and concept/category similarity. Your code-overlap numbers are useful, but for 4.3(a) I would also include evidence App Review can evaluate quickly: a table of all five affected apps, their Bundle IDs, App IDs, categories, core user flows and monetization; screenshots or a short video showing the document-parser feature immediately visible in Real Cost, not hidden behind purchase or onboarding; a comparison against the closest loan/debt apps, focused on user outcome rather than implementation; the exact build numbers and metadata versions that were rejected; a statement that there are no shared templates, contractors, SDKs, backends, assets or metadata patterns beyond ordinary SwiftUI scaffolding. In Resolution Center or a formal appeal, I w

Regarding different versions of the app for different country App Stores - you choose the countries in which each app is listed for sale. So you could use a different app for different countries. Each different app would actually be just a different version of the same app. But here you would run up against being rejected for '4.3 Spam' https://developer.apple.com/app-store/review/guidelines/#spam A better solution would be to have the app detect the country App Store from which it is purchased. I do not know a straightforward way of doing that because currentLocale is set by the user's preference not the user's App Store country. But another way is to make an SKProductRequest for an IAP - any IAP. During the response to that SKProductRequest you would examine the SKProduct's priceLocale.countryCode and that would reveal the counry of the App Store. https://developer.apple.com/documentation/storekit/skproduct/1506145-pricelocale?language=objcIn this process there is no need to actually make the purch

I could not get it wrapping at the right place. It looks like SwiftUI wraps to balance as much as possible to have same length text on both lines. No way to directly ask for a lineBreakMode, unless you go through UIViewRepresentable https://stackoverflow.com/questions/58469001/how-can-i-get-text-to-wrap-in-a-uilabel-via-uiviewrepresentable-without-having/58474880#58474880 . how to vertical align top for text High Tide Declare in the HStack (see below) I tested with a longer text just to check Text(1:08 AM (Tue 03) January and more) Why do you define explicit GeometryProxy var ? How to you call to initialise (in SceneDelegate for instance). I changed as follows to be able to test struct TideForecastInfoView: View { // var geometryProxy: GeometryProxy var body: some View { GeometryReader { geometryProxy in VStack { getHeaders(geometryProxy) TideForecastEntryView() // geometryProxy: geometryProxy) .padding(2) } .background(.white) .clipShape(RoundedRectangle(cornerRadius: 14)) .shadow(radius: 8) } } @ViewBuilder

Thanks Jay_limbani for this topic, I'm facing this issue as well. Let me borrow your topic to ask Apple App Review Team to assit me, hope you don't mind. Appreciate and thank you. Submission ID : c845d491-a9e6-46b2-81d1-acb659cf55c6 Dear App Review Team, I hope this message finds you well. Harmonian is not just another app; it’s a heartfelt effort to create a platform where individuals facing life’s challenges can find support, guidance, and hope. It is a unique, ad-free space focused on fostering mental well-being, empathy, and positive engagement—unlike entertainment-driven or generic platforms. Our mission is to make a meaningful difference by helping people connect, share, and uplift one another in a safe and harmonious environment. I understand your concerns under Guideline 4.3(a) regarding similarities with other apps. While certain features may seem familiar, I assure you that Harmonian is fundamentally different in its purpose, execution, and user experience. It is built with a focus on pers

Hi, Unfortunately, I am still facing the same issue. The latest versions have been rejected multiple times under Guideline 4.3(a) - Design - Spam: “We noticed your app shares a similar binary, metadata, and/or concept as apps submitted to the App Store by other developers, with only minor differences. Submitting similar or repackaged apps is a form of spam that creates clutter and makes it difficult for users to discover new apps.” I’ve carefully reviewed this feedback and made significant updates after each rejection, including adding new features, improving the UI/UX, rebranding, and introducing localization for more languages. Despite these efforts, the app continues to be rejected for the same reason. Here’s a summary of the key changes I’ve made so far: • Added ~10 unique new features • Completely revamped the UI/UX • Introduced new languages (localization) • Implemented TipKit • Rebranded the entire app • Improved security • Added entirely new modes The latest version of the app is vastly diffe

Hi @lazyvar, thank you for your insightful feedback! I completely understand your point about idea saturation. However, my game mechanics are quite different—for example, Scream Bird relies entirely on real-time voice/microphone controls rather than conventional touch controls. However, you're right, while the mechanics are different, the gameplay is quite similar, so it could be considered spam; if so, I accept that and agree if my game isn't approved. The main issue I'm facing is inconsistency: the game was approved after initial rejections (oddly, a version that had just been rejected was approved again, which is something I've never experienced before). But then it triggered a Account pending termination message when I submitted another game (Hopscotch). That's why I'm requesting Apple to officially review it. To elaborate on Hopscotch, it's a hopscotch game, quite unique and, in my opinion, quite challenging. You tap the left side of the screen to land with your left foot, tap the right side to land with

I feel it is less about what differences are inside the application, and more about Apple wanting to reduce the clutter in the Appstore.I am all for reducing the number of junk apps, clones, flappy games, and spam, but to outright tell all developers that they have to combine several games into a container app, some of which just don't belong together is overstretching this guideline.Apple needs to soften up the 4.3 guidelines, and allow developers to continue to publish apps that are branded toward the specific target market. eg: diet apps should not be combined. I as a customer would not want to download an app with multiple varying diets when I'm only looking for one specific one.Same with travel apps - if I want an app that caters to Paris traveling, I do not want NYC, Rome, London, Milan, & other cities in a bundle.The idea behind the agreement is well intended, but it's taken too far, without consideration for marketing & other things that come into play with the Appstore.So the topic i