Appodeal - iOS Issues.

On android everything seems to work fine. I even have an app on the store. No issues so far.

On iOS I had to remove the following plugins to get it to compile:

– Flurry Analytics

– Applovin

It looks like Appodeal is using these internally on the iOS build which results in not being able to use them together.

Sad because:

  1. I like the cheap and easy rewarded interstitial from Applovin. 

  2. At this point due to the other bug with Google Analytics I either have to use Flurry on Android and Google on iOS or use the Google Analytics lua package.

If this is not the place to post it please delete it.

thank you

Hi Agramonte;

From the absence of any response in this thread, I’m guessing you never received any enlightenment on your question at the end of July.

What was the symptom (error message) when you couldn’t compile? Was it a specific error message or just a long wait and then a “Build Failed: The request timed out.” ???

The reason I ask is that I am trying to test AppoDeal with iOS (Corona Build 2931) and I am getting this:

– It builds fine without the AppoDeal plugin in build.settings. Tested this several times.

– Include AppoDeal (and remove Flurry – which is a super disappointment if I have to do this) and it won’t build. I had already removed other “now-incompatible” plugins such as Applovin and F.A.N. Time after time I get a “Build Failed: The request timed out.”.

My remaining plugins (including AppoDeal) are:

AppoDeal

iCloud

Facebook.v4 (not FAN – just Facebook)

Apple Gamenetwork

Google Play Services (for adMob)

Does Corona (Danny??) have any thoughts on this?

If Flurry is “out” with AppoDeal, I would have to migrate my apps from Flurry (2+ years of analytics history) to use AppoDeal on iOS. Jeesh!

Just like you, I have noticed that the Android plugins seem to be professionally encapsulated in the Android build process – they don’t bump into each other and bomb things (as they do in the iOS implementations).

Steve

============================================================================

HALF AN HOUR LATER

The “time out” quit happening.

But now that it quit, I find that AppoDeal also seems to fail the building process when “google.play.services” is also one of the plugins. Double Jeesh! If you use AppoDeal, give up the capability to do a lot of other things. in your iOS games.

Keep in mind that Appodeal is a mediation provider. The main reason to use them is they give you a 100% fill rate and the highest eCPM they can get for any ad. You don’t need to run Appodeal along side other ad providers. When you include multiple ad providers you’re in effect doing your own mediation and the two will run into a conflict.

On iOS, the documentation clearly states that you cannot run the plugin.google.play.services plugin (AdMob V2) as it’s built in. Simply put a supportedPlatforms line in your build settings so it only loads on Android.  See the docs for a list of included providers.

https://docs.coronalabs.com/plugin/appodeal/index.html

I don’t know why Flurry would cause problems with this.

Are there any errors?

Rob

Thanks Rob. 

Yes, keeping google.play.services in there was an oversight on my part. I guess it was the fact that AdMob is not actually listed in the list of their mediation partners that made me wonder and decide to test it.

In the end, AppoDeal seems so problematic on several fronts that I’m probably not going to test it any further (or be able to use it). 

One of the problems is one that neither you nor I can “fix”. In fact, you addressed it in a different forum post. Including the single AppoDeal plugin adds 30.9 Mb to my app’s file size. A popular app of ours jumps from 78.0 Mb to 108.9 Mb with the addition of their plugin. Yes, I know the rationale for how great life will be with 100% fill rates and all these services being mediated (so their various providers’ code needs to be in the plugin). But a percentage (albeit not a major one anymore) of our users is sensitive to app file size – and this is the sort of bloat I normally only associate with the software company in Seattle. 

One of the other problems is something your tech folks may be able to fix. I cannot make an iOS build with a fairly normal (for many developers) selection of plugins included along with the AppoDeal plugin. The builds always (over 3 different days of trying) time out. I even made some test builds using your Hello World example and they always times out without building with these fairly routine plugins:

[lua]

plugins =

{

[“plugin.appodeal”] =

{

            publisherId = “com.coronalabs”,

            supportedPlatforms = { iphone=true }

        },

[“plugin.iCloud”] =

{

publisherId = “com.coronalabs”,

– supportedPlatforms = {iphone = true},

},

[“plugin.facebook.v4”] =

{

publisherId = “com.coronalabs”,

},

[“plugin.notifications”] =

{

   publisherId = “com.coronalabs”,

},

[“CoronaProvider.gameNetwork.apple”] =

{

   publisherId = “com.coronalabs”,

   supportedPlatforms = { iphone=true},

},

[“plugin.flurry.analytics”] =

{

   publisherId = “com.coronalabs”,

supportedPlatforms = { iphone=true}

},

},

[/lua]

The error looks like this in the console:

Sep 09 03:08:25.617 ERROR: XMLRPC: The request timed out.

Sep 09 03:08:25.617 WebServices: XMLRPC request failed

Sep 09 03:08:25.622 iOS build failed (11) after 240 seconds

Sep 09 03:08:25.848 ERROR: Build Failed: The request timed out.

If I take out all of the plugins except AppoDeal, your Hello World example will build with a build time around 261 seconds. (it almost times out by itself)

