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/
Related
Does anyone know if exit(0) is deprecated in iOS application? I know it is not a good decision to manually terminate the app, but does Apple ban the application if we use it in the code?
I got an app which was rejected because of a way of exit (via UIAlertView), doing an exit(5) when user click on the correct button.
I received that:
We found that your app includes a UI control for quitting the app.
This is not in compliance with the iOS Human Interface Guidelines, as
required by the App Store Review Guidelines.
Please refer to the attached screenshot/s for reference.
The iOS Human Interface Guidelines specify,
"Always Be Prepared to Stop iOS applications stop when people press
the Home button to open a different application or use a device
feature, such as the phone. In particular, people don’t tap an
application close button or select Quit from a menu. To provide a good
stopping experience, an iOS application should:
Save user data as soon as possible and as often as reasonable because an exit or terminate notification can arrive at any time.
Save the current state when stopping, at the finest level of detail possible so that people don’t lose their context when they start the
application again. For example, if your app displays scrolling data,
save the current scroll position."
It would be appropriate to remove any mechanisms for quitting your
app.
A "hidden" exit could be understood as a crash for the user, no?
No, Apple will not reject your app for using exit(0).
You are correct, it is not a great design choice, but it can be useful sometimes.
As Larme mentioned, if used incorrectly, it can be perceived as a crash and a crash will result in your app being rejected.
However, it can be very useful in applicationDidEnterBackground when (on a conditional basis ) you might want to force the app to start a fresh.
No, you must not call exit as your app SHOULD be rejected. This has been repeatedly discouraged by Apple and is known to cause serious bugs with iOS multitask switching. You should simply leave the user to use the home button themselves.
http://developer.apple.com/library/ios/#qa/qa1561/_index.html
"Additionally, data may not be saved, because -applicationWillTerminate: and similar UIApplicationDelegate methods will not be invoked if you call exit. If DURING DEVELOPMENT or TESTING it is necessary to terminate your application, the abort function, or assert macro is recommended."
2012-04-09
Updated to more strongly discourage the exit function, and include best practices for debugging.
2008-08-27
New document that discusses best practices for terminating an iOS application in code.
Straight from the iOS Human Interface Guidelines
http://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/MobileHIG/UEBestPractices/UEBestPractices.html#//apple_ref/doc/uid/TP40006556-CH20-SW27
"Don’t Quit Programmatically
Never quit an iOS app programmatically because people tend to interpret this as a crash. However, if external circumstances prevent your app from functioning as intended, you need to tell your users about the situation and explain what they can do about it. Depending on how severe the app malfunction is, you have two choices.
Display an attractive screen that describes the problem and suggests a correction. A screen provides feedback that reassures users that there’s nothing wrong with your app. It puts users in control, letting them decide whether they want to take corrective action and continue using your app or press the Home button and open a different app
If only some of your app's features are unavailable, display either a screen or an alert when people use the feature. Display the alert only when people try to access the feature that isn’t functioning.
If Necessary, Display a License Agreement or Disclaimer
If you provide an end-user license agreement (or EULA) with your iOS app, the App Store displays it so that people can read it before they get your app.
If possible, avoid requiring users to indicate their agreement to your EULA when they first start your app. Without an agreement displayed, users can enjoy your app without delay. However, even though this is the preferred user experience, it might not be feasible in all cases. If you must display a license agreement within your app, do so in a way that harmonizes with your user interface and causes the least inconvenience to users.
If possible, provide a disclaimer within your app description or EULA. Users can then view the disclaimer in the App Store, and you can balance business requirements with user experience needs."
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).
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.
What is the proper way of ending an application on the iPhone when you are finished with it?
thanks,
anton
Jaanus is referring to this paragraph in the Apple iPhone Human Interface Guidelines
Stopping
People quit an iPhone application by opening a different application. In particular, note that people don’t tap an application close button or choose Quit from a menu. In iOS 4.0 and later, and on certain devices, the quitting application moves to a suspended state in the background. All iPhone applications should:
Be prepared to quit at any time. Therefore, save user data as soon as possible and as often as reasonable.
Save the current state when stopping, at the finest level of detail possible. For example, if your application displays scrolling data, save the current scroll position.
iPhone applications should never quit programmatically because doing so looks like a crash to the user. There may be times, however, when external circumstances prevent your application from functioning as intended. The best way to handle this is to display an attractive screen that describes the problem and suggests how users can correct it. This helps users in two ways:
It provides feedback that reassures users that there’s nothing wrong with your application
It puts users in control, letting them decide whether they want to take corrective action and continue using your application or press the Home button and open a different application
If certain circumstances prevent only some of your application's features from working, you can display either a screen or an alert when users activate the feature. Although an alert doesn't allow much flexibility in design, it can be a good choice if you can:
Describe the situation very succinctly
Supply a button that performs a corrective action
Display the alert only when users try to access the feature that isn’t functioning
As with all alerts, the less users see them, the more effective they are. For more information about creating alerts, see “Using Alerts.”
There is no way for an iPhone application to quit/terminate itself. Apple actively advises against it in their Human Interface and/or programming guides (can't remember which exactly) because it would look like a crash to the user.
An app should not terminate by itself.
Also, avoid showing an "exit screen" that prompts the user to quit the app manually as in iOS4, the app might stay open in the background and your user would be stuck in that exit state.
is it possible and how to implement forbiden exit from application on iphone/ipad?
we have an application that must permanently work on ipad device. user should not have any way to exit from application. could you advise how to implement this functionality?
By jailbreaking it and installing custom software that enables you to do that.
Or putting a lot of tape over all the buttons.
Anyways, you can't do this with a standard app on a standard device. Just think about it - would be a pretty annoying thing for apps to do, wouldn't it?
Apple's own human interface design guidelines would forbid this. Your app can't encroach on the abilities of the OS that transcend your own application's responsibilities. The whole point is to have a consistent experience for the device and if you're modifying something as fundamental as switching apps, you're violating that principle.
If you can't exit the app, you're essentially turning your device into a single purpose unit. How do you expect to get back to the app list if you disable fast app switching and the home button?
Whatever solution you find would not be approved by the app store.
You should look at whether the current multitasking features can help chip away at your reasoning for needing the app to always run in the foreground.
If you are talking about an enterprise app locally distributed, you might be able to do this, though probably not.
The best idea would be to physically break or block the hardware button.
Or issue alerts to the device every 10 seconds making the thing effectively unusable when outside the application (you can ignore incoming notifications for you in-app).
Why do you have this requirement?
There is no way to implement this functionality. You cannot do it.
You can't do it, But if you jailbreak and configure the "Home-Button" settings you can :)
Btw, If you do it, the only way to quit will be a shutdown... And to shut down every time would be kinda annoying...