Wobble functionality etc. allowed in iPhone App Store? - iphone

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).

Related

Embeding multiple apps in an app?

I am a newcomer to application development and I'm wondering if the concept I have can actually be created.
My concept involves creating an app that has the ability to embed another app within itself.
I'll do an example which is also a very bad one but you'll at least get the point.
Picture an app on the iphone that's called "Kwesi's app". Once you tap on it, it opens up a page with 3 icons. A facebook icon, a gmail icon and a hotmail icon. Now tap your finger on the gmail icon and instantly your gmail opens up withing "Kwesi's app" and you have full access. There is also a button in the top left corner that says "Main Menu". Once you tap the "Main Menu" icon, you go back to the three icons and can now rinse and repeat.
I hope this example is clear enough.
The question I seem to be coming back to is, would it be possible having an application that embeds or links you to other apps in that manner? I can only guess that it'd be really weird since they'd have to be installed seperately on your phone but I don't want that. I want one app that can handle an already set amount of apps within itself as the above example shows.
Thank you very much for reading and any thought would be very much appreciated.
/Kwesi
No, that is not possible in iOS for security reasons. But you have the following choices to modify your idea:
Register a protocol for the app : This will allow you to send data between applications using protocols. However, if the app wasn't made by you and doesn't have a protocol, then you can't use it.
Using this idea, it is possible to open an application. For example, opening Facebook with "fb://" or evernote with "evernote://". I am sure there are other applications that have these protocols. Just be aware that you don't have control on the application in this case. You can only open it and send data to it.
Since your example was about Facebook, Gmail. Then I would suggest using their corresponding API and build everything in your application. Many famous applications provide APIs for a fee or free usage. You have to check with each one separately.

Simulate actual button press on mobile-safari on iPod Touch / iPhone

I am building a web-based tool for internal purposes for my company that runs on an ipod touch. It's working fine, but there are a few quirks such as not being able to auto-focus on a text field when a page loads without the user actually tapping the screen (I can "focus" the field, but the keyboard is not active). Additionally, I cannot programmatically trigger sounds to play (I am using the jPlayer library). What it seems to come down to is this:
Is there some way I can trick the browser on an ipod touch 4 to thinking the user has actually tapped a specific div on the screen? If I can do that, I can solve every other issue. Since this is for internal purposes, I am free to make any modifications needed. However, I need to able to do keep the "app" code in HTML5 and JavaScript for a myriad of reasons. Perhaps an app with a modification to safari to allow this, then I can run my site in that app?
Perhaps an app with a modification to safari to allow this, then I can run my site in that app?
Yes, you could write a really simple app with just a UIWebView in which you display your HTML5 based app. If you need extra things such as back button etc. you would have to implement that (it's also not very difficult). The UIWebView should behave mostly exactly like Safari, so it should be a de facto "app with a modification to safari".
You could then give the right element focus and call
[webView becomeFirstResponder];
The sounds could also be played programmatically by simply requesting the appropriate URL.
I think with this setup the additional effort in terms of coding beyond your existing web based tool is minimal. However, this assumes you have Xcode, know some basic Objective-C and are familiar with the procedures of ad hoc or company distribution of "real" apps.
You can try to use a timed event

UINavigationButton in Tabbar - possible rejection?

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.

Temporarily Lock or Disable iphone home button

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/

mobile application features

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.