Just some over-officious reviewer, you could point to the 200,000 other apps that hide the status bar. How ridiculous.
Wow - being rejected for hiding the status bar, never heard that one before. As Nick says, contact the App Review team and point out the huge number of games that do the same - like perhaps Angry Birds for example.
Can you post the screenshot that the Apple review team sent you?
Apples HI guidelines state the following:
Think twice before hiding the status bar if your app is not a game or full-screen media-viewing app.
Although these apps might permanently hide the status bar, you should understand the ramifications of this
designdecision.Permanentlyhidingthestatusbarmeansthatusersmustquit yourapptofindout, forexample,
whether they need to recharge their device.
Without seeing your app/game, its hard to know if it is relevant to remove the status bar from the screen, although Apple seem to think so.
Well here is the response to the defence of users using the notifications swipe feature.
“” … Thank you for your response. We understand it can be frustrating to receive information you may not have expected.
Our main concern is that your application covers the status bar, which is not a new development in our guidelines. While users can swipe down to view their notifications bar, that does not replace viewing the native iOS status bar. It would be appropriate to revise your application so that the native iOS status bar is permanently visible when the app is in use.
For more information regarding the status bar please refer to the iOS Human Interface Guidelines.
Thank you again, we look forward to reviewing your application upon resubmission."""
Have sent away a new version - reluctantly showing the status bar - will be interesting to see if that will take 7 + days to review or reject resubmits are done faster.
In the review rules - the “empire” states that pointing to other apps in the marketplace is not a valid defence for overturning a rejected status - thus the notifications bar was my only plausible defence. The “empire” probably wouldn’t like the reason "because the design of teh bar does not suit my apps design , or i don’t think it looks good within my app.
The reality is that yes it’s simple to include it - but as others have pointed out - other apps don’t have it - and the issue of users checking their battery etc… is common no matter what apps a user is using.
It seems unfair that some devs (me) have to contend with blending/incorporating the status bar into the apps graphics color scheme, and others don’t - But again this comes back to my personal feelings about the status bar being a sharp contrast to the color scheme of my app (there is room for the status bar - but my personal preference would be to not have it). But the empire has spoken.
T.
Below is a function that could solve the problem - ie my compromise option of turning on and off depending on where the user is in the app ( storyboard ).
I did not include it in the new version - well yes i did but just assigned the StatBar to be “tran” all the time, so no On/Off functionality - as I can’t afford the possible argument and time wasting causing a delay for release.
local StatBar = “tran”
– local StatBar = “dark”
– local StatBar = “deft”
– local StatBar = “hide”
function StatusBar()
if StatBar == “hide” then
display.setStatusBar( display.HiddenStatusBar )
elseif StatBar == “deft” then
display.setStatusBar( display.DefaultStatusBar )
elseif StatBar == “dark” then
display.setStatusBar( display.DarkStatusBar )
elseif StatBar == “tran” then
display.setStatusBar( display.TranslucentStatusBar )
end
end
StatusBar()
This rule isn’t even followed by all apps made by Apple. For example, the camera app covers up the the status bar.
If they have always had this rule, they haven’t been enforcing it.
Yeah,
nothing much i can do - any future apps i do will incorporate the switching On/off function - in an attempt to bend this rule - ie i’ll show the status bar within the app - but only on secondary scenes - like menu, instructions etc… - so if the user wants to see it they are just a button press/touch away but stay within the app ( paused).
T.
You should NOT be bowing to that rejection. Someone made it by mistake, plain and simple. You need to escalate that to their boss.
Games are an exception to the status bar rule – they always have been and they always will be.
Jay
And to follow up on that, send them this:
Page 125, under Bars subhead:
The status bar, navigation bar, tab bar, and toolbar are UI elements that have specifically defined appearances and behaviors in iOS apps. These bars are not required to be present in every app (apps that provide an immersive experience often don’t display any of them), but if they are present…
Page 126, under Guidelines subhead:
Think twice before hiding the status bar if your app is not a game or full-screen media-viewing app.
Point out that you are in compliance with 10.1 because the HIG says a status bar is not required to be present in an app and even admits that GAMES (apps that provide an immersive experience) often don’t have them.
If you do NOT fight this you are doing a disservice to yourself and every other iOS game developer.
Jay
Well said Jay. I still would like to see the screenshot apple sent with the rejection. It’s hard to play devils advocate without knowing 
On most apps that hide the status bar, you can just swipe near the top center of the screen. When you do this a small grayish rectangle appears. It looks like a heater vent to me. If you swipe down on this rectangle, you get another screen that shows the status bar plus some other info. The rectangle is at the bottom of this screen, and if you swipe up on it, you go back to your app.
Have you managed to block this from working in your app?
Thanks for quick reply.
I don’t believe i did anything to block this - just tried the version on my ipod and it worked -its the notification bar i think.
But that sounds like a valid reason to put to the review board. thanks.
T
Just some over-officious reviewer, you could point to the 200,000 other apps that hide the status bar. How ridiculous.
Wow - being rejected for hiding the status bar, never heard that one before. As Nick says, contact the App Review team and point out the huge number of games that do the same - like perhaps Angry Birds for example.
Can you post the screenshot that the Apple review team sent you?
Apples HI guidelines state the following:
Think twice before hiding the status bar if your app is not a game or full-screen media-viewing app.
Although these apps might permanently hide the status bar, you should understand the ramifications of this
designdecision.Permanentlyhidingthestatusbarmeansthatusersmustquit yourapptofindout, forexample,
whether they need to recharge their device.
Without seeing your app/game, its hard to know if it is relevant to remove the status bar from the screen, although Apple seem to think so.
Well here is the response to the defence of users using the notifications swipe feature.
“” … Thank you for your response. We understand it can be frustrating to receive information you may not have expected.
Our main concern is that your application covers the status bar, which is not a new development in our guidelines. While users can swipe down to view their notifications bar, that does not replace viewing the native iOS status bar. It would be appropriate to revise your application so that the native iOS status bar is permanently visible when the app is in use.
For more information regarding the status bar please refer to the iOS Human Interface Guidelines.
Thank you again, we look forward to reviewing your application upon resubmission."""
Have sent away a new version - reluctantly showing the status bar - will be interesting to see if that will take 7 + days to review or reject resubmits are done faster.
In the review rules - the “empire” states that pointing to other apps in the marketplace is not a valid defence for overturning a rejected status - thus the notifications bar was my only plausible defence. The “empire” probably wouldn’t like the reason "because the design of teh bar does not suit my apps design , or i don’t think it looks good within my app.
The reality is that yes it’s simple to include it - but as others have pointed out - other apps don’t have it - and the issue of users checking their battery etc… is common no matter what apps a user is using.
It seems unfair that some devs (me) have to contend with blending/incorporating the status bar into the apps graphics color scheme, and others don’t - But again this comes back to my personal feelings about the status bar being a sharp contrast to the color scheme of my app (there is room for the status bar - but my personal preference would be to not have it). But the empire has spoken.
T.
Below is a function that could solve the problem - ie my compromise option of turning on and off depending on where the user is in the app ( storyboard ).
I did not include it in the new version - well yes i did but just assigned the StatBar to be “tran” all the time, so no On/Off functionality - as I can’t afford the possible argument and time wasting causing a delay for release.
local StatBar = “tran”
– local StatBar = “dark”
– local StatBar = “deft”
– local StatBar = “hide”
function StatusBar()
if StatBar == “hide” then
display.setStatusBar( display.HiddenStatusBar )
elseif StatBar == “deft” then
display.setStatusBar( display.DefaultStatusBar )
elseif StatBar == “dark” then
display.setStatusBar( display.DarkStatusBar )
elseif StatBar == “tran” then
display.setStatusBar( display.TranslucentStatusBar )
end
end
StatusBar()
This rule isn’t even followed by all apps made by Apple. For example, the camera app covers up the the status bar.
If they have always had this rule, they haven’t been enforcing it.
Yeah,
nothing much i can do - any future apps i do will incorporate the switching On/off function - in an attempt to bend this rule - ie i’ll show the status bar within the app - but only on secondary scenes - like menu, instructions etc… - so if the user wants to see it they are just a button press/touch away but stay within the app ( paused).
T.
You should NOT be bowing to that rejection. Someone made it by mistake, plain and simple. You need to escalate that to their boss.
Games are an exception to the status bar rule – they always have been and they always will be.
Jay
And to follow up on that, send them this:
Page 125, under Bars subhead:
The status bar, navigation bar, tab bar, and toolbar are UI elements that have specifically defined appearances and behaviors in iOS apps. These bars are not required to be present in every app (apps that provide an immersive experience often don’t display any of them), but if they are present…
Page 126, under Guidelines subhead:
Think twice before hiding the status bar if your app is not a game or full-screen media-viewing app.
Point out that you are in compliance with 10.1 because the HIG says a status bar is not required to be present in an app and even admits that GAMES (apps that provide an immersive experience) often don’t have them.
If you do NOT fight this you are doing a disservice to yourself and every other iOS game developer.
Jay
Well said Jay. I still would like to see the screenshot apple sent with the rejection. It’s hard to play devils advocate without knowing