Download directly

In this episode, Donn talks with Xamarin cofounder on how one can use Xamarin for Android development.

They start off chatting about using Xamarin just for business logic sharing. This Joseph tells us was the original intention for use. They also touch on Xamarin forms which allows you to additionally build UI elements cross platform.

Even if you don’t use Xamarin or plan to use Xamarin right away, this was a fantastic insight into the platform, from the creators directly. They touch on advantages, how to really leverage the platform and potential downsides.

This is our last episode for 2016 and we’re glad we get to end on an high note. See you in 2017!

Show Notes

Apps using Xamarin for Code sharing

Notable alternatives:

Contact

Transcript

Donn Felker: I have someone quite special here today. He’s talking about a topic that I’ve been very interested in getting to: cross-platform development. We’ve actually had quite a few people ask us about this. I’d like to welcome Joseph to the show.

Joseph Hill: Thanks for having me.

DF: Joseph, can you give our listeners who aren’t familiar with you some background information—who you are, what you’re working on, what you’ve worked on in the past, and so forth?

JH: I currently work for Microsoft, since they’ve acquired the company I helped co-found (Xamarin). We created Xamarin as a company focused on cross-platform mobile development. The thing that was special for us was understanding that, while people need to create cross-platform apps, they need to create native apps as well. I think that turned out to be the thing that gave the company length.

Of course, my background before that was as a C# developer and a member of the open-source community. Xamarin itself took the open-source model of technology, and then wanted people to write C# applications.

DF: Our audience here at Fragmented is mainly made up of Android engineers. We’re highly focused on that. We get a lot of questions about cross-platform development. There are a bunch of different tools for that nowadays, like Xamarin, React Native, Cordova, and who knows what else. But for folks who aren’t familiar with what Xamarin is: if you were in an elevator together, how would you explain Xamarin to another engineer?

JH: First and foremost, Xamarin has always been focused on letting developers do anything with C# that they could do with Objective-C or Swift on iOS, or Java on Android. The idea is basically a complete mapping of Android APIs to C#, giving the ability to use things like Native Android Layout, XML, Android resources, and even libraries, but with the C# programming language. The benefits to that are obvious if you’re a C# developer already; but even if you aren’t, it’s nice to have a language that’s powerful, and available on Android, iOS, Windows, and web servers, because you don’t have rewrite code. Also, it helps you avoid bugs—you don’t fix a bug on one platform and then find out months later that you still have the same bug in a different code base on another platform.

DF: You said that I can use C# to develop Android apps, but you also mentioned iOS. Does that mean that I just write the code once and compile it, and I get two outputs from the one app, or do I have to code for each individual platform?

JH: You can share code, but at the end of the day, you’re writing a native iOS app and a native Android app. Historically speaking, we started by putting C# on iOS. We wanted to enable the developers (Windows developers, at the time) who were telling us, “Hey, we need to get to iOS. Can you help us do it?” There was a temptation to just give them all the APIs they had on Windows, so that they could make ugly Windows apps running on iOS. But we didn’t want to do that. We wanted them to make great iOS apps.

At first, once we produced the iOS product, people would ask us about Android, and we’d say, “Android uses Java. Java’s enough like C#. Just use it.” But these forward-thinking developers would say, “Well, it’s about the advantages of using a single language. Plus Visual Studio is a great IDE, and I want to be able to leverage all of the benefits of this ecosystem.” So it was from that tipping point at the very beginning that we said, “This actually resonates with developers—not being ‘write once, run anywhere’, but to actually be native first while keeping cross-platform capabilities.”

DF: Let’s dig a little deeper into the weeds here. Say upper management hears about how great cross-platform development is—it’s going to save a lot of money in the future, since developers only have to write apps in one language, and so forth. If I wanted to build both an iOS app and an Android app and share some code between them, what does that look like from a developer perspective? Do I have different projects in GitHub, or do I just have one big project with shared code?

JH: In the Visual Studio build system, we have the concept of solutions, where each solution can have multiple projects in it. Android Studio follows essentially the same model, of course. When you’re working with Xamarin, you would have a head project for each platform that you’re targeting. You might have one project for your Android-specific code, another project for your iOS-specific code, and a shared project, like you said.

