4.3

>Wanted to check if there's really a issue - with different bundle idAs that example is specifically called out in 4.3 Spam,my opinion is yes, issue.An while we're on the subject, you are also at risk of violating 4.2.2Minimum Functionality

Because 4.3 is as you note about spam*, not branding per se, first things first**...Did you appeal?If so, what did you say?How many times?How many rejections?What did each rejection say?Were you told to make changes to meta data and not re-submit another build?Were you told to resubmit?And, since this might be about you/your account, and not simply this app, this time.How many apps of this general type have you put in the store so far that are yours for your product?How many apps of this general type have you put in the store so far that are for clients w/their own accounts and their own products?** Note these are simply questions to learn more details about what’s transpired to this point, not suggestions on what you should do next.* • 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

Let me try to understand what you are writing. Your app and device is on the market (#1 above) . Now you are trying to get approval for an additional app that interfaces with a similar device marketed by a different company (#2 above where with our own should be with their own). And the additional app has now been rejected under the guideline 4.3. Is that correct?You have two avenues forward -1) create a separate developer account under your clients name and submit the additional app under that account. Be sure that the additional app is really different from the user's perspective.2) (better IMHO) update your current app so that it is a generic app that can be used by either your device or your client's device (or future clients). Under that generic app create two branded options that the user selects. Advertise your device (and have your client advertise their device) as using the well-known generic controller for photo frames.

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

With two apps having the same functionality but different branding, you're more likely to have problems with 4.3 (Spam). Apple has been pretty rigorous enforcing that rule over the past few years.

Search here on white label, container, branded apps.Example: https://forums.developer.apple.com/thread/46910Also see the ASRGs, example 4.3 Spam