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.
Related
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
Ok so I implemented iAds into my current app.
Problem is how do I know its working as intended or not?
Debugging on local device or simulator shows the Test Advertisement, but also often shows nothing and the
"The operation couldn’t be completed. Ad inventory unavailable"
exception is thrown on FailedToReceiveAd.
So I set the iAd banner to hide if exception is thrown. And show if ad was succesfully loaded.
Anyway i did setup all the settings required in IC and sent the app to appstore(update).
Now in my iAd module i can see the following data.. *se pic
It does look right but when i ask some friends to check if the app is displaying ads ok they say the never see any ads.. I have seen some questions regarding this but only answers saying fill rating isnt up to quota or something equal to that.. What percentage do i have to reach for my ap to start displaying ads properly??
And is there a way for the app get out of that annoying exception that comes up way to often?
I think you misunderstand what the fill rate is. It isn't a quota that you need to reach. The fill rate is the percentage of requests for ads that result in an ad actually being served.
iAd's fill rates, as you've already heard, are pretty low, often less than 20%. What that means is that only one time out of five -- and probably less -- are you likely to see an ad. Worse, most countries don't have any inventory at all.
What can you do to increase the fill rate? Not a lot. Make sure you actually show the ad. Make sure it's visible for at least a few seconds.
You can increase the chance of actually displaying an ad by using something like AdWhirl, but chances are it won't be served by Apple in the case.
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).
I'm working on an enterprise iPhone application for a client, the issue at hand is customer information will show up on the phone. My client is worried that the information could be caught using the iphone screen capture feature (home + power button), then emailed or synced from the phone. Is there any way to disable the screen capture feature? Can this be done programatically or is is possible through a configuration profile?
if your customer could retain the ownership of a handset, they can restrict Screen Capture feature using iPhone Configuration Utility. Make sure you don't give these phones to any one outside of this organization, otherwise you are in violation of your Enterprise legal agreement with Apple.
Since this is for an enterprise app, perhaps you could put a transparent overlay view atop everything, that in a drawRect went opaque when it detected the layer was being asked to render for a screen shot (perhaps by looking back up the stack trace?)
You might try setting debug points in every possible view and layer drawing methods, and see if anything is triggered by a screenshot.
Screen capture can be enabled/disabled for iPads/iPhones that are managed via the iPhone OS Configuration Utility. See page 33 at http://manuals.info.apple.com/en_US/Enterprise_Deployment_Guide.pdf where it says:
** Allow screen capture: When this option is turned off, users are unable to save a
screenshot of the display.*
In other words, in enterprise deployments where the "customer" owns the iPads (or requires employee-owned devices to be configured by IT) screen capture can be suppressed at a device level.
It's also possible to detect if screen capture has happened and to record this (so perhaps a manager can pay a friendly visit).
It is not possible to suppress screen capture under program control. Apple prefers to exercise tight control and grudgingly yields a bit to enterprises. It doesn't yield much to developers. (How do you like being a sharecropper on Apple's plantations?)
Seriously, there are good reasons to control screen capture. In the education space, we'd like to use iPads as secure testing devices. In a proctored test environment, the proctor can make sure a student doesn't have a camera or notepapers to carry away test questions. Therefore the major remaining risk to test item security is the screen capture. If you couldn't suppress it, students could quickly snap every test question they encounter and email them to their buddies (or post them online or sell them to a test-prep company).
For random consumer iPads used under uncontrolled conditions, developers don't have this capability. Them's the breaks :-).
No, there isn't. The user is always able to perform this function.
Yes, you can do this in at least two ways. Internet Testing Systems (ITS) of Baltimore has an iPad testing app in the store, interestingly it is "PEARSON NNAT2 -Stanford 10 - OLSATS", a Pearson app that can be used to take any of these three tests. see https://itunes.apple.com/us/app/pearson-nnat2-stanford10-olsat8/id546817211?mt=8 -- it is free and you can download it.
If you simply require your user to put the device into Guided Access mode after starting the app and before proceeding, using UIAccessibilityIsGuidedAccessEnabled(), you can then prevent the user from using "print screen" -- OR from switching to any other task. Examsoft is a vendor that uses this approach.
These features are generally of concern to test publishers and assessment delivery vendors; I have a blog post and screen shots the ITS approach, and code to emulate the Examsoft approach, here: http://mindstormtools.com/2013/02/23/ipads-for-assessment-test-delivery-profile/ and http://mindstormtools.com/2013/02/20/ipads-for-assessment-guided-access/
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.