You can share libraries. You can either write the libraries or use libraries that other people have written which are cross-platform. You might end up with multiple shared projects within your solution. We also make a library called Xamarin.Forms. It’s an abstraction toolkit that focuses on some kinds of UI sharing, so you could share UI code as well.

But typically, you’re going to have a project with code that’s specific to each platform that you’re targeting.

DF: So I would keep pertinent business logic that applies across all projects in those shared projects. Is that correct?

JH: Right. Let’s say you’re making an app that needs to render some financial calculations, so you write some logic that creates amortization tables. If you did that on the web, you would just do it all on the server. You wouldn’t want to run calculations on the device, because you can’t trust those calculations.

But you’re going to render these tables on the phone, and you want to run the calculations locally on the device so that the user has a responsive experience when they see what the models look like or what the final costs are going to be. But you’re going to run the same logic you ran on the server, since you trust those models.

Then there’s also code sharing for things like authentication. Maybe you have ten apps, but they always run against the same user/password login system—the same authorization-granting API. So you put that logic in a library which ends up getting used across your apps. Or, if you’re in a large organization, other parts of the organization can use those same components in their apps as well.

DF: To bring it full circle (keeping it simple), we have one shared library where we have all of our authentication logic, and where we build those amortization tables and any other financial things we’re going to work on. Then, on top of that, we have Xamarin for Android, Xamarin for iOS, and so forth, which talk to those same shared libraries.

But as a developer, I only have to write that code once. Then I unit test it, or whatever, and it’s good to go. I know that it works, and that it’s going to work the same on both platforms, since both platforms talk to the same shared library.

JH: Right. Importantly, if you find a problem in your model and fix it, you know that you fixed it on both platforms. And if you’re working in a single solution and change an API in your shared code, you get feedback right away from your iOS and Android projects that those guys are still building. You didn’t really break anything that both apps are depending on.

DF: Just to make sure that I’m for with the listeners, all of this is written in C#, right? As in, is Xamarin all C#, top to bottom?

JH: Talking specifically about Android code, we expose all of the Android APIs as C# code. So, when you have an Android specific project in your solution, you write all of that code in C#.

The exception comes when you’re also using Android XML for layout. If you were using other tools for processing Android layouts, you would have access to all of those, but we’re not making you write Java code—although you can bind Java code. On the iOS side, you can bind Objective-C code. You can bind C code. All of that is available to you, but we give you the ability to just write C#.

DF: You bring up a very good point there. In Java (actually, in pretty much all of the languages now), we have a very big open-source community with tons of libraries available. Especially in Android, if you look at your build.gradle file, every project has a ton of dependencies that are pulled in—logging libraries, API libraries, and everything else. If I want to continue using libraries that I’m already kind of familiar with, since they do a great job, can I continue to do so?

JH: Absolutely. Now, they don’t become inherently cross-platform when you do that. It’s not like when you opt into Xamarin, your Android JAR files can be used by your Xamarin iOS app. But by all means, you can continue using any Android libraries you were using before.

Occasionally, if it’s an open-source library, customers will opt to port it from Java to C#, since that’s fairly straightforward. That’s also an option, and that might give you the ability to make the code more portable to iOS, but you don’t have to do that.

In fact, some of our customers who already have an app written in Java will keep a big chunk of that app, compile it as a JAR, and just start building new code in C# tomorrow. They won’t necessarily mess with the working Java code they already have.

DF: That’s important, because a lot of the teams that I work with on a day-to-day basis build a lot of Android custom views that do a specific thing in Android which we don’t really want in iOS (or isn’t even iOS specific)—think floating action buttons and Material Design things that we’ve custom built. It sounds like just I can pull those in and use them in the Android version.

JH: Like I said, there’s a gradient. You can pull those in and make them as Xamarin specific as you want, or just leave them as is.

DF: I think that when a lot of people hear about Xamarin, they’re afraid of leaving everything that they know to hop over to something like this: “I know all of these libraries, but now I’m going to hop over here, and I can’t use them.” I think that knowing you can still use them is a big win.

