WPMobile.App turns an existing WordPress website into an Android and iOS application while keeping the website at the centre of the project. From the beginning, I chose not to include advertising or audience analytics SDKs in the native application layer.
Applications generated with WPMobile therefore do not automatically include Google AdMob, Firebase Analytics or other tracking SDKs.
This decision is mainly based on two reasons: I do not want to impose third-party components that are unnecessary for many projects, and I prefer to avoid technical complexity and support requirements that would eventually affect licence prices.
This is not a general objection to advertising or analytics. It is a question of necessity, trust and maintenance.
What is an SDK in a mobile application?
An SDK, or Software Development Kit, is a collection of software components provided by a vendor to integrate specific features into an application.
An advertising SDK such as Google AdMob can be used to display advertisements inside an app. An analytics SDK can collect events related to application usage, such as app launches, viewed screens or certain interactions.
Other SDKs provide authentication, payments, advertising, crash reporting or various external services.
These tools can be useful. However, unlike a service loaded occasionally from a web page, a native SDK is integrated directly into the application binary. Its code becomes part of the distributed application even when some of its features are not used.
It is important to distinguish the presence of an SDK from its actual activity. An integrated component does not necessarily collect data continuously. Its behaviour depends on how it works and how it is configured. Nevertheless, it remains additional third-party code inside the application.
First reason: not imposing unnecessary SDKs on every project
Applications created with WPMobile serve very different purposes. Some belong to small associations, while others are blogs, WooCommerce stores, member areas or business websites.
An association app does not necessarily need AdMob. A private customer portal may have no reason to track every interaction. A store may already use analytics tools configured for its WordPress website.
If I systematically integrated several popular SDKs, they would be present in every application, including those that have no use for them.
I prefer the opposite approach: an application should contain what is necessary for its operation. An additional integration should address a real requirement rather than simply being added because competing products offer it.
This approach matches WPMobile’s architecture: WordPress remains at the centre of the project, while the native layer is limited to the functions required by the application.
Third-party SDKs also raise questions of trust
Advertising and analytics SDKs may process information about devices, interactions or application usage. The exact data involved depends on the provider, configuration and enabled features.
Some vendors provide privacy controls and mechanisms for limiting collection. This does not mean every SDK is problematic or that all SDKs systematically transmit personal information.
However, their presence creates a dependency on an external vendor whose behaviour may change independently of WPMobile.
Personally, I prefer not to integrate this type of component without a clear need. Even when an SDK is disabled or configured to limit collection, its implementation, documentation and future vendor updates still require trust.
Not including it avoids introducing that dependency into applications that do not need it.
This is a form of technical minimisation: fewer third-party components mean fewer external behaviours to monitor, without claiming that an application automatically becomes private or GDPR-compliant because of this decision alone.
An SDK can also create privacy obligations
Apple and Google require developers to disclose certain data collection and processing practices in their respective privacy declarations.
When an SDK collects information, the application owner needs to understand what data is involved and verify the required disclosures. Depending on the processing performed, additional obligations may apply, including user information and consent requirements.
Simply integrating an SDK does not automatically make an application non-compliant. However, each additional component can make the analysis more complex.
By avoiding advertising and analytics SDKs by default, WPMobile reduces the number of native third-party components whose data practices need to be examined.
This does not remove the need to audit services used by the WordPress website itself. A WebView app can display pages containing web analytics tools, external content or other scripts. These services remain present in the web environment and must be managed according to their own requirements.
Second reason: every additional SDK requires maintenance
Integrating an SDK is not simply a matter of adding a few lines of code and forgetting about it.
Vendors regularly release new versions to fix bugs, support new Android and iOS versions, modify APIs or meet new app-store requirements.
Each update may require checks involving minimum operating-system versions, permission changes, new dependencies, configuration files or evolving privacy requirements.
An SDK may also introduce conflicts with other native components or impose additional build constraints.
The more SDKs an application includes, the larger its maintenance surface becomes. Even when a feature is used by only a small minority of customers, it must remain compatible with future application versions.
This is particularly important for a product that generates Android and iOS applications from a wide variety of WordPress configurations.
Installation and configuration also create support work
An advertising or analytics SDK generally requires configuration before it can be used. This may involve creating an external account, adding identifiers, registering an application, configuring events or adjusting privacy settings.
Problems are then no longer limited to WPMobile itself. They may originate from the SDK provider, an incorrectly configured account, changes to the vendor’s interface or restrictions imposed by Apple or Google.
For each additional integration, I would therefore need to maintain documentation, follow vendor updates and answer related support requests.
A feature used by a small number of customers can consequently create maintenance work for the entire product.
I develop and maintain WPMobile independently. Time spent supporting these integrations is necessarily time not spent on the application’s core functionality, Android and iOS updates or fixing existing issues.
This complexity would eventually affect licence prices
WPMobile uses a one-time licence model without a recurring WPMobile subscription. I want to keep this model as simple as possible.
Adding numerous SDKs and their configuration systems would create an initial development cost, but more importantly an ongoing maintenance and support cost.
That cost would need to be absorbed somewhere. Eventually, it could require higher licence prices or additional paid services to finance the integrations.
This would mean making every customer pay for complexity that only benefits some of them.
I therefore prefer to focus development on features directly related to turning a WordPress website into a mobile application.
The WPMobile pricing model reflects this approach: a native application based on WordPress, with a deliberately controlled technical scope.
How can audience analytics work without a native SDK?
The absence of Firebase Analytics or an equivalent SDK does not mean audience measurement is impossible.
A WPMobile application displays the existing WordPress website inside a WebView. If the website already uses a web analytics solution, that solution may continue measuring pages and events in this environment, subject to its configuration and applicable privacy choices.
Google Analytics, Matomo or other web analytics solutions can therefore be used at website level rather than systematically adding a native SDK to the application.
There is an important difference, however: web analytics do not fully replace native application analytics. They may not measure installations, app launches or every event specific to the mobile operating system.
For some of these indicators, Apple App Store Connect and Google Play Console already provide data related to application distribution and usage.
The appropriate choice therefore depends on what information is actually needed. Not every project requires an additional native tracking system.
What about displaying advertisements inside the app?
WPMobile does not integrate Google AdMob or an equivalent native advertising SDK.
It is important to distinguish advertisements integrated directly into an application through a native SDK from advertising placements displayed on the WordPress website.
In a WebView app, website content continues to load from WordPress. Web advertisements present on those pages may therefore appear in that environment, depending on how they work, the advertising network’s terms and the rules applicable to applications.
This does not turn those advertisements into native AdMob ads. The technical possibilities, commercial terms and distribution rules may be different.
I prefer to maintain this separation rather than integrate a native advertising network into every application, including those that do not want to display any advertising.
Fewer SDKs does not mean zero external dependencies
A mobile application obviously cannot operate without technical components. Android and iOS provide their own APIs, and certain features require communication with platform services, particularly for push notifications.
The objective is therefore not to claim that WPMobile has no dependencies at all. It is to avoid adding third-party advertising or analytics SDKs that are unnecessary for basic operation.
This distinction matters: limiting optional dependencies is an architectural decision, not a promise that the application never communicates over the network or processes data.
The WordPress website also retains its own plugins, scripts and services. Their presence and configuration remain independent of this decision concerning WPMobile’s native layer.
A simpler application to maintain over time
Over the years, Android, iOS and app-store requirements continue to evolve. Native versions, required Android SDK levels, notification mechanisms and various operating-system behaviours must be updated regularly.
I have already discussed these constraints in the article about WordPress mobile application maintenance. Even a WebView application requires ongoing technical attention.
Limiting optional integrations makes it possible to concentrate that work on genuinely necessary components instead of multiplying dependencies that need to be maintained.
That is ultimately the reasoning behind the absence of AdMob, Firebase Analytics and other native tracking SDKs in WPMobile: avoid imposing unnecessary components, reduce dependencies on external vendors and prevent their maintenance costs from affecting every licence.
An application does not need to include every possible integration to be useful. Above all, it needs to meet the requirements for which it was created.
