“4.3”

Your reply clarifies that the charts and the practitioners’ interpretation of them are part of the app’s core workflow. That may be why App Review continues to classify the product under astrology, even though it also includes client records, payments and case management. I would make a product decision before requesting another review. If chart generation and interpretation remain central, explain what makes that experience substantially different from existing astrology apps and ask App Review which part of the submitted experience led to the 4.3(b) classification. If the core product is professional client management, consider whether it can stand on its own without astrology-specific charts, filters or claims. Changing the category or metadata alone is unlikely to help if the main workflow still centers on astrological practice. For a call or appeal, show the first-run experience and the complete workflow, then state plainly which features are astrology-related and which serve general client mana

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

While still struggle to find a solution for 4.3, knowing that some Apple employees might look into these forums, we have some thoughts which I believe holds true to many of the businesses affected by 4.3 to share:1. Many of white label businesses are not only not-spamming the App Store but are serious enough to always keep their apps up-to-date, follow all the Human Interface Guidelines and make sure they always fix bugs2. Many of our businesses are not extremely interested for the App Store presence; We could still live with hosting our links directly to the App Store for our clients to download, we are not particularily interested for search, therefore we don't really care to spam.3. Each of our so-called similar apps may share a common flow (fleet management through a map with route details for brianm@MCLEOD, food ordering for our business etc) but the real service we offer is completely unique for each of our client and their end-customers. Unique products, unique offers, prices, stores,

I am in the same boat. To target the little guys who are honest and create apps for small businesses that have different criterias and looks. We don't even make money off of it or are we targeting a wide audience. I mean if the YMCA in Louisville want their own app, we will create it and it will have similar funtionality as it hooks into our API scheduling system. The YMCA is targeting that area, not trying to make money. We dont use a commercialized template or app generation service. Our apps are unique, not another flashlight app. I mean are there really more then one YMCA of Louisville app?4.2.6 Apps created from a commercialized template or app generation service will be rejected.4.3 SpamDon’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

The guy who made a phone call said that my account is flagged as a spammer.I'm making apps since 2009.He said these things made me a spammer.releasing upgraded version as a separate app without removing the previous version.releasing free version and paid version (aka PRO version) as separate apps. ... this used to be allowed, but not anymore. Developers must use in-app purchase.Spam does not necessariy mean releasing many apps that were made from a single template. If the functionalities of two or more apps are very similar even though they have been built from scratch separately (like making an upgraded version from scratch), they become spams.And the similarity is decided by Apple, not by actual users who actually use the apps. This decision is mainly made by their appearances such as icon, UI, etc. They often refer to these elements as framework. Thus, when they say your apps share the same framework, it does not mean the apps use the same template framework. It simply means, they look too similar.Once yo

They rejected and reviewed it twice ( I did not submit anything). This is what I got after the status was changed several times: Hello, Thank you for your continued patience. We are writing to let you know that we have completed our evaluation of your app and account. Upon further review, we found that your app does not comply with the following guidelines: Guideline 4.3 - Design - Spam Your app has similar features to others. 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. You can avoid delays to future submissions by ensuring your apps don’t attempt to mislead or harm customers or undermine the review

Can you please help me with what exactly Apple is expecting for point number 2? You need to take a closer look at this document you were sent: https://www.ietf.org/rfc/rfc9458.html#name-key-configuration As the rejection said, the data format described there simply is not JSON[1]. The details depend on exactly what you're encoding, but the basic format is a series of fixed-size binary elements concatenated together. For example, this description from section 4.3. Encapsulation of Requests: Construct a message header (hdr) by concatenating the values of key_id, kem_id, kdf_id, and aead_id as one 8-bit integer and three 16-bit integers, respectively, each in network byte order. In other words, that creates a single chunk of binary data 56 (8+16+16+16) bytes long. [1] FYI, JSON tends to be a particularly poor format for this kind of security data, as the format itself is relatively wordy and the fixed-size data elements mean that most of the data (key names, punctuation, etc.) tends to end up at exactly

Since it takes a day or two to try and verify anything on this problem (no luck so far with anything I tried), francisaugusto, can you tell me if you're accessing the extension delegate from your complication controller at any point? In my early tests, it looked like the app could work indefinitely for as long as the complication didn't need to access the extension delegate (or extension delegate to access the complication controller). I had a setup where I would just show the time of the latest refresh on the complication, and I'd initiate the complication server refresh on the extension delegate, without setting any chanel of communication between the extension delegate and complication controller.Can you also tell me are you forcing the main thread execution onto anything background tasks related in your extension delegate methods? I was all along forcing the task completion onto the main thread, as per some suggestion I've read somewhere, but now I'm running a test where I've eliminated all main thread fo