JH: Historically, in the case of .NET and Java, you can almost always find the same libraries in the other language, or forks and ports of those libraries. At the same time, making it easy to consume libraries as is has always been a top tenet for us. You can start with one approach and switch to the other, so it’s very easy to ease yourself into it.

DF: So you guys basically run C#, and you’re able to talk to all of the Android and iOS API bindings. But let’s say I’m building an Android app. How is the bridge made from writing C# to actually getting a native Android application? What happens and how is that maintained?

JH: At the end of the day, Xamarin uses the Mono runtime (at the core) to compile C# to Intermediate Language (IL)—like how Java compiles to Java bytecode. Then, in the case of Android, that IL is turned into ARM executables.

DF: What is IL, for those who are coming from the Java world?

JH: The Intermediate Language is very much like bytecode, but C# compiles and F# compile to it. Then it’s the job of (on Android) the JIT to just-in-time turn that intermediate representation into an actual native ARM executable.

DF: So it’s truly native? It’s not like running a WebView inside of my app?

JH: Correct. When we talk about these bindings, what we’re really saying is that we’re using JNI with that. It’s a bridge between the .NET code and the Java code. Also, we have cooperative garbage collector that makes sure that when we dispose of an object on the Java side, it goes away on the .NET side (and vice versa).

DF: Are there any performance implications to doing that?

JH: That’s what I was about to say. There’s a performance implication to speaking across the bridge. If you were in a tight loop, creating an Android button, and you made a list in an odd way, you might stack a bunch of buttons up and create all of them. There is an additional cost to doing that.

On the flip side, we have a very high performance JIT. When comparing strict C# (which is not speaking across the bridge) to strict Java, we perform at least as well. I don’t have specific benchmarks in front of me, but there are even places where C# code would actually perform better. Typically, I just wouldn’t really consider that there’s a performance cost to choosing to use C#. It really only comes to light when you’re doing something the wrong way, like I just described—where you’re doing a lot of cross-talking from C# to Java that you probably shouldn’t be. Instead, you would just take a different approach.

DF: Does the same thing happen for iOS?

JH: iOS is not JIT-ted. When we talk about JIT, we’re talking about just-in-time conversion of the intermediate representation to the ARM executable code. On Android, that’s completely allowable. Basically, you generate some code you want to execute, make it executable, and run that code.

But on iOS, that’s not allowed as a security restriction. When you start writing to memory, you’re not able to make that memory executable, which means you can’t have a JIT on the device. You could certainly generate all the code, but iOS will never let you execute that ARM code once you’ve generated it. So, we use ahead-of-time compilation on iOS. Our AOT uses LLVM, which is an optimizing compiler. It’s the same back end used for Objective-C and Swift, so (at the end of the day) you’re generating the same ARM code that you would generate from those languages. But it’s all generated ahead of time on your Mac, before it’s compiled into the app that you ship.

DF: Lt’s go back and really hop into the weeds here. Suppose I’m writing an app, and I need to put a text box into and Android form, and then get a reference from it. In Android, we normally do things like findViewById(). Then we get a reference to that, and we can work with it. If I’m doing this in Xamarin, am I working with a .NET text box or with the Xamarin representation of an Android text box?

JH: You’re speaking directly to the Android text box.

DF: So it would be like a TextView, an EditText, or something like that.

JH: And you could do exactly what you just said. It’s still “find by ID”. It’s the same resources pile, which gives you the same handles (the same IDs). That model should be instantly familiar to any Android developer, because it’s the same.

Going back to what I said earlier with Android XML, layout is also going to be the same.

DF: We still write our layouts in XML, then?

JH: Correct.

DF: From my personal experience as a previous C# developer, I know that making the change from C# to Java (and vice versa) is actually quite easy, because the languages are very similar. Personally, I actually prefer C#, which might come as a shock to a lot of our listeners. I think it’s a beautiful language. I know that my co-host Kaushik also loves C# and feels it’s a very beautiful language. That’s one thing which I definitely miss from working inside of Java for the last eight years, which is having access to the beautiful language that is C#. It seems like Xamarin gives you that ability.

