DEV Community: Thomas Smolders

We worked with Xamarin for almost three years, this is what we learned

Thomas Smolders — Wed, 06 Feb 2019 18:16:10 +0000

At In The Pocket, we used to be mostly focused on native development. However, we recognized the benefits of working with cross-platform frameworks: a single code base leads to a better management of feature parity and maintenance, while equally decreasing client costs.

Xamarin became open source and free for community developers in a short period after its takeover by Microsoft. These (in our view) positive changes led us to the point where we decided to investigate Xamarin as a cross-platform solution for our client’s projects.

After working for almost three years with Xamarin, we want to share our experiences and techniques with the different types of Xamarin projects we have been working on.

Xamarin Forms: everything shared

If we’re talking about Xamarin, we need to clarify that there are multiple approaches to using Xamarin. You can use Xamarin Native, which is the more traditional approach. With this approach, we can share the business logic of an application with other platforms, but the UI layer still needs to be created separately for each platform. The second approach is called Xamarin Forms: this builds on top of the traditional approach, but adds some abstractions to commonly used UI components. This allows us to write our UI once for several platforms.

We were quickly sold on the idea of Xamarin Forms, as it implies sharing both the business logic and the UI of an application. While shared business logic is already a big advantage, we used to spend a lot of time on creating separate views for each platform. The idea of only having to do this once was really appealing, so we decided to give Xamarin Forms a shot.

Initially, this seemed to be a good approach. As we were indeed sharing both business logic and views, there was no longer a typical Android developer and iOS developer: we were all working on the same code instead of in separate silos, which made for very tight collaboration.

However, as projects advanced, we encountered some unforeseen limitations. Firstly, at In The Pocket, we pride ourselves on delivering pixel-perfect designs. We want our projects to look perfect and perform without any hiccups. With Xamarin Forms, you can quickly create a basic-looking UI, but as soon as you want to start customizing, you need to turn to custom renderers. While our designers made compromises to make the views less complex, we still needed a custom renderer for many of our views. This way of working was slowing us down considerably, and we were creating once again separate views per platform.

Another issue was the performance: while it was acceptable on iOS, we noticed that our Android builds felt slow, especially at the startup. Also the rendering of XAML pages turned out to be a bottleneck, which caused hiccups during navigation. While we made some changes to improve the performance, in the end we were still not happy about the smoothness of the application.

I think the main issue we had with Xamarin Forms, was that it just wasn’t up to par with truly native applications. We were all native developers until we started with Xamarin, and where we used to have the means to customize virtually anything and have native performance, Xamarin Forms did limit us in both development and performance.

I’d like to note that this was the experience we had with the framework. I’m certain many other teams will find Xamarin Forms the perfect framework for their applications, and they’re probably right. For In The Pocket, Xamarin Forms wasn’t the perfect fit as we felt hampered by some of its limitations.

Xamarin Native: a better fit

With our enthusiasm tempered by our struggles with Forms, we decided to create our next Xamarin projects with the Xamarin Native approach. Since we still had a healthy mix of Xamarin experienced Android and iOS developers in our team, it was no problem to switch to this approach.

Very quickly it became clear that this way of working was a better fit for our needs. While the business logic was still shared, we now had the ability to customize the UI in a more native way, like we were used to. The performance was also (nearly) the same as on native platforms, and we could still share much of the code base because of the many third-party libraries out there. These help with sharing some platform-specific logic components, such as a database or looking up device info.

Another benefit for us specifically, is that we can take advantage of the native experience that is already present in our teams. Since our views are still handled natively (albeit in a different language), we can spar with the other native developers about features and how to implement them.

In order to develop a Xamarin Native application, we did need to change the way we approached features. While we could just assign any developer to a Xamarin Forms story, we now had to expose the public properties of the viewmodel before the other platform could plug in their views. Currently, we let one platform take the lead on a feature, creating the views and viewmodels first, while letting the second platform plug in after the first platform had finished its coding, or at least its viewmodel. We found out that this approach causes the least conflicts while developing simultaneously.

Communication is key in Xamarin projects: a change in a viewmodel might have consequences in both platforms. Changes that impact the native implementations need to be documented on the stories, and we communicate it explicitly to the involved developer as well. By working closely together, we have become a better team, and better developers.

Our approach on MVVM: MvvmCross

