We identified one or more issues with a recent delivery for your app, "BeepingmeServiceProvider" 1.7 (1). Please correct the following issues, then upload again.
ITMS-90809: Deprecated API Usage - New apps that use UIWebView are no longer accepted. Instead, use WKWebView for improved security and reliability. Learn more (https://developer.apple.com/documentation/uikit/uiwebview).
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 7 months ago.
This post was edited and submitted for review 7 months ago and failed to reopen the post:
Original close reason(s) were not resolved
Improve this question
I got this warning when I was publishing my app
The developer of play-services-safetynet (com.google.android.gms:play-services-safetynet) has reported critical issues with version 17.0.0. Consider upgrading before publishing a new release.
Here's what the SDK developer told us:
The SafetyNet Attestation API is being discontinued and replaced by the new Play Integrity API. Begin migration as soon as possible to avoid user disruption. The Play Integrity API includes all the integrity signals that SafetyNet Attestation offers and more, like Google Play licensing and better error messaging. Learn more and start migrating at https://developer.android.com/training/safetynet/deprecation-timeline
How do I remove the critical issue and get my app into production?
SafetyNet is a set of APIs from Google Play Services for developers to ensure that apps are running in a safe environment. It is optional for app developers, and app developers can choose to use it or not. SafetyNet prevents an app from working if an app’s developer doesn’t want it to work on devices which are rooted, tampered, running custom ROM, or infected with malware.
Banking apps, Snapchat and Netflix are examples that uses something called SafetyNet to detect whether your device is rooted or not, and blocks access to those features.
For those apps which are using SafetyNet:
In June 2022, Google announced that we should start integrating with the Play Integrity API as soon as possible. The Play Integrity API includes all the integrity signals that SafetyNet Attestation offers and more. SafetyNet Attestation will continue to work for your app as of now.
At the end of June 2023, developers that have migrated to the new API will be able to continue using the old SafetyNet Attestation on older versions of their apps, but those that have not migrated will not be able to do so.
At the end of June 2024, Google says SafetyNet Attestation will be retired entirely.
If you are not using safety net anywhere just do the below changes in your code.
implementation platform('com.google.firebase:firebase-bom:30.2.0')
implementation 'com.google.firebase:firebase-core'
implementation('com.google.firebase:firebase-auth') {
exclude module: "play-services-safetynet"
}
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 .
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.
Due to reasons out of my control I'm forced to use the legacy Facebook Javascript SDK on a new application. My question is. Is this possible? Des Facebook allows you to use the old legacy SDK on new applications? Or is it deprecated already and cannot be used on new applications?
Facebook is moving to OAuth 2.0. All apps are required to migrate over by October 1st. This means the old school Facebook JavaScript SDK is going to be phased out as it does not support this. I'm not sure if the old JavaScript library will stop working at that time, but I would definitely migrate to the newer SDK.
http://developers.facebook.com/blog/post/497/
Yes you can still use it. Its still even documented. Just reference it here:
http://static.ak.connect.facebook.com/js/api_lib/v0.4/FeatureLoader.js.php You obviously run the risk that they will eventually disable it but it is used all over the Internet so they are not likely to permanently kill it anytime soon.