JH: If you look at early versions of C#—which is probably what most Java developers who have been around for a while made their assumptions about what the language from—C# and Java look very similar. But actually, C# has evolved quite a bit. Java has even evolved to pick up some of the C# idioms. C# continues to evolve, bringing in nice features like async.

DF: Yeah, that’s a beautiful one.

JH: I’m biased toward C# (many people are), but at the same time, there is a common heritage. They’re clearly inspired by the same C-type constructs, with semi-colons and curly braces. Typically, people give it an objective look. First off, it’s something you can get comfortable with very quickly, and moving the other direction is fine as well, though you’re going to miss the features that you got used to on the C# side.

DF: Yeah, when I came over to Java, I had an array list of something and I went to go use a lambda expression, but it just wasn’t there. I found myself writing so many verbose for-loops and so forth, so I can definitely relate.

But let’s take this in a slightly different direction here. Android releases new operating systems all the time. They’ve released Marshmallow, N, etc. They just keep coming out (and will hopefully continue coming out). When a new Android version is coming out, either as a developer preview or when it’s being released, how does that get into Xamarin? If I’m using Xamarin, can I actually use those new APIs?

JH: Every time there’s a preview of a new Android release, we have a team of engineers who download it and start creating bindings right away. We have tools for generating those bindings, so it’s typically a process of coming along behind the generated bindings and saying, “This is not quite what you would expect the C# API to look like.” So we go through and refine it, bringing async into APIs that need to be async-ified. Or, if developers would expect a more delicate model for raising events or whatever, we try to bring in the C# behaviors that we think they would expect to see on top of that.

What’s really neat is that Xamarin was (of course) a proprietary solution for the past 5+ years, but after Microsoft’s acquisition of us, they open-sourced everything. So, if you watch it all on GitHub, you can actually see this whole binding process take place publicly. We aren’t just dumping this out there. We encourage the community to come participate.

DF: So if I find a bug in a particular implementation of a UI widget, for instance, can I create a pull request back to the project?

JH: Yes, please do. We would love to have those. Also, it’s nice to be in a situation where we have a community that’s anxious to have this kind of help. If Google drops a new preview of the next version of Android, and there’s an API that you’re really anxious to try, jump in! We’re here to help you take advantage of that API, start binding it, and get involved with the community.

DF: That’s excellent to hear, especially since it’s open-source now. Just to be clear, if a new version of Android comes out and it has a new UI widget, your team of engineers will hop in there and create that binding so that you can expose it inside of Xamarin, correct?

JH: That’s our priority—making sure that it’s not only exposed, but that it’s a beautiful looking API that developers want to use. But you’re absolutely free to go bind it yourself. You don’t have to contribute it back if you think we’re going to do it anyway. If you just want a quick and dirty hack to be able to try something out, you can do that as well.

DF: What’s the average turnaround time that you guys usually have when a new release is pushed out before it is available to the public?

JH: That’s a good question. We have an excellent track record of tracking these things very closely with iOS. Apple gives us a nice, long lead time. You start seeing previews that we can start tracking with our own previews in the summer (at WWDC). By the time they get close to GM, we have everything bound and most of the kinks worked out, and people can start submitting apps to the app store before the release.

On the Android side, we’ve historically lagged more behind. Because of the adoption curve of new versions, it hasn’t been as pressing that we track them closely, and we’ve never gotten publicly dinged for not doing that. But the nice thing is that, as we’ve gotten more developers on board, we’ve begun having more customers that even Google cares about. They have a vested interest in us supporting this new API soon as well, because they want to push adoption of new versions. So I don’t think we’re quite the same day yet, but I think we are in a position to be close.

DF: Would you say it’s within the month? Two months?

JH: I was shying away from that, because I don’t remember what the exact period was on the latest release. I do know that a year ago, we were out within days.

DF: That’s amazing, though. I personally don’t have a problem with that, especially when you’re creating a bridge between two different languages. A couple of days? I can wait. If I’m a C# developer (and I used to be on many C# teams), and I need to support the new version of Android, I can probably wait a couple of days afterward. Again, I know there are people who feel differently, but I don’t see why it’s a humongous problem (although the fact that you guys are trying to push forward is great).