Currently, we are using MvvmCross as our framework to share business, communication and presentation logic between the platforms. This framework has been around for a while, and it has definitively proven its value over the years. It’s also very well maintained, with regular new releases, and always extending documentation. It’s built from the ground up to be extensible and adaptable. This enables us to quickly build apps on the base implementation - while allowing us full flexibility in tweaking the UI and the presentation.

Of course there are other interesting frameworks out there. We continue to keep an open mind to other frameworks, and since we like reactive programming, we probably will give ReactiveUI a go as well.

Native bindings: an alternative approach

One of our Xamarin projects involved another approach to Xamarin development: working with native bindings.

All of the UI components and the UI logic were built in a native project, that was compiled to a native library. These libraries were then consumed in a Xamarin Bindings project, where we could connect the UI components to the Xamarin environment.

This allowed us to quickly upscale the team with developers that had no experience in Xamarin. For them, it was just another native project, where they could work within their competence. It was then up to the Xamarin developers to connect the libraries with the Xamarin project.

This approach also gave us a lot a freedom: we could use all native components and libraries at your disposal internally in the library, and you didn’t need to worry about binding these libraries to Xamarin, since they were not exposed to the Xamarin component.

However, this approach was not without its flaws. The connection between the native component and Xamarin component was done through abstract classes that were created in the native component. These were implemented afterwards in the Xamarin component (viewmodels for Android, controllers for iOS). This meant that we had to create separate projects, so code reuse was not feasible.

Another obstacle was the debugging of the UI components in combination with the Xamarin project. We created a mock project to quickly test all available native components and views. However, when combined with the Xamarin component, we sometimes experienced issues that weren't reproducible in the mock project. Debugging these issues proved to be very hard, as breakpoints weren't possible in the Xamarin Bindings projects and as we thus were limited to using logs.

Summary

At In The Pocket, we’ve worked with the different variants of Xamarin. While we recognize the benefits of Xamarin Forms, it’s been a bumpy road for us as it just wasn’t a good fit, due to limitations in customizability and performance issues. The Xamarin Native approach is a lot more to our liking, especially in combination with a framework like MvvmCross. It allows us to share our code base, while still being able to deliver a pixel-perfect design, with a near-native performance.

I interviewed my coworkers (a.o. our Technology Manager) about Flutter 1.0

Thomas Smolders — Thu, 13 Dec 2018 16:11:34 +0000

Last Tuesday, Google launched the first stable release of Flutter, its open source, cross-platform UI toolkit and SDK. Here at In The Pocket we watched the livestream of the launch with some beers, pizzas and tons of enthusiasm. Before and after the presentation I (Thomas, a Flutter rookie) had met up with Bram (our Technology Manager) and Yves (our Xamarin Lead and avid Flutter enthousiast).

If I have understood correctly, Flutter will ensure that we no longer have to develop an Android and iOS application separately, but we just have to build one? Or am I too naïve?

That is of course the goal of every cross-platform framework. Both Xamarin and React Native want to achieve the same goal, but important to keep in mind is that none of these frameworks are the silver bullet. You can’t expect to just choose 1 framework and be able to create all possible apps with it. We still look at each app’s requirements individually, and decide which approach (native or one of the cross platform frameworks) is best suited to address its specific requirements. Flutter offers us yet another, and dare we say, very powerful means to create beautiful apps using a single code base.

Why did Google launch this Toolkit? The first thing that comes to my mind is that there were several applications that were first released on iOS and only months later on Android - a scenario Google would prefer to avoid?

That might be one of the reasons indeed, but as we’ve seen in the keynote, Flutter doesn’t limit itself to just Android and iOS in fact. With a bit of work, developers will be able to create desktop applications, as well as web applications with Flutter, and most likely even Fuchsia apps in the future. We think that with Flutter, Google wants to create a universal way to develop apps for all kinds of platforms, with an easy to use, easy to extend toolkit. Of course, Flutter is a Google product, so this is another way to bind developers to the Google ecosystem, and let them use more Google products along the way (which is not necessarily a bad thing).

Does this change anything for us?

We think it probably will. Flutter has been in beta since earlier this year and we’ve been experimenting with it along the way, but there was always some hesitation from other developers because of that ‘beta’ label, which is considered as unfit for production. And as we’ve seen in the past, Google might start on a product, but halt development before an official version is released. Now that this first version is officially out of the box, more people will most likely start experimenting with this.

