iOS app with content downloading automatically (about App Store policy) - ios

I have an app in the App Store with a number of different soundboards. I release updates every once in a while with new content. Some content however is forbidden by Apple (foul language) resulting in updates being rejected. To make updating faster and easier, I'm building an update which automatically downloads new content from a server. So my question is; what will happen when content in an update is found inappropriate by Apple? Will my app be removed from the App Store? Will they ban my developer account? Will they even find out? The app is in Dutch and therefore it's quite hard te determine what is permissible by App Store policy and what is not. I had some explicit content accepted in updates, while other seemingly less explicit content got rejected.

Your app is never reviewed by the same person and so much depends on the reviewer. There is a Dutch review team so regarding not noticing due to language, I wouldn't rely on it.
Now I have released apps that breach API terms with youtube and the apps existed on the appstore for a long time. Once it was brought to Apple's attention, they removed the app but did not suspend my developer account (I imagine that you have to break policy repeatedly for this and do something much worse than simply having foul language in your app). In my opinion, If Apple notices that your app has foul language on it, they will simply remove it from sale and ask you to submit an update which addresses the issue as they did in my case.

Related

How do I replace an old expired iOS app with a new app that I built from the ground up?

I have what I believe to be a pretty unique situation and I can't seem to find a solution online. The problem timeline:
4 years ago I paid a developer to build/upload an app to the iOS App Store for me under my own developer account.
Over the years it became outdated and this April it was kicked out of the App Store
I took some online courses this year and rebuilt the app from the ground up.
I would like to post my rebuilt version to the App Store - completely fresh like it's a brand new app (because it basically is)
A couple more things to consider...
I used Swift vs the original Objective-C that the developer used.
I used UserDefaults instead of what appears to be iCloud. (the dev account seems to be littered with permissions for things I don't intend to use - so advice on how to get rid of all of the weird stuff I don't use would be helpful, too)
I also have a different but similar bundle identifier (it replaces "RandomRuby" with "Random-Ruby") that Apple's App ID registration system seems to not like.
The level content and game play are the same - but I have no idea how to figure out what level the previous users were on. (which I'm ok with if it's ethical to make people start over).
It had In-App purchases (they could purchase consumable "Rubies" to use for hints and there was an "Ad Free" upgrade option. The new app doesn't use ads - it just has consumable "Rubies" for monetization). I have no plan to add ads back in - so I imagine a complete reset would be ok here, too? Again - is that ethical?
With all of this context - my question is...
How do I upload a completely-rebuilt-from-scratch app with the exact same name from the exact same company as an expired app through the iOS Developer system? Is this even possible? I'm having a hard time figuring out where to start. I can't even get past creating an App ID.
To update an existing app in your Apple Developer account you only need to use the same BUNDLE ID (e.g. com.apple.keynote) in your Xcode project and a higher version/build number. Everything else is not relevant.
Your previous iOS APP is bounded with the Apple Developer account when it was submitted. And the APP name is unique, just like anyone else may not create another app named 'Facebook'.
So, if the Apple Developer account was not yours, you are in trouble. You need to ask the previous programmer to transfer the APP to you.
If the Apple Developer account was merely expired, and you can prove that the account belongs to you, I guess you can contact Apple Support for help.

How To Setup iOS App to Have Notify Button on App Store Pre-Launch

Some iOS apps that have not yet launched on the iOS app store now (Super Mario) have the ability for users to click a button on the app store listing to be notified when the app becomes available. How is this done? This will obviously impact a large number of apps/developers. If this is not yet possible for general release apps from the general developer community, only for apps that have specially arranged it with Apple, please update answers to this question when/if this becomes generally available, which seems likely.
Please do not downvote this question as 'off topic' given that the answer to this will obviously be important to a lot of iOS developers who turn to SO for answers (like I just did).
Thanks
This is not a feature part of the Apple Developer Program.

Does ios app Metadata rejected means binary is good

I recently got a phone call from Apple saying they would reject our app since there's a problem with the metadata. I asked whether there's a problem with the app itself and she said she doesn't know because she's not part of the review team. She said it should be ok.
So I changed my metadata and resubmit the app, and the status now is in review. According to itunesconnect programmer guide, they will reuse the binary. Does that mean the binary is good? Is it possible that they will take a look at the app again and reject me for some reasons other than they specified in the resolution centre?
I know this is a question that probably only apple can answer, but this is our first app so i don't really know how it works. I asked apple but they didn't tell me anything.
You do not need to upload new binary. They will review it again and approve it (or reject for other reason). It took only few hours in my case. But you can't be sure the binary has already been checked. Maybe they only did the metadata so far and will check the binary after your metadata correction. Anyway, no need to upload anything now.
Usually reviewers stop their review process as soon as they find an issue. This means that the metadata rejection can be the first of a longer list (hopefully no!) or that they reviewed your whole app and found the only issue at metadata level only: in such case fixing your metadata should be enough.
Recently I saw one of my apps rejected due to a mistake in adding an In App Purchase (basically the app was referring to an IAP still not in iTunes). After fixing it (no binary change, just adding the "in app") they found an issue in the app this time and then the binary was submitted. It would have been quite easier for me to know of the two issues together and fix them once, instead the triple-trip delayed my final app submission by 10 extra days (consider 5 days between two consecutive reviews)
From my experience, it doesn't always mean the binary is good. They may have very well reached the point of checking metadata and found an issue without testing the binary itself. Expect the Unexpected with Apple.
This is due to metadata information, no need to upload new binary. They will review it again and approve it (or reject for other reason). In my case, I was using location in background mode but in my Application description did not include the required "battery use" disclaimer, I changed the meta data (Application description only) according to apple message. It took only few hours (hardly 4 hours) and application was live. I was socked :) because some people was saying, It will take upto 7 days(as apple normal process).
Following was reason for app reject in my case(Below was the mail, I received from Apple)
From Apple
   * 2.16 - Multitasking Apps may only use background services for their
