App being rejected due to 4.2 Guideline

Hi all!!


I am new to this forum and I am not 100% sure if this is the right place to ask. But in the last days I have had quite some trouble with this guideline and my app being rejected from the app store.


Here is more or less what apple team is sending to me:


Guideline 4.2 - Design - Minimum Functionality


Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience. As such, the experience it provides is similar to the general experience of using Safari. Including iOS features such as push notifications, Core Location, and sharing do not provide a robust enough experience to be appropriate for the App Store.


Next Steps


To resolve this issue, please revise your app to provide a more robust user experience by including additional native iOS functionality.


We are not able to provide feedback on app concepts or features, but we recommend evaluating your suggestions against the App Store Review Guidelines, as well as the iOS Developer Program License Agreement (PLA), and the iOS Human Interface Guidelines.


Additionally, if you are considering implementing any of the following functionality, we recommend reviewing all associated reference material and other resources available on Apple Developer for any additional requirements.


And I have seen a similar response in other posts (in fact it is pretty much the same text, so I feel that I can't really get good feedback from the review team as this seems pretty much like a templated answer), but the main issue here is that I actually use native iOS functionality.


I mean navigation and date pickers are pretty much as native iOS as it can get so I am struggling in finding what else I can do to workaround this issue. I also use push notifications to remind users when they need to permform some actions that they might have forgotten to do. Do you guys have experience running across this issue?


One thing I can mention though is the app itself doesn't have a bunch of screens and it is mainly intended as a finance tracking app which I use in conjuntion with a backend server which sends the data over through a secured API. In the app users can upload their balance amount at the end of the month by selecting the closure date and can later review them through a history screen if they need to change something else. Is this a factor when evaluating the app?? Because actually that is basically all my target users will need from the app so I would say it willl prove quite challenging to add new functionality when it might not be used alltogether in the end.


Thanks in advance! Any help is appreciated!!

Replies

The rule of thumb is that, if the app can run on a browser as web pages, it does not meet minimum functionality.


Just using a date picker is not enough.


Typically, you could do some processing of data (including historical data) on the device, to enrich user experience.

> Typically, you could do some processing of data (including historical data) on the device, to enrich user experience.


Indeed, I thought of that myself. But I am not sure if the users of the app will like that, since data analysis was not part of the initial design. Still, I will consult if they are open to adding new functionality. Although I actually have some history, I don't do any kind of analysis processing there. I only display it and give users the ability to change them if they deem that appropiate.


Other than that, do you think improving buttons or data lists to be more according to apple's styles could improve its design? Is there any doc I can read on that? I wasn't able much information regarding that in the Apple Human Interface Guidelines


> Do yourself a favor, put that naive assertion aside, realize that 4.2 means you don't have an app, and go back to work. Start here:iOS Human Interface Guidelines.


Thanks for the suggestion! I think the app actually covers many topics discussed there. In the app's forms I have validators in place and I also don't allow people to submit anything if the data is invalid (I indicate with a red label on the field when an input is incorrect) and send buttons are seen as visually locked and they are also not pressable. I also make sure the inputs display only the correct type of input (if numeric, display numeric keyboard, if text, then text keyboard, and so on). Also, responsiveness seems to be working as the app adapts to multiple sizes (portrait and landscape also displaying correctly). Do you think I might be missing something there or doing something wrong?. Also, if I were to colour my buttons. the colors of should be tight to a standard?


Thanks in advance for your help!! And sorry if my comments are somewhat n00b like 🙂 I happen to know very little yet about the whole apple world (more of a backend guy myself) but I am doing my best effort!!

Claude31: I have a number of apps on my iPhone from the App Store that technically can "run on a browser as web pages". Here is a list of some of them:


The New York Times App

Facebook

Amazon

LinkedIn

Twitter

Google (let's face it, a browser doesn't do anything more than Safari does)

Imdb

Wikipedia

Hotwire

Travelocity

eBay

Evernote


I also have several games that started as web-based games and are now alive and well on the iPhone, which clearly should violate this rule because they originally were run on a browser as web pages.


About the only types of apps that can qualify are:


Apps that use Bluetooth for communication (e.g., hotel apps that allow digital keys)

Apps that use AR

Apps that use the accelerometer

Apps that use hardware that mobile browsers aren't allowed to use


The only thing worse than this is: All mobile browsers are awful for browsing web pages. This is the primary reason NYT, Amazon, et. al. provide their own mobile apps specifically designed to source content from their backend services into an app targeted to display the content.


At the very least, this guideline is not being uniformly applied.

The apps you cite are BIG players in the App Store with many tens of thousands (millions?) of users. They do seem to get preferential treatment compared to indy developers.

I don't think the standard is "if the app can run on a browser as web pages". I think the standard is "include features, content, and UI that elevate it beyond a repackaged website". The NYT app - as you correctly pointed out - is suitable as an app as are many of the other apps you listed. They present content on a mobile device that, while it could be presented on a website, when presented on a mobile device, is better viewed through the app then through a web browser on the mobile device. And there is some compelling reason for viewing it on a mobile device.

PBK: Except, the rejection notice specifically states (and I'm directly quoting):


"Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience. As such, the experience it provides is similar to the general experince of using Safari." (emphasis added)


I don't know of any other way to describe "mobile browsing experience" apart from what you quoted from me: "run on a browser as web pages." If you have a better description, I'd love to hear it.


Perhaps I'm mistaken, and the iPhone version of Safari cannot perform a "mobile browsing experience" that is as good as a native mobile app? In other words, perhaps mobile Safari isn't capable of delivering as great an experience viewing web pages as desktop Safari, and so Apple's guideline is really protecting against apps that don't deliver anything more than what the limitations of mobile Safari can? In that case, the guideline should really read:


"Your app provides nothing better than the limited experience of Apple's Mobile Safari app."


The guideline is vague, is applied to some apps and not to others, and Apple offers no assistance or examples. Some of Apple's own apps can't pass this guideline - for instance, the App Store Connect app itself.

Sounds like you're saying you deserve a slot in the store simply because "I'm no worse that anybody else...".


Don't forget to add that particular celebration of mediocrity to your resume, or, better yet, use it in your next appeal to review.

Try this experiment. Download the NYT app and use it to read articles on a mobile device. Then open Safari on the same mobile device and go to the NYT using Safari. Read the same article. The difference between those two experiences justifies the app and would pass the 4.2 guideline. Apple is saying your app does not provide such a difference.

I did just that and couldn't find any significant difference. The NYT article in Safari shows social sharing buttons in-line in the article (to the right of the title) whereas the one shown in the app shows it as tucked inside the single share button in the title / navigation area.


Here is a screenshot of the two side-by-side compared on iPadOS 13. Left is Safari, right is NYT app.


https://imgur.com/a/J0X7LA5