We found that your app uses a background mode but does not include
functionality that requires that mode to run persistently. This
behavior is not in compliance with the App Store Review Guidelines.
We noticed your app declares support for audio in the
UIBackgroundModes key in your Info.plist, but no audible content is
played when the application is in the background. While your intention
may have been to provide this functionality, at the time of review, we
were not able to play background audio for your app.
As indicated in the iOS Application Programming Guide:
"This key is intended for use by applications that provide audible
content to the user while in the background, such as music-player or
streaming-audio applications."
Therefore, it would be appropriate to provide audible content to the
user while the app is in the background or remove the "audio" setting
from the UIBackgroundModes key.
For discrete code-level questions, you may wish to consult with Apple
Developer Technical Support. Please be sure to:
include the complete details of your rejection issues
prepare any symbolicated crash logs, screenshots, and steps to reproduce the issues for when the DTS engineer follows up.
For information on how to symbolicate and read a crash log, please see
Tech Note TN2151 Understanding and Analyzing iPhone OS Application
Crash Reports.
If you have difficulty reproducing this issue, please try testing the
workflow as described in "Testing Workflow with Xcode's Archive feature".
So here are my problems/questions:
in the resolution center it told them that they have to start a video
first or else there obviously won't be audio playback in background
mode and also send them a screenshot that it actually works
are they actually to answer me? I've wrote the above about one hour
ago and still got no answer
will i have to resubmit the App and wait another 7 days or can they
still approve the App?
I had the exact same problem and rejection reason.
What I did was file an appeal, citing Technical Q&A 1668, "Playing media while in the background using AV Foundation" (Usually here, but not at the moment), where it explicitly says that the UIBackgroundModes audio key may be used to play video in the background, either over AirPlay, or on a local device by detaching the AVPlayerLayer from the AVPlayer.
About a week later, my appeal was approved and the app was submitted to the store. Not that I ever received an explicit answer from Apple about this. But, the approval was the important part, I guess.
// edit: I filed a radar with Apple asking for an explicit video backgrounding mode a few weeks back. Its on OpenRadar now, if you want to dupe it.
You will not have to resubmit the app, they will respond to you.
https://developer.apple.com/appstore/contact/appreviewboard/index.html
This link will get you to the form for the appeal process, though I assume you have already done this based on info in your post. If you feel like you need an expedited review there is a link for that as well. You just have to make your case, try to be very careful to address every point they make about why your app doesn't meet the guidelines.
I had the same problem and where I was using the UIBackgroundModes key to play videos in background via Airplay. while Technical Q&A 1668, it is clearly mentioned like this
Important: The UIBackgroundModes audio key will also allow apps to stream media content in the background using AirPlay (see also Special Considerations for Video Media).
Related
I haven't been doing this long, but this is the first time that I've had an app rejected. This is what was in my rejection.
PLA 3.3.1
Your app uses public APIs in an unapproved manner, which does not comply with section 3.3.1 of the Apple Developer Program License Agreement.
Specifically, your app contains a mechanism to keep a device awake. Please see attached screenshot(s) for reference.
Since there is no accurate way of predicting how an API may be modified and what effects those modifications may have, Apple does not permit unapproved uses of public APIs in App Store apps.
The screenshot that they included showed my setup screen where I give users the option to have the application keep the device awake. I tested it, and it only keeps the device awake when in the application. I did not come up with this idea all by myself. I've seen it as an option in other apps.
I am not using anything non-apple to do this. This is my code for keeping the device awake.
UIApplication.sharedApplication().idleTimerDisabled = keepDeviceAwake
where keepDeviceAwake is a Bool that is turned on or off by a user setting.
Is there something wrong with the way that I'm using this or what I'm doing with it?
To give more of an idea, this app is a counter app. I was thinking that it would be really annoying to have to keep turning on the iDevice when counting things, so I give the option to keep the device on while in the app.
The documentation note on idleTimerDisabled says:
You should set this property only if necessary and should be sure to reset it to NO when the need no longer exists. Most apps should let the system turn off the screen when the idle timer elapses. This includes audio apps. With appropriate use of Audio Session Services, playback and recording proceed uninterrupted when the screen turns off. The only apps that should disable the idle timer are mapping apps, games, or programs where the app needs to continue displaying content when user interaction is minimal
Apple probably feels that your app doesn't fall within the guidelines.
I have written an app which uses midi for playing audio. The app uses MIDIDestinationCreate and enables UIBackgroundmodes as suggested by Apple in the iOS6 release notes.
The App review team have rejected the app because they say that it does not play any sound when put into background mode. They suggested that I change the plist accordingly and uncheck audio/background mode. This of course causes the app to crash when playing the midi and is also mentioned in the question here as well as the iOS6 release notes:
CoreMIDI/PGMidi Virtual midi error in iOS6
Ideally, I don't want it to play music when in the background. When the user puts the app in the background, they've finished.
I replied to the app review team referring them to the iOS6 release notes for MIDIDestinationCreate. This made no difference - they just maintain that audio needs to play while that user has dismissed the app - perhaps like iTunes I guess.
They suggested submitting a DST for an alternative solution- which I have done but there's no reply.
Are there other solutions for playing midi or perhaps ways of appeasing the app review team?
The developer support team replied and there was no issue with the method of implementation.
It seems like the reviewer made a mistake. I lodged an appeal and the App was approved.
My alarm clock app was received an rejection from app review process:
2.16: Multitasking apps may only use background services for their intended purposes: VoIP, audio playback, location, task completion,
local notifications, etc.
2.16
We found that your app uses a background mode but does not include
functionality that requires that mode to run persistently. This
behavior is not in compliance with the App Store Review Guidelines.
We noticed your app declares support for audio in the
UIBackgroundModes key in your Info.plist, but did not include features
that require persistent audio.
As indicated in the iOS Application Programming Guide:
"This key is intended for use by applications that provide audible
content to the user while in the background, such as music-player or
streaming-audio applications."
Therefore, it would be appropriate to provide audible content to the
user while the app is in the background or remove the "audio" setting
from the UIBackgroundModes key.
For discrete code-level questions, you may wish to consult with Apple
Developer Technical Support. Please be sure to:
include the complete details of your rejection issues
prepare any symbolicated crash logs, screenshots, and steps to reproduce the issues for when the DTS engineer follows up.
For information on how to symbolicate and read a crash log, please see
Tech Note TN2151 Understanding and Analyzing iPhone OS Application
Crash Reports.
If you have difficulty reproducing this issue, please try testing the
workflow as described in
with Xcode's Archive feature".
I have sent an mail to notice I need background mode to play alarm when it is alerting and user press "home" button that makes app into background. And then I got an reply:
Hello,
Thank you for contacting us to provide additional information about
your app Kill Ants (alarm clock). I have added this information to
your app record.
In the future, you can add this information directly to your app
record by including this information in the Review Notes of your app
or by replying in the Resolution Center when your app is in the
Rejected state. When you provide information in either of these ways,
it is not necessary to also provide the information by email or
through the Contact Us form.
You can find more information about "Editing and Updating App
Information" in the iTunes Connect Developer Guide here:
When the Resolution Center or Review Notes are no longer in the
editable states referenced in the Guide, you can continue
communications through iTunes Connect Contact Us using the steps
below:
Go to
Select 'App Review'
Select 'Continuing Communications', then add your information or questions.
I hope this information is helpful.
Best Regards,
App Review Team
How do I handle this problem? I app actually needs the backgroundMode to play alarm music in background. Anyone has the same problem? How do you solve it?
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.
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.