[Feature Request] Implement ad widgets without native views

[naamapps]

Hey,
It may be a silly question but is there a reason this package uses native views (which are expensive and have a lot of performance issues) instead of actually using flutter widgets?

This package currently is unusable in terms of lags and crashes.
Implementing ads as widgets instead of native views will solve all those issues.

There are plenty of other ad packages (for example https://pub.dev/packages/native_admob_flutter) which also uses native views and have the exact same performance issues.

Maybe I'm missing something and it is impossible to do..
just thought it is worth suggesting.

Hope you will consider this as this will differentiate this package from others and also bring Flutter as a framework to a higher level.

Thanks

[TahaTesser]

Labeling as a valid request

[heshaShawky]

I guess it's because they are using a web view to presents the ads, the problem is web views are not stable yet on flutter ( because of the rendering mechanism that flutter currently using that causes the web view to keep reinitiate every time the page/screen rerender ).

[naamapps]

Hey @TahaTesser, do you know maybe if there are plans to do this implementation?
Ads are the main source of income for my app and I currently cannot go to market with this half-baked implementation.
I really hope there are plans.
Thanks

[Albertbol]

up!
This package is very important for many applications, would be nice to make it more efficient, currently, it's lagging productions applications on iOS, making it lag once in a while.

[DFelten]

I would also be interested to know why it's not possible to develop the Ads with Flutter only. Does Google not want that?

[3eif]

Are there any updates on this issue?

[Milluz]

Also flutter and native views don't play well together(on iOS) when talking about stack widgets. flutter/flutter#59751
I had a problem showing dialogs over native ad views. Needed to make custom dialogs to avoid this issue.

[naamapps]

This needs to get prioritized by the flutter team.
This package should have been developed with pure dart solution from the get go. I don't understand why the team chose to implement this in native views.

Please at least update us if it's planned to be implemented.

The current solution to the package is like every other package existing in pub.dev.

Only google can develop the pure dart solution, we can't do it ourselves. So please communicate with us, this is the minimum we ask for.

[3eif]

Definitely agree with the above. I have not been able to properly monetize my app due to this issue and have been waiting for almost a year now for proper monetization support. An update on this issue would be very much appreciated 🙏

[3eif]

It's so frustrating to see no updates on this and honestly I don't think a 100% dart solution will be developed any time soon.

The Flutter team itself doesn't seem to be acknowledging the buggy and poor performance of this package since they have constantly advertised that the package perfectly works and is incredibly easy to implement.

It was only a couple weeks ago since Flutter announced "General Availability for the Google Mobiles Ads SDK for Flutter" when the package is clearly not ready for general availability. There are currently 100+ issues on this repo, android inline ads still cause major performance issues, and there is still not a proper implementation for native ads.

The Google Admob SDK's docs for Flutter also fail to acknowledge the issues of the package and lacks documentation for troubleshooting and setting up certain ads.

Over the past year it has been really demotivating for me to work on my own Flutter app because of all these issues. Ads have been constantly the main source of bugs and crashes for my app and every time I try to find a way to implement ads into my app, I come across a random error, a weird/obscure bug with native views, very very bad performance, and most of the time a combination between all of them.

Unless the Flutter team acknowledges this large issue, the 100% dart solution will not be coming any time soon. We've been constantly asking for updates on this issue and have not got one since August and most likely never will. Even if no dart solution will be planned, the team should at least acknowledge and fix all the issues on this package's repository.

Flutter is great and I think the Flutter team has developed a great solution for developing cross platform apps. The only thing that puts me and so many other developers off here is the lack of monetization support. I'd love to continue using Flutter, but if there is no proper support for monetization I'll unfortunately have to move to something else like React Native.

[blasten]

We have fixed the performance of ad widgets on the Flutter master channel.

After Flutter v2.11.0-0.1.pre, you should see these improvements, but if you want to try it now, you can build your app with Flutter master.

[naamapps]

The performance on flutter 3.0 is indeed better than before, but still not perfect in my opinion.. I still see the casual frame drop here and there when scrolling or navigating the app.

Hoping one day a pure dart solution will happen.

[timothyhoang-google]

We are working on supporting Dart only Native Ads in Q4'22. I'll provide an updated timeline closer to launch.

[naamapps]

Great news @timothyhoang-google!
Looking forward using this in production

[DFelten]

We are working on supporting Dart only Native Ads in Q4'22. I'll provide an updated timeline closer to launch.

This is great news. I am very excited :) But what does Dart only mean in this context?

