4.3

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

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

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 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

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