Someone wants me to make an App, where the NavigationButton (usually top left) shall be put into the Tabbar (in this case leftmost Button of the Tabbar). I wonder if that might yield a possible rejection.
It reads in the Appstore Review Guidelines:
a) Apps that alter the functions of standard switches, such as the Volume Up/Down and Ring/Silent switches, will be rejected
-> Could that also include NavButtons?
Furthermore:
b) Apps that do not use system provided items, such as buttons and icons, correctly and as described in the Apple iPhone Human Interface Guidelines and the Apple iPad Human Interface Guidelines may be rejected
I do not know whether we crossed the line there.
What's your opinion on this?
I'd say it's a bit of a crap shoot and you need to weigh whether the feature is important enough to possibly delay your release by 2 weeks or more. If you submit it with the feature I would spend some time working on a different solution so that if it is rejected you can submit with the changes right away.
From personal experience, I had an app rejected because they didn't like the image I used on a button since that image was meant to convey "picking a contact for use in the app" not picking a contact to add information too. It was my opinion that this was a petty almost silly thing, but I corrected it and resubmitted. Both reviews took over 2 weeks. So it took me over 4 weeks to get approved.
Apple has gotten better about telling you what won't be accepted, etc. But different reviewers seem to have different opinions. I'd say the description of your feature is likely to be rejected, but you'll never know until you submit it.
Instapaper has a back button in a tab bar at the bottom. I think that if you decide to do this, you shouldn't use the system back button but create your own. Using the system button feels like a HIG violation.
Related
I'm currently designing an app for the iPhone and I'm deciding on some features that imitate several native iPhone UI components and elements.
In my app, the user has to arrange several items on screen. Basically, they are free floating (not in a grid). In order to be able to move them, the user has to hold a finger on one of the items until all items start to "wobble". Just like on Springboard, when moving applications. Is it allowed to imitate this functionality?
Another function is the "split screen", as seen when adding an application to another application. The screen breaks open, showing a new group with the familiar textured background. In my app, some screens require a user decision by picking one out of four icons. I want to present this by using such a modal view over the main view, more or less like the "add to group" function of Springboard. Is this allowed?
I'm well aware that there are several programming questions related to my issue, but none of them covers whether apps are allowed if they include the functionality. Any help is greatly appreciated!
(On a side note, I read on HN today that Apple doesn't really answer questions to Support about app approval, therefore I ask here.)
I think the biggest problem you might have is the "free floating" functionality. There's a very big gray area as to what's accepted and, from my experience, you can't have an app with with seemingly floating windows like a desktop.
I can't see Apple having a problem with the Springboard functionality because the Facebook app has it. I would just try to make your own version and not try to reproduce the code.
Also, the Split Screen animation should be fine.
My 2 cents.
There is nothing in the guidelines about such functions not being allowed. I have submitted to apple an app recently with a wobble function like you mention and the reviewer did not mention anything about this being not allowed (The app was rejected for another reason which has to do with content licensing).
I have a question for the iPhone Development community. I am currently building my first app, and on two of my views I have some buttons. Sales and Marketing have requested that these buttons do nothing and have the title of “Feature Available in Pro Version” or have a title of an application but when touched, an UIAlertView is displayed stating “Feature Available in Pro Version”.
First off, I think this is wrong from a user interface and experience. Secondly and more importantly, I think this will cause a denial when I finish the application and send the app in to the App Store for approval. I have look into the iOS Human Interface Guidelines and really can not find whether this will be an issue or not. I would like to tell Sale and Marketing that their request is stupid and will not get the application approved and they need to stick to their jobs and quit trying to play programmer.
Any comments would be greatly appreciate.
Quoting http://developer.apple.com/news/ios/appstoretips/
Only display the UI for what your "Lite" version will do. Grayed out menu commands, "more track/car choices" you can see but not select, etc. makes your "Lite" version feel more like a commercial than a product, and an annoying and ineffective one at that.
...
It's important to follow these simple rules not only to create a better user experience, but also because your app will be returned to you by the App Review Team for modification if it is found to have time limits, incomplete functionality, or disabled functionality.
Come up with some better options for your clients. They are not trying to "play programmer", they are trying to market their product. Also, try to mitigate the risk of the app being rejected by getting it in a submittable state as soon as possible, or at least make sure that you have a plan B for the things that you suspect might fail to get approved.
It sounds like you're just looking for a stick to beat your sales and marketing team with - there are quite a few apps out there in the wild that exhibit precisely this behaviour, painful though this might be to you. (The buttons do something after all - they show a dialog.)
That said, it's hard to recommend a more pleasant alternative without knowing more about your app. (Does it have the concept of "levels" for example? If so, you could replace the buttons with a nicer "purchase the full app to unlock additional levels" style message.)
I am pretty sure this never used to be allowed. If you show user interface elements they have to be fully functional. I don't know in which document or agreement this is stated, though.
It also may not cause your app to be rejected, at least not initially. The app may be removed from the store at a later date, though.
Apple has been known to quickly reject apps for non-functional or grayed-out buttons, especially if these non-functional UI elements are just to advertise Full or Pro versions in Lite apps.
Apple has also been known to approve apps with a non-functional button or two (happened to one of my apps, got a bug report several weeks after the app had become available in the App store), but this is probably due to oversight, and not a policy that anyone should count on.
If you want an advertisement for your Pro version, make it look and act like a standard in-app advertisement, and not a misleading UI element. Serving house ads, or mostly (99%) house ads is a widely done practice.
I know the iphone home button is extremely crucial for the functioning of the iphone.
However I have an idea for which I need the application running and the home button to be disabled. I tried googling, but haven't been able to find a solution.
Temporary or timed locking (Lock for 5/10 mins.) would also do.
The app. should work on non-jailbroken phones, hence going around apple won't work.
Appreciate any ideas.
Note, from 2014 onwards: just to be clear,
this is now built in to iOS...
Click to accessibility, click "guided access".
Conrats for "inventing" it, PlanetUnknonw! :-)
The answer below is only of historic value...
For the record, it's silly that people are saying "Why would you want to do this?"
it's a great idea for example for APPS FOR SMALL CHILDREN (which is indeed a very large market on the iPhone).
If you've ever marketed an app for small children, you'll know that instantly parents write in abusing you because you "did not stop that stupid home button working, so the child just turns off the game and makes phone calls"
To which you have to reply that it's of course not possible because of the way the iPhone works.
So yes it's a good question. As far as I know, Planet, it is not possible.
Apple should add a "kids mode" where parents can lock the fone on TO one particular app for awhile. (Perhaps you would have to long-press or something the home button to unlock it.)
UPDATE
*iOS 6 reportedly has a "Single App Mode" - Check out vpdn's answer below https://stackoverflow.com/a/10503799/333259
This is against the iOS interface guidelines, and apps have been rejected for "overriding" or restricting behaviour of hardware buttons/switches.
I suggest you have a read of the App Store Review Guideline for iOS apps for a good overview of what you shouldn't be doing.
Particularly:
10.5
Apps that alter the functions of standard switches, such as the Volume Up/Down and Ring/Silent switches, will be rejected
Pretty sure that the Home button is included in that.
I'm not sure what your "idea" is here, but I would suggest you look into other things such as backgrounding. There is a feature that allows you to finish executing tasks in the background, even if the user presses the home button, and optionally display a notification after certain time (before the task "expires"). I imagine that this might offer a more appropriate solution (again dependent on what your idea actually is).
In iOS6 (to be released), there's a feature called "Guided Access", which will allow device owners to lock users (like toddlers and school kids) into an app.
Update: Before the shitstorm about NDA content starts, here's where I got the info from: http://www.theverge.com/2012/6/11/3078350/apple-ios-6-guided-access-parental-control
You can't unless you want to run it on jail broken devices.
Apple currently will not allow any software to disable or change ANY button functionality for iPhone, iPad, and iPod touch, so the only software solution is to jailbreak the device, so you're not forced to live by Apple's rules.
However, PaperclipRobot.com is about to release a home button cover specifically targeted to keeping young kids from pressing the home button. Not the exact solution to your problem as stated, but I figured it added to the discussion.
Unsure if you are looking for a way to do it in code in an app or if you're thinking of locking it in general.
Anyways, if you're looking for a way to do it in general, here's a guide for it
http://igrudge.net/how-to-disable-the-home-button-on-ios-devices-iphoneipad/
If you are looking to temporarily disable the home button to keep a child in a particular app, the tip for a make magazine article is to use a bulldog clip to cover the home button cheaper, and more reusable than a bubcap, temporary and effective.
Source: http://blog.makezine.com/2011/03/01/ipad-home-button-child-lock/
I just added a done button on my number keyboard and read that using the keyboard class directly is illegal but some people said that their app was successfully submitted to the app store? Does anyone know if it is legal or not?I have been googling around for 1hr and I keep getting yes and nos.. anyone knows for certain if this will cause the app to get rejected?
Thanks
It is not absolutely sure that doing something like adding a DONE button to a numeric keyboard is legal or not. It all depends on Apple, some app is rejected but many apps is already approved by Apple. It is hard to say.
It also depends on your technique as well. Usually, I see that people will work into the UIKeboard view hierarchy to add the DONE button and for this case, the usual approval problems is like I described above, some fail, some succeed
Suppose one wants to port a desktop app to a smartphone (which can mean write from scratch).
How in your opinion should a mobile version relate to to the desktop one? In other words, what are the common features of mobile apps?
I can say:
short user interface (not time consuming)
dense content, filtered in comparison with the desktop relative
personal: no mult-user requied (smartphone is a personal device)
What else?
Apple has some guidance in the Human Interface Guidelines
Some things I would think about are:
How do you want to present your data efficiently, yet elegantly?
Which controls and view types will you use? Meaning, does this part of the program do best with a UITableView or a UIScrollView or should there be a drill-down Navigation to flow better? Essentially, I'm just saying, determine the flow-down structure of your application. You need to become familiar with each and every control so you know where a typical user expects them to be.
Users on an iDevice (except for iPads) are used to a one-window environment. Therefore, don't try and pack every little detail into the screen. Break it up logically and intuitively.
Strike a balance between functionality and useability. Don't just throw an app out there that works great but looks like garbage. People like eye candy (men especially).
Like you said, multi-user is only realistic on the iPad and even then it's a stretch for anything other than games.
Think about what the user expects and is used to based on other apps and try to continue that trend. For instance, if you are showing the keyboard and there is no obvious way to dismiss the keyboard, make it so that when they tap on some area of the view outside of the keyboard, the keyboard gets dismissed. Otherwise, the user is just stuck there with this stupid keyboard on the screen and no logical way to get rid of it (sorry, I really hate when developers do this one).
Lastly, use the app yourself for at least a week prior to releasing it. If you aren't 100% behind it, change it. Some people are all about "failing first and fixing later" but I disagree. The most important day is the first day of launch. After that, it's either word of mouth, cross-promotion, or your advertising money. Make it a success on the first day.. and also realize that more people use the AppStore on Wednesday/Friday/Saturday/Sunday than any other days of the week.