We found that your app uses one or more non-public APIs, which is not in compliance with the App Store Review Guidelines. The use of non-public APIs is not permissible because it can lead to a poor user experience should these APIs change.
We found the following non-public API/s in your app:
allowsAnyHTTPSCertificateForHost:
If you have defined methods in your source code with the same names as the above-mentioned APIs, we suggest altering your method names so that they no longer collide with Apple's private APIs to avoid your application being flagged in future submissions.
Additionally, one or more of the above-mentioned APIs may reside in a static library included with your application. If you do not have access to the library's source, you may be able to search the compiled binary using "strings" or "otool" command line tools. The "strings" tool can output a list of the methods that the library calls and "otool -ov" will output the Objective-C class structures and their defined methods. These techniques can help you narrow down where the problematic code resides.
We appreciate that you may have made the precautions in your code for using non-public APIs, however, there is no way to accurately or completely predict how an API may be modified and what effects those modifications may have. For this reason, we do not permit the use of non-public APIs in App Store apps.
If there are no alternatives for providing the functionality your app requires, we encourage you to file an enhancement request. Or, try working with the Apple Developer Technical Support team to explore alternative solutions.
On occasion, there may be apps on the App Store that don't appear to be in compliance with the App Store Review Guidelines. We work hard to ensure that the apps on the App Store are in compliance and we try to identify any apps currently on the App Store that may not be. It takes time to identify these occurrences but another app being out of compliance is not a reason for your app to be.
For discrete code-level questions, you may wish to consult with Apple Developer Technical Support. Please be sure to:
include the complete details of your rejection issues
prepare any symbolicated crash logs, screenshots, and steps to reproduce the issues for when the DTS engineer follows up.
For information on how to symbolicate and read a crash log, please see Tech Note TN2151 Understanding and Analyzing iPhone OS Application Crash Reports.
If you have difficulty reproducing this issue, please try testing the workflow as described in https://developer.apple.com/library/ios/qa/qa1764/Technical Q&A QA1764: How to reproduce a crash or bug that only App Review or users are seeing.
You should be happy that Apple discovered a security risk in your app. What you are doing is completely disabling client side server verification in a SSL/TLS connection. That's really NOT what you want to do - unless for unit testing.
You should fix the security risk, and also NOT follow Prem Kumar's link in his comment - since the suggested code does actually the same (disabling server trust verification), just without using private APIs.
You maybe using QQ-SDK1.8, it use private API:allowsAnyHTTPSCertificateForHost. And 1.8.1 version has repaired it .
Related
We know that apple has implemented ATS beginning this year. However, when I open an app like Yelp, I am able to open up virtually every plain http URL in app; opening up a restaurant website for instance. However, I was under the impression this was not allowed.
I wanted to ask, especially after looking at former SO questions (though many are from 2015), as small developers, are we able to implement this feature ourselves? Do we have the power to allow arbitraryLoads or NSTemporaryExceptionAllowsInsecureHTTPLoads in the info.plist that would be allowed in the app store review process?
Down vote if you must, but I'm looking for an answer from the community with experience.
The recommended way to do this is to load any arbitrary web content in a SFSafariViewController within your app. Content loaded in the SFSafariViewController is basically the same as running within Safari, and does not require all sites to conform to Apple's ATS requirements.
Alternatively, if you need to use older components to load web content (e.g. WKWebView), there is a NSAllowsArbitraryLoadsInWebContent exception that you could use, but that is challenging, because that exception was only supported in iOS 10+, so if you support iOS 9 in your app, you have to do a weird combination of the NSAllowsArbitraryLoadsInWebContent and NSAllowsArbitraryLoads exceptions. This will cause you to provide justification to Apple due to the use of NSAllowsArbitraryLoads. At this point, I would recommend the SFSafariViewController route.
Let say were starting a website from the ground up and want to also create apps.
Could you just create the website with a REST API's and have it work on browser and PhoneGap? Would there be a conflict with Cordova plugins you may use?
So the design is responsive and its all HTML, CSS and Javascript and connects to a REST API (log in, reg, messages, db calls, etc) for the browser website and apps.
This way you can use the same code for everything and can still use some of the great Cordova plugins for the app to make it more flexible.
Would this work?
I posted this answer else where but I think it is relevant here.
Unfortunately for your app to pass Apple App store approval it will have to provide some basic functions and display correctly without an internet connection. This means at a minimum, if you plan to generate content on a server you will probably need the Cordova plugin for network information:
https://cordova.apache.org/docs/en/latest/reference/cordova-plugin-network-information/
I would make sure you are familiar with the Apple Human Interface Guidelines:
https://developer.apple.com/ios/human-interface-guidelines/overview/design-principles/
You will probably also need to bundle any JavaScript. Apple is very picky about apps that download code (this can include JavaScript).
This is a section from the iOS developer Agreement.
3.3.2 Except as set forth in the next paragraph, an Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exceptions to the foregoing are scripts and code downloaded and run by Apple's built-in WebKit framework or JavascriptCore, provided that such scripts and code do not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store.
Another big concern is performance. How will your app handle a poor 3G or even 2G connection? Do you need to cache the responses from the API and only download them if they have changed on the server?
If a user is browsing your website on a browser they know they need an internet connection, if they are using your app they want it to work when online and offline.
Edit
Apple commonly uses this reason for rejection for website only apps.
We found that the experience your app provides is not sufficiently different from a web browsing experience, as it would be by incorporating native iOS functionality.
While your app content may differ from your web site or other existing sites, the experience it provides does not differ significantly from the general experience of using Safari, as required by the App Store Review Guidelines.
I got following message from app review team, now i am confused how to fix it and what is the problem exectly any help would be appreciated.
2.5
We found that your app uses one or more non-public APIs, which is not
in compliance with the App Store Review Guidelines. The use of
non-public APIs is not permissible because it can lead to a poor user
experience should these APIs change.
We found the following non-public API/s in your app:
currentHost
If you have defined methods in your source code with the same names as
the above-mentioned APIs, we suggest altering your method names so
that they no longer collide with Apple's private APIs to avoid your
application being flagged in future submissions.
Additionally, one or more of the above-mentioned APIs may reside in a
static library included with your application. If you do not have
access to the library's source, you may be able to search the compiled
binary using "strings" or "otool" command line tools. The "strings"
tool can output a list of the methods that the library calls and
"otool -ov" will output the Objective-C class structures and their
defined methods. These techniques can help you narrow down where the
problematic code resides.
We appreciate that you may have made the precautions in your code for
using non-public APIs, however, there is no way to accurately or
completely predict how an API may be modified and what effects those
modifications may have. For this reason, we do not permit the use of
non-public APIs in App Store apps.
If there are no alternatives for providing the functionality your app
requires, we encourage you to file an enhancement request. Or, try
working with the Apple Developer Technical Support team to explore
alternative solutions.
On occasion, there may be apps on the App Store that don't appear to
be in compliance with the App Store Review Guidelines. We work hard to
ensure that the apps on the App Store are in compliance and we try to
identify any apps currently on the App Store that may not be. It takes
time to identify these occurrences but another app being out of
compliance is not a reason for your app to be. For discrete code-level
questions, you may wish to consult with Apple Developer Technical
Support. Please be sure to:
include the complete details of your rejection issues
prepare any symbolicated crash logs, screenshots, and steps to reproduce the issues for when the DTS engineer follows up.
For information on how to symbolicate and read a crash log, please see
Tech Note TN2151 Understanding and Analyzing iPhone OS Application
Crash Reports.
If you have difficulty reproducing this issue, please try testing the
workflow as described in
https://developer.apple.com/library/ios/qa/qa1764/Testing Workflow
with Xcode's Archive feature".
any help would be appreciated.
It looks like you are using this method to get your current ip in your application. You can use other alternatives like in the link mentioned:
https://stackoverflow.com/a/6535436/1111384
You can use this to get current ip.
Hope this resolves your issue.
Does anyone know if I use the Twitter Framework will my app contain encryption?
Frameworks are not included in your app. They are in the device's firmware and are not copied into your app. So even if an iOS framework had encryption in it, it is not included in your app, you just make function or method calls to it, and are not distributing encryption software.
I think no one really answered your question directly; they were merely inferring your intent. The Twitter framework docs only mention HTTP for API requests. The Twitter docs on this say that SSL is optional though encouraged. So I'd imagine that iOS is handling user authentication via SSL in the background, but that all API requests by developers are done over HTTP using oauth. This is only speculation -- to verify you'd want to run a packet sniffer on your local network and check out the transactions when you call the framework methods.
Regarding the export controls mentioned in other comments here, I'd advise you to look at the iTunes Connect FAQ dealing with export controls within the Dev Center. Apple makes it very clear in that document that using encryption integrated into the iOS frameworks still requires you to apply for an ERN with the US Dept. of Commerce. (I won't quote it due to NDA) The other comments currently on this page are simply wishful thinking. I'm sure some developers were confused (and it is confusing), or perhaps have outright lied and have apps in the store which are violating US law. IANAL; I'll leave that choice up to you.
Having said that, there have been some exemptions added to these requirements, as outlined here.
Recently I've heard that Apple is using tools to search for references to undocumented APIs and are rejecting iPhone apps from the App Store because of it.
The popular Three20 framework is causing people to get rejected.
I also just saw that the KissXML library has also caused rejection.
I'm looking for an Objective C DOM-based XML parser and am now considering TouchXML.
Can anyone confirm that TouchXML does not reference any undocumented APIs? I don't want to risk an app rejection based on this.
I can confirm that I've included no private frameworks in several projects that use TouchXML that have all become apps in the App Store. I would ask the question at the google code site to make sure, but John Wight who wrote the library writes very clean and tight code. It would surprise me if he used any undocumented APIs.
Also, I wouldn't worry about it too much. Build your app and submit it and if it gets rejected, fix it then. Apple will even tell you what API you're referencing that you're not supposed to if that is the case. If you have to go through their bureaucracy anyhow, you might as well benefit from it by making them tell you what's wrong. Also, keep in mind that probably everyone gets rejected at least once--especially if it's your first app. ;-)
Tidy does. My app was just rejected from the app store on that basis.
"3.3.1 Applications may only use Documented APIs in the manner prescribed
by Apple and must not use or call any private APIs."
The following non-public APIs are included in your application:
tidyBufAlloc
tidyBufFree
tidyBufInit
tidyCleanAndRepair
tidyCreate
tidyOptSetBool
tidyParseBuffer
tidyParseString
tidyRelease
tidySaveBuffer
tidySaveString
tidySetCharEncoding
tidySetErrorBuffer
tidySetOutCharEncoding"
I know that there is at least one app on appstore which uses TouchXML. But during development process I found some bugs there, so I try to find some alternative now.
Consider using libxml2. It has a steeper learning curve, but the speed and flexibility are worth it.
I've just had an app rejected precisely because it uses touchXML