intended purposes: VoIP, audio playback, location, task completion,
local notifications, etc.
2.16 Details
Your app uses the Location Background mode but does not include the
required "battery use" disclaimer in your Application Description.
Next Steps
Please add the following disclaimer to your Application Description:
"Continued use of GPS running in the background can dramatically
decrease battery life."
Please see the app store screenshot for confirm.
In my experience, they reject the app as soon as they find a reason and they won't review it any further until next submission. So if the metadata is rejected it does not mean that they have approved the binary.

How to Minimize App Store Approval Time

What are some things and techniques I can do to minimize the time it takes for my apps/updates to be approved for the App Store? Do smaller updates generally take less time, and do paid applications take longer than free ones? What about the size of the binary?
In my experience, everything takes exactly the same amount of time. You sit in the queue for 6 days, then they review it for an hour or so (much less for updates), and you're either in, or rejected. If you are rejected, it will take a few more days to work through whatever the issue was.
So the only way to take less time, is don't be rejected. :) Seriously, though, go read the developer agreement and the "do this and we'll reject you" document.
They aren't even looking at your app for that 6 day "cooling off" period, so I can't imagine what you could do to make it go faster. (Although I've heard that there is a mechanism for expedited updates in emergencies; but I have no first-hand experience with that).
I cannot post a comment yet, so I am posting this as an answer to your question based on my experience submitting new apps, as well as updates to existing apps in iTunesConnect.
Unfortunately there really isn't anything you can do to speed up the process, aside from fixing the issues in your app if it gets rejected, and re-submitting asap.
Apple allows you to request an expedited app review.
https://developer.apple.com/contact/app-store/?topic=expedite
Please note: If you're facing extenuating circumstances, you can request the review of your app to be expedited by completing the form below. Expedited reviews are granted on a limited basis and we cannot guarantee that every request will be approved.
I have personally used it twice. Once for a cosmetic issue in an app, which was rejected. Another time for a critical bug fix, which was accepted. I wrote a very detailed explanation of what my application did, what the bug was, why the bug was important to our (Mine and Apple's) customer.
One thing I have found is that free apps versus paid apps sometimes take different amounts of time.
For example I have a paid and free version of the same app. I submitted an updated for both one right after the other. First I submitted the free version, then I submitted the paid version immediately after. For some reason the paid version went into review, and was approved a day later, where as the free version is still waiting for review even know I submitted it first. I suspect that free and paid apps have different 'queues' or 'priorities' over at apple.
You can request an expedited review in emergencies. I used it once and the update was available about one or two days later.
However, they say, the expedited review will only be granted in limited cases. So I wouldn't use it if not absolutely necessary.
You can request the expedited review in iTunes Connect. I think the option was on the detail page for an app which is 'Waiting for Review'. There was also a list, in which cases an expedited review can be granted.
App approval times will vary depending more on what else is going on, and can otherwise vary for no obviously predictable reason. I've seen a small update to a simple app take longer to approve than a new large app with lots of features.
Maximum app review times seem to be around the days that lots of other developers are submitting apps, near some major holidays, shopping seasons, or when Apple has just released some OS update, app service or new device. Shorter wait times can sometimes be had by avoiding these longer review time periods. There are services that track the number of new apps introduced per week. Look for the nulls.
Staying well away from any hint of violating any of Apple's App store rules or guidelines, or anything else that can be seen as controversial, also helps not getting hit by a long (additional time required) review time. Other factors seem to make less difference.
Take a look Apple review support
Once you've submitted your app for review, you can view its status in the My Apps section of iTunes Connect or on the iTunes Connect App for iPhone and iPad. Review times may vary by app. On average, 50% of apps are reviewed in 24 hours and over 90% are reviewed in 48 hours. If your submission is incomplete, review times may be further delayed or your app may be rejected. Once your app has been reviewed, its status will be updated and you will be notified.
I tried to use the expedited review for an app for a skistation, so it would be available before the winter season started and it was declined.
You need obviously a very good reason like a big security issue etc to get a expedited review.
Step 1:
Related to your project, note what is the third party libraries are involved and make a note what makes it rejected in apple store.
Step 2:
Make your code stable and keeping in mind about rejection points which you cant keep
(i mean like really stable no warnings, no chance with wrong icons, no chance with mistakes).
Step 3:
Finally, then decide to send for review
That will at-least speed up your process. once you get rejected then its a bad, you have to really wait longer. (from experience saying)

Reasons for rejecting iPhone application by Apple store [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
Can anybody help me out to know the possible reasons for which Apple store can reject or raise objection to submit any iPhone application.
Here are possible reasons (unofficial, from here):
Vibration. It is not permitted to use continuous vibration in your apps - short bursts as warnings is all that is allowed. Don’t bother trying to set up a timer to keep the vibration going, it will cause your app to be rejected.
Linking to private frameworks. This is obvious, but somehow in playing around with stuff we had linked to the MoviePlayer.framework. That’s a no-no, and cost us about ten days while we unlinked that framework, recompiled, and then resubmitted.
Improper handling of editing in tableview cells. Also obvious, but be aware that if you enable table cell editing, you’ll have to manually specify which cells should respond to editing controls and which should not. We had some random prefs cells in one of our early apps that were able to be swiped to bring up a ‘delete’ badge. Of course it didn’t do anything, but Apple justly considered this poor design and rejected our app.
Icons. Make sure the 57 pixel icon is identical to the 512 pixel version. Also, use a different icon if you are creating ‘lite’ and ‘pro’ versions of your app (i.e., free and paid). Using the same icon for both sends your app straight to … you guessed it … the bin.
Copying existing functionality. This one is much more subtle and insidious, and has probably affected the great percentage of developers. In addition to the widely publicized Podcaster debacle, reports from user comments indicate that Apple is casting a wide net when looking for duplicated functionality. Mini web browsers, or apps that essentially show web pages, seem particularly vulnerable, even if they add new and/or useful functionality. Stay away from email clients as well.
Using appropriate keyboard type. If your app asks for a phone number or other numeral-only input and you present a keyboard that also includes the possibility of entering standard alpha-numeric input … yep. (Thanks Jeremy1026)
Version numbers. If your app is currently at version 0.99 or below, you’d better consider giving it a promotion as Apple seems to prefer 1.0 and above. One of ours was recently rejected for being .016, with a message suggesting that our version number wasn’t even numeric. When we resubmitted the same app from scratch as version 1.0, it went through.
Network Reachability. If your app requires any type of network access you need to make sure it works when that access isn't available. If it doesn't it will be rejected. Apple provides sample code to test this which you can use as-is in most cases: https://developer.apple.com/library/content/samplecode/Reachability/Introduction/Intro.html
And last, but not least:
Flatulence Don’t even try. ;-) UPDATE: sorry, this seems to be outdated by now. Apple makes a lot of money now with "fart apps": see this article.
Edit:
Here is a link to a recent article about ten iPhone Apps That Didn't Make Apple's App Store.
And a tip: Apple has a Mac app called Application Loader that you could install. Once you install it, it analyzes your app's zip file. It verifies all the certificates, icons, and other things are correct before submitting to Apple. Using the Application Loader minimizes your chances of app rejection.
Another interesting resource: App Store Roundtable: Transparency and the Approval System (appleblog.com)
Yet another edit:
New rules by February 2010: "No Swimsuits, No Skin, And No Innuendo" (source: TechCrunch article, Wobble author's blog)
By the way: during the iPhone 3.0 preview event (march 2009), an Apple spokesman told that 96% of all submitted application were approved.

			
				
Apple have now (as of 9th September 2010) published their official list of app store review guidelines:
appstore approval guidelines
(apple developer login required)
or a mirror here:
app store guidelines
Will apple want to create an app like that in the future? If (yes) reject.
Do you have a really awesome idea that apple may want to use in the future if(yes) reject
Here's the video of the SDK announcement that describes Apple published list of rejection criteria:
SDK Announcement
As others have noted, Apple also seem to have a bunch of other conditions that they don't publicise. Note that rejection notices are now covered by the NDA.
I can't confirm this but it makes sense, but people are reporting their apps being rejected for being too simple or too trivial.
Just got a bounce for handling network outages badly. If you connect to the network, be prepared to handle any error conditions that may come up.
My paid version of app was rejected by appstore.
After Purchasing and downloading app first screen was "User Agreement" and when user taps on " I agree" only then he is able to continue using app.
Apple described the reason of rejection "when user purchased app from appstore and download in phone then you must not restrict user to Agree with Agreement" instead display your agreement before downloading app in iTunes.
Amazingly, apps can get rejected for trying to keep their interface consistent with Apple's own apps. (ie, using pinch zoom/expand gestures)
There is a site I know which can help you generate great advertising ideas with iPhone. see this site:
http://itunes.apple.com/app/adpack/id359562015?mt=8
I submitted a paid app to app store but get rejected and i learned another possibility of app rejection
My app was Game Center enabled. When app starts first screen was login screen that prompt user to login through GameCenter to continue.
They rejected the app giving reason- As user will not be able to get services of your app unless he is not logged in with Game Center although he paid you to download app. You cannot restrict user to login through Game Center each time before app starts.
From 1st May,2013 onwards if we don't support iPhone 5, your app will be rejected.So iPhone 5 support is must.

Resources