JH: Having a community there and people who care about native development certainly pushes it forward.

DF: You mentioned something called Xamarin.Forms. Yesterday, here at the Microsoft Connect event (right now, we’re in the New York City Microsoft offices), they were saying that they had used both shared libraries (like we were talking about earlier) and Xamarin.Forms to build an application, basically allowing for over 90% code sharing between the platforms. What is Xamarin.Forms, and if I’m a new Xamarin developer, why should I care about it?

JH: From day one, we kept telling developers that they should be creating native experiences. But a lot of times, businesses would be coming back to developers, saying, “We really just want you to write it once.” So Xamarin.Forms is basically a library that we created to fit that need: giving the developers the ability to do write once, run anywhere with Xamarin when they need to, without necessarily giving up completely on the ability to do native things.

Xamarin.Forms is an abstraction toolkit that gives you layouts and controls for writing cross-platform apps. Depending on the kind of app you want, you can share up to 100% of the code.

DF: Between platforms? As in…iOS and Android?

JH: iOS, Android, and Windows UDP. The trade-off is less control over exactly how things get rendered, but since it’s still an abstraction, it’s still using native rendering. When you make a Xamarin.Forms app, you define a layout, and then Xamarin.Forms decides how to use native buttons, native text boxes, etc. So you end up with a native look and feel, even though you may not have quite the complete control to say, “This is the native behavior I expected.”

Xamarin.Forms was designed to keep those native capabilities at arms length. With the first release, we had this idea of custom renderers. As soon as you realize, “I need this screen to be native,” we’ll give you the ability to put a native screen in there. What you saw James demonstrate on stage yesterday was how we’ve made native embedding even easier. Instead of having to figure out what a custom renderer is, or how you should go about writing one (which is probably creating a new class, extending something, or whatever), the native embedding…

Actually, let me take a quick step back. Xamarin.Forms layout is done in XAML (another XML format, separate from iOS storyboards or Android XML). Typically, if you’re making your UI in Xamarin.Forms, you can write it in C#, but you can also write it declaratively in XAML.

Anyway, in his example, James took an iOS segmented control and said, “That’s the control I want. It’s iOS specific, but I want it in the middle of this Xamarin.Forms page.” So, in the XAML, he was able to start a new tag that says, “Give me the iOS segmented control right here.” On Android, that’s nothing. It’s ignored. It doesn’t exist. But on iOS, it’s going to render that control.

DF: Suppose I’ve built a nice little custom UI widget for Android and for iOS that has a certain behavior for my particular business needs. Is there a way to say in XAML, “Hey, if we’re running Android, show this one; but if we’re running iOS, show this one”?

JH: Absolutely. That’s what the custom renderer is. With the custom renderer, you tell Xamarin.Forms at the shared code level, “I’ve written a custom pie chart that renders the way my business wants it. On iOS, it’s rendered one way; on Android, in another. Give me the thing that on this platform is the pie chart.” That’s how Xamarin.Forms itself works under the cover. We give you a lot of renderers packaged in, but the community has created many custom controls of their own. So that’s how you go about doing that.

DF: Okay, let me bring it from top to bottom again for our listeners. If we start at the bottom, we have the shared libraries, which talk to our API and hold our authentication, business logic, and so forth. That’s shared across both iOS and Android. Then, from there, we’ve now introduced this new layer (Xamarin.Forms) which allows us to write our UI once and display it on various different platforms. Then, on top of that, we have our independent platforms (Android and iOS). That stack reduces that layer to a much thinner surface area. Would you agree?

JH: That’s the objective.

DF: Basically, I have very little Android and iOS specific code. The rest of it is shared.

JH: Again, we’re developers. We recognize the productivity benefits that developers want to get from sharing code, and what businesses want to get from sharing code. With Xamarin.Forms, we want to make that possible. At the same time, we recognize that when you put the app into the hands of users, they may say, “This is not the behavior I was expecting. When I’m running my other Android apps, they do the right thing. Why can’t you do that?” We don’t want developers to be stuck with an abstraction. Instead, we want to give them the power to come back and put some native polish on it, like a floating action button.