Will the ads also internally no longer be based on Platform Views? Or can we just implement the look of the ads via Dart? So it's dart only for our implementation, but not the internal structure.

[atrope]

That is indeed the greatest news we had since the launch of flutter! 🥳 🥳

Rewinding to my post:
#269 (comment)

I even sent an example of tagless request, dart only:
#269 (comment)

@timothyhoang-google If you need any help beta testing or anything let us know!

[timothyhoang-google]

Will the ads also internally no longer be based on Platform Views? Or can we just implement the look of the ads via Dart? So it's dart only for our implementation, but not the internal structure.

@DFelten - To avoid ambiguity, we mean Dart only for implementation, meaning Flutter developers using the plugin only need to write in Dart.

Internally, Platform Views are still required because the Flutter plugin relies on the native GMA SDK's implementation for rendering and measurement. For example, all ads except for Custom Native need to be rendered in a native WebView. This is required for complying with industry standards such as Open Measurement.

[naamapps]

@timothyhoang-google
Well this was a bit misleading.
This doesn't really resolve the issue because it requests an entirely new implementation with pure dart, without native views at all internally.

Just for clarification,
Are native ads going to be rendered without native views? From what you wrote, I understand that this ad type is possible to implement with a pure dart solution.
Thanks for your efforts.

[timothyhoang-google]

Implement ad widgets without native views

There's probably confusion on my side, so let's clarify how we're addressing the statement above. From this thread and other issues, the statement above usually covers two scenarios:

1. Using this plugin, I don't want to implement ad widgets using native views. This would be a Dart-only developer experience.

   We are working on this side of the issue in Q4'2022.

2. I want this plugin to implement ad widgets without using platform views. This would be a Dart-only GMA SDK implementation.

   TLDR; Re-writing the GMA SDK for Flutter to be Dart-only underneath is currently infeasible. This plugin has been designed as wrapper around the native GMA SDK and this won't change in the foreseeable future due to both (a) industry limitations and (b) design choices.

   Detailed explanation:
   (a) Industry Limitations: mobile ads SDKs have been designed to accommodate digital advertising's web origins. As a result, almost all major platforms still render ads using WebViews. There are critical technologies such as viewability and measurement that require a WebView to execute. DSPs and advertisers rely on these measurement solutions for reporting and will not buy inventory if measurement doesn't work.

   Hypothetically, if we were to re-write the Flutter GMA plugin tomorrow to have a Dart-only underlying implementation, this would likely also involve creating a new measurement standard for Dart. DSPs, advertisers, and measurement vendors would need to adopt this new standard and re-implement their measurement technologies to be able to measure Dart widgets.

   What this means to the developer: you would have a optimized plugin with a Dart-only underlying implementation, but zero to very low ads demand/revenue until the industry catches up by adopting Dart-only measurement standards and buying this type of inventory.

   (b) Design Choices: The native GMA SDKs are the implementation source of truth for Google mobile ads and are already IAB OM certified --- this is important to DSPs and advertisers buying inventory using the GMA SDK.

   Re-writing the GMA SDK for Flutter Ad Widgets to be Dart-only would create a large amount of redundant code that will be harder to maintain in the future. This new library would not be OM certified (or able to be certified until a new standard is created for ads not rendered in WebViews) and any new features that have been built into the native GMA SDKs would need to be replicated.

[naamapps]

Thanks for the detailed explanation @timothyhoang-google.
I'm happy that you guys decided to make the developer experience better by using only dart to get ads up and running on flutter apps.