I’m guessing that your engineers are aware of how near the “timeout edge” this plugin actually is because of the recommendation (on your documentation) to use build 2016.2914 or later. I am using 2016.2931. I’m headed out of town later today on some vacation so I’m not certain I will be able to follow up on this thread quickly. But I thought your team should be aware of this build problem in case they can address it on your servers.

Steve

I’ll see what I can do about the time out. We might be able to adjust that. There isn’t much we can do about the library size though.

Rob

Thanks Rob. That is what I figured. The timeout was totally reproducible last Friday, Saturday and today. Appreciate your assist.

Steve

Can you try the latest daily build?

Thanks

Rob

Hi Rob;

I just tried it with build 2943 (latest Daily). The Hello World App (with AppoDeal and multiple plugins) now builds in 86 seconds.

Sep 12 03:03:19.299 Copying world.jpg to /Users/steve/Desktop/Just 2 Builds/HelloWorld.app/world.jpg

Sep 12 03:03:19.306 Building: Signing application with “iPhone Developer: Steve Bullock (XJE7TARRS3)”

                    “iPhone Developer: Steve Bullock (XJE7TARRS3)”

Sep 12 03:03:19.967 iOS build succeeded in 86 seconds

Thanks for your group’s work to fix/improve this.

This was using plugins:

AppoDeal

iCloud

facebook.v4

gamenetwork.apple

Now that I can build with multiple plugins, I can confirm the disappointing news that Agramonte began this thread with . . . . .

Flurry will not build with AppoDeal. I get the (now familiar) “problem linking the app” due to duplicate symbols between AppoDeal and Flurry. This is a snippet of the end of the extensive “duplicate symbols” error messages:

duplicate symbol _OBJC_IVAR_$_FlurryPLCrashReportMachExceptionInfo._type in:

                        /Users/steve/Desktop/Just 2 Builds/HelloWorld.app/.build/plugin.appodeal/libAppodeal.a(PLCrashReportMachExceptionInfo.o)

                        /Users/steve/Desktop/Just 2 Builds/HelloWorld.app/.build/plugin.flurry.analytics/libFlurry_7.5.2.a(PLCrashReportMachExceptionInfo.o)

                    duplicate symbol _OBJC_METACLASS_$_FlurryPLCrashReportMachExceptionInfo in:

                        /Users/steve/Desktop/Just 2 Builds/HelloWorld.app/.build/plugin.appodeal/libAppodeal.a(PLCrashReportMachExceptionInfo.o)

                        /Users/steve/Desktop/Just 2 Builds/HelloWorld.app/.build/plugin.flurry.analytics/libFlurry_7.5.2.a(PLCrashReportMachExceptionInfo.o)

                    ld: 785 duplicate symbols for architecture armv7

                    clang: error: linker command failed with exit code 1 (use -v to see invocation)

                    BUILD ERROR: There was a problem linking the app.

                    

                    Check the console for more information.

Sep 12 02:58:27.728 iOS build failed (12) after 77 seconds

Sep 12 02:58:28.104 ERROR: Build Failed: There was a problem linking the app.

So Agramonte was on the money with his initial post above.

Steve

Hi all, So can I say that Appodeal now works with Android and iOS, and does anybody actually used their plugin live in the stores now? The idea of having 100% fill rate and using mediation to get the highest bidder is very difficult to ignore. Santi

I have 3 apps live on the store with Appodeal. The link to Facebook Audience Network and Unity Ads has not happened (not sure how long that takes) and I do get 100% fill rate. As far as the highest bid for every ad: I am not sure about that. But it sure beats all the work of getting multiple ad networks going and deciding on segmentation.

They also pay net 15 for the networks that are not linked (Admob, Facebook and Unity are linked) which is always nice to me. Overall for me it is a great plugin. If you have a bigger team you probably can squeeze out more revenue than what Appodeal gives you, but for small team whatever you lose isn’t worth the hours it would take.

hi agramonte,

thanks for the feedback.    I would assume (since we’re in coronalabs forums), that those 3 apps live apps you have are made with Corona SDK,  Yes?    

“They also pay net 15 for the networks that are not linked (Admob, Facebook and Unity are linked)”  – sorry i don’t quite get this.  care to ellaborate?  

Thank you!

santi

Yes 3 are Corona. I have 2 other that are not Corona (Marmalade and Native) also using Appodeal. The nice part about the native SDK is you get to pick the adapters, but otherwise I don’t see any difference.

Hi Agramonte,

Diana from Appodeal is here. I wanted to jump into this thread and ask if everything is alright now. I am sorry to hear that you had some problems with integration. I wanted to provide you my help with Unity and FB, could you please PM me so I can help you. 

Santiagoluib3,

We have publishers who are with Corona and Appodeal live in Store :slight_smile: I am glad to answer all the questions about our service, what we do, why we do it and how :) 

I am fine. Thank you for the response.

Hi Agramonte;

From the absence of any response in this thread, I’m guessing you never received any enlightenment on your question at the end of July.

