My app was rejected by Apple with the following message:
We found that your app does not comply with the Guidelines for Using Apple’s Trademarks and Copyrights, as required by the App Store Review Guidelines. Specifically, your app includes the use of “iOS” in the app bundle name.
It seems that when a new Cocos2d-x project is created a single Apple project is created with 2 targets, one for iOS and the other for Mac (desktop), and " iOS" and " Mac" are appended as suffixes on each of the targets. The project name has no suffix added.
In the info tab of the project I find the following variable used to populate the keys Executable file and Bundle Display Name: ${PRODUCT_NAME}. I can’t find where I can adjust the PRODUCT_NAME variable. I tried setting those fields to simple strings but that didn’t prevent the problem.
I also opened the project file and found a text document with several listings of the project with iOS suffix, but after adjusting them I found that upon opening the project in XCode, XCode seems to overwrite the file with the original settings.
…/proj.ios_mac/MyProject.xcodeproj/xcshareddata/xcschemes/MyProject.xcscheme
Can anyone offer advice on adjusting the “app bundle name” to conform with Apple’s requirements? So far I’ve only tried submitting from XCode, which seems to obscure some things. I’m going to try Application Loader 3.0 as an alternative approach to uploading the content. Maybe that will give me a chance to change the app bundle name before submitting it.
Also, I recommend that Cocos consider a different naming scheme for the Apple project target names. Perhaps “device” and “desktop” are suffixes that will distinguish the 2 target types and also adhere to Apple’s requirements.
I’m still down the rabbit hole. I’ve asked over at the Apple dev forums too.
I am surprised I can’t find info about resolving this. Maybe I got an especially picky reviewer at Apple.
I can’t find where the PRODUCT_NAME variable is declared.
When I change the 3 references to PRODUCT_NAME in info.plist to simple strings then re-launch XCode, the target name retains an iOS suffix (the strings are saved and are evident within XCode).
I’m now looking for info on how to modify the name of targets in XCode. It’s deceptively difficult to find out how to do that.
re: [quote=“slackmoehrle, post:2, topic:19612”]
We just created an example project. You should change it to meet your needs.
[/quote]
It’s fair enough to define a limit to Cocos’ responsibility, but if the defaults Cocos uses result in difficulty in app submission, then those defaults should be reconsidered.
BTW: I’m assuming that the iOS and Mac suffixed target names in XCode were created when Cocos2d-x created the base project with both a desktop and device version of the project. Maybe that’s not even the case.
i dont think you can change the bundle name on the fly(on the app developer site atleast). You have to create a new project in cocos2d-x and while creating package name dont use iOS anywhere. I am assuming that you are using it while creating the bundle online. Create a new bundle w/o the iOs suffix or prefix and change the info.plist file to reflect your new bundle name and that should be it.
Thanks for the suggestion. The problem isn’t regarding my Bundle ID. I’m using a simple reverse-domain style string without any inclusion of iOS.
I think what Apple means by “app bundle name” is the value found when looking at the info tab for the target. There’s a key listed there “Bundle name”. I’ve tried leaving the default, ${PRODUCT_NAME}, and I’ve tried filling it with a simple string. Nothing works.
In iTunesConnect when looking at the details for one of the builds that fails, I see 2 references to the string “iOS”. They are both found in the first line under the Store Information > Entitlements section:
GreyShaders iOS.app/GreyShaders iOS
I’m figuring that they come from the info.plist file. The first is probably from the key Executable File (which is populated with value ${EXECUTABLE_NAME} and the second comes from the key Bundle name (as described above).
This is why I’m trying to figure out how XCode populates the variables ${PRODUCT_NAME} and ${EXECUTABLE_NAME}.
[edit]
Solved it!
I found the definition of PRODUCT_NAME under
Build Settings > Packaging > Product Name
(EXECUTABLE_NAME is derived from PRODUCT_NAME).
It had the iOS suffix. I removed the suffix and submitted a new binary.
BTW, I checked this setting in a brand new template project created by Cocos2d-x. This Build Settings > Packaging > Product Name field is filled with a value that includes the iOS suffix. When editing this field I saw that it was actually pointing to ${TARGET_NAME}.
So when the Cocos new project script appends " iOS" onto the end of the target name that suffix trickles down into the resulting executable name and bundle name, causing Apple to reject the build. If others haven’t experienced rejection for this cause then I must have just drawn a picky reviewer at Apple, because the process is easily repeatable.
oh ok. i thought you named it with ios at the end, i think the problem is when cocos2d-x creates a project, to differentiate the iOS version from the Mac version the .app or target is automatically suffixed with iOS and Mac. If you look at the project in xcode in Products you will see PROJECTNAME iOS.app and PROJECTNAME Mac.app. I think the reviewer is having a problem with this. I think that is where the problem is. I dont think he is liking the iOS at the end of the name of the app bundle.
You can just rename the file manually after archiving. Go to the organizer and select the archive and do show in finder. go INto the archive by doing show package and make changes to plist file. But I am not sure if anything will get broken as the application name is still suffixed with iOS and the plist file also have links to the icons which also have iOS suffix in the end(Even after changing the name of the app init in Xcode).
But I think if someone from Cocos2d-x responds to this query cos I think it is sketchy if we try to resolve this at our level.
@slackmoehrle Hi! Do you think this can be done by changing the name of the application file name manually?
By changing the Build Settings > Packaging > Product Name value I was able to disassociate the target name (“MyProject iOS”) from the resulting binary. I submitted a binary that has no trace of “iOS” that I can detect. Will confirm the solution once my submission has been approved :).
I tried several ways of intervening in the process between the XCode build and the upload to iTunes Connect. None of the changes I made to the binary before submitting it were successful.
One route I never explored was command line compilation. That would probably have worked too.
Oh! let me know if the solution works. Although renaming project files could get real dirty real soon. UGH!! If it works it is a solution none the less.
I’d like to clarify that changing the Product Name is enough, just like I mentioned in my first reply to this thread.
So, yes, Build Settings > Packaging > Product Name
Please don’t try and point this back as had you guys named the targets different, I wouldn't have had this issue. Seriously. This isn’t even remotely close to a cocos2sd-x issue. It is an Xcode issue. Go create sample projects from any of their pre-canned starter projects and the same thing happens. The first target is always the Product Name until you change it.
Thanks for offering the correct solution. Being new to XCode there is a lot to learn about the quirks of this particular IDE. I didn’t know how to find the Product Name declaration.
To clarify: You said, “The first target is always the Product Name until you change it.” While that association between Product Name and target name may be standard, my discovery is that Cocos2d-x creates a target name with the suffix " iOS" while the canned projects don’t add that suffix (Please correct me if that " iOS" suffix comes from somewhere other than Cocos2d-x). My recommendation is to adjust the target naming scheme to conform with Apple’s requirements and then developers wouldn’t encounter this.
I’m not casting blame here, just suggesting a structure that reduces the number of tweaks required to conform a project before release. With an out-of-the-box Cocos2d-x 3.2 project developers may have their submissions rejected for violating Apple’s clause 8.1 unless they know to make (and know how to make) this tweak to their project settings. The Cocos2d-x documentation burden and developer angst could be reduced with the naming convention change I recommed. Seems like a win all around to me. Apologies if it seemed like there was any blaming going on. Just looking to report problems, report solutions and ultimately recommend refinements to the Cocos2d-x tool so it can be as optimal as possible and minimize frustrations for developers unfamiliar with the subtle particulars.
well what @EMebanei s saying is correct. There is no finger pointing at the developers going on. If this becomes an issue and builds are getting rejected because of this i think it needs to be fixed.
Yeesh. I just got rejected, too. Can’t have ‘iOS’ in the name. Sure, it’s a dick move for Apple to do this, especially after waiting in the queue for a whole week to do a trivial check that should have been rejected by their ‘tool’.
But gods, I can’t help but be annoyed and whiney. So please bear with me.
For those who are curious, here’s what I ended up doing and discovering. I created a new project from scratch, and dinked around a bit.
cocos2d-js-v3.3
Make a NEW project. ‘cocos new -l js ProjectName’. If you don’t, there’s a lot of trash that just looks too suspicious. Just temporarily rename your work and copy your work over to the ‘new’ one. (And of course, deal with the version control fallout, later).
Find ‘project.pbxproj’, in the frameworks/runtime-src/proj.ios_mac/ProjectName.xcodeproj folder that cocos made. It has ‘ProjectName iOS’, peppered throughout. Change them to ‘ProjectName’. Yes, this came from cocos.
Open it up in XCODE. Hey, looky! The project target doesn’t ’ iOS’ on the end.
When you invoke your build, add ‘-t ProjectName’, or cocos will choke, and won’t find your iOS project. This is again within cocos.
Something like…
cocos compile -p ios -m release -t ProjectName --sign-identity “iPhone Distribution: Blahblahblah (license plate)” (that last mess from your developer certificate thingy)
And now I’m back into the kinds of ‘App Store Submission’ errors that have me looking away from this for hours at a time, that I fixed before, but have all come back, like ‘invalid image path’ for a bunch of icons files, and ‘version must be greater than 5.1.1 for that arm64 stuff’. Maybe I’ll update after I finish bandaging my forehead from banging it on the desk. Hope it doesn’t break… the desk, I mean.
added… Looks like it got past their robot. Just like it did with the ‘wrong’ name. Next they’ll tell me they don’t like one pixel on an icon, or something stupider.
Compared to this, the Android submission was an absolute breeze. Once I got past their killer robot, it went right in.
Just to state for the record. You did not need to create a new project to take care of this.
Go back to your rejected project (since it works) and just edit your Scheme and change the Product Name under __Build Settingsand also look through theinfo.plist` as a precautionary to make sure there isn’t anything hardcoded there. I notice some developers do hard code values here.
Either the target names in the template project generator (cocos new) should be changed to have a different suffix now that this issue has been found, or the Product Name should be set (hard coded, if you will) to Project Name (without the suffix) as long as having the same name for both iOS and Mac builds don’t conflict (they shouldn’t, but I guess I haven’t tested yet).
