Safety mobile application does not only concern passwords or payments: any file delivered in an app can be extracted before a launch. In 2026, assets related to Tesla Optimus Gen 3 were spotted in an Android package, reminding us that a disabled but embedded feature often remains visible to anyone who knows how to analyze the application.
Mobile application security: why can a hidden feature leak?
Mobile application security must treat the published package on App Store or Google Play as a public document. An Android APK, an Android App Bundle, or an iOS IPA contains compiled code and resources, and these elements can be inspected before the feature is opened to users.
A mobile application is distributed software: once downloaded, part of its content lives on the customer’s phone. Images, JSON files (structured data), interface labels, 3D models, sounds, or screens prepared for a future campaign can therefore end up in the hands of competitors, journalists, security researchers, or simply curious people.
The Tesla Optimus Gen 3 case illustrates this well. On September 23, 2026, Not a Tesla App, Drive Tesla Canada, Humanoids Daily, and Tesla Briefing rapporté the presence of images or renders related to Optimus Gen 3 in the Tesla Android application, without these files constituting an official announcement from Tesla. Humanoids Daily states that it verified nine PNG files under assets/mock/ in Tesla Android 4.61.0-4607, with three names containing _gen3.
The trap is common: a team prepares a version, adds the screens for a new feature, disables the entry in the menu, then publishes. On the interface side, nothing appears. On the package side, the resources are already there. In the projects we carry out, we often see this confusion between “not visible in the app” and “not delivered in the app.” These are two very different realities.
Which files in a mobile application expose the most risk?
The riskiest files in a mobile application are business resources, technical secrets, and markers of future features. In 2026, OWASP MASWE-0004 classifies sensitive data hardcoded in the package as a mobile security weakness, especially lorsque this data should remain on the server side.
A “secret” is information that gives access to a service: API key, identifier, token, private URL, or technical password. The OWASP Mobile Application Security Cheat Sheet states in 2026: “Do not hardcode credentials in the mobile app.” In other words, do not put credentials directly into the application code.
The risk is not only hacking. For an executive, the leak can affect strategy: name of an unannounced product, visual of a new range, targeted countries, upcoming prices, wording of a campaign, partnership screen, or a feature that is encore unstable.
Before publication, teams must check the following categories of files:
- images, videos, sounds, 3D models, and demonstration files related to a future sortie;
- translation strings containing product names, offers, countries, or non-public prices;
- configuration files, API endpoints (service addresses), and test environments;
- API keys, tokens, third-party service identifiers, and embedded certificates;
- screens or components disabled only by an invisible button in the interface.
At this budget, it is better to plan a short but systematic package review rather than a heavy audit carried out too late. For an SMB, this step generally costs less than an emergency redesign after publication, especially if the product launch depends on a marketing or industrial schedule.
How can you avoid including sensitive resources in an APK or an IPA?
Avoiding the inclusion of sensitive resources in an Android APK or an iOS IPA relies on three practices: do not ship what is not public, remove unused resources, and move sensitive decisions to the server side. Android documents in 2026 the removal of unused resources via Gradle with shrinkResources.
An APK is the historical Android installation file; an Android App Bundle is the format used to generate optimized variants depending on devices. According to Android documentation in 2026, bundles include compiled code and resources. If a confidential image enters this flow, it can resorface in an installable version.
The first rule is organizational: a code branch intended for publication must contain only what can become public. Honestly, putting confidential visuals in the app “just in case” is rarely worthwhile. The gain of a few days before launch does not outweigh the risk of a leak.
The second rule is technical: enable cleanup mechanisms when the framework allows it. On Android, shrinkResources can help remove unused resources, but it is not a magic protection. A file referenced by mistake, kept by a build rule, or loaded dynamically may still remain present.
The third rule concerns product segmentation. If a feature is planned for two months from now, its sensitive assets can be served later from an API (communication interface between systems), a CDN (content delivery network) like Cloudflare, or private storage, with access control. The mobile app then displays alors what the server autorrizes, at the desired time.
This choice must be framed from the specifications stage. A dedicated article on the specifications for a business application helps precisely formalize the data, screens, and access rights before development begins.
Are feature flags enough to protect a mobile launch?
Feature flags are not enough to protect a mobile launch if the confidential code and resources are already in the application. A feature flag is a feature toggle, often controlled remotely, that activates or deactivates a behavorr without a new version being published on the stores.
Firebase Remote Config, documented by Google in 2026, allows changing the behavorr of an application or a server via parameters used as feature flags, without requiring users to download an update. Google also documents server-side support for Remote Config with Firebase Admin Node.js SDK v12.1.0+.
This is practical for managing a gradual rollout, testing a user flow, or quickly disabling an unstable option. But a client-side flag does not hide a delivered file. If the button is disabled and the images are in the package, the sensitive information remains extractable.
The right trade-off depends on the level of confidentiality. For a minor interface improvement, a client-side feature flag is often enough. For an unannounced product, a strategic partnership, or a pricing offer, the decision and the content must remain on the server side until launch.
On the agency side, the reflex is to separate “experience flags” from “confidentiality flags.” The former control ergonomics. The latter prevent even the delivery of sensitive elements until business, legal, or marketing approval has been given.
| Control | Protects against | Main boundary | Indicative effort 2026 |
|---|---|---|---|
| Client-side feature flag | Visible activation of a feature | Does not hide embedded resources | 0,5 to 2 days excl. tax depending on integration |
| Server-side Remote Config | Controlled activation without store update | Requires a clean API architecture | 1 to 4 days excl. tax depending on the project |
| Removal of unused resources | Files forgotten in the Android build | Does not remove every referenced encore file | 0,5 to 1 day excl. tax |
| APK/IPA analysis with MobSF | Secrets, permissions, files, and suspicious comportements | Produces alerts to be reviewed by a human | 1 to 3 days excl. tax for CI setup |
| Manual release review | Business leaks and packaging errors | Depends on an up-to-date checklist | 0.5 to 2 business days per sensitive version |
How much do pre-publication checks for a mobile app cost?
In France, mobile application security checks before publication generally cost from a few hundred euros to several thousand euros before tax in 2026, depending on the scope. A targeted review of an APK or IPA costs less than a full audit with dynamic testing, CI and correction of the code.
For an SMB project, expect around €600 to €1,500 before tax for a one-time verification of a sensitive build, depending on the providers and the volume of files. A more structured audit, with static analysis, secret review, CI (continuous integration) configuration, and reporting, is more in the range of €2,000 to €6,000 before tax in 2026.
The timeline is often more important than the price. A light review can be done in 24 to 72 hours if the package is ready and the checklist is clear. A proper setup in the release pipeline usually takes one to two weeks, because false positives have to be handled, the rules documented, and the team torined.
This cost should be compared with the cost of a leak: disrupted product announcement, broken embargo, competitor informed, damaged trust, or rushed withdrawal of a version. For an app published on the stores, the guide on publishing on the App Store and Google Play also reminds us that validation timelines can complicate an urgent correction.
The development schedule also matters. If security is added the day before submission, it becomes a bottleneck. If it is built into the schedule, it becomes a normal step, like functional testing. To estimate this margin, you can compare these checks with the timelines presented in a realistic mobile app development schedule.
What tools should be used to detect a leak before going live?
The most useful detection tools before going live combine static analysis, package inspection, and business rules. MobSF, or Mobile Security Framework, is documented in 2026 as a static and dynamic analysis tool for Android and iOS, especially for APK and IPA binaries.
MobSF can identify excessive permissions, URLs, sensitive strings, risky libraries, or suspicious behavors. OWASP also documents MobSF static analysis in 2026 as a mobile security testing tool for Android. It is a good foundation, but not the final judge.
A tool does not always know that a file robot_gen3.png, a campaign name, or an internal price is confidential. Mobile application security therefore requires a business checklist: product names, codenames, non-public visuals, launch countries, partners, offers, legal content pending approval.
Best practice is to integrate these checks into the CI, that is, the pipeline that automatically builds and verifies the application. With each release candidate (a version candidate for publication), the package is analyzed, then a person decides on the alerts. For topics close to embedded AI or low latency, the same trade-offs between client and server can be found in AI architectures integrated into applications.
Finally, keep one simple rule: everything that cormes from the server and enters the application must be something you can stand behind publicly. If the answer is no, the file probably does not belong in the build.
What checklist should be applied before each sensitive release?
A sensitive mobile app release should be validated with a short checklist covering resources, secrets, flags, APIs, access rights, and generated packages. In 2026, this discipline mainly reduces publishing errors, which remain a frequent cause of exposure before launch.
Start by naming the confidentiality level of the version: standard, campaign, partnership, unannounced product, reinforced security. The level changes the approval workflow. A bug fix does not require the same level of review as a strategic launch.
Then check the actual contents of the published file, not just the app screen. Unzip it, inspect it, search for sensitive names, run a tool like MobSF, check the translations, and compare it with the list of authorized items. Simple, but effective.
Add a business owner to this review. The developer spots an API key, but the product director spots an unannounced product line name. Mobile application security is not just a technical matter; it is also about protecting the commercial timeline.
Defining this type of project upfront avoids most unpleasant surprises. An outside perspective often helps separate what can be delivered in the application, what must remain server-side, and what must wait until the exact launch day.
FAQ on leaks and mobile application security
Can an Android APK really be opened by a third party?
An Android APK can be downloaded, extracted, and analyzed using accessible tools. Resources, configuration files, and text strings can often be inspected, even if compiled code requires more skills.
Does Apple iOS better protect an application's resources?
An iOS application limits certain uses through the Apple ecosystem, but an IPA file remains a package containing code and resources. Sensitive visuals, texts, or configurations should not be considered secret just because they are distributed on iPhone.
Should all unused assets be deleted before publishing?
Unused assets must be removed before publication if they reveal business, product, or security information. Automated mechanisms help, but a manual review remains necessary for sensitive launches.
Is an API key in a mobile application always dangerous?
An API key in a mobile app becomes dangerous if it grants access to data, quotas, or actions without server-side controls. In 2026, OWASP recommends keeping static secrets on the server side via middleware or an API proxy whenever possible.