The Evolution of Cross-Platform Development With Xamarin

Just like the era in our own evolutionary history when quadrupedal mammals made the leap to bipedal, Xamarin.Forms marks an important milestone for software builders, architects and designers. It offers the ability to develop and design an app that runs on three different platforms with the same C# code base and user interface, massive code reuse and platform-specific customization, if desired.

I decided to participate in this important phase in software’s maturation. I built a Xamarin wellness app. Captured here, I’ve included my initial reactions to the Xamarin pros and cons I identified. (Full disclosure: I lead MentorMate’s Strategic Consulting team and brought solution architecture and engineering experience to my effort.)

Weighing the Xamarin pros and cons: What I built

I’ve spent a majority of my time recently working in the healthcare space. Since biometrics have been top-of-mind, it made sense to use wellness as the inspiration for my build. I created a health dashboard allowing the user to input and track measurements including cholesterol, waist-hip ratio, BMI and heart rate over time.

All metrics tracked in the dashboard can be viewed in a three-by-three grid. The user selects the desired metric (Ex. cholesterol) that they would like to track. He is then taken to another screen.

When the user is looking at the home screen, color signals alert them when measurements need to be updated. Recently entered metrics display as bright green, over time this color fades to black. Once the metric reaches black, it should be taken again. The dashboard also shows the history of measurements taken by a user. Future iterations include making this more graphical.

Pro/Con: Building on Android was more user-friendly than iOS.

I began building my Xamarin.Forms app and testing on Android. Bear in mind, this healthcare dashboard was the first piece of technology I (personally) built for Android. My career has been more focused building in Objective-C for iOS. I installed Visual Studio on my Windows machine and used that to build my project. Since the Android emulators were painfully slow, the path of least resistance was to view work and validate functionality on an actual Android phone since phone debugging on Windows is only supported for Android devices.

The process validating the dashboard on iOS required a little more accommodation, constraining my work environment. While I continued building on my Windows machine, the iPhone I used to debug needed to be cabled to a Mac (or the build host). This Mac was then connected to the same Wi-Fi network as my build computer. Why? Visual Studio IDE must reach out to the Mac during certain processes including debugging or designing. The connection between Visual Studio and the Mac OS is made through a SSH connection accessing Apple’s compiler, code signing tools and certificates.

Minor details separate my experience testing the application on iOS and Android. When debugging on iOS, I was limited to one room as my build host was a desktop. With Android, I was free to roam, and it was faster to debug. I could make updates, then turn around quickly and run it again, so I have opted to do my initial development and testing on Android. Of the Xamarin pros and cons I identified, this was the most meaningful to my work experience.

Pro: Prebuilt Xamarin.Forms layouts offer added functionality.

I built the health dashboard using the pre-defined layouts in Xamarin.Forms using common user interface code. Of the pre-defined layouts, I used the stack layout with the grid layout nested within. I did this by creating my own layout classes and deriving the functionality I sought. I also built a shared implementation of a “cell” within the grid that is associated with a specific “measurement”, so the majority of the code in the cell (including evaluating the measurement against its limits and determining the color coding) is also reused between the cells.

Essentially, Xamarin.Forms enabled me to write code that says, “Give me a new stack layout in the first cell, and put a grid layout in the second cell.” This process is incredibly intuitive for developers who know how to write and read code. Though as a note, it’s OK to code your layout as long as you understand you must then change your code to change the layout. Unless you have another motive like using a XAML designer, I would probably stick to coding the screen layouts.

After building out a rough version of the app, imagine my surprise when I fired it up on Android the orientation of the app flipped too. The Xamarin layouts are built and designed to be responsive and fill the screen at the proper resolution. I, myself, did no work to support the orientation change. For teams building with Xamarin, the accumulation of these features is hours of time savings pocketed. I was even more floored when I got it to run on an iOS device for the first time and it all just worked — everything!

Pro/Con: Work within the design limitations Model-View-ViewModel offers.

While I didn’t work with a designer on my test project, there’s a classic tension that arises between designers and developers — designers delivering UX/UI that can’t be implemented technically, and developers pushing back and failing to creatively realize the experience. Aligning developers and designers is critical to achieving elegant UI with Xamarin.Forms.

When designers approach creating a mobile experience with Xamarin.Forms, they must begin by thinking about the common denominator, as they are designing the experience as it will be represented on iOS, Android and Windows phones. They must ask, “What elements and functionality are consistent across all experiences? How can this be cleanly represented?”

It’s a more disciplined process requiring deep knowledge of interaction patterns across all three operating systems. Design decisions must be based on universal patterns rather than interactions that might delight an Android user and confuse an iOS user.

While I didn’t focus on UX when building my sample app, designing the layout and flow within Xamarin.Forms are where the real benefits of code reuse becomes clear — up to 80-90%. Though some platform-specific behavior can be defined using Xamarin.Forms with DependencyService.

Rather than leading with UX/UI, understand the limitations of the platform and craft beautifully within those bounds. Granted, the concessions made to achieve cost savings with Xamarin.Forms will not make or break the experience. It’s much like considering the control of nonresponsive design compared to the slightly less control responsive design affords creative teams. Though (worth noting) if more specificity is needed, developers can build a custom renderer.

6 Xamarin.Forms design principles

Spoiler alert, I asked a designer. Here are the best practices to frame experience and aesthetics creation for Xamarin:

• 1. Strive to create a universal understanding.
• 2. Study the limitations of each platform.
• 3. Think across platforms. Just like your development will be.
• 4. Synthesize first. Design second.
• 5. Don’t assume functionality across platforms is apples to apples in applying the C# to the SDK.
• 6. Avoid the temptation to abandon familiar interaction patterns. Why? Xamarin uses native controls where possible so the iOS and Android “text edit” controls look and work like default controls for each respective OS.

Pro/Con: Give your users something to look at while the app loads.

We’ll end with a consideration for something that should come at the very beginning — wait time. After completing my dashboard, I noticed it was a little slower to load as it was retrieving results from the server for display. Had I added a graphic or animation that displayed during the load process, the lag may have appeared less noticeable. It’s a minor learning about the Xamarin pros and cons, but every detail counts.