They rejected it again. The stupid, it burns:
22.2: Apps that contain false, fraudulent or misleading representations will be rejected
We found that your app, and/or its metadata, contains content that could be misleading to users, which is not in compliance with the App Store Review Guidelines.
It would be appropriate to remove or revise any content referring to "screensaver" screen saver functionalities are not possible on iOS devices.
I have submitted an appeal, but it sure would be nice to have some inside help to make them reach a "yes" decision than to have it summarily re-rejected by some flunky who doesn't know anything about the long history of this package, or open source, or me.
I am a strong believer in nepotism in cases like this. Please help.
I wrote:
You have rejected my app, XScreenSaver, because you say that including the word "screen saver" will confuse people.
I very strongly believe that naming this app anything else will confuse people far more.
The XScreenSaver package has existed since 1991. It has been the default screen saver package on Linux for most of that time, and as such has literally millions of users who are familiar with it. Though it originally ran on X Windows, when I ported it to Mac OS X, I kept the name "XScreenSaver" in order to avoid confusion. It is extremely popular on Mac OS X as well.
As this is a straightforward port to iOS of the 200+ display modes included in XScreenSaver, naming it something else on iOS would create far more confusion than it eliminates.
Again, this package has had the name "XScreenSaver" for literally twenty-one years. There are millons of users who are familiar with it under that name, and many of them want to run these demos on their iPhones and iPads.
Please don't make it harder for them to find it by making me name it something confusing.
I love the implication that my application is "fraudulent". Nice.
And my prediction of the date on which they would next reject it was spot on! Ten days, again. (June 22, July 3, July 13, July 30.)
Previously, previously, previously.
Update: RESOLVED FIXED!
XScreenSaver Player? It doesn't save your screen, it just plays the things that used to save your screen!
Your suggestion contains both the words "screen" and "saver". I don't particularly want to get into some play-by-mail argument with a ten-plus day turnaround time about this with some bot where they take suggestions like yours (and, no doubt, the dozen similar ones that are incoming) and cut-and-paste the exact the same rejection message. The package will be thirty-one years old by the time that plays out.
Given that you're gonna have this fight.. TheAppKnownAsXscreensaverInTheWholeWorldExceptiOSwhereThereIsNoScreenSaver ? If nothing else that'll indicate if there's a functioning brain cell in the evaluation department (not a given...)
That'll fit quite nicely in an icon name on an iOS device.
Some more ideas you'll reject...
"Just Like Flying Toasters But Completely Different"
"XScreenSaver is not a Screen Saver on iOS"
"XScreenSaver: Not Available on Android"
"Rhymes with Hex Green Shaver"
"I'm using XScreenSaver Ironically"
"Retro XScreenSaver Simulator" (because hip and cool young people like retro things and it's simulating the act of saving your screen)
XEenscrayAversay
Plus they can still complain about the X - I mean, seriously, my iPad is running Xwindows? I don't think so.
It sure is fun dealing with the Apple walled garden, eh?
I suspect that the turnaround time on responses is strongly tied to your rank in the app store - the higher our app goes, the quicker the approval process goes. We're down to only 6 days now, from 14!
Living in the future is so awesome.
" I don't particularly want to get into some play-by-mail argument"
Of course you realize that's probably what will happen eventually.
That's so much more depressing than my guess which was, "Okay, so they have to approve a LOT of submissions, and they're just perpetually about two work weeks behind."
Blegh.
Overall, do you prefer the technical challenges on open platforms or the social brain-damage on curated/policed ones?
I sell beer, dude.
Both flavors of bullshit in your Hobson's choice taste as sweet.
Clarify this for me please. You sell beer for a living, so you do this for... fun?
Yeah, so, I'm not a good decision-maker.
I think it was well said previously: "Once again it becomes clear that my one purpose in life is to serve as a warning to others.".
Reminded of that one almost every time you post something with the "firstperson" tag.
Obviously you are a better decision-maker than some of us since you actually sell beer for a living (and pizza?). I always said I'd open a bar when I'm sick of dealing with software. :-)
Doing it "for fun" is to remind you why you no longer do it for a living.
Cheers,
The pain, the pleasure, the pain, the pleasure. There are - subconscious - motivations here.
"Da pain, boss, da pain!"
s,sell,& and drink,
The pre-processor wrappers he had to write to simulate OpenGL on OpenGL ES lead me to think that he prefers the technical AND social brain damage in the walled garden. Although considering the textual screams I've read on this blog, I wonder if it shouldn't be called a walled dungeon...
Just had a similar issue with google trying to get a new transit feed accepted.
Some of the stops on some of the bus routes are by request only, and are flagged as such in the feed as per googles specifications. We then created the shape files which define the path the buses take to get from stop to stop, since the bus almost never stops at those by request stops we left them out of the shape file so our shape files accurately showed the path the bus takes over 95% of the time.
Google rejected it. The reason was there were stops (the by request stops) that were too far from the path we had drawn so our path was inaccurate as "people looking on google maps to see where the bus goes will see inaccurate information." We explained that by leaving out the on request stops the path drawn is MORE accurate most of the time, while doing it the way google was requesting (including the on demand stops) is actually less accurate as it will result in google showing the bus going places it actually doesn't. And on our transit system that's kind of a big deal since pickups/dropoffs are allowed at any point on the route - so one of the benefits the transit authority was expecting from having the feed on-line was letting people see the paths on the map and know where to meet a bus even if there isn't an official stop.
After going back and forth with google a few times, thankfully not nearly as slow as the appstore approval process but still apparently outsourced to india, we finally gave up modified the shapes to include the seldom used by request stops in the shape files. So now our data is inaccurate most of the time and less useful to the people who will be using it. But google is happy because it fits their definition of "accurate".
The real crazy part is they've got several automated tools they provide for validating feeds - but none of them check for a number of issues like this which only come up in the final review where it appears they're using some tools internally that do check for those issues. Add in all the times they'd send us a rejection and request a fix despite the fix having been made several revisions previously and pushed to google several times since it was fixed...
Yeah, I don't see anything that could convince me to take on a project that involves getting approval in the apple appstore!
"Some of the stops ... are by request only" but the bus "almost never stops at those" and so you "left them out" of the route ... however "pickups/ dropoffs are allowed at any point on the route"
So I'm fascinated. How do passengers "request" the stops that the bus "almost never stops at" and indeed doesn't ordinarily get close enough to for it to satisfy Google's route validator? Do they submit a written request a few days in advance? Is there maybe a large Roman-style beacon which they can set ablaze? Are all the resulting infrequently used sections of the route loops? If not, what happens to people expecting to board the bus at a point where it would ordinarily pass, but sometimes doesn't because of a "by request" stop? Why are these "request" stops different from the places where "pickups/ dropoffs are allowed at any point"?
You've never tried (attempting) riding
masspublic transit outside a major, major city, have you?It's common for a lot of places to run bus services that are basically subsidized transit for the elderly/disabled who'd otherwise be completely homebound. The bus is summoned with a device called a 'telephone.' It's also common (and annoying) for places that get 3 riders a day to have a tiny central loop with the option to ask the driver to make an excursion to anywhere worth going rather than parking the bus for 30 minutes. This is fun because it relies on the good will and memory of the driver to pick you up for the return trip (probably improved now that everyone has a phone in their pocket).
I've lived in a village when I was younger. That village is in an area that's a bit special (for example, there are London Underground stations and a disproportionate number of armed police) but in most ways it's just a country village. It has one bus, and I used to travel on that bus when I was a kid. Every stop was a "request stop" but none of them were skipped just because nobody had made an announcement in advance that they'd be requesting a stop there that day. As you illustrate, such an approach results in passengers being left in the middle of nowhere, which seems like a pretty serious defect to me. Instead we'd weave our way through the countryside, taking an hour or more to reach our destination even if nobody else wanted a bus that day. Predictability is a really good thing in public transport.
And actually although I now live in a city I live in the outskirts, my last train home only stops near my house if the guard determines that one of the passengers is going there. If everybody is headed into the city proper the train just breezes through, but that last train is never listed as visiting my home station for picking up passengers even if it does stop, so there's no chance anyone will be disappointed.
So, per your last paragraph, you completely understand the point the OP was making, but you were just arguing to be an ass?
The purpose of that last paragraph was to show how a thoughtful transit system can avoid frustrating users / potential users with "stops" they can't actually use. I've never seen a system like Jason's although since he's explained it in more detail below I believe him that it exists and is even common somewhere in the world. I don't know why they've done it that way, and nor seemingly does Jason.
Quite simply they have to call the transit authority and request the stop. I'm by no means a transit expert but it seems this kind of thing isn't entirely unheard of, after all as I pointed out the google GTFS feed specifications have specific exemptions listed for specifically this kind of on request only stop.
The "request" stops are different in that they aren't along the path that the bus normally travels, usually they're a block or two out of the way so instead of going straight for two blocks down the normal path the bus turns and loops around it when taking the on demand stop. In one case the on demand stop is at a small "town" between two larger towns that are serviced by the one route. To make the on demand stop the bus must leave the highway and re-enter it. Something it only does when a request for that stop has been made in advance. But now google maps shows the bus as always doing it.
I'm in full agreement that it's silly and a poorly planned...(and IMHO is one of the less silly and poorly planed aspects of our transit agency) but I still believe google's position is wrong about how to deal with these as under google's method the data displayed on google is wrong the vast majority of the time and occasionally correct. While leaving those stops off of the path would result in google display information that is correct the majority of the time and only incorrect on the rare occasions when those stops are used. If their concern is, as the claim, to display the most accurate information to their users then you would think they would want it to be accurate as often as possible.
this is par for the course. best advice for dealing with this stuff: chill out and don't get mad. take it from the dude who got the game "ow my balls!" approved - it's worth the wait. i'm still working on getting an approval for an app i first submitted on april 29th. http://reviewtimes.shinydevelopment.com
As previously, I do not offer any opinion here as to whether Apple is being reasonable or not. The following is just for people who want to work with Apple nevertheless.
First, by all means do not take personally the accusation of the app being misleading (especially the "fraudulent" bit, in your case it's just considered "misleading", but they only have one category for the two as well as "false")… They are trying (badly) to communicate that they estimate that user is going to be misled with that app name; take it as feedback on the app submission, not as a judgment of value over you as an app developer or publisher, or over the core app.
I don't think Apple cares a lot about the long and illustrious history, or about the brand recognition of XScreenSaver; even if the reviewer and his manager and his manager's manager were all fully aware of the sheer depth and value of it all, Apple cares much more about the image it's projecting (consider it narcissism if that helps you stomach it), including through the third-party apps it is distributing on the iOS App Store. And chief among the image preservation concerns is not misleading the customer; doubly so for a feature (screen saving) that the user cannot tell is is having a positive effect: how can the user know whether his screen is still good because he used a screen saver, or whether the screen saver is snake oil and his screen would have stayed good anyway? Using a screen saver is chief among the computer things users do because an entity (either the local computer expert, or the platform vendor, etc.) of trust told the user to do so. Apple most definitely does not want anyone to think iOS devices would be subject to any screen degradation whatsoever if no screen saver was used. The only way they might take you seriously with the importance of using any variant of "screensaver" as a name is if there was a trademark involved, and as far as I know there is none. It's useless to propose keeping the name and clarifying/putting a disclaimer in the description, as Apple wants to make sure everyone, including people who read nothing except the description are not misled.
My suggestion would be to name the app something in the spirit of "visualizations", "contemplations" (and talk of, say, individual "modules") or something coming from the demoscene, except do not put "demo" or any combination thereof, as "demo" (as in "try before you buy") is taboo on the iOS and Mac App Stores. You might have to scrub any mention of "screensaver" from the app, except maybe once as XScreenSaver in the acknowledgements.
Your longwinded apology for Apple is fantastically uninteresting to me.
If you do want to get the app on the iOS App Store, it helps to understand them. I am not saying it's normal or fair for any developer (you or anyone else) to have to do this effort (nor am I saying the converse).
...by all means do not take personally the accusation of the app being misleading...
At the very least it's something they could have mentioned in one of the earlier 10-day cycles. Apple picking out one bug or issue per attempted submission is utter bullshit.
Even so, doing a cursory search shows five apps on the first results page of apps with "screen saver" or "screensaver" in their names. Again, utter bullshit and shifting standards.
"Ring tones".
"Dialed numbers".
These are misleading to users.
it's skeuomorphic!
hm, isn't a screensaver also skeumorphic? It's an appendix that refers to a previous technological era and is no longer needed but provides familiarity to the user. So actually Apple should love screensavers.
There is no special treatment to be found. I am told that the submission process is the same inside Apple, with the sole difference being the ability to overrule the result. You will not succeed down that path. Either show how your interpretation of some other rule of theirs allows what you want, or bend to conform to their rules.
Their rules are arbitrary and we can debate their consequences endlessly, but Apple has shown zero interest in the Internet's opinion of them.
And yet somehow the horridness that is the Podcast app got through...
I believe that “sole difference” of “the ability to overrule the result” (which is quite an important difference!) would be sufficient here.
Oh I know! You should just call it XSS– oh.
You are fighting an uphill battle by framing XScreenSaver as a set of screen savers. It makes perfect sense everywhere else it's available, but you can't get around the question "why would you need a screen saver on iOS?" and I don't fault the reviewers for forming the question because it'll be the first thing many people ask too and the fact is that it really doesn't work as a screen saver. In this way, it really is misleading, although certainly not maliciously so or by choice. Either you stop and take this as a legitimate point and change your approach so that it isn't, or you hope someone will eventually approve it by mistake.
The good news is that you have already tossed the screen saver part of the UI (turn on after X minutes). Frame it as "watch nice effects". Store's full of those apps. Make it able to run the hacks on extra screens if you have to. (The Simulator supports testing this.) If Wal-Mart sells fireplace videos, the App Store should be able to distribute self-solving mazes ready for AirPlay with a straight face.
I am not saying that it's fair that you have to give up your name - or convince someone higher up to eke out a lasting, documented exception which doesn't go away the next time some reviewer has a brainwave. Depending on how you look at it, you are both technically correct. But the quibble is entirely in the name begetting the part of its purpose that you can't provide on iOS. If you found another name, the issue would be off the table forever. (Maybe they would also accept big bold text at the top of the app description saying "THIS IS NOT ACTUALLY A SCREEN SAVER, IT'S JUST A PORT OF XSCREENSAVER.", but they could say that it assumes a lot of knowledge and they wouldn't be wrong.)
So it's either finding a new name or hoping Phil Schiller is a long-time XScreenSaver fan. Or just saying "fuck this" and not dragging it through this beloved process again. Nothing wrong with having principles.
Well, it's not like it is running on many CRTs these days, LCDs don't need them, do plasma? So functionality isn't there, it is just fun to watch. I install it for that reason.
That shift happened years before LCDs took over. Screen savers went from meaning screen-exercising burn-in protection to thing that comes on after a few minutes and block everything until you move the mouse or hit a key, possibly asking for log in or a password again.
No, I'm afraid LCDs do exhibit varying degrees of image persistance with varying levels of permanence. Displays permanently tuned to e.g. a 24-hour cable news station are a canonical example.
Is the name XScreen (no 'saver') taken by anyone for anything? Describe it as being all about cool screen effects and all that, and put in little itty-bitty text at the bottom "Also available on Linux and OSX as 'XScreenSaver'" Or maybe leave that bit off until the first upgrade.
Not what you asked for, I know, but it's all I can suggest.
This seems like the only way to go that's actually going to work. Change the name so it can get approved, and make reference to the original in the descriptive text so people can find it.
XSpleenSaver. Anyone who is familiar with XScreenSaver will know what it's for...
Make sure you don't have the word "Amazon" in it either: http://boingboing.net/2012/07/28/apple-wont-carry-an-ebook-be.html
I think that you completelly missunderstood apple. The important part is "X" in screen saver., not screen saver. Reviewer was hoping for some porn, ond found nothing. So far, I think this is the best explanation O;-)
It is also perhaps worth noting that a quick search on the iTunes Store for "Screensaver" yields dozens of hits, many of which have the word "Screensaver" (and often little else) in title. Not that "Apple Store Guidelines Inconsistent, Capricious" would make a list of noteworthy items of the day.
(Not trying to play defensive here, just pointing this out.)
Apple's store guidelines aren't static. A lot of the rules, undoubtedly including this one, were added in response to antipatterns they see developing in the store, and they don't reject apps retroactively.
As far as this particular rule goes, I can fully understand the concern they're dealing: there have been tons of bogus apps in the store that claim to add OS features, but didn't (because they couldn't). One popular example for a while was apps which claimed to modify the lock screen by setting the background to an Android-style pattern lock, or to even sillier things like a fingerprint scanner. There are a lot of really gullible users out there.
If it helps any, a few such apps are still in the store (and still receiving updates) with a disclaimer along the lines of:
And refer to the hacks as "visual effects" (not "screensavers") in the description, if they aren't already
This is what you are really up against: Ripoff artists who have called $1 apps screensavers in the past. Take a deep breath, name it after yourself, e.g. "jwz's graphics demos" or the like, and then change the name after it's accepted.
This appears to prove that version binary updates can have revised names, but I have no idea whether they still go through name review. Please disregard and forgive my confusion if this is what you have been doing, which suddenly seems very likely.
"They don't reject apps retroactively"
They sure as hell do.
Ah, fine, overgeneralization. Perhaps better: When they add new rules, they don't go searching for apps that violate them.
I believe you are in violation of Apple patent number 420: An application for predicting an application store's rejection of an application.
"eXScreenSaver" as it isn't really a screensaver any more?
Next up: rejection because the BSOD module will mislead users into believing there are actual errors with their device.
Honestly, that was what I expected, more than the name.
Because I've already had Linux distros exclude BSOD for exactly that reason. I'm not even joking.
Why would you put up with this abuse? Do you feel you deserve to get shit on? Your artful and effortful application could only possibly enrich the Apple app store - yet the repayment is arbitrary and purposeless torment. Leave the visualizations where they belong - on Linux, where they can be appreciated on a platform that demonstrates respect for the developer and respect for the end user.
It turns out -- shockingly enough -- xscreensaver is already on Linux.
You may have noticed.
Unless you're using Gnome. Or KDE. Where apparently it does not meet their exacting standards either, which are apparently as or more severe than Apple's.
Wait, what was your point again?
Seemed a convoluted way to let you know we don't want you to suffer the fools at Apple.
Would arguing with them about the myriad existing screensaver.* apps be worth a ten day trial/wait?
Just rename it "Butt-Head
AstronomerApp Reviewer". I'm sure they'll appreciate the joke.That's ancient enough history that I'll bet many Apple people don't know or appreciate it, even if some of us do...
revasneercsx?
“Otherwise we would have to send an enforcement officer to confiscate your ice cream cones."
I see at least 8 apps in the App Store called "screensaver." Does that help your argument? Or will they just pull those apps?
The stupid, it burns!
If anything in a screensaver is "fraudulent", it'd be the OSX screensaver on the MacBook next to me--which has left the mouse cursor visible on top.