02-21-2017, Mobile Development
by Antoni Zolciak
Here's Why We Decided to Do Xamarin Mobile App Development
At In’saneLab, we have always been close to mobile development. As true hipsters of programming, we did Responsive Web Design before it became widely known.
What’s true, though, is that we were more focused on web than mobile. Mostly, we did ASP.NET (among others) and desktop projects with WPF. That brought us closer to both .NET and the idea of a native app. But, candidly speaking, we were not focused on the latter.
“It wasn’t the business model we had in mind. The whole philosophy of In’saneLab is to work with just a few technologies and to be exceptionally good at them,” says Slawomir Grycz, our CEO, Xamarin and .NET team leader.
“Then, February 2016 happened. That’s when Microsoft announced plans to acquire Xamarin. The decision influenced our company to a great extent. We saw it as a clear sign to enter the mobile development market. Microsoft kept on investing into mobile and open source with .NET Core, Visual Studio for Mac, or SQL Server. That was a clear statement of how important Xamarin became for the guys from Redmond.”
Developing in Xamarin is up to 66% cheaper than the alternative
Mobile application development is different with Xamarin. From a technical standpoint it’s an environment consisting of:
- .NET (C#)
- Native SDK libraries wrapped in .NET
Native iOS, Android, and Windows UIs share business logic, data access, and network communication.
Then, you build on top of it.
Let’s say you are a bank. Now, let’s assume you want to build apps for iOS, Android, and Windows Phone. Doing it the old way, you would have to write and design three separate applications from the ground up.
With Xamarin, you build a base for those three. Depending on how much your apps will rely on the device’s physical capabilities such as file system, geolocalization, or cache, you can save between 40% and 66% of your budget.
“You can literally spend up to 66% less money on maintaining and updating an app,” Slawomir says. “It’s more difficult with the building process – but still, I’d estimate savings of over 50% compared to the traditional way.”
Save over 50% on building and up to 66% on maintaining your apps
“In the future, we will be able to reuse more than 90% of the code with Xamarin.Forms,” he adds.
However, Forms aren’t there yet. They’re tempting, sure, but not mature enough.
Creating and publishing applications are just the first steps. You also have to maintain and update them afterwards, and this is where Xamarin shows its true potential. You can literally cut as much as 66% of the cost.
Okay, so where’s the catch?
Truthfully, implementing Xamarin development into our company wasn’t that grand of an option at first. It would cost $999 per developer, per device platform, for Xamarin business subscription.
Now, it’s open-sourced.
“That was literally the thing for us”, Slawomir recalls. “I saw it as a perfect way of having a native mobile application development at In’saneLab. Xamarin allowed us to keep the number of technologies we used on practically the same level – and to further grow our skills within the chosen few.”
Backed by ongoing research, we decided to incorporate Xamarin development into our services. We don’t use Forms, though. Not yet.
“Instead of Xamarin.Forms, we kept the native front-ends approach,” our Xamarin team explains. “It takes more time and effort to develop, but the end result is bulletproof.”
Don’t get us wrong: Xamarin.Forms is a brilliant idea. The concept is about utilizing XAML to create a unified UI view that is automatically translated into three native ones.
Nonetheless, the functionality is just not there yet. We believe it will be – still, we won’t go with the Forms until the tech can deliver on the promise.
Xamarin is making waves already
Xamarin certainly can be considered a revolution. While Java and .NET are rather hermetic and competitive environments, Xamarin is something that connects developers from both sides of the isle. Looking at this issue from a practical perspective, Java guys who build Android apps are doing two things:
- Front-end with XML.
- Back-end with Java.
If they were to transform to Xamarin, all they would have to do is implement .NET into back-end instead of Java, and then use the front-end knowledge they already have.
Xamarin had its ups and downs over the last couple of years. However, there should be nothing but success waiting for it in the future. While we’re not the first adopters of Xamarin, we surely are one of the early ones.
“In its current stage, Xamarin requires a vast knowledge of native SDK and a proper approach to both the architecture and the design patterns such as MVVM. The majority of Angular and WPF coders will know what I’m talking about,” Slawomir says.
Xamarin’s killer feature
Without a doubt, the most important feature of Xamarin is its ability to take advantage of Objective-C and Java Android libraries.
Swift libraries are not quite there yet, but the integration is ongoing.
A large part of most important native components is already integrated within Xamarin. “You can just download them,” Slawomir adds. “Sometimes, though, we may require libraries that don’t really have their Xamarin alter ego”.
This issue can be solved by generating a port of the libraries originally written in Objective-C or Java. While this may not be as quick and easy as it sounds, the Xamarin community has our backs. And it works both ways.
As In’saneLab, we’re an active member of the community surrounding Xamarin. That’s actually how we got in touch with Miguel de Icaza, Xamarin’s CTO and co-founder, who helped us with the process of becoming an official Xamarin Technical Partner.
“This is going to be a huge deal for us,” says Slawomir Grycz. “Such status was obtained by 250 companies globally. In Krakow, I believe only a handful of companies have received it. Usually, the Technical Partner status is claimed by corporations or firms that employ more than 150 people.”
Currently, In’saneLab employs fewer than 30 people.
Our little Xamarin talks
From the moment I joined In’saneLab, I’ve been wondering about one thing. If we’re building mobile apps, why are there no Android or iOS developers employed?
“See, that’s the idea. We actually do hire Android and iOS developers. They simply decided to learn Xamarin, too,” Slawomir told me. “Our way of practicing Xamarin is based on UI views that are 100% native. With Android, we use XML. With iOS – the native SDK’s API. Until Xamarin.Forms is commercially ready, we’ll continue with this approach.”
As proven by our colleagues, developers with an experience in native development are able to learn Xamarin quickly.
The majority of great Xamarin developers originated in two places. They were either:
- Native developers who decided to pursue .NET, or
- .NET developers who learned native SDK’s.
According to our team, that’s all there is to it.
2 bad things about Xamarin
Every solution has its pros and cons. So does Xamarin.
While our team members are completely in love with the concept, I managed to get them to talk about the drawbacks of Xamarin’s technology.
I promised to keep everything they told me a secret.
So here are the secrets.
- The file size of a Xamarin app will be a bit bigger in comparison to an app written in Objective-C or Java.
We need to add Mono Framework to each app. This allows .NET to interact with the world of iOS, Mac OS, or Android. Xamarin does have tools (Xamarin Linker) that empower us with the ability to optimize the file size, but it won’t be as small as the other would.
- A humble-sized community.
While the community surrounding Xamarin is very active, supportive, and focused on growth, it’s still small. It can’t be compared to Java communities. On the other hand, we plan to use that to our advantage and add as much value to the group as humanly possible.
3 good things about Xamarin
This was easier.
Basically, I had a hard time selecting only three Xamarin advantages out of all those that our team talked about, but let’s give it a shot:
- Ability to extract business logic to a single shared project.
It’s easier and cheaper than maintaining and updating three separate apps.
- If you’re a native developer or a .NET developer, you can learn Xamarin easily.
Really, it’s not that hard. If you’d like to talk about it with a human, drop Slawek an email at email@example.com. He’ll show you the ropes.
- The way we do it, you’re getting a 100% native output code.
Let’s say you want to download an app made with Xamarin from the App Store. If we wrote this app, you’ll be downloading something that resembles Objective-C in almost every aspect.
What that effectively means is that it will be just as fast, just as reliable, and just as pretty. The other so-called cross-platform technologies have an additional layer of abstraction that masks their code to work on native devices. Such an approach will never work, nor be as reliable as a fully native code.
Xamarin apps ARE native apps
At In’saneLab, each and every UI view is written 100% natively.
We use the same libraries that already exist for Java, and Objective-C. What we do is create a wrapper that can transmit the details from an app to a library. Both logic and business intelligence stay within C#.
With iOS, the output code is identical to the one generated with Objective-C (native assembly).
Launching an app on Android requires Mono VM (Virtual Machine) which executes the output code written in Java/C++ with JNI (Java Native Interface).
Whenever our development team is asked how native is the code written in Xamarin, they ask right back.
“Is an Android app written in C++ with Android NDK (Native Development Kit) more or less native than an Android app written in Java with Android SDK?”
*evil smiley face*
That’s it for now. Thanks for your time!