Could it be the size of the zip? I think that’s it. Historically there have been 32-bit limits on zip archives. These were fixed with ZIP64 but it’s possible that notarytool didn’t get the memo. To test this I created a 4.3 GB file full of random numbers: % dd if=/dev/random of=random.dat bs=1024 count=4199218 I added it to my app and then resigned it. % mv random.dat Test718887.app/Contents/Resources % codesign -s Developer ID Application -f -o runtime Test718887.app I then zipped and notarised it as above. This time around, I saw the error you’re seeing: % notarytool-submit Test718887.zip Conducting pre-submission checks for Test718887.zip and initiating connection to the Apple notary service... Error: Test718887.zip must be a zip archive (.zip), flat installer package (.pkg), or UDIF disk image (.dmg) Note notarytool-submit is an alias that expands to xcrun notarytool submit CREDENTIALS. That seems kinda wonky to me and I recommend that you file a bug about it. Please post your bug number, just fo

Hello, Thank you for your patience as we considered your appeal. The App Review Board determined that the original rejection feedback was valid. Your app does not comply with: 4.3(a) - Design During our review, we found that this app duplicates the content and functionality of other apps submitted to the App Store, which is considered a form of spam and not appropriate for the App Store. Apps submitted to the App Store should be unique and should not duplicate other apps. We encourage you to create a unique app to submit to the App Store. For more information about developing apps for the App Store, visit the Develop section of the Apple Developer website. We appreciate your efforts to resolve this issue and look forward to reviewing your revised submission. Best regards, App Review Board This is the appeal ticket I received, and I want to thank the App Review team for considering my request. Based on the message, I would appreciate it if other developers who have encountered this issue could help me

We are reaching out to seek your guidance regarding our app's approval process. Despite diligently resolving all the issues and strictly adhering to Apple’s guidelines, our app continues to face rejection under Guideline 4.3(b) - Design - Spam. We want to emphasize that our app offers a truly unique experience, unlike anything currently available on the App Store. It is designed to foster real-world social connections and encourage users to explore new locations. Our minimalist black-and-white design, paired with innovative functionalities, sets us apart from other apps. We have carefully crafted every detail to ensure a fresh and distinctive user experience. During our one-on-one app review, we thoroughly explained our app's concept and demonstrated how it differs from existing apps. We are confident that no other app on the market offers what we are trying to bring to users. Given that we were live on the App Store in 2020, but had to postpone our launch due to the pandemic, we believe our app is n

Hello also, I would like to make an appeal on behalf of legitimate developers around the world. How long has item 4.3 be around? It seems like I’ve read that rule many months back. And after seeing all the spam apps on the market I wondered if this rule was even being inforced. It seems, perhaps, they are finally starting to do something about it.What is furstrating for legitmate developers is having to compete with all these thousands, if not millions, of spammed apps. Take Solitaire for example. Just do a search and you will find multiple developers all with the same exact solitaire game spammed 50+ times. Each of these apps are identitcal except for the background and the card back. And they all have 10 to 50—5 star reviews! Many of the reveiws are identical across multiple apps and developers. Do the math. And the worst thing is they utilize the keywords so that these apps appear in all sorts of searches.I trully love Apple’s quote in the Review Guidelines, “Come up with your own ideas. We know y

Hey lifeofjer, I'm really glad you shared this, because we’re going through a very similar situation right now with our app Cloose. Although Cloose isn’t a dating app, Apple keeps interpreting it as one and rejecting us under 4.3(b) – Spam. Our concept is a social map, built around real-time location and spontaneous proximity, where users can connect if they happen to be nearby and active on the map — no swipe mechanics, no auto-matching, no profiles sorted like in dating apps. We even removed all “dating-like” terminology and visuals, including hearts, swipes, and the word “match.” Still, we keep getting the same general response from Apple: that the app doesn’t provide a unique enough experience. To really demonstrate how different our app is, we even created a full walkthrough video showing all the redesigned functionalities, safety mechanics, merge-based interaction logic, delayed/obfuscated location, and more. But honestly, we’re not sure if the review team has watched it. Here’s the video, in c

The thing you flagged as confusing is, I think, the most important detail in your post: the number stayed at 4.3(a) but the body changed. Attempts 1 to 4 were about a binary match. Attempt 5 is about concept and look in a saturated category. Those are two different findings with two different fix surfaces, and almost everything you did between attempt 2 and attempt 5 — refactor, rename, reorganise assemblies, obfuscate — was aimed at the first one. On the binary side, it is worth turning I changed the code into a number before changing any more of it. In a Unity IL2CPP build, your own scripts are usually a small fraction of the compiled code; the engine, the ad SDKs and the third-party libraries are the bulk, and those are exactly what the reviewer named on your call. You can measure the split rather than guess at it: Build with a link map (Other Linker Flags: -map $(TARGET_TEMP_DIR)/link.map), then total the __TEXT,__text bytes per object file and group them by static archive. Or run size -m -x on t