DF: So that means that if I want to implement the Material Design guidelines on Android (this is a big thing), I can add some custom renderers and have that full, nice, fluid motion; the ripple effects; and all of that stuff. Then for iOS—well, I’m not an iOS developer, so I don’t know the exact terms, but I can implement everything iOS-style there as well.

JH: Correct. That’s the power we want to put in the developer’s hands.

DF: Which brings up a question that Kaushik really wanted me to ask you: “Can you build really complex apps with Xamarin, or are you shoehorned into creating simple applications that are just forms over data?”

JH: I think that’s a leading question for Xamarin.Forms. Sometimes, developers only try the Xamarin.Forms approach since it has the same name as Xamarin. I do think it’s nice to be able to speak specifically to this topic, because that perception might be true with Xamarin.Forms—that it’s good for forms over data apps. It’s powerful for other things (like prototyping) as well, but it’s not the right solution for everything.

With Xamarin itself, the functionality is better than just a toy. We not only want you to be able to build any kind of app you want, but we want your apps to be better. Since you were able to be more productive with C#, Visual Studio, and sharing that code in more places, you can spend more time making new features, rather than implementing the same feature twice.

C# is powerful and performant. It powers a lot of games. It’s big in VR and AR. All of that functionality and power being back in the hands of the developer—that’s much more than just a toy app.

DF: For example, I recently got done with a client project: building a fitness application. Google has released an audio player called ExoPlayer, which is a very configurable audio player for Android. We played audio classes through that, because we needed to control buffering and all of this other stuff. As you said before, I can still use that library for Android with Xamarin. I can still connect to that library, do the audio playback, and everything, correct?

JH: Absolutely. The situation here, then, is finding an equivalent library over on the iOS side (if you want to have that functionality over there).

DF: So I can build those media playback applications, and I’m not limited to the Forms. Even though it’s called “Xamarin.Forms”, I’m not shoehorned into x amount of controls. I have those, and if I want to hop into fine-grained Android, I can go back and do that too.

What apps or companies that we’d be familiar with are currently using Xamarin?

JH: A lot of businesses are going mobile, so many of the stories I keep hearing are from shipping companies and airlines (like Alaska Airlines) putting devices in the hands of field workers and field engineers.

But one of my favorite stories recently has been Outback Steakhouse. They’ve written a five-star app in Xamarin. Almost every restaurant has an app these days. It’s kind of like a web page. They have to put some information on the page so that people know where to call to make reservations, and can get directions and see the menu.

But what Outback asked, “Customers have these devices in their hands. How can we provide a better experience to them when everybody has a mobile app?” The app is reviewed very well not only because it’s native and provides a pleasant experience, but because it lets you do cool things like pay directly from your phone (so you don’t have to wait for the server). That’s transformative to business. Those are the things that make being in this space now a fun place to be.

DF: I’ve worked with a lot of startups, and I get courted by a lot more. They often ask me a question: “Should we use Xamarin, PhoneGap, or React Native?” To be honest, I don’t have any experience with PhoneGap or React Native, other than just perusing the documentation. I’ve actually built apps with Xamarin, though, so I can speak to it. I know that you’re going to be biased toward Xamarin, but what’s your response to that when a company comes to you? Do you have a set of parameters, so you can say, “Well, in this case, you’ll probably want to go with React Native,” or “In this case, you’ll want to go with Xamarin,” or is it always Xamarin?

JH: I’m incredibly biased, but let me at least give you my justifications for being biased. All the other solutions you mentioned (Cordova, PhoneGap, and React Native) fall into a class of APIs that are frankly closer to (at best) the Xamarin.Forms experience.

In the world of React Native, for instance, you’re given a limited set of APIs to build your apps. If you like Javascript…I mean, it’s popular for a reason. It lets you do some cool things, and also makes for great demos. I’m biased toward C# because I think it’s a more powerful language, but at the end of the day, despite the name, React Native is not the 100% mapping of native APIs that Xamarin gives you. With Xamarin, you’re never caught in a place where you need something and can’t get to it.

