Rejected on Guideline 4.2.2 - Design - Minimum Functionality

Have you appealed stating:

"The app now provides a much better user experience to the user than simply hitting the website and much of our video content is unique to the app."

I have now! I will update here once I receive a response 🙂

As an update to everyone here, we discussed this app with Apple and the reason for the rejection is that it doesn't provide enough unique functionality to the users, differing the app from the website.

The arguments around each of our functionality:

Favourites: "Users can bookmark the videos on the website using Safari so this doesn't provide a unique enough experience for the user"

Sharing Videos: "Users can share the URL to videos via Safari..."

Unique Video Content available only to mobile users: "This isn't enough value to our users" (Even though I explained the demographic of our users and the social importance of our content to our users.

Not even the ability to download and store the video offline in order to view at a later date / time was enough functionality for this app.

I question how apps such as 9 NOW and ABC iView provide any additional value to users since all they seem to do is agregate the media from their websites.

thanks for sharing this, I think it's quit usefull. I don't know why thier replies arround this topic are vague and unclear.

Fuzzy rules will waste time for both developers and reviewers

Just looking at your preview images for your app, the following appears to be missing:

Information about each video segment (in the areas where videos are listed)

To be frank, the preview images for the app in question make it look like it has less useability than a YouTube channel. And that's pretty much the minimum bar that all of the video services meet--At least as useable as a YouTube channel.

Hi guys. Same problem (( Can u recommend me what i can do?

Guideline 4.2.2 - Design - Minimum Functionality

We noticed that your app only includes links, images, or content aggregated from the Internet with limited or no native iOS functionality. We understand that this content may be curated from the web specifically for your users, but since it does not sufficiently differ from a mobile web browsing experience, it is not appropriate for the App Store.

The next submission of this app may require a longer review time.

Next Steps

- Review the Minimum Functionality section of the App Store Review Guidelines.
- Ensure your app is compliant with all sections of the App Store Review Guidelines and the Terms & Conditions of the Apple Developer Program.
- Once your app is fully compliant, resubmit your app for review.

Submitting apps designed to mislead or harm customers or evade the review process may result in the termination of your Apple Developer Program account. Review the Terms & Conditionsof the Apple Developer Program to learn more about our policies regarding termination.

If you believe your app is compliant with the App Store Review Guidelines, you may submit an appeal. Alternatively, you may provide additional details about your app by replying directly to this message.

As I mentioned in a similar recent thread

https://forums.developer.apple.com/thread/87254

I think the key phrase is “native iOS functionality”, which experience benefits aside also has the benefit to Apple of tying your app more to iOS. I don‘t know how you implement your sharing but if you use UIActivityController to provide sharing to social media and other apps, then that would certainly be native iOS functionality.

hey devs,

are there any further news. I am in the same situation right now?

thanks

Hi Guys,

I just got our first app rejected under 4.2.2.

I share the same view as @bestnation: "I question how apps such as 9 NOW and ABC iView provide any additional value to users since all they seem to do is agregate the media from their websites."

My argument on similiar grounds to apple is:

"There are thousands of business out there who offer the same service and numerous of them have an iOS app, I wonder how can they all get approved if their apps offer the same service? The only thing that makes sense to me would be that it is accepted that the app is a need for their business rather than being "just another app on the app store".

The thing is business apps should be treated differently than standalone apps. At the end of the day, the functionality of a business app has to be dictated by the nature of the business rathar than native iOS functionality.

>...the functionality of a business app has to be dictated by the nature of the business rathar than native iOS functionality.

When native funtionality takes a back seat to any app category, the platform is doomed.

This is #4....please stop spamming the forum with the same comment, thanks,

I recently finally launched my app to the App Store. Before that, my app was consistently rejected for the same reason (Guideline 4.2.2 - Design - Minimum Functionality). In total, it took about a month from the first submission to the first approval. It was a very struggling experience. Below are the things I tried. I hope it could help people who are in a similar situation.

Context: My app is for reading tech news (e.g. TechCrunch) and Venture Capital blogs (e.g. YC, A16z). I also use ML to generate audio for articles so users can listen to them like a podcast.
More details: https://apps.apple.com/us/app/id1529509067

Here are the things I tried:

• Explain to reviewers that by nature a news aggregation app will mainly include links. Failed.

• Show thumbnails for articles. Failed. 

• Load parsed content directly instead of showing the source websites. Failed

• Add the "article bookmark" feature. Failed.

• Explain to reviewers that "article bookmark" uses persistent storage and it can't be done through a website. Failed.

• Add the "article commenting" feature. Failed.

• Update the app metadata (description, screenshots) to highlight the "audio" feature. Failed.

• Explain to reviewers that "audio" is a differentiator and the feature largely leverages native iOS functionalities. Approved!

Looking back, the original concept of "listen to articles" was probably already sufficient, but we just really need to help the reviewers get it.