How to Learn Cross-Platform Mobile Tools
By: Ethan Campbell
Step 1: Learn Native
Platform-Specific APIs and Architectural Patterns
When using a cross-platform tool to create iOS and Android screens, the controls you create are actually abstract controls which the cross-platform tools will map to the appropriate controls in iOS and Android. In other words, creating a Button in Xamarin is creating a button object which will compile into a native UIButton object in iOS and a native Button object in Android. The common properties to both of these native objects will be available in the abstract Xamarin button object. However, if you need to dive deeper into these controls to fine-tune their appearance (i.e. add drop shadow, custom corners, custom borders, custom events…etc.) you will need to write native code to achieve your objectives. While you’ll still be using your cross-platform language, the interaction with the native object requires knowledge of the native controls’ properties and methods.
It’s also worth noting that if you need to split out into native mode for large portions of your app there may be some discomfort in working in a different architectural pattern. Native iOS follows the MVC pattern, which will be familiar to a NativeScript + Angular developer. However, if you’re using ReactNative (CQRS) or Xamarin.Forms (MVVM), you may need to acclimate to the environment. Native Android is slightly more flexible as it can be implemented to follow either the MVP or MVVM pattern.
The native development community has made tens of thousands of open-source libraries available via dependency managers like Cocoapods and Maven. These libraries provide drop-in solutions for things like calendar picker controls, charts/graphs, image caching, and adding a parallax effect to controls, just to name a few. Hand-crafting this type of functionality would otherwise add days/weeks/months to a project but instead is accomplished in mere minutes/hours. Cross-platform toolsets thankfully can access this deep repository, but each has its own mechanism for importing and building a “bridge” into these native libraries. However, since they are native libraries, the open source code itself and all code samples for usage are written in the native languages (Kotlin, Java, Objective-C, or Swift.) Additionally, in the case of React Native, the “bridge” code itself must be written in Objective-C, so at the very least the price of admission here is a cursory knowledge of the native languages.
Speaking as veteran mobile developer, I can tell you that one of the more painful lessons you learn early on is proper application signing. If you are unfamiliar with this process, please familiarize yourself with iOS and Android code signing techniques. Failure to be prepared when it comes time for UAT and production deployment will result in Googling the following questions: “What is a .jks file? I already created a certificate, why is it bothering me about a provisioning profile? What signing identity? I forgot my KeyStore password what do I do?” These are lessons unavoidable for the native and cross-platform developer alike.
We also recommend learning the basics of how the iOS and Android compilers work under the covers. Of all the areas we’ve covered so far, compilation and linking issues have the potential to cause the largest amount of frustration because triaging the issue can be difficult due to the many different possible causes. You’re effectively trying to figure out the human-equivalent to fever and malaise. It could be as benign as a simple virus, but maybe it’s meningitis. Just as a physician knows how to efficiently investigate and make the appropriate diagnosis, the seasoned native mobile developer learns to recognize the subtle details in the error message and make the appropriate adjustments to the iOS Build Settings, Phases, and/or build scripts. Or in Android, maybe a simple adjustment to your gradle build script will do.
Here’s a common example. A Google search for how to persist data to a device using cross-platform tools yields many helpful results. Most of these involve reading/writing key-value pairs to SharedPreferences in Android while leveraging UserDefaults in iOS. This is a great place for saving things like user preferences, but a bad idea for saving username, password, access token, or any kind of PHI (Protected Health Information). Unfortunately, this is commonly what the developer is wanting to persist in the first place! This data is easily hackable should the phone be lost/stolen. In fact, local storage in an iOS app is stored unencrypted and easily pulled off the device by making a backup in iTunes and performing a simple dissection. A proper understanding of the native mobile security model would reveal that the user should store these types of credentials in the Keychain for iOS and KeyStore for Android.
About Ethan Campbell
Ethan is a Sr Software Engineer for Aptera Software, specializing in mobile technologies. He has been developing enterprise solutions since 2000. As an avid mobile development enthusiast, he loves to study new mobile technologies, languages and industry trends.