The other argument people typically use is, “Well, it’s only two platforms. I don’t like writing in two different code bases, but it’s only Objective-C (or Swift) and Java. We’ve decided we need a native experience, but do we even care about sharing code?” A lot of times, people will end up with an iOS-specific app (or a Java specific app) because that was their requirement at the time—you know, “We’re buying iPads, so I know I’m writing an iOS app. I’m just going to use Objective-C or Swift, because it’s just the iPad today.”

But then, six months later, you’re done with the iPad app and everyone is pleased with it—and you have to do a new app on Android. Suddenly, your app is cross-platform, and you wish you could use some of the code that you had before: “Oh, I just wrote authentication for that app on the iPad. Now I’m going to be writing authentication and all of these web service calls again, and offering data synchronization. It’s a totally different app—except it’s not. It’s still the same model, so I’m still using the same business objects that used in the other app.”

So you’re not necessarily a cross-platform developer, because you’re not writing a single app cross-platform; but (over the course of the year) you are a cross-platform developer, because you keep having to write for this platform, then that platform, then bringing it back to the web. It’s when you’re in that mode that you realize that cross-platform is more than just trying to write one app for multiple platforms.

DF: Let’s say that I’m an engineer or an engineering manager. After hearing this interview, I go take a look at Xamarin and say, “This looks like something interesting for me or my team. I want to take us there. But we already have an existing Android application. How do we go from that native Java Android app to Xamarin? Is there any help for that?”

JH: There is help, but there’s also just the fact that Java is pretty approachable. Hopefully by now, you understand that the structure of Xamarin compared to Android with Java has a lot of similarities beyond just the language—for instance, you’re using the same Android XML.

A lot of it depends on the size and complexity of your app, and what your objectives are for getting to the other side. It probably needs to be decided on a case by case basis.

At a minimum, though you should enter this thinking, “Oh, I can file a new app, and copy over my Android XML resources and everything else that’s not the code into my new Xamarin Android project and leverage that. That’s not being rewritten. Then I can take the Java and convert that, though it might be a little tedious. You can probably find tools out there that can convert Java to C#, so that could help.

Lastly, you could get back to that part about bindings, and being able to leverage native libraries. You could just take the Java you’ve already written, keep it compiled as a JAR, and save it for porting later. Make sure you’re committed to moving over, add some Xamarin functionality, and use those two things.

DF: So you could just see if it works—kind of kick the tires a bit. That makes sense. It seems like a very viable approach, especially if I can compile at least the non-Android stuff down into a JAR and reuse it. I think that would ease a lot of pain and apprehension that some folks have about transitioning over a larger existing project.

Here’s the million-dollar question: if I’m developing for Xamarin, it’s in C#. Let’s be honest: when everybody thinks of C#, they think of Windows. Do I have to buy a Windows machine to do this? Where can I develop this? What do I need?

JH: That’s a great question. If you’re going to develop for Android, you can currently do it on Windows or Mac. We’ve now open-sourced the full toolchain, so you could even (with a lot fewer IDE conveniences) do a lot of it on Linux if that’s what you wanted to do. But from our tooling perspective, if you’re on Mac or Windows, it’s not going to be that different. You have Visual Studio on Windows, of course; and yesterday, we announced Visual Studio for Mac. That was previously Xamarin Studio, which was a mobile-specific IDE that’s very Visual Studio-like. We’re beginning to bring Visual Studio functionality into it, so that you aren’t just writing mobile apps, but are able to write your ASP.Net core back inside the IDE and share that code.

DF: That will run on Unix based systems too, with the announcements that were made yesterday that .NET will run on those systems. So it doesn’t matter: you can deploy your back-end to Linux as well.

The last real question that I have here is: are there are any real gotchas about Xamarin? Is there anything we developers should be aware of when looking into Xamarin?

JH: Way to end it on a happy note! I think that the challenges I see people hitting today are very different from what they were a few years ago. We used to get dinged on the size of the runtime, but apps are now so big that when the Mono runtime adds a couple of MB, it can still be smaller than most of your other apps.

DF: That’s a good question. How much size does it add? Just a couple MB?

JH: It starts at about 4 MB. I think we’re actually under that, and we’re constantly trying to trim it down. When you bring in portions of .NET libraries that you’re using, we use a linker to link away the portions that you aren’t, so we give you the minimum amount of Xamarin and Xamarin libraries that are needed to support your app. That does add some size, and I know that people still look at that, so you do have to be aware that that’s coming in there.

