Apple Reject - 10.1 Overlay On Status Bar

Getting Started Newbie Questions
#1

Hi All,

Well my first rejection - (party???)

So this was a new app - and basically i believe it relates to the classic

 

 

local d = display.setStatusBar(display.HiddenStatusBar) – line 

or 

            UIStatusBarHidden = true, – line in build settings.

I think most of us would include this line - 1) to give us more display room , or 2) because it doesn’t look that great with our game design.

With these reason in mind  -just wondering if anyone else has been rejected re this issue.

To fix it quite simple but in my opinion doesn’t look very good - i would be OK with a compromise ie display it on my menu screen - thus the user will be able to check “Status” from within my app - but hide it again in the main game section.

Currently use storyboard - so attempted to achieve this  on an app but no luck thus far - 

Anyone else tried this? - i assume just a basic show /hide type deal - but it escapes me at the mo.

The funny thing is i had an update (another app) just approved which didn’t show status bar (all my apps hide it via the build settings line).

So is this a new thing ON new apps - or ???

I build universals - i have extra space on iPhone5 but otherwise on 4… i need the room so don’t really want to show the status bar.

T.

below is quote from web searching the problem, and part of  apple explanation.

“”""Hiding the Status Bar

You can also hide the status bar completely, but give some consideration as to whether you should do this. From the iPhone Human Interface Guidelines: “People expect to be able to see the current battery charge of their devices; hiding this information, and requiring users to quit your application to get it, is not an ideal user experience.”

“”"""""

10.1

We found that your app does not comply with the Apple iOS Human Interface Guidelines, as required by the App Store Review Guidelines.

Specifically, we found that when your app is open it displays an overlay on the native iOS status bar. Please see the attached screenshot for details. It would be appropriate to revise your app so that it does not cover the native iOS status bar when the app is in use. 

It may be helpful to review the iOS Human Interface Guidelines to help ensure your app is in compliance with these terms and conditions. 

#2

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?

#3

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

#4

Just some over-officious reviewer, you could point to the 200,000 other apps that hide the status bar. How ridiculous.

#5

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.

#6

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. 

#7

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

#8

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. 

#9

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.

#10

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

#11

And to follow up on that, send them this:

http://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/MobileHIG.pdf

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

#12

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  :slight_smile:

#13

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?

#14

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

#15

Just some over-officious reviewer, you could point to the 200,000 other apps that hide the status bar. How ridiculous.

#16

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.

#17

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. 

#18

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

#19

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. 

#20

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.