First off, there are many of these topics here, and I have read a lot but could not find a solution, as it was only a warning, but now its a rejection.
I submitted my app and got this email:
Dear Developer,
We identified one or more issues with a recent
delivery for your app, "Gallery-Share" 1.0 (1.0).
Your delivery was successful, but you may wish to correct
the following issues in your next delivery:
ITMS-90809: Deprecated API Usage -
Apple will stop accepting submissions of new apps that use
UIWebView APIs starting from April 2020. See
https://developer.apple.com/documentation/uikit/uiwebview for more information.
After you’ve corrected the issues, you can upload a new binary to App Store Connect.
Best regards,
The App Store Team
I'm not aware that I used any Webviews.. I made my app with xamarin so for me this message is a bit cryptic.. What is the cause and solution for this message? How can I figure out where I used Webview, and how can I replace it with something apple likes?
Related
I received the below email shortly after I submit my app to the AppStore from XCode Organizer. My app contains the framework in this GitHub (https://github.com/wujianguo/iOSAppsInfo), I use it to create shortcuts to the rest of the users installed applications, and ONLY for that purpose.
Is there a different way of getting a list of all installed apps so I can create shortcuts or will all methods be instantly rejected as below?
Dear developer,
We have discovered one or more issues with your recent delivery "shortcut-app". To process your delivery, the following issues must be corrected:
Non-public API usage:
The app references non-public selectors in Xxxx xxxx: _applicationIconImageForBundleIdentifier:format:scale:, allInstalledApplications, appTags, applicationProxyForIdentifier:, localizedShortName, openApplicationWithBundleID:
If method names in your source code match the private Apple APIs listed above, altering your method names will help prevent this app from being flagged in future submissions. In addition, note that one or more of the above APIs may be located in a static library that was included with your app. If so, they must be removed.
If you think this message was sent in error and that you have only used Apple-published APIs in accordance with the guidelines, send the app's nine-digit Apple ID, along with detailed information about why you believe the above APIs were incorrectly flagged, to appreview#apple.com. For further information, visit the Technical Support Information page.
Once these issues have been corrected, you can then redeliver the corrected binary.
Regards,
The App Store team
This library uses private API which you cannot use especially when you submit the app to apple, as they will reject it like this.
I am not aware of another way to get installed apps, but in order for apple to accept uploading the app, you must stop using this library, specially this method.
With our latest release, we converted our app from paid to in-app subscription purchase. We promised our current users that we would grandfather them into the subscription because they already paid for the app. In our code, we look for a valid receipt with an original application version prior to our first subscription version. It all worked great in our tests.
When we released the new app, we started getting feedback from our long-term users that they were being asked to subscribe (they shouldn't even see the subscribe button). As we researched the issue, we noticed that all of these users purchased our app prior to the app being transferred to a new developer in September of 2014.
Recreating this issue is difficult - how do we simulate an app install in 2014? I may be able to login as one of the affected users, which would involve using their Apple credentials. I'm not very comfortable asking users to share their credentials.
Since I haven't been able to recreate it and our code is pretty simple, my best guess as to what is happening is that we aren't receiving a valid receipt for users that purchased prior to the app transfer in 2014.
So, I have a few questions:
Has anyone else experienced this?
If so, how have you resolved it?
How would you troubleshoot it?
FYI - I've filed an issue with Apple (3045378).
In speaking with Apple Developer Technical Support, we discovered a way to pull the NSLog messages off of the devices using the recently released Unified Logging feature. A couple of our users submit their logs, which clearly showed that they were getting valid receipts, but the originally purchased versions of those receipts are 4 and 2.8.
Given that our current version is 1.7.1, these are strange and non-typical numbers. However, the Original Application Version reported from the receipt is actually the CFBundleVersion (or Build), which can be a completely different string than the App Version reported in the App Store.
I assume that the developer prior to the app transfer was using a different build numbering system than the standard ... scheme.
I refined the version check within my code and re-submitted the app. It was released today, and, so far, all are being grandfathered correctly.
After updating PSPDFKit library in my application. But the interface of the library didn't change much from the previous version. Then I had uploaded it for internal testing(I use Xcode 7.0.1.) and received next warning:
I can see the build on iTunes page but it already almost 24 hours in Processing state.
The questions are:
1)If anyone received the same recently?
2)If there connection between the warning and Processing state taking so long?
3)Is this warning really can lead to rejecting the application?
And I saw similar questions on Stack-overflow but they seem to be outdated.
if an app use non public api then app will be rejected from apple.
This written on apple page
https://developer.apple.com/app-store/review/guidelines/
Apps that use non-public APIs will be rejected
I'm one of the PSPDFKit SDK authors.
None of the mentioned method names are private API and we haven't seen such a report so far. Please contact us at support.pspdfkit.com directly so we can work out what's going on here. Since we recently released PSPDFKit v5, many companies updated their apps so we can say with guarantee that our product does not get flagged on iTunes for such issues.
I also recommend updating Xcode, as we only list Xcode 7.1 and higher as compatible: https://pspdfkit.com/changelog/ios.
I've noticed that Instagram and some other apps allow users to report problems but don't actually let people report "bugs". Since I guess the premise of the Apple review process is they catch all bugs and there are no bugs in IOS apps, it makes sense that they do not use the word.
However, is Apple likely to reject the app if you use the word "bugs"?
Coming from a web background where it is okay to launch with a beta, I would like to be honest with users rather than politically correct if that is possible.
The reason I want to let them report bugs is not so much to catch them as we hope to launch bug-free but if anyone has a problem let them report it rather than write a bad review.
Would appreciate any guidance.
Thank you.
Apple review guideline;
2. Functionality
2.2 Apps that exhibit bugs will be rejected
I don't think this means that they have a filter on the word 'bug'. You may find some bug tracking apps available on the app store where they used the word so rejection it not a given, just because of a report bugs section in your app.
But at the time of an Apple review, if they find any bug, they will reject the app so that you may fix it. So you need to be very sharp at it that your app should not have any permanent bug or issue.
For confirmation you may contact App Developer support at https://developer.apple.com/contact/submit.php
You need to avoid using bug, beta or similar words. The phrase Bug report gives users the impression that your app has known issues. I would recommend Send feedback or Contact developer.
The App Store Review Guidelines does not allow you to submit beta apps.
2.9
Apps that are "demo", "trial", or "test" versions will be rejected.
Beta Apps may only be submitted through TestFlight and must follow the
TestFlight guidelines
Similarly, you should not leave known issues present in your app. If you already know the issues, you need to fix them before you submit the app.
For example, when I wrote Please reboot the app if it freezes in the description, it was rejected.
I get the following error message when I try to upload the archived app to the App Store:
I tried removing AdColony I was able to upload. Any ideas on how to get this error fixed?
We have throughly tested the app submission process and have found that apps submitted containing our SDK are being processed successfully through Apple’s iTunes Connect site. Our SDK is fully compliant with Apple’s stated intended usage and collection requirements for IDFA.
When you are submitting your app, that contains our SDK, through iTunes Connect you MUST check all 4 of the boxes asking about IDFA. Please see our support documentation on this issue here: http://support.adcolony.com/customer/portal/articles/1516610-device-identifiers-user-privacy.
We did have some reports from developers who were using other monetization partner's SDKs finding that one of these additional SDKs was causing the rejection. You should check with any other monetization partners that you are working with to ensure that their SDKs are up to date and not the cause of what you are seeing.