I'm just concerned this is not enough, because web views (native views) in flutter are just not good enough for production use.
If they were performant and stable, I would say everything is perfect (except of the developer experience - that you're solving in Q4).
But they aren't permorment and they are really not stable in both android and ios.

I understand that (re)writing the entire GMA SDKs for dart-only is hard and difficult, and requires a lot of approvals, money and resources.
But I don't think these reasons are strong enough to leave the situation as it is now.

After all, if you (Google) decide to go for it and make GMA for dart, then I think at the end-game it will be worth it, business-wise and for the community of Flutter devs.

As you said, this probably will not be developed in the near future.
But the minimum I expect is to fix native views for ios and android, because this is the root cause of this issue.

Thanks again.

[Tom3652]

I also understand much better the reason now with the detailed explanations thank you for that.

A dart only solution for implementation is already very good !
But I must agree with @naamapps, the real solution for this issue then is to fix the PlatformView, otherwise it makes native ads unusable :(

I wonder however who would be in charge of this work because it's a general Flutter issue...

Note : I am currently unable to go in production only because of this unfortunately

[saddemYassin]

@timothyhoang-google so how it does work with unity framework ? https://developers.google.com/admob/unity/native/custom

[timothyhoang-google]

@saddem123 - the Unity plugin is similar to the Flutter plugin in terms of API dependencies from the native GMA SDK (native dependencies pulled in here). Similarly, ads are rendered in a WebView and displayed in an overlay above the Unity game.

[ramtinq]

@timothyhoang-google please take a look at this (deprecated) package:

https://github.com/bdlukaa/native_admob_flutter

somehow (at least in Android) it renders native ads much smoother than this plugin, while it also provides Dart-only developer experience.

Thank you.

[timothyhoang-google]

@ramtinq - if the smoother Android rendering performance is specific to Virtual Displays, then unfortunately this is not supported due to policy (this is also called out in the native_admob_flutter package readme). If there is a rendering optimization for Hybrid Composition in native_admob_flutter that is absent from google_mobile_ads then we can investigate further.

[naamapps]

Hey @timothyhoang-google
We have passed 2022 Q4, is there an update about the release?

[timothyhoang-google]

This feature should be code complete - @jjliu15 will merge the changes once testing and documentation is complete (next 1-2 weeks).

[andaas4]

Any updates on this? As it have now been 4-5 weeks.

[naamapps]

What's the hold up here guys?
We're nearly at Q2 2023!

[timothyhoang-google]

The changes to support Dart Native Ads is being developed in parallel with an update to support WebView API for Ads APIs. This update requires a major version update, as this increases the minimum supported GMA SDK version.

[andaas4]

Any ETA on when Dart Native Ads will be available? @timothyhoang-google

[naamapps]

I don't think it's on their radar..
The new templates based solution is really not customizable and so minimal, that it lost its point.

What we need is a Dart only, widget based solution.

If removing the need of platform views is not possible, the flutter team can take inspiration from @bdlukaa's (now deprecated) package and develop an AdBuilder which enables the option to build the layout of the ad using dart code - and behind the scenes it would transform into a platform view native ad.
This would result with better customization and DX!

Flutter team, this issue is ongoing for 2 years now, please take this package seriously and not like a side project.
I appreciate your work, but this repo looks so abandoned, every issue is only being reproduced but without any solutions.

Hope for the best.

[timothyhoang-google]

@andaas4 - We released support for Dart APIs for Native Ads with v2.4.0 (changelog).

Dart only, widget based Native Ads is not feasible at this stage. More details in my post on Sep 26, 2022 on this issue.

[yullg]

I want a full-screen AD widget that can be placed in the widget tree instead of opening a new interface.

[felipecastrosales]

Any updates in this case? Would be great.

[sabbaghpierre]

Hi, any updates regarding this? The performance of our app after adding Banner Ads is atrocious...

[rahulraj-idt]

@timothyhoang-google This is really critical issue, we are trying to figure out work arounds. The one comes top of my mind is get the data from the SDK or from the native side using a method channel and create a pure flutter ad unit. Any suggestions? Thanks!

[timothyhoang-google]

FYI - @malandr2 (new manager for this plugin)

[vaHeidi]

It seems unlikely this problem is getting resolved anytime soon.
Did anyone come up with an actual workaround that doesn't result in atrocious performance?

[heshaShawky]

It seems unlikely this problem is getting resolved anytime soon. Did anyone come up with an actual workaround that doesn't result in atrocious performance?

it's not going to be from a technical perspective as it's not that easy to achieve and I am not talking about just the flutter widget but connecting this widget to their system as well.

they are using Web View for a reason, so they have full control of everything on the ads but in Flutter they do not, so if they make an update for example for the ads, the ads will not be updated unless you update the package code and this is a serious business issue.

So the best case scenario is fixing the performance issues with the ads or using a web view with flutter as it's till now really bad!!

[3eif]

It seems unlikely this problem is getting resolved anytime soon. Did anyone come up with an actual workaround that doesn't result in atrocious performance?

Move away from Flutter to something else with better monetization support like native

[heshaShawky]

It seems unlikely this problem is getting resolved anytime soon. Did anyone come up with an actual workaround that doesn't result in atrocious performance?

Move away from Flutter to something else with better monetization support like native

React Native is better till now from overall performance

[EArminjon]

What about Server Side Rendering and RFW (https://pub.dev/packages/rfw, https://pub.dev/packages/swap) instead of native views ?