DF: Let me interject on your sizing comment there. A lot of folks who listen to this worry about the size of their Android applications and about how many methods they have. It turns into an almost religious war inside of Android itself. Personally, I’m very pragmatic about the situation. If I can gain a ton of productivity by using a different tool—Xamarin or whatever—and it’s going to cost me a few MB, at the end of the day, I don’t care. It’s allowing me to ship my app faster and be much more productive, so a couple of MB are really not that big of a deal. I think that people need to recognize that they are building something, and not focus on these minute details and tear something apart because it adds a couple of MB.

JH: There’s something we refer to as the power of defaults. We give you defaults that make things work, but they can always be tuned later. You can choose what ARM processors and API levels you’re targeting. So I pretty much agree with you: on the runtime side, I don’t think you should sweat it.

And the challenges of large Android apps are something that hit everyone, regardless of whether you are using our framework. We’re all learning together what strategies to use to reduce late loading. We all share in figuring that stuff out together. I would hope that if you’re pragmatic (and you should be), this is not something you’re sweating about.

DF: If folks want to get started with Xamarin, where should they go? How do they learn more about it? Where do they download it? What does that look like?

JH: There is of course, https://www.xamarin.com/download. You can get Visual Studio or our own IDE, Xamarin Studio, directly from there. We have a developer portal, https://developer.xamarin.com/guides/android/, which has tons of great documentation. We’re very proud of the work we put into the that.

We also have Xamarin University. Prior to our acquisition, it was a fairly expensive service that provided a lot of great instruction for learning Xamarin development and mobile development in general. That still exists, and it’s still a great product. One thing that we’ve been doing over the past month is turning some of that content into self-guided learning, so that’s a really great place to start. You can learn a lot about mobile development, development with C#, and just getting started with Xamarin by checking that out.

DF: I think it’s important to note to our listeners: as a very heavily focused Android podcast, we’re all Java developers here. But I’ve been part of a gaming company in Minnesota for years. We recently went through a big rewrite. Everything was all native Objective-C and Android Java, and we rewrote it all in Xamarin. I don’t think you should dismiss this simply because it’s a Microsoft product. It’s a very viable product, which I have used previously, all the way back to when it was just called MonoTouch. It saved me a lot of time in developing applications like that.

You’re going to have some of bugs regardless, but if you’re having problems building applications and doing cross-platform stuff, or running into business logic issues or weird platform bugs, Xamarin and Xamarin.Forms are definitely worth taking a look at. This is from my own personal experience, and it’s been fantastic.

Is there anything you would like to share with the listeners here before we wrap up?

JH: I’d just like to piggyback off of what you said there. We have a great community that’s been very passionate for the years we have been around. It’s large, and it’s been growing at a healthy clip. But when Microsoft acquired us and made everything not only free, but open source, it grew our community by multiples, so it’s a great time to get involved. There are lots of other people learning it at the same time.

People always have had concerns about our company, with a commercial product that we were charging a lot for that could go away: “Do I want to stake my business on this?” Now it’s such a big part of what we are doing with Visual Studio (and of course, on the Microsoft side, with Azure) that it’s really brought down barriers for a lot of people to adopt it. It’s been great for the community.

Like I said, any developers who care about C# being a great language aside, I think we have a good approach for the cross-platform challenges we’re all facing.

DF: If folks want to reach you, what’s the best way to do that? Are you on Twitter?

JH: I am @josephhill on Twitter. You can also email me at [email protected]. I love Twitter and have a lot of fun there.

DF: We appreciate you coming on the show. This has been super informative. The topic has been requested quite a few times over the last year. A lot of folks want to hear about cross-platform development, Xamarin, and what we think about it. This has been a phenomenal, really good deep dive into what Xamarin is. I can’t say thanks enough, and I know that Kaushik would say the same thing if he were here. Thank you for coming on the show, Joseph.

JH: I appreciate that. I hope your audience enjoys this—and if they do, we have lots of great people in the community that you should have on your show in the future.