What was the symptom (error message) when you couldn’t compile? Was it a specific error message or just a long wait and then a “Build Failed: The request timed out.” ???

The reason I ask is that I am trying to test AppoDeal with iOS (Corona Build 2931) and I am getting this:

– It builds fine without the AppoDeal plugin in build.settings. Tested this several times.

– Include AppoDeal (and remove Flurry – which is a super disappointment if I have to do this) and it won’t build. I had already removed other “now-incompatible” plugins such as Applovin and F.A.N. Time after time I get a “Build Failed: The request timed out.”.

My remaining plugins (including AppoDeal) are:

AppoDeal

iCloud

Facebook.v4 (not FAN – just Facebook)

Apple Gamenetwork

Google Play Services (for adMob)

Does Corona (Danny??) have any thoughts on this?

If Flurry is “out” with AppoDeal, I would have to migrate my apps from Flurry (2+ years of analytics history) to use AppoDeal on iOS. Jeesh!

Just like you, I have noticed that the Android plugins seem to be professionally encapsulated in the Android build process – they don’t bump into each other and bomb things (as they do in the iOS implementations).

Steve

============================================================================

HALF AN HOUR LATER

The “time out” quit happening.

But now that it quit, I find that AppoDeal also seems to fail the building process when “google.play.services” is also one of the plugins. Double Jeesh! If you use AppoDeal, give up the capability to do a lot of other things. in your iOS games.

Keep in mind that Appodeal is a mediation provider. The main reason to use them is they give you a 100% fill rate and the highest eCPM they can get for any ad. You don’t need to run Appodeal along side other ad providers. When you include multiple ad providers you’re in effect doing your own mediation and the two will run into a conflict.

On iOS, the documentation clearly states that you cannot run the plugin.google.play.services plugin (AdMob V2) as it’s built in. Simply put a supportedPlatforms line in your build settings so it only loads on Android.  See the docs for a list of included providers.

https://docs.coronalabs.com/plugin/appodeal/index.html

I don’t know why Flurry would cause problems with this.

Are there any errors?

Rob

Thanks Rob. 

Yes, keeping google.play.services in there was an oversight on my part. I guess it was the fact that AdMob is not actually listed in the list of their mediation partners that made me wonder and decide to test it.

In the end, AppoDeal seems so problematic on several fronts that I’m probably not going to test it any further (or be able to use it). 

One of the problems is one that neither you nor I can “fix”. In fact, you addressed it in a different forum post. Including the single AppoDeal plugin adds 30.9 Mb to my app’s file size. A popular app of ours jumps from 78.0 Mb to 108.9 Mb with the addition of their plugin. Yes, I know the rationale for how great life will be with 100% fill rates and all these services being mediated (so their various providers’ code needs to be in the plugin). But a percentage (albeit not a major one anymore) of our users is sensitive to app file size – and this is the sort of bloat I normally only associate with the software company in Seattle. 

One of the other problems is something your tech folks may be able to fix. I cannot make an iOS build with a fairly normal (for many developers) selection of plugins included along with the AppoDeal plugin. The builds always (over 3 different days of trying) time out. I even made some test builds using your Hello World example and they always times out without building with these fairly routine plugins:

[lua]

plugins =

{

[“plugin.appodeal”] =

{

            publisherId = “com.coronalabs”,

            supportedPlatforms = { iphone=true }

        },

[“plugin.iCloud”] =

{

publisherId = “com.coronalabs”,

– supportedPlatforms = {iphone = true},

},

[“plugin.facebook.v4”] =

{

publisherId = “com.coronalabs”,

},

[“plugin.notifications”] =

{

   publisherId = “com.coronalabs”,

},

[“CoronaProvider.gameNetwork.apple”] =

{

   publisherId = “com.coronalabs”,

   supportedPlatforms = { iphone=true},

},

[“plugin.flurry.analytics”] =

{

   publisherId = “com.coronalabs”,

supportedPlatforms = { iphone=true}

},

},

[/lua]

The error looks like this in the console:

Sep 09 03:08:25.617 ERROR: XMLRPC: The request timed out.

Sep 09 03:08:25.617 WebServices: XMLRPC request failed

Sep 09 03:08:25.622 iOS build failed (11) after 240 seconds

Sep 09 03:08:25.848 ERROR: Build Failed: The request timed out.

If I take out all of the plugins except AppoDeal, your Hello World example will build with a build time around 261 seconds. (it almost times out by itself)

I’m guessing that your engineers are aware of how near the “timeout edge” this plugin actually is because of the recommendation (on your documentation) to use build 2016.2914 or later. I am using 2016.2931. I’m headed out of town later today on some vacation so I’m not certain I will be able to follow up on this thread quickly. But I thought your team should be aware of this build problem in case they can address it on your servers.

Steve

I’ll see what I can do about the time out. We might be able to adjust that. There isn’t much we can do about the library size though.

Rob

Thanks Rob. That is what I figured. The timeout was totally reproducible last Friday, Saturday and today. Appreciate your assist.

Steve

Can you try the latest daily build?

Thanks

Rob