Guys. ROB was right. IF you are using facebook plugin you have to declare that you are using IDFA.
If you are using social plugin is not necesary.
If you get a message saying something about limit tracking, it is because you are using booth at the same time.
Facebook plugin is not necesary is you are using social one for facebook.
Guys. ROB was right. IF you are using facebook plugin you have to declare that you are using IDFA.
If you are using social plugin is not necesary.
If you get a message saying something about limit tracking, it is because you are using booth at the same time.
Facebook plugin is not necesary is you are using social one for facebook.
I have both social & facebook plugins and I could upload my app & got approved (“ready for sale”) after I checked IDFA & the first option under it. (I do have some ad showing in my app)
FYI.
So it seems that if you have ads in the app Apple will give it a pass with the right checks, but if you don’t have ads they will reject it.
Its totally the Facebook Plugin. We removed it and switched over to the Social Plugin and it passed the binary check.
I had this issue, then went to 2189 this morning and that resolved it.
My app used NO ads, no plugins, no anything. It’s a paid game but this stupid IDFA thing kept popping up. I’d upload binary and within 2 minutes status would go from upload recieved to invalid binary.
After I went to 2189 build, that went away and now waiting for review. What a pain in the ass!
@Rob, I don’t understand why you keep saying that we HAVE TO show ad to pass review team iDFA check. When submitting a binary in itunes connect you can choose option that IDFA only attributes app installation from previously served advertisement - that is from EXTERNAL ad like facebook ad, or an ad in another app. So I DON’T have to show the ad in my app if I just want to call facebook.publishInstall() method to be able to advertise my app in facebook feed.
The problem is, I’m writing it again, that Corona builds don’t respect Limit Ad Tracking, so don’t just force us to show the ads to hack it around if we don’t won’t to show ads for some reason. If apple makes it possible to use IDFA to attribute app installation from previously served external ad, Corona should adjust and allow its users to do the same. I need a social plugin for sharing, but I also I need a facebook plugin for calling publishInstall method. Right now I have only two options with Corona: either delete facebook plugin, ( and close the opportunity to advertise on facebook) or keep the facebook plugin and display ad in ‘about us’ screen, which isn’t a real solution of the problem.
This respectation of Limit ad Tracking - is it something that facebook has to change in its own API first so you could wrap it later in lua for Corona? Or Corona engineers could change the code to make the future builds respect this setting earlier?
@whammy, there are two parts to this:
1. Passing the automatic check in Application Loader.
2. Passing the human check in about a week when your app is reviewed.
There seems to be plenty of suggestions above on how to properly submit an app and get it past the application loader. The Facebook SDK tracks ads. I’m pretty sure it’s due to their publisehdInstall’s API call. Now everyone seems above seems to be saying that if you don’t use Facebook, things are good. If you do use Facebook, you have to check that you’re using the identifier and the first option under it. What I don’t know and I’m guessing is that if you are saying that you’re checking this and still getting rejected by Application Loader, then it must be scanning for a known ad library and I was suggesting you add an ad library to respond to that.
Now for part 2, the App Review process; There was a post a couple of weeks ago about some one who got rejected by the human reviewers for saying they were using ads when they were not. Since it takes around a week to get approved, many people posting to this post are still waiting on that answer. So if you say you use the IDFA and you are not really using it, the human reviewers may punt you.
I fully agree that putting ads in a pay app is bad, but I’m just offering suggestions on how to get around Apple being difficult about this until Facebook gets us away to make this optional.
Just a quick update:
Based on our investigation, the Facebook SDK is causing rejections for lots of developers (not just Corona devs).
We’re looking into what can be done. The challenge is that the current, released Facebook SDK (v3.14) does continue to access the offending API (advertisingIdentifier) which it presumably needs for monetization purposes.
OK, thanks for the note.
@Walter, I may be wrong, but in my opinion this advertisingIdentifier will be in use in all facebook future SDK because it tracks app installs from their facebook feed ads. Apple seems to be fine with that - that’s why they got this option to select when submitting a binary: “IDFA is used to attribute app installation from previously served ad”. The thing they don’t seem to approve is lack of respect of Limit Ad Tracking settings in iOS. Is it something that Corona engineering can fix, or it has to be fixed by Facebook first?
@whammy, both the advertisingIdentifier and ad tracking would need to be controlled by Facebook’s SDK (and also ad network SDKs). It’s up to Facebook to honor the ‘advertisingTrackingEnabled’ iOS API that would then honor the Limit Ad Tracking settings. In the past, we’ve been able to work around a lot of things, but as you can see, we are facing hard limits here on what’s controllable from our side.
Okay, so quick follow-up.
We’ve updated the Facebook plugin to the latest version of the Facebook iOS SDK v3.14 (which was just released yesterday). There’s a chance this may satisfy Apple. Let us know if you have any luck!
Sounds good! My build has passed an Application Loader check with Facebook plugin included (I selected the second IDFA usage option - attributes app installation from previously served advertisement)
We’ll see how it goes with a human check in about a week.
Thanks Corona for a quick update!
So just to clarify… are you saying that any build before 2169 will fail - regardless of the plugins used?
Looks like I may finally have to bite the Graphics 2.0 bullet - this could be a huge piece of work.
I was just rejected, but also have flurry and gameanalytics plugins.
Apple will reject any app build with 2168 or earlier that does not contain ads or features where they have deemed the IDFA is valid. There was a post the other day that said iAds doesn’t use the IDFA, so you may be required to use ads from a provider that requires it. Then you have to set the right value in iTunes Connect to match what your app is trying to do.
Flurry and GameAnalytics should not require this ID and most builds should get the latest plugin. The problem is that prior to 2169 this ID was baked into the core, and Apple’s auto-scan see’s it and looks at your iTunes settings and if you say you don’t use it, Application Loader will punt you and not let your submit. If you tell iTunes you’re using it when you’re really not to get past the Application Loader block, then their human testers will punt you for not using the ads.
You can put:
graphicsCompatibility = 1
in your config.lua where you set your width and height and should be able to build with minimal changes. If you’re using the old legacy sprite library you will need to download it from our github repository and drop the sprite.lua in your folder with your main.lua and you’re good to go there.
Rob
Thanks Rob.
I tried compatibility, but it still messed everything up - it was some time back - I’ll get into it later this week and see if there’s a simple solution.
Thanks,
Nathan.
OK, so officially my app got accepted by the apple review team. I used facebook and social plugins, I selected the second IDFA usage option - attributes app installation from previously served advertisement (I’m using facebook.publishInstall) and build my app with Corona 2169.
I display no ads.
So no - you don’t have to display ads inside your app if you use IDFA just for marketing your app with external ads.
Hey Rob,
When I run in compatibility mode my images are all over the place.
Pre Graphics 2.0 the x/y coords were the top left of the object at the point of creation, then the middle of the object from there on.
The compatibility mode doco (http://docs.coronalabs.com/guide/graphics/migration_v1.html#TOC) seems to indicate that it’s only top left this is supported?
“Display object constructors will treat the x and y values as left and top respectively, instead of the center, just like in V1”
Thanks,
Nathan.
In compatibility mode, the x, y values should resort back to top left for most objects like they did in v1. In v2 everything has been moved to center. Can you post your config.lua?
Here’s my config.lua for review.
application = { content = { graphicsCompatibility = 1, -- Turn on V1 Compatibility Mode width = 320, height = 480, scale = "letterbox", fps = 30, imageSuffix = { ["@2x"] = 1.5, ["@4x"] = 3, -- for iPad 3 } }, }
I’m running 2189 - when I run without the compatibility flag it’s all over the place.
Here’s one object that works:
myMenuObject.MenuMessageDialog.HeadingTxt = display.newText(myMenuObject.MenuMessageDialog.Group, "Heading", 0, 0, font.bold, 16) myMenuObject.MenuMessageDialog.HeadingTxt.x = 100 myMenuObject.MenuMessageDialog.HeadingTxt.y = 100
It over-rides the original x,y at object creation with a new x & y which were always relative to the middle of the object.
Here’s one that doesn’t work:
local textOptions = { parent = myMenuObject.MenuMessageDialog.Group, text = "", x = 100, y = 100, width = 200, height = 100, align = "center", font = font.normal, fontSize = 14} myMenuObject.MenuMessageDialog.MessageTxt = display.newText(textOptions)
Note that this method of text creation which allows alignment has always been relative to the centre of the object on creation - perhaps compatibility doesn’t take this into account?
Also buttons don’t work if their alpha is zero (“myMenuObject.MenuMessageDialog.ButtonOK:setFillColor(217,217,217,0)”) which was fine before.
Nathan.
Nathan.