With the 1.0 release, it is now also “safe” to use Flutter for client applications. While the benefits are clear, it’s still risky to create a long-term product, based on a beta framework. With this stable release, we can build up some more experience with it, and let our clients reap the benefits.

Flutter isn’t the first attempt to create something cross-platform as you’ve mentioned, there’s React Native, Xamarin and others, why would Flutter be different?

For this, we need to have a look at the different aspects of each framework. In native Xamarin, which is C#, the focus is on sharing the business logic of the mobile applications. Xamarin Forms adds a layer on top of this, so the UI can be shared as well, but it still renders to native elements. Xamarin is a great way to have cross-platforms apps, where you have the choice of still having a very custom layout by using native Xamarin, or go for a more basic UI with Xamarin Forms, if code sharing is more important.

React Native lets you share both business logic and UI. The business logic is written once for each platform and is executed on a different thread by using the same javascript engine that is used by the browser running on your phone. React renders to native UI elements over a JavaScript bridge. The end result will be an app with a native look and feel. As the language is the one from the web, and as the business logic (global state management, API calls, etc.) can also easily be shared with the accompanied web application, React Native is appealing for web developers and can certainly be a perfect fit for certain products.

Each of those frameworks has some drawbacks of course, be it in performance on some platforms, disappointing tools, or hard to customize. The Flutter team has tried to identify and improve all of these shortcomings. Their main focus is letting developers deliver beautiful, smooth apps at a high pace, with an awesome development experience. The main difference between Flutter and React Native (or Xamarin Forms), is that the UI is not rendered to native UI elements but by the Skia rendering engine. This means that your UI will look exactly the same no matter the platform. This leads to a faster development cycle for features, since you only have to create a single layout. If needed, Flutter still allows to have views that look native to each platform, all from the same codebase, within the same environment.

For a more in depth look at what the Flutter architecture looks like, check out the architecture overview that the Flutter team has made available here.

What makes Flutter also stand out are its basic elements, called widgets. In fact, everything in Flutter is a widget, not only your UI elements. In the end your entire application is just a tree of widgets. There are widgets responsible for layout, animation, positioning but also for building other widgets for example. While you can create your own widgets of course, Flutter already provides you with a large set of pre-built widgets to use. This way, you can quickly develop a good-looking application, targeting android devices with the Material Design widgets, or iOS devices with the Cupertino-style widgets.

Were there announcements during the keynote that you didn’t expect?

The most unexpected part, was the way that the team presented Flutter as a portable UI toolkit. Also there were already some steps made by the community to make Flutter work on more than just Android and iOS, but to see that initiative presented on the main stage of the event is a game changer, they’re even taking it one step further and including web applications.

Other than that, there were some interesting announcements. The Flare tool will be a welcome asset. It allows the designer to create complex animations, that can be easily imported in a Flutter application and manipulated in code. This makes us think a lot of Lottie animations, so this is a very welcome addition.

We were also pleasantly surprised with the announcement of the partnership with Square. They have already delivered some very useful libraries for other languages, so also for Flutter they will be a great asset for sure. Less surprising was the partnership with Nevercode. While we haven’t used it ourselves yet, there are quite a few articles relating to Nevercode and Flutter, so this was a logical evolution.

One of the biggest drawbacks of Flutter that we saw, was that there was no support yet for integrated webviews or Google Maps. With the plugins that were released just a few days ago, they also got rid of that hurdle, so for us, there’s really no reason left not to start using Flutter.

Why did they go with Dart as a programming language?

This is a question that is asked often. There is also a section about this on their FAQ page. In short, Dart just satisfied all of their needs. In practice, Dart is not that different of any other modern object-oriented language. If you know Swift, Kotlin, or Javascript, you’ll get to know Dart in no time. Dart also allows the code to be compiled in different ways. That’s how Flutter can both support JIT (just-in-time) compilation needed for the stateful hot reload, and AOT (ahead-of-time) compilation for more performant release builds.

No, Flutter will probably not be the Holy Grail as some people might claim, but it is definitely a framework to keep an eye on. Now that Flutter is not in beta anymore, it can mature and we can build up more experience with it. As Bram and Yves said: there’s really no reason left not to start using Flutter!