Guideline 4.2.3 - audio guide app rejection

Hi,

We are trying to submit an app that is an audio / video guide for a museum.


The app was rejected based on Guideline 4.2.3 - Design - Minimum Functionality:

Your app did not include sufficient content in the binary for the app to function at launch, and we were required to download or unpack additional resources before we could use it.

To resolve this issue, please revise your app to ensure that users can use the app on launch without needing to download or unpack additional resources.


The exhibition changes their pieces regularly and so we chose to put the main contents (audio, video, images and texts of those pieces) out of the binary in order to be downloaded by the user after installing the app.

In this way we want to guarantee that the user will always have access to the most updated contents. This is why the app has little content when it is installed. When the user install the app, he only has access to the content that will be permanent, such as the contacts of the museum, tickets, its description, credits, etc.

How do you suggest we make this content management that changes monthly, without having to constantly submit new versions of the app every month?


I can send you a TestFlight link to see the app.


Best regards

Rui Avelans Coelho

These two statements describe two different initial experiences:


App Review: Your app did not include sufficient content in the binary for the app to function at launch,


Your post: When the user install(s) the app, he only has access to the content that will be permanent, such as the contacts of the museum, tickets, its description, credits, etc.


If App Review is correct then change the app so that the user, upon launch, has access to the permanent content and, while viewing that content, have the app load the other stuff in the background.


If App Review is wrong, then appeal telling them that the app functions on launch and loads the other stuff while the user accesses the permanent content.

Hi PBK, thank you for your help.

We are giving the user access to the permanent content but the app was rejected again.

You can see some screenshots here:

https://www.dropbox.com/s/fbfs1x4rqvauaqs/apple%20dev.zip?dl=0


It is working this way:

1 - initial logo

2 - welcome

3 - ask user to download audio/video contents but in the upper left corner have access to the side menu

4 - side menu

5, 6 - examples of permanent content of the museum

7 - if the user have chosen to do the download it goes to this screen

8 - after downloading the contents the user can listen to the audio of each point

9 - or see the textual content


We though that this was enough to have the app accepted. But it was rejected.


Are you suggesting that we should do the download of the textual content (that is very fast because is only text) in the background as soon as the user opens the app for the first time? And only ask for permission to download only to have access to the audio/video contents?

Is it ok to do this background download of the text without asking permission to the user?


Best

rui

Look, App Review got to the page (3) in which you display "The app does not have content loaded" and they stopped and rejected you. Change that to "You can view the permanent exhibit and also ...... using the side menu. Would you like to download additional content to also access audio and video of the ........?"


>Are you suggesting that we should do the download of the textual content (that is very fast because is only text) in the background as soon as the user opens the app for the first time?


Yes.


> Is it ok to do this background download of the text without asking permission to the user?


Why not?


> And only ask for permission to download only to have access to the audio/video contents?


Why do you need to ask permission to download anything? Do you think Apple is telling you what they are downloading right now on your computer as you read this? Just do it in the background. Display a little activity indicator somewhere if you want. When the user goes to display something that is not yet downloaded tell them 'not yet downloaded - please wait".

> Is it ok to do this background download of the text without asking permission to the user?


Depends...


The app (vs. your content) is via the App Store, downloaded via cellular or wi-fi...is the content wi-fi only (noticed wi-fi in the screenshots, but that might just indicate a test mule)? Is it captured/gated wi-fi at the museum...is the content local when the user is at the museum or can anyone, anywhere take tours?


You stated it's an 'audio guide' app, but then you outline downloads that include 'audio, video, images and text'. I can see bits of text being fast, but speed might be a factor with multimedia content, and entirely different than quiet little text snippets in the background while the user is other distracted by....?


In any case, I think it's misleading to characterize the app as an 'audio guide' when it seems more like it is genuinely multimedia based. If you work instead to deal with the review guidelines that cover -all- of those assets, you may have better luck w/review when it's UI is changed accordingly.


Not to say you can't pre-package content for download, but that you may also be required to address basic networking issues in addition to providing an otherwise gelded app, which needs to stand on it's own as downloaded, rather than simply work as a A/V portal.

Guideline 4.2.3 - audio guide app rejection
 
 
Q