Once iAd is displayed, does it never go away? - iphone

Is it okay to display and hide an iAd at will?
Or is there an Apple-policy that says we MUST show an iAd at all times?
Also, any way to configure (or if its even possible) to set the interval at which the ads are rotated/updated?

The iAd Programming Guide is quite specific about this:
Once you display the ad banner, you should leave it visible for at least 30 seconds, unless the user requests a new page or screen as described in your agreement under “Minimum Rendering Time”.
I personally haven't signed any iAd agreement but if you use it in your app, you presumably have. So look there for more details.

Related

Has the iAd request rate changed in iOS 6?

I have an app that uses iAds and I have noticed a major decline (50-60%) in the number of requests made per session since releasing an update built upon iOS 6. My average session and session length has not changed, in fact the session length has increased slightly. The structure of the app has not changed and the number of view controllers with ads has increased slightly. My assumption was that after the update I would see an increase of the number of ad requests.
The code (logic-wise) that requests ads hasn't changed and in testing ads show up fine.
The only differences are that the new app is written in MonoTouch, and was previously an Objective-C app, and it is built on iOS 6. I won't rule out the possibility I've done something foolish, but ads do appear fine in the App Store version. I can't figure out what would cause some a steep drop in requests unless the iAd banner is just not requesting as frequently.
Apple changed some things in iAd with iOS 6:
You no longer specify an orientation, ADBannerView sizes to the orientation
You can set AutoresizingMask to allow it to resize
It's possible they could have changed the refresh rate as well.
I wouldn't think MonoTouch would cause any problems. We have a MonoTouch app, and it pulls the most money from iAd than any other ad network's banners we use.
I wrote to iAd support and got an explanation. Simply put, in iOS 6 you absolutely need to be sharing the same iAd banner view between view controllers.
I was creating a new one in ViewDidLoad, based on some code I'd found a few years ago. The newer iAd samples (AdSuite, I think?) show how to share a banner between view controllers, but the gist is just to create a singleton class or to create the banner view in your app delegate and use it everywhere.
My app update recently hit the store using the shared banner and I immediately saw a significant jump in iAd requests. There were no other ad related changes that would have affected the requests, so I'm certain the shared banner view was the key.
As Ken Pespisa says one should share one banner between viewcontrollers. Apart from the sample code AdSuite, there is a very good video at WWDC 2011 explaining the code involved step by step:
iAd implementation best practices

Apple iad loaded but not shown, counts towards impressions?

I've noticed something interesting in what seems to be the recommended way to show iads in some apps.
In the Apple NavigationBanner example ads are downloaded by the AppDelegate but (according to my reading) are only displayed when the user clicks something in the table and a TextViewController is put on screen.
I'm using this exact behaviour in my app but it occurs to me this could be bad, loading but never showing could cause payouts for ads that were never displayed. I wouldn't want to accidentally fall foul of the rules.
Am I right to be worried about this? Or are Apple perhaps using some unknown mechanism to track what ads have been put on screen instead of simply downloaded to calculate their impression count?
Thanks.
Apple is very careful to ensure that ads are only credited when displayed.
In one of our games, we had an issue with layout which would sometimes cause an object to be in front of the iAd (a very small one, in fact - you could still see the ad). In those cases, the iAd framework logged that we wouldn't receive an impression because the ad was obscured.

Wobble functionality etc. allowed in iPhone App Store?

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

Available & Most Profitable Ad System for iPhone App?

After release my first iPhone application I had a fairly decent turnover in turns of sales considering it was a pretty niche application in the health and fitness category. However, I decided to make the application free until the next update and in the first 3 days downloads of my app have increased by 1433% - which is quite staggering.
So it got me thinking maybe the option of a free application, with ads would be a better option. With that said, what are the available options for integrating ads into an iPhone app and which is the most profitable?
iAD is the most profitable as it pays lot per impression, but they don't always fill the slot. The best thing you can do is to implement some service like AdWhirl which will fill the empty slot with another service such as JumpTap or Admob when the iAd slot does not come through. You can adjust the frequency of each ad network to your liking as well, so if later, you decide that JumpTap should be shown always, you can adjust it from the web interface instead of pushing a new version of your app.
The best solution is to use iAds now that Apple has prevented other ad networks from device-tracking.

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.