Impressive Xamarin SDK brings native iPhone and Android development to C# programmers, Visual Studio
Unless you've been living on a planet far, far, away from the galactic trade routes, you know there are only two practical choices of programming languages -- Java and Objective-C -- for developing native mobile apps. If you are an experienced C# codesmith who wanted to try your hand at Android or iOS app development, you were out of luck. No longer: Xamarin 2.0, an SDK produced by Xamarin, allows you to write Android and iOS apps using C# code. Equally important, you can do this with Microsoft's Visual Studio.
The Xamarin SDK is based on an open source project known as Mono that allows Microsoft .Net applications to run on other platforms. Xamarin currently consists of class libraries, a C# compiler, and a virtual machine. The class libraries implement the core APIs of Microsoft's .Net 4.0 framework. The compiler complies with the C# 5.0 standard, and it has support for namespaces and assemblies. The virtual machine executes the Common Language Infrastructure bytecode generated by the C# compiler.
[ Also on InfoWorld: Programmer picks: 6 tools for rapid mobile development | Learn how to work smarter, not harder with InfoWorld's roundup of tips and trends programmers need to know in the Developers' Survival Guide. Download the PDF today! | Keep up with the latest developer news with InfoWorld's Developer World newsletter. ]
The Xamarin SDK also provides platform-specific frameworks that work with Google's Android APIs and Apple's iOS APIs. However, these frameworks are not abstraction layer APIs that only access a lowest common denominator of platform services. Instead, they provide "bindings" -- mechanisms that enable C# method calls to properly invoke native methods designed for use with a different programming language -- to the native APIs for each platform. The Android API binding frameworks are called Mono for Android, while those for iOS are called MonoTouch. The result: Xamarin lets you write a native mobile app entirely in C# code.
To use the Xamarin SDK to its fullest, the app should be factored so that its UI code is uncoupled from its core algorithmic code. That is, you write the core algorithms with the .Net framework, then implement the native UI for each target platform using the Mono for Android and MonoTouch frameworks. The factored design allows the app to be built and deployed on both Android and iOS devices, where the app's core code uses the native API of the target platform. This scheme lets you repurpose field-tested C# code and libraries. It also provides some flexibility in choosing how many of the platform's native APIs to use. For example, your app might draw on the .Net networking stack for network services or rely on the platform's own networking stack frameworks.
To develop your Android and iOS apps, you can use Xamarin's own IDE, Xamarin Studio, or stick with Visual Studio. The Xamarin IDE allows you to organize projects into solutions so that one build command will make both an Android app and an iOS app. The Xamarin IDE also lets you execute and debug code in simulators for each platform or on the devices themselves. There's no compromise if you prefer to develop in Visual Studio, as Xamarin lets you build, download, and debug app code on the target devices with Microsoft's IDE.
iOS app development: It's complicatedAlthough Xamarin lets you use your Windows PC for iOS development, that doesn't mean you don't need a Mac. For a number of reasons, Xamarin still requires Apple's iOS SDK tools to complete the code generation. For example, the Xcode simulator is required for code debugging, and the app's interface must be designed using Xcode's layout and storyboard editor, Interface Builder (IB). Finally, to distribute apps in the App Store you must use Xcode's code-signing mechanism.
How is it possible to use Visual Studio to write and debug iOS apps? Xamarin performs a clever sleight of hand that sets up the Mac as a back-end build server to Visual Studio. Installing Xamarin on the Mac places a remote build server on the computer. This build server uses Apple's Bonjour service discovery protocol so that Windows systems can find it on the network and establish remote sessions with it. An inexpensive Mac Mini can be used as a shared network resource for multiple Windows developers.
When you execute a build with Visual Studio, the remote session has the build server issue the appropriate command lines to the Xcode build tools. (This works because the Xcode IDE itself is simply a GUI layered over command-line tools.) After the build completes, the iOS simulator on the Mac starts and remote commands from Visual Studio operate the simulator through the Xcode debugger. Or the Xcode debugger can download the code onto an iOS device, and you can debug it there through Visual Studio.
The other aspect to iOS app development is whether to IB or not to IB. The UI of an iOS app can be constructed two ways: either through program code or by using Xcode's visual editor. IB lets you lay out the app's interface by pointing, clicking, and dragging UI elements. These UI elements are actually Cocoa Touch framework objects in a serialized format. That is, you manipulate the UI objects themselves in IB. This ability to edit Cocoa Touch objects is not easily duplicated on the PC. Therefore, you either have to use IB on the Mac to design the app's UI or write the UI entirely in code to implement it. In the latter case, you can use a utility like PaintCode, which lets you design the UI visually; it then generates the appropriate Objective-C or C# code.
Constructing the UI for an Android app can be accomplished with Windows tools, because Android uses XML to store the layout. Xamarin Studio has a graphical layout editor similar to IB that lets you construct the Android app's UI visually. Xamarin also provides an add-in that implements this graphical editor in Visual Studio.
Using Xamarin Studio to run a C# app in the iOS simulator. A breakpoint has been set in a platform-specific UI file that manages the native implementation of a log-in screen.
Xamarin setup: Mind your step A quick check with Xamarin tech support confirmed that the MacBook Pro I use for iOS development was suitable. This Mac has 8GB of RAM and runs Mac OS X 10.7 (Lion). I had the Apple Xcode 4.5.2 tools already installed, along with a number of code-signing profiles set up for debugging code on an iPhone 4 and iPad. From my experience, configuring profiles in Xcode is a fussy business, so I took no chances by making and testing a profile just for Xamarin work.
A Windows machine wasn't available, so I used VMware's Fusion 5.0.3 to set up a virtual PC on the Mac. The virtual PC ran Windows 8 Professional, and I installed the Visual Studio 2012 tools on that. Note that you cannot use the Express version of Visual Studio for code development with Xamarin.
The installation process is lengthy. The Xamarin installer downloads and installs a lot of files on both the Mac and the PC, such as the SDK components, the IDE, and Android SDK (if it is not present). However, I didn't experience any problems with either the Mac or PC installations.
I started on the Mac side with the Xamarin Studio to weed out any issues with the iOS tools and profiles before switching to the PC side. I downloaded the source for a Xamarin cross-platform example app to have something to work with. The example consisted of a solution containing three projects. The first project had the common code, the second had code for the Android platform, and the third had code specific to iOS. You can start builds for the complete solution (which constructs the Android and iOS versions of the app) or separately. Xamarin's per-project build control reminded me of CodeWarrior.
I built both versions of the app, and when I went to debug the code, the iOS and Android simulators appeared on demand. I could set breakpoints, view variables, and step through the code. Debugging the iOS app on an Apple device took some work, because that's when the code signing comes into play.
I initially got error messages about an invalid profile when trying to download to the iPad. Knowing that the profile was good, I went through the various iOS build settings in Xamarin Studio and tracked the problem down to blank fields for the app name and bundle identifier. Xcode creates default values for these settings, while Xamarin does not -- oops. After I entered valid information into these fields, I was able to debug the app on both the iPhone and iPad from Xamarin Studio. I did not have an Android device to test hardware debugging.
I switched over to the PC side and fired up Visual Studio, then opened one of the example iOS projects. To build the app you have to first connect to the Mac build server. I chose Tools > Options and under the Xamarin iOS settings looked for a Mac build host. Sure enough, there was the MacBook-Pro.local build server, and I clicked on it. That's all it took. I then had Visual Studio build the project, and the remote build went smoothly.
Xamarin has this process down to a science -- I never experienced any problems with the iOS builds. When I started the debugger, the iOS simulator appeared, and I was able to use Visual Studio to set breakpoints and step through the code. Considering all the layers of emulation and redirection, what Xamarin has accomplished is pretty amazing.
Using Visual Studio to debug an iOS implementation of an OpenGL app. Notice that Visual Studio has halted execution on a breakpoint, and that the variable, transY, has been updated (red).
Visual Studio, meet the iPhone Getting Visual Studio to download the app onto an iOS device did not go as smoothly. First, I had a different code-signing issue, which I tracked down to having to specify the app's signing profile along with its bundle ID. On the Mac, both Xcode and Xamarin Studio can find and assign the correct profile based on the bundle ID information alone. But Visual Studio only sees the Mac as a build server and thus needs the profile information entered explicitly.
Next, when I plugged a USB cable into the iPad, VMware Fusion asked whether the Mac or PC should manage the USB port; I chose PC. Visual Studio failed to detect the device. Xamarin tech support quickly set me straight: Because the build and debug control is managed by the Mac, it needs to own the USB port. After I chose the Mac, Visual Studio detected the device and downloaded code to either the iPad or iPhone. I could set and remove breakpoints, single-step through source code, and watch variables change.
I could build Android apps in both the PC version of the Xamarin Studio and in Visual Studio, but I could not get the Android simulator to launch. I knew this issue had something to do with the VMware environment, because a vanilla install of the Android SDK from the Google site exhibited the same problem. VMware helped me sort it out: Before you install the Android Developer Tools, turn off Shared Folders under VMware Fusion's Virtual Machines menu. Shared Folders allows you to easily share files between the Windows VM and the Mac, but it mangles a directory path that Xamarin Studio and Visual Studio need to launch the simulator. As long as Shared Folders is turned off, you can use the Android simulator.
Xamarin's tech support was very good. Reps often responded within hours of a query -- once, within 15 minutes. Also, the company issues frequent updates. It seemed that every time I launched the tools I got messages to download patches. On the downside, the documentation appears to be a work in progress. For a number of areas the online reference material displayed the message: "Documentation for this section has not yet been entered."
Xamarin offers its SDK in various flavors, ranging from free for the extremely limited Starter edition to $1,899 for the full-featured Enterprise edition. Note that it is all too easy to run into the 32KB code limit on the Starter edition. If you want to experiment without code restrictions and with Visual Studio, you'll need to register for a trial version of the Business edition.
Xamarin's toolkit is pretty compelling. It opens app development of the most popular mobile platforms to C# developers, and it lets you bring existing C# source libraries along for the ride. It provides the means where you can wrap such code with a UI native to the target platform. Finally, the SDK lets you use either Xamarin Studio or Visual Studio for C# development, and it allows the Mac required for final code generation to be shared.
You'll have to hire Android and iOS developers to handle the UI details, but if the plan is to deploy an app using C# code, then you've already discarded the hybrid app option and you'd be hiring those programmers anyway. Talented C# programmers seeking access to the rapidly growing mobile market will want to take a close look.
- Xamarin lets you write mobile apps entirely in C#, with no hacking necessary to access native iOS and Android APIs
- You can use Visual Studio to debug code both in simulators and on hardware
- Tech support responds promptly
- The Mac required for final iOS code generation can be shared
- Documentation is still not complete
- You still need a Mac for final iOS code generation
This article, "Review: Xamarin 2.0 works mobile development magic," was originally published at InfoWorld.com. Follow the latest developments in application development and mobile technology at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.
Read more about application development in InfoWorld's Application Development Channel.
This story, "Review: Xamarin 2.0 works mobile development magic" was originally published by InfoWorld.
Apple's iPhone 8 will likely launch in September, despite other reports to the contrary.
Microsoft removes and depreciates features in its Windows 10 Creators Update that apply to commercial...
A review of 18 companies that offer free cloud storage
Three people from Illinois have sued Microsoft, claiming that the free Windows 10 upgrade they...
Developers require a powerful development environment, such as public cloud. They'll get what they need...
Catching an insider taking confidential information doesn't happen by chance, and policies and...
Old gear, bad locations and overcrowded volume top the poor choices that many companies make when it...