App Store Metadata Rejected, listed 9 items. How do I found out which ones are the problem? - metadata

Got Metadata Rejected from App Store. I have done a lot of research online. But still couldn't figure out exactly what needs to be done.
I did my best to make sure the wording is appropriate. Replied the message in resolution centre about what I have modified. (understood that binary is fine).
But 1 day later, Apple replied saying please make sure that your app does not violate any of the guidelines listed in our previous message.
Here is the items they are talking about.
It is just a math game I made to calculate 24 from 4 numbers. Very straight forward.
I asked in my reply about which one is the problem because there are a few items are obviously not related to my app.
Guideline 2.1 - Information Needed
This type of app has been identified as one that may violate one or
more of the following App Store Review Guidelines. Specifically, these
types of apps often:
1.1.6 - Include false information, features, or misleading metadata.
2.3.0 - Undergo significant concept changes after approval
2.3.1 - Have hidden or undocumented features, including hidden "switches" that redirect to a gambling or lottery website
3.1.1 - Use payment mechanisms other than in-app purchase to unlock features or functionality in the app
3.2.1 - Do not come from the financial institution performing the loan services
4.3.0 - Are a duplicate of another app or are conspicuously similar to another app
5.2.1 - Were not submitted by the legal entity that owns and is responsible for offering any services provided by the app
5.2.3 - Facilitate illegal file sharing or include the ability to save, convert, or download media from third party sources without explicit authorization from those sources.
5.3.4 - Do not have the necessary licensing and permissions for all the locations where the app is used

Related

AppStore rejected because of code obfuscation and selector mangling: none is done in the app

My iOS app has gone through multiple releases. I just added another feature (playing audio files using facebook audio360 tbe format), and the app got rejected with the wording:
From Apple
2. 3 Performance: Accurate Metadata Guideline 2.3.1 - Performance
We discovered that your app contains hidden features. Specifically, It
would be appropriate to remove all code obfuscation and selector
mangling from this app before resubmitting for review.
The next submission of this app may require a longer review time.
Next Steps
Review the Performance section of the App Store Review Guidelines.
Ensure your app is compliant with all sections of the App Store Review Guidelines and the Terms & Conditions of the Apple Developer
Program.
Once your app is fully compliant, resubmit your app for review.
Submitting apps designed to mislead or harm customers or evade the
review process may result in the termination of your Apple Developer
Program account. Review the Terms & Conditions of the Apple Developer
Program to learn more about our policies regarding termination.
If you believe your app is compliant with the App Store Review
Guidelines, you may submit an appeal. Alternatively, you may provide
additional details about your app by replying directly to this
message.
I am not performing "code obfuscation and selector mangling", has submitted an appeal, which was also rejected pointing to the same guideline.
I am using objective-c with some swift, Xcode 9, Product -> Archive -> Submit to App Store... Is it doing some obfuscation that I could turn off?
Perhaps your audio playing feature is using a 3rd party framework which does use code obfuscation?
In any case, you can use the /usr/bin/nm tool for outputting the symbols within your raw executable and see if any of those look "mangled" in any way.
It's most probably a 3'rd party library that does that.
I used Hopper to get to know the library.
First, unzip the ipa and get the app file.
Second, Drag it to Hopper and start scanning it.
Third, search for the mangled selectors.

Prototype/TestFlight iOS application under personal account

I've been struggling to find an approach to a problem I have with registering an iOS based application with Apple. I have an idea for a an iOS application that would require from Apple that the organization to be a registered 501c3.
What I want to do is develop the application under my personal developer account (I have apps in the store already through an LLC I have) to be able to test and prototype the idea fully with beta users via Test Flight and then if that shows promise go through the nightmare that is registering for a 501c3 entity with the IRS. This process can take a long time from what I've read and is very complex and also there are significant costs involved (probably requires hiring an attorney/accountant to wade through all the paperwork). So the bottom line is I really don't want to go down the road of setting up a corporation, registering for non-profit status, yada yada if my app just isn't what it appears to be in my head when users have it in their hands. I want to vet all the systems (which includes a fairly large backend admin web based application) prior to setting up the charitable organization. In case anyone wants to know the app is going to accept donations via Apple Pay as a part of the application which Apple requires that you're a registered 501c3 otherwise I wouldn't go down this road at all.
I read the policies on transfer of apps, and contractor scenarios in the Apple Enrollment documentation but it doesn't really answer my questions about registering an App ID under one company (my personal account/LLC) but deploying the app under another entity after being fully tested. FYI this isn't a contractor relationship as both organizations will be my own. Also transferring seems to require that the App already be on the store as well as has severe limits to its entitlements (e.g. you can't use iCloud entitlements which my app will use) neither of which would work in my case.
Anyway - to recap I want to develop and beta test with users in Test Flight using my developer account and only after it's vetted put the App into the approval process after I get my 501c3 setup and registered so Apple can approve it's ability to accept donations via Apple Pay. My concerns are mostly around technical issues related to this and/or how Xcode and entitlements/certifications/provisioning may cause issues. e.g. if I develop and then register the application name in my personal account I'm under the impression this is globally unique so my 501c3 wouldn't be able to register that same name?
Thanks for any help!

AFNetworking is legal?

I got response from Apple Review Team:
Dear Developer,
Your app, extension, and/or linked framework appears to contain code
designed explicitly with the capability to change your app’s behavior
or functionality after App Review approval, which is not in compliance
with section 3.3.2 of the Apple Developer Program License Agreement
and App Store Review Guideline 2.5.2. This code, combined with a
remote resource, can facilitate significant changes to your app’s
behavior compared to when it was initially reviewed for the App Store.
While you may not be using this functionality currently, it has the
potential to load private frameworks, private methods, and enable
future feature changes.
This includes any code which passes arbitrary parameters to dynamic
methods such as dlopen(), dlsym(), respondsToSelector:,
performSelector:, method_exchangeImplementations(), and running remote
scripts in order to change app behavior or call SPI, based on the
contents of the downloaded script. Even if the remote resource is not
intentionally malicious, it could easily be hijacked via a Man In The
Middle (MiTM) attack, which can pose a serious security vulnerability
to users of your app.
Please perform an in-depth review of your app and remove any code,
frameworks, or SDKs that fall in line with the functionality described
above before submitting the next update for your app for review.
Best regards,
App Store Review
I check my code again and I see AFNetworking included methods: performSelector:, method_exchangeImplementations(), respondsToSelector:
I intend to tell Apple that AFNetworking is an opensource and legal but I think Apple will NOT trust me
So I have 2 questions:
Does Apple ask me to remove AFNetworking from my code after they know AFNetworking included respondsToSelector:, performSelector:, method_exchangeImplementations()
As the way Apple see AFNetworking, is AFNetworking legal? Are there any documents to prove it?
After getting the same message and reading in different forums, it is possible you are using a 3rd party service which allows you to alter the code after uploading the app to the AppStore.
The most popular service for that is Rollout.io, which I had to remove from my own app.
I strongly doubt that AFNetworking would cause you any issues (still looking for an answer from Apple myself, and will update when they do answer)
Update: Apple has approved my app, meaning it was Rollout.io indeed. I believe it'll be true for any 3rd party code injection tool.
I still have AFNetworking, so no problems there.

Will my app be rejected if it uses the "aluminum look" for its icon?

I have created a nice icon for my app that quite accurately reproduces the style of Apple's Aluminum logos (ex. iCloud, etc.)
In reading the app review guidelines, I noticed this:
8 - Trademarks and trade dress
8.1 Apps must comply with all terms and conditions explained in the Guidelines for Using Apple Trademarks and Copyrights and the Apple Trademark List.
8.2 Apps that suggest or infer that Apple is a source or supplier of the app, or that Apple endorses any particular representation regarding quality or functionality will be rejected
8.3 Apps which appear confusingly similar to an existing Apple product or advertising theme will be rejected
8.4 Apps that misspell Apple product names in their app name (i.e., GPS for Iphone, iTunz) will be rejected
8.5 Use of protected 3rd party material (trademarks, copyrights, trade secrets, otherwise proprietary content) requires a documented rights check which must be provided upon request
8.6 Google Maps and Google Earth images obtained via the Google Maps API can be used within an application if all brand features of the original content remain unaltered and fully visible. Apps that cover up or modify the Google logo or copyright holders identification will be rejected
In particular 8.3 seems to say that you can't look too much like an apple product.
Will my app be rejected?
There are lots of apps that have aluminum icons. You'll probably be fine. But it is Apple. You never know. And changing the icon if they don't like it isn't a big deal. See what happens.
There is no way to tell for sure until you submit the app for review. Nobody can tell you what will happen except the people doing the reviews at Apple and you won't find that out until you submit it. I would submit it and see what happens.

Handling data migration from 'lite' to 'pro' version of iPhone app

I am near the end stages of developing an iPhone application and will be releasing it as both a 'lite' (ad-supported) version and a 'pro' (ad-free, likely with additional functionality at some point) version.
I've followed suggestions here and elsewhere about creating multiple targets, etc. and am able to build these without any problems.
But this does bring to mind a question: What is the best, most user-friendly, accepted way in which to handle transitioning from a lite version of an app to a pro version?
As I see it - and please correct me if any of my assumptions are wrong - there are potentially two ways to do this:
Give each application its own Bundle identifier (ie. com.companyname.fooapplite and com.companyname.fooapppro). This will result in both being treated as being completely separate entities. Data is not automatically migrated should a user move from one to the other and both could very well have both installed on the same iPhone at the same time.
Give each application the same Bundle identifier (ie. com.companyname.fooapp), so that they are treated as essentially the same application. The lite version of the application will be overwritten by the pro version if they download and install it. Data from the lite version is maintained in the pro version.
The latter seems ideal to me - I can't imagine someone wanting to keep a lite version after they've just purchased a pro version - but this brings up a few questions:
Does Apple even allow option #2?
Will using option #2 result in any goofiness I should be aware of, ie. the two versions stepping on eachother in some way.
If it's not allowed, is there a suggested practice in place to migrate data from what are basically two completely different applications? I'm aware of StoreKit, but it isn't supported on free applications.
As it is, this current app doesn't really generate data of huge value and the worst thing that will happen is users will have to re-enter some authentication credentials upon upgrading to pro. But down the road, if I were to develop a similar app that stores valuable data locally, I'd like to know how to best transition users and their data in a seamless manner.
Thanks,
Jeff
One more option is to exchange data from the Lite to the Full version via a URL. Register a myFullApp URL with the full version and have the Lite app present an upgrade option that calls that URL with the various data you want to exchanged encoded in it.
That does require the user fire up your Lite version and hit a button, but it's fairly simple too.
I have not tried this myself, but a third option to exchange small amounts of data is to use the Keychain API. Apps that share an identifier stub -- com.companyname.foo as a parent to com.companyname.foo.fooapp and com.companyname.foo.fooapplite -- can supposedly write to the keychain from one app and read from the other. Haven't seen this done, but a lot of people claim it's possible. And in any case, the keychain is probably a good place to be storing things like authentication credentials.
Option four would be to have the lite app store some user data on a server you operate, and have the full app retrieve it from there, but there are all kinds of problems with that approach.