In article <
michelle-86EF9C...@news.eternal-september.org>,
Michelle Steiner <
mich...@michelle.org> wrote:
> And from
> <
http://www.icenium.com/blog/icenium-team-blog/2013/05/14/ios-app-store-appr
> oval-tips-and-tricks>
>
> Top Ten (or so) Reasons for iOS App Store Rejection
>
> Rejection is hard, and it's even harder not to take it personally. Remember
> asking Susie out to prom in High School? You were a Freshman and she was a
> Senior? Yeah, that didn't work out so well. I feel your pain buddy. And
> while I can't help out the awkward 14 year old in you, I can provide some
> guidance on what to avoid when writing an app for iOS. Some of these points
> are broad, others more specific, most may even be considered common sense,
> but my best advice is to use this as a quick checklist while you are
> gathering requirements and planning your app development strategy.
some are just flat out wrong.
> 1. Don't copy the functionality of an existing app. We are all standing
> on the shoulders of giants to a certain extent, so it's ok to take an idea
> and improve upon it. However, if you copy an app verbatim, you will most
> likely find yourself going to prom alone, er, I mean getting rejected by
> Apple.
except when they don't reject. there are quite a few clone apps which
last until the original app developer notices and requests a takedown.
if you clone something popular, apple might notice, but if it's a less
common app, the reviewer might not know about the original among the 1
million apps.
> 2. Make your app relevant and useful to a relatively broad population.
> Apple will not approve an app that is targeted to a very specific or
> limited audience. For example, if you develop an app that is ONLY meant to
> be used by your local pickup basketball team, you're gonna have a bad time.
there are apps that are targeted to specific niches, including
requiring specific hardware for the app to even function.
> 3. If you are taking in-app payments, please don't try to take someone's
> money without using Apple's In-App purchasing API. This is a guaranteed
> rejection. And yes, there's a Cordova plugin for that.
you can't take the payments outside the app store but you can have them
subscribe or pay for it elsewhere, which is reflected in your account
when you log into it (or some other method).
> 4. Apple tends to make really pretty images and icons, don't they? Well,
> don't get tempted to use them. While you might think Apple would be
> flattered by this, they most definitely are not, and will reject you if you
> copy icons that are not meant to be re-used in an app.
that's obvious although apple gets to do it themselves, such as with
the swiss railways and clock icon they stole.
> 5. Be a miser when it comes to downloading data within your app. Keep in
> mind that many of your users are on limited cellular data plans and won't
> appreciate the fact that you are downloading 5MB of data every time you
> open the app. There are no specific guidelines from Apple, but you should
> be safe if you keep your downloads to a minimum.
that won't get a rejection, it will just piss off users.
> 6. Don't rely on an always-connected device. If your app crashes or
> otherwise doesn't function because it doesn't have a network connection, it
> probably won't get approved.
that's common sense, and apple mentions apps should check and that
conditions can change at any time.
> 7. It can be tempting to tease with a "beta" or "demo" version of an
> app. Apple forbids these types of apps, so it is best to stay away from
> using this kind of title in your app description.
you can't call it 'beta' or 'demo', you just have to call it something
else.
there are plenty of apps that have two versions, one which is 'lite'
and usually free, while the main version has full functionality and
costs money. that's for all intents, a demo. you just can't use the
word demo. it's very stupid.
another way is adopt the freemium model where you get basic
functionality for free (i.e., the demo) and must pay to unlock
everything else. a lot of games do this, where you get a couple of
levels and that's it, until you buy more levels.
> 8. If your app takes longer than 10 seconds to initially load, it won't
> get approved. And yes, this is a good sign that you are probably doing
> something wrong anyway!
also wrong. i've launched apps that take a while to start up and much
longer than 10 seconds. tetris blitz takes 40 seconds until you get to
the point where you can play (tested just now on an iphone 4), with the
initial splash screen lasting more than 10 seconds.
> 9. Don't abuse the iOS file system. Since iOS 5.1, Apple doesn't allow
> apps to save data to the device that normally gets backed up by iCloud
> (without the user's permission). Instead, save this data to the device's
> cache. You can use Local Storage (which uses the cache), but just be aware
> that anything saved here may be overwritten.
>
> 10. I can't stress this enough: don't violate the Human Interface
> Guidelines! Apple has very specific directions on the sizes and locations
> of buttons/icons/navigation bars/etc. Violate these by a few pixels and you
> may find yourself in rejection land. (However, if you use Kendo UI Mobile a
> good portion of this has been taken care of for you!)
nonsense. there are a *lot* of apps that have horrible user interfaces,
some with tiny buttons (including apple) or they recreate apple's ui
elements but don't do as good of a job. this tends to happen with
cross-platform ios/android apps.
> 11. Avoid downloading external scripts. There is A LOT of confusion
> out there regarding the concept of downloading content/scripts within your
> app at runtime. Apple's own guidelines state, "Apps that download code in
> any way or form will be rejected". This is unfortunately vague, as one
> could interpret that as being HTML/CSS and JavaScript as well. My advice is
> to stay away from downloading/executing JavaScript in your app - I would
> definitely avoid CDNs especially as your app will be more performant
> keeping everything on the file system.
there are apps that can download code now. it's limited but not
entirely forbidden.
> 12. Keep the size of your app (the final .ipa file) down to a
> manageable size, most likely under 50MB. If you have multiple image assets,
> consider utilizing lossy compression on your JPEGs and PNGs.
that's definitely *not* a reason for rejection. there are a number of
apps that are 1 gig in size or more, notably gps navigation apps and
some graphic intensive games.
if an app has to be big, then it has to be big.
> 13. Don't go crazy with the vibration function. Vibrations should ONLY
> be used for alerts. You will annoy your users, but more importantly, your
> users won't see your app in the first place if you abuse this privilege.
>
> 14. Maybe most important of all, though, is that an app is an app
> because it can't be a mobile web site. I know, I hear you! But Apple cares
> about this and as hybrid mobile app developers you have to be very aware of
> this too, since you ARE developing with the HTML5 stack. If it looks and
> feels like a web site, it probably won't pass the review.
facebook did.
> Also remember that you are dealing with real people who sometimes make real
> mistakes. Case in point: I previously submitted an app that was rejected
> for storing data in an inappropriate location (specifically, they thought
> we were storing data in a place that normally gets backed up in iCloud). I
> had to inform my reviewer that they were incorrect, that we were in fact
> storing the data appropriately (supported with documentation of course).
> They then promptly approved the app!
one of the more amusing rejections was that apple said you can't use
the coverflow apis for some silly reason.
because of that, a developer wrote his own version of coverflow for his
app. the app was rejected because it used coverflow.
he wrote back and said he wasn't using *apple's* coverflow, he was
using *his own* coverflow. it was later approved.