I'm wondering if there's any risk to see the app rejected from the AppStore (iPhone app) if I modify the existing UITabBar making it slightly taller. I'm working on a custom uitabbar with custom background pattern that is also just a little bit taller (8px) than the default one. It additionally has a raised central button.
I really don't see why this could reject the app but I thought I would better ask first since it's quite a lot of work implementing this custom design and I might have overlooked some of the HIG guidelines/rules.
Many thanks,
Tomas
There are tons of apps in the AppStore with custom tab bars, starting with some of the most popular ones like Instagram so you should be safe.
There are huge numbers of apps out there with custom tab bars, including non-standard sized ones and ones with protruding central buttons. They're fine, as long as they work correctly.
Related
New to iOS developing here. Basically I am creating a soundboard app. I have the app essentially working (aka buttons returning sounds).
However my app only looks proper on the iPhone 6. I just have one ViewController in my main storyboard. When I run the simulator for the 4S/5/6+ or iPads, my buttons are pretty much everywhere.
I tried playing with size classes/autolayout through Apple's documentation, but couldn't get it working properly. What's the best (easiest ;) ) route I can follow to have it basically looking the same on ALL devices?
PS: I have one background placed too, I don't mind if it looks different on all devices since it's pretty minimalistic, but if someone can shed some light here too, that would be great.
Thanks!
You have a few options:
1) Continue your plan spending time getting friendly with Auto Layout and Size Classes. This might be difficult at first, but it will really pay off later. You should use the Assistant Editor's Preview mode to let you see iPhone 4, 5 and 6 side-by-side as you work so you can make sure your layouts look great everywhere.
2) Use a component like UIStackView where layouts are automatically adjusted to fit various devices. If your soundboard is as simple as a grid of buttons, you can do that in just a few minutes using a stack view.
3) Use a component like UITableView or UICollectionView where content is designed to scroll. Using this method you design only one sound button of your app (i.e., enough to play one sound) then have iOS replicate that across all the sounds you want. When your interface is presented on a device of a different size iOS will just make the content scroll.
Very roughly, option 1 makes you do all the work; option 2 makes your layout shrink down until it fits the available space; and option 3 makes your layout stay the same size no matter what, but you should expect it to scroll on some devices.
There is no right solution; it's entirely down how you want your app to work.
Is it acceptable (i.e., to App Store) to have buttons in a UINavigationBar change on-the-fly? For example, perhaps there are two buttons on the Nav Bar for + (Add) and Trash (Delete), but once the + has been touched (for adding an item) the buttons change to Cancel/Save?
A related question, assuming it is acceptable, is whether it is preferable to activate/deactivate buttons as required, or whether it would be better better to make buttons that are not relevant to the operation underway simply disappear to be replaced by those which are relevant at any given time?
Not sure I've made myself clear here, but I haven't seen anything on this in the HIG. Thx.
I don't think there's anything wrong with changing buttons on UINavigationBar. I even have an app published to AppStore (and many other apps too) implementing such feature and Apple's ok with that.
I have an app which has had its UI designed for iOS7. Specifically, the UINavigationBar should have the "flat" look. In iOS6, the appearance is very different. Is there an easy way to make it retain the style of iOS7, or do I have to customize the bar?
You have to fake the iOS7 appearance by theming the controls in the app. You won't be able to get things like the blurs without a lot of effort, but the navigation bars and buttons are all pretty simple images so easy to replicate.
Strongly consider not supporting iOS6 at all though. There is a lot of difference between the two systems and you will burn a lot of time supporting a shrinking portion of probably non-active customers. Everyone that can run iOS6 can run iOS7. If they don't care enough to update their phone, they aren't going to care enough to download your app.
I want to design a page with tab bar on top of it.In some articles of this site.(i missed urls) i found that this is not a common way and the question gets some down rate.
The question is this: whethere having a design like this may cause that apple not approve the application on his store?
Even if it doesn't make Apple reject your app, think of the users not being used to the tab bar being at the top and how that is going to affect how well the app does in the Store.
Every platform has its own design patterns and there is a reason for that. If you stick to them there is a higher chance that the first-time users have an easier time using your app, which results in a higher chance that they keep using it. If they don't know how to use it or find it hard, they will move to another one.
Take a look at the Human Interface Guidelines and apply them. It will do good.
I am planning to use a couple of picker controls and segmented controls (as a kind of control panel) embedded in a container view controller to control the contents of a second child view controller. However, according to Apple iOS Human Interface Guidelines, on an iPad a picker may not be presented in the main screen and must be presented in a popover:
On iPad, present a picker only within a popover. A picker is not
suitable for the main screen.
How strict is this rule?
Would it be ok in my case to have the picker on the main screen in order to provide the required interactivity?
Clearly the answer to your question really depends on Apple, not on anything we developers might think or say. Your screen design looks very reasonable to me, but the issue is really whether Apple will approve it.
It might be better to ask if anyone has had an app approved with pickers outside of popovers.
Alternatively, you could ask if anyone has had an app rejected for using Pickers outside popovers.
Apple rules and common sense have a high degree of overlap, but where they differ the only thing that matters is Apple. Either ask them, or just submit your app for approval and see.
Good luck!
Here is my experience regarding picker.
I had an app (say appAA) approved, which use picker view in a modal view, three pickers, one followed by another.
I had another app (say appBB) which basically copies the modal view of appAA. This app was rejected because of a functional problem which I could not reproduce. I debuted in Resolution Center, then the reviewer rejected again with additional reason, saying the pickers are not presented in popover!
I guess I have to put the pickers into the popover if I want appBB to be approved since the review mentioned so.
I think the answer is simply How ugly does it make the UI look?
The left/right edges of the picker were originally intended to be flush with the edge of the iPhone screen (and it was hardcoded to be 320px wide, which failed to work sensibly in landscape mode). On the iPad, the UIPopover lets it be flush with the frame. The obvious way to achieve this effect without using a UIPopover is to draw your own frame, instead of leaving a flat grey background between the pickers.
However, the easiest (and better looking, IMO) solution is to take the picker background (as a 1px-wide image) and use a UIImageView to stretch it behind all the pickers so they look like part of a continuous bar. Remember to check both retina and non-retina versions.