I am guessing that the App Store now verifies the symbols in the binary and if it find one that it doesn’t like, your application is not only rejected; but you can’t appeal and your reviews will now take longer. You effectively become second class.
It could be as simple as a mistyped selector in a declare or plugin.
Apple probably do not want building trade ex-workers to upload applications One day, they will start to ask for CSI degree before allowing XCode / Swift downloads ;-
In the Apple API, is there’s an API validator, something like <API_Call_Name>.Exists ?
That would require proper system administration knowledge - something that Apple and Microsoft are getting sneakier and sneakier about removing from the system owner’s scope of access.
Okay, so the poor fellow who’s had his app rejected for this reason, finally got a resolution from Apple; and an explanation.
His application was written in Objective-C, and has a lot of custom classes. Apple were reading his selectors (method names) and decided that they didn’t like them.
As we can build custom Obj-C classes in Xojo (via declares or plugins), and custom sub classes of OS supplied classes. This is something to pay attention to if you get the same rejection.
I had customers who disliked the peoples names I used (they do not provided yet at this time with real contact infos) just because I used politician, names of movie/music stars, etc.
In the next beta, I used a different approach like Michael G (G for Gotbatchov) and they saw nothing / did not react.
Yes, I asked them tons of times to send me their contact data so I can implement them in their software. And, all of a sudden, they send it to me (and what a bad list it was)
So: perception vs real use. I never let Listbox1 as a reference in a project, I try to use a meaningful method / function / whatever name, never double meaning word (when I know the used word have two different meanings), etc.
I also had one of my apps rejected because it turns out that I had mistakenly named one of my methods by the same name as an Apple private API. In that, I also learned than simply changing it by adding TG to the beginning or end of the method name did not clear the automated check. I had to completely obfuscate every call in the project to that method.
Apple wan’t it’s apps, and software to be clear with method names and such because they can simply filter crash reports and maybe other stuff to target specific items in logs.
In my case, it was a collision with a private API name. My app wasn’t denied because of any name, but because their automation claimed that I was calling a private API.
I don’t know of a list and think you just have to be unlucky. In my case, I was just unlucky. IIRC, I used a pair of extensions to the Window class that I named SmoothResizeVertical and SmoothResizeHorizontal and one or both of those matched a private API call.
For your security, to make you safer. Apple is protecting the user from malevolent developers.[quote=418158:@Emile Schwarz]So: perception vs real use. I never let Listbox1 as a reference in a project, I try to use a meaningful method / function / whatever name, never double meaning word (when I know the used word have two different meanings), etc.[/quote]
I once had a function called “youFu##ingPieceOfS##t”, which was fine, until an exception occurred in that function and I get sent e-mail reports…
Basically it’s to put our apps through the same excruciating validation checks as the App Store apps, but we can sell them on our own.
It would be nice for Apple to properly document it’s public API…
You can turn off function names, so then your custom function names won’t trip up Apple’s security, however any exceptions won’t be able to report the function they were raised from.