Protecting Localized Xamarin Forms Applications

June 4, 2020 574 Views Johnny

Localization is often a key ingredient when building Xamarin Forms applications with a global audience. There are different ways to approach app localization, but most of these leverage the built-in tools provided by the .NET Framework. These include RESX files to configure localized strings and an auto-generated resource class which provides strongly-typed access to the string translation at runtime. This mechanism has been available since .NET 1.1, and is used for localization of WinForm, WPF, ASP.NET, and Xamarin applications.

Dotfuscator can usually process localized apps without issue. We’ve built smarts into Dotfuscator to handle resource classes and seamlessly process satellite assemblies. However, recently we worked with a customer for whom this was not the case. After obfuscation, their localized Xamarin Forms application remained in the default language (English), regardless of the OS language setting. In this post, I’ll describe how this happened, and how to properly configure Dotfuscator for this scenario.

Please consider the following example. This basic Xamarin Forms app displays a flag image for the country, as well as a few localized strings for the UI controls.

The default locale is English (en-US), with the ability to change different languages based on OS language preferences. The localization strings are configured via RESX files, along with an auto-generated “AppResources” class file to access the translated strings at runtime:

I’ve protected this app with the default Dotfuscator settings. After doing so, when I change the default OS to a different language, notice the image (flag) will correctly update, but the text strings remain in the default English:

This happened because Dotfuscator renamed the auto-generated AppResources class. Normally, Dotfuscator’s Xaml Analysis automatically matches the Xaml to the corresponding class name. However, in this case, the compiled Xaml still looks for the original AppResources class name when displaying the localized strings.

In order to prevent the UI from displaying the wrong localized strings, I open the DotfuscatorConfig.xml in the Dotfuscator Professional Config Editor, and exclude the auto-generated AppResources class from the Rename transform:

After configuring this rename exclusion and re-deploying the APK, the localized strings are properly displayed:

In most instances, Dotfuscator handles app localization without issue. But If you notice that the strings do not follow the OS language settings after protecting your localized Xamarin Forms app, you may need to exclude the auto-generated resource class from renaming.

The full example can be downloaded here.

This example is based on the ResX Localization demo found here.

If you have any feedback on this topic, or other topics you would like us to discuss in the Support Corner, please feel free to contact us at support [at] preemptive [dot] com.

Latest Blog Posts

Mobile Application Protection Increases Profits

Application security can often be viewed by development teams as a time-consuming barrier to finishing a project. In a world where "time equals money", the rush to ship functional applications can overshadow the need to ensure those applications are secure. It is true --- features are what sell software and fixing bugs retains customers and loyalty. Both actions can be directly linked to revenue and profitability. So, what effect does an investment in application security have on a company's bottom line?

The coronavirus crisis is changing human behavior. From the persistent need for social distancing to the potentially permanent adoption of work-from-home mandates, the “new normal” is uncharted territory.

But the growing priority of public health also has knock-on effects in other fields, such as credit and debit payments. While the United Stated has historically lagged behind other countries such as Canada, the United Kingdom and Australia when it comes to the adoption of contactless card transactions, the demand for physical distance now trumps the functional familiarity of swipe-and-signature or chip-and-PIN interactions.

Facilitating “no contact normalcy”, the PCI Security Standards Council (PCI SSC) includes guidance for both commercial deployments and software applications to help solve potential payment security gaps. Here’s what you need to know.

In the months since we released the Dotfuscator 6 beta, we’ve been hard at work finishing the feature set, fixing issues, and putting on the final touches in preparation for the full release. Now, we are happy to announce the full availability of Dotfuscator 6!

It’s official. COVID-19, more commonly known as the Coronavirus, has been declared a global pandemic by the World Health Organization (WHO) with hundreds of thousands of cases worldwide. In the United States, restrictions are ramping up as case numbers soar — New York governor Andrew Cuomo has ordered all nonessential workers to stay home, and my own state’s governor Mike DeWine has issued a statewide shelter-in-place order.

Along with disruptions to daily life, the expanding impact of COVID-19 has forced businesses to rapidly pivot and adopt remote-work models — even if they have no experience with mobile connections and on-demand collaboration. The result is a surge in remote everything, from team chats to primary school education to project management and even healthcare delivery. See my previous blog on our customer commitment during the age of Coronavirus.

And while efforts to bridge the digital divide are having a positive impact for both workplace productivity and the mental health of those in isolation, there’s a potential pitfall: Cybersecurity. As noted by CNBC, there’s already been a significant uptick in scam and phishing emails — but what happens if malicious actors breach critical apps and services?

Protecting Localized Xamarin Forms Applications

Mobile Application Protection Increases Profits

No Contact Normal: Solving the Payment Security Gap