No conflict, but the API’s are different. So you would have to wrap some in if/else clauses.
You would need to restrict Chartboost (our plugin) to only be required for iOS (via build.settings) and require it in your Lua code under a different variable name. For instance:
local chartboost = require( 'currentChartboostandroid' ); local chartboostPlugin = require( 'plugin.chartboost' );Our iOS chartboost plugin is now available: http://gremlininteractive.com/product/chartboost-plugin-for-the-corona-sdk/
Thanks Gremlin! I’ll be purchasing today for sure!
Thanks. License purchased 
Thank you
Purchased!
I have a question though… If I want to use my plugin for one app in 3 different stores - amazon, apple, playstore - will it count as 1 towards the “app limit” or 3?
(P.S I know the android version is not out yet. just wanted to clarify).
They say it’ll count as 1 as long as the app name is the same across all stores.
http://gremlininteractive.com/corona-plugins-faq/
However I’d like to know how they determine the name of the app across platforms. Android allows multi line app names while iOS doesn’t, so my Android display names are usually longer than on iOS.
Personally I’d prefer if they’d register licenses based on bundle-id/package-id (com.company.myapp) which I always keep the same across all stores.
Also, what happens when you localize the app name?
I do this for all my new apps.
+1 for using package names instead of app names!
Ingemar is correct.
This is actually a good idea, we will look into this. PS: Sending you the plugin binaries now 
I’m also interested with it being based on the bundle-id/package-id. I’ve had apps where I release on Android with one name and have to slightly tweak it for iOS because that name is already taken. This means I have 2 slightly different names for the same app so that would count as 2 (which is a deal breaker).
We are contemplating changing to the bundle id/package id system.
We agree that it would give more flexibility.
Natively supported ad plugins are free to use the advertising identifier API, so this is a non-issue for those plugins.
Previously, we had to remove this from the Lua API for practical reasons — namely if a natively written app happens to reference the API and links to the corresponding framework, but never actually uses the API in practice, Apple will reject those apps. They only find it acceptable when used in ads; the developer must also mark certain checkboxes during the app submission process.
In the longer term, we’d like to bring this functionality back in a plugin, but it’s not a high priority for us given that (1) Apple restricts the use of this API for specific situations (i.e. ads) and (2) practically all 3rd party networks (except Chartboost) write native plugins and thus have access to everything they need.
Walter, thanks for the answer.
(2) practically all 3rd party networks (except Chartboost) write native plugins and thus have access to everything they need.
Unfortunately, Chartboost is one of the biggest and best paying ad networks specifically for indie game developers.
And Chartboost is not the only one without a native Corona plugin - Revmob is another.
It would be really cool if you could get in touch with these guys to solve this ASAP, to keep Corona an attractive platform for indies to monetize their games via ads.
Thanks!
Thomas
I agree. Chartboost was the best option available and I also noticed that I had a drop on the installs. Thanks for posting about it @Thomers.
We are looking into making a Chartboost plugin for Corona, using their native sdk.
More info soon.
I would wish for a better appreciation of, and support for, non-native ad networks. It’s really slim pickings out there within the native plugins.
Let’s say you’re an Android developer, and let’s say you have good reasons for avoiding the READ_PHONE_STATE permission, then there’s a pretty slim offering of ad networks to choose from. (Fortunately, I don’t think this change affects Chartboost on the Android side – yet, but likely will as of Aug 1)
Revmob is about the only network left that actually works in a developer-friendly way across platforms. Here’s some notes I’ve been trying to keep for myself, and granted they’re very hodge-podge, but nearly every provider available has some serious usability flaw upon actual implementation and testing. Provided for public comment…
via ads library:
AdMob - would be great except for performance problems and ‘unruly’ behavior
iAds - iOS only (android matters to me too)
InMobi - both versions require READ_PHONE_STATE on Android
inner-active - requires READ_PHONE_STATE on Android
Vungle - video-only
CrossInstall - requires READ_PHONE_STATE on Android, ‘ugly’ interstitials
via plugins:
SponsorPay - sample won’t even run on Android, so I’ve not yet bothered
PlayHaven - can’t even download sample, so again, haven’t yet bothered
Tap for Tap - undoc’d READ_PHONE_STATE on Android, banners don’t position properly on non-320x480
Other third-party listed in forum:
AdBuddiz - no idea even what this is
AppRever - READ_PHONE_STATE, build errors
LunarAds - not really an ad network itself, just mediator, graphics V2 incompatible
Chartboost - still works on Android, no longer works on iOS (& may have display probs on odd-sized content)
RevMob - hey, one that actually works!
via roll-your-own: (given an image url and click url, developer handles the display, those sorts)
appnext - offer wall only
leadbolt - via webview, tho can be tricky to plop the device id into the html before load (needed to track installs)
i’ve not yet investigated:
appbrain/applift
millenial (and previously jumptap)
adcolony (video only, so unlikely supportable without native plugin)
etc, many others
We have completed work on our iOS chartboost plugin and will be launching next week.
In the mean time we are working on the Android version.
Will keep you guys/gals posted.
Awesome! Looking forward to this as I’ve pretty much given up on Revmob.
FYI.
I have verified that daily build 2162 works with the lua implementation of Chartboost.
https://github.com/ChartBoost/corona-sdk
Our game is live and serving ads.
When I submitted on iTC, I indicated the following:
– Yes, using IDFA
– (Checked first box) Serve advertisements within the app
– (Checked fourth box) Limit ad tracking settings in iOS. I confirm…