Is there any list of methods which are not allowed when they are compiled in the application? Or a syntax that is not allowed?
With this message from Connect recently our app has been rejected due to the removeEvents method name:
Your app uses or references the following non-public APIs:
removeEvents:
The use of non-public APIs is not permitted on the App Store because it can lead to a poor user experience should these APIs change.
End. No more details regarding the finding.
The method is used in the app on a core data object (subclassed from NSManagedObject). The object (and the method) was generated by mogenerator app for quite a long time. I did not find any reference in the updated review guidelines for iOS10 that is relevant to this.
The issue is that in the rejection statement from Apple there is no private api, or a conventional object description, or any principle that I could follow to avoid this next time when the app is being approved. It is then making from the review an unpredictable process.
I could not find any trace of this method using both nm or otool. None of them has found a reference to this.
EDIT: In the iTunes Connect is an option to submit an appeal to the App Review Board. I did not noticed this before. The question is when they will review the review.
No more details? In that case you didn't read carefully. There will be a link to the rejection that explains exactly how to look for this if it happens in a third party library for example. Been there, done that.
So you can file a complaint and they will laugh at you, because you didn't bother reading the app rejection.
To save you the bother, search through your own source code, then use the strings and otool tools to find the library that caused the problem, update the library and check if the problem is gone.
And if you use removeEvents yourself according to your comments, then fix your code.
A member from the review board has contacted us and confirmed that the only way to get the information about a collision with a private api is to let the app pass through the review process. Apple offered to complete a new review in two days and so they did.
I have renamed the method and the app was not rejected.
Related
I created an application that simply spins a picture of my goose on screen. That's it. Nothing else.
Could that be deployed to the app stores?
Context:
I'm a mobile app engineer for a few different companies (finTech, gigEconomy, social...) and all of our applications have very specific use cases for the end user.
I'm also an artist in my own time, and have built a few different apps that help people make art.
For each of these, the data gathered by the apps must be well documented and explained to the end user to be accepted by the App Store along with the purpose of that collection.
That's got me thinking, would the Apple App Store accept an app that does not collect any user data at all, but also has no true "purpose"? (Google Play Store too, though I expect their review process is so easy you can get just about anything up there anyways...)
I haven't found any relevant answers to this question online and might test it just for fun, but would love some insight by other curious developers if they have tried uploading apps just for fun
You might find the following section from the official App Store Review Guidelines useful:
4.2 Minimum Functionality
Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or “app-like,” it doesn’t belong on the App Store. If your App doesn’t provide some sort of lasting entertainment value or adequate utility, it may not be accepted.
Does this include a purpose or does this mean that an app like you have suggested in your scenario gets rejected? Absolutely not.
After a quick google search, I have found the IsItMyBirthday app which lets you pick a date and it tells you if that date is today. Is this useful or unique? We could just look up the date in the calendar on the phone itself.
However, this could be considered a 'joke' and a joke has a purpose and might be considered as unique. An app that does nothing, could be considered a joke as well. It has a purpose and Apple might agree or disagree.
In my experience it can be very random on why an app gets rejected or accepted. For example one of our apps got rejected in version X for reason Y. We released a new version without changing Y and it was accepted.
I'm trying to create a small console application sending and receiving message from SFB.
I started by using the code from https://github.com/tamhinsf/ucwa-sfbo-console and followed the readme.md for creating the app in the Azure Management Portal (I assigned all the delegated permissions just to be sure).
All already included API work (so I'm sure I'm logging in correctly), but when I try to invoke makeMeAvailable to receive IM call (looking at https://ucwa.skype.com/documentation/KeyTasks-Communication-IncomingIMCall) I get the following response
{"code":"Forbidden","message":"The requested operation isn\u0027t allowed."}
My post data is the following
{"SupportedModalities":["Messaging"]}
Which is just as the example from the ucwa.skype.com site.
I'm also finding problematic to send a message, on the skype site the https://ucwa.skype.com/documentation/Resources-startMessaging shows a call to
Post https://fe1.contoso.com:443//v1/applications/970/communication/startMessaging
but on my application response embedded.communication._links.startMessaging is /messagingInvitations and not /startMessaging.
The documentation on https://ucwa.skype.com/documentation/KeyTasks-CreateApplication-3 also shows
"startMessaging":{"href":"/ucwa/oauth/v1/applications/105/communication/messagingInvitations"},
I'm quite confused over what I should do to correctly send and receive messages and the API documentation did not really help.
Thank you in advance.
makeMeAvailable isn't supported yet in UCWA for Online. Probably when it'll be introduced, a new app permission will be added in AAD permissions, which will need to be granted. So, that's expected, but the documentation is indeed outdated and just referring to behavior for UCWA for On-Prem.
See also / vote: Enable 'me' resource and controlling self user's presence in UCWA
You're correct, good finding. However, POSTing on the messagingInvitations resource (which is no where in documentation), is the correct way. So following the principle of using the URIs returned by operations, and not composing URIs by convention in your code is the way to go.
You can notify this by creating an issue here: https://github.com/OfficeDev/skype-docs/issues
I am creating the app which loads the HTML page in UIWebView. Here, we are doing the offline capture feature for the app(doing encryption and storing data to the device using coredata).
Note : My App UI is completely UIWebView.
Recently, I heard that these kind of apps gets rejected by apple app store.
If it is true or some one have the same rejection, please provide the info.
your help could be appreciated.
Just using HTML as an implementation method of your UI doesn't become a reason for rejection. This once has been an issue a few years ago, and Apple formally does not limit implementation method anymore. If they do, most of hybrid app platforms couldn't work.
If someone have rejection of their HTML UI app, that should be due to bug or crude implementation of the app features rather than using of HTML stuff. In many cases HTML based UI on mobile systems fails to provide nice responses, then you need to care a lot not to break them. If the reviewer think your app is broken, then your app will be rejected.
Take care that the basis of normal or working state is always Apple's native app.
Yes. An app which its purpose is only to preview a website will be rejected based on Apple's Review Guidelines. Your app has to offer a minimum functionality and introduce at least some App Specific values to be acceptable. You can refer to this link for more information on Apples policy for releasing new applications:
App Store Review Guidelines Minimum Functionality
I know that there are some restricted api's or code that are not allowed to be in your app when you submit it to the app store.
How do you know what they are? Is there a way to check your app before you submit it to ensure you have not used such api's?
It is probably better to avoid this problem at the design stage, than trying to fix it later, so I was wondering if there is any tool in Xcode, or document to determine this.
The way Apple intends for you to do this is to use XCode's Validation feature. When you're submitting an app, you build for achiving (or Archive from the XCode menu). Then, you open up Organizer to see the archive you just created. At this point, you can press the Validate button in Organizer. That will perform a validation, without actually submitting the app. It will tell you if you're using Private APIs. Depending on how you use them, it might identify what the violation is:
There's definitely ways that code can fool this validation step, and "get away" with using Private APIs until the reviewer looks at the bundle. But, as far as I know, those ways would all be intentional methods of hiding Private API usage, and it sounds like you're trying to discover accidental usage.
If you fail this Validation test, then you might want to use something like AppScanner, mentioned in alan duncan's answer. But, for completeness, I wanted to make sure people knew that this Validation step is available in XCode, and checking for Private API usage is one of the things it's doing before you submit (and have to wait a few days to be told what you did wrong). Also, even if you don't use the Validate button in Organizer, but just use Submit, the tool is performing a Validation for you. The only difference is whether the bundle actually gets uploaded to iTunes Connect.
If you stick to documented interfaces as suggested above, you're fine. The only issue is with third-party libraries whose implementation may be opaque to you.
There is a Mac app called AppScanner that scans from private API usage. I have no experience with it, though.
You will get more information on Apple approval process from
App Store Review Guidelines for iOS apps (You must be a registered iOS developer for accessing this data).
iOS Human Interface Guidlines.
get the private API list.
use class-dump to process the Mach-O file, and get the processed string.
use regex to get the interface, class, or method in the string.
match the API to private API list.
then GOT it~
I opened a porject to do this, but because the reason of my company, canceled. very sorry for this.
I am developing an application where in i want to alert the user if he receives a message from a contact.
I have been struggling for the same yet haven't found any solution to this.
I also wanted to know if the sdk 3.0 allows access to the call history..
There is no access to SMS messages from the application sandbox, and there is no access to call logs from the application sandbox. You can file a feature request with Apple, but I doubt you will see changes to this any time soon. You will not be able to provide any functionality in your app that depends on this information.
Similar question here regarding call history:
Reading call history in iPhone OS
Short answer is, not possible. I do not believe this has changed in 3.0.