After examination of the present native mobile app development challenges in part one and the introduction in Xamarin in part two of this blog series, the final part comprises insights and learnings out of direct project practice.
In the last months we collected various insights into the implementation of an iOS and Windows 7 client using Xamarin.
Basically we can anticipate that the experience was predominantly positive. Nevertheless we must mention flaws that should be considered prior a project launch.
Advantages – General
• A platform neutral code-basis up to 50% – 70% is achievable.
• It is possible to parallelize web development (incl. backend) and frontend development teams by the separation of UI and business logic.
• As a Xamarin Partner (Premium Status) leads could be passed on.
Advantages – Technical
• Complete Two-Way Data Binding is available.
• A strict separation of UI and business logic is enforced.
• Theoretically it is possible to maximize the Code-Sharing proportion up to 100% using Xamarin Forms
• The used toolchain is known and technically mature. Visual Studio, TFS, Jenkins, Git, etc. (Xamarin Studios is not listed but has to be used on Mac)
• In case there is a productive .NET backend, the existing data model inclusive logic can be used for the client development.
Unfortunately, beside these positive aspects we also discovered a bunch of unpleasant peculiarities:
Disadvantages – General
• Out of an Android and iOS point of view one gets caught in the Xamarin Ecosystem. The existing codebase cannot be used further in case of changing to a direct native iOS or Android development later on. As a consequence the whole client has to be redeveloped.
• Visual Studio as Windows IDE is sufficient. Xamarin Studio, which is required for development on Max OS X, is not as mature as Xcode or AppCode and can be frustrating.
• Apple’s instruments – one of the most helpful iOS development tool – is near entirely useless because the .NET Runtime is blackboxed for this application. Only less important attributes can be monitored. Thereby it is referenced on Assembler-References in general. This circumstance withdraws an important optimization and analysis tool from the developers.
• We encountered several app crashes that I haven’t experienced during my four years classical iOS development not even once.
Disadvantages – Technical
• The Xamarin-“Overhead” respectively its footprint increases direct proportional to the amount of linked APIs and slows the app launch down.
• Platform specific and C#/.NET architecture-concepts are mixed. Therefore the client-specific implementation has to be reconsidered.
• Xamarin related bugs are possible because of an additional layer in the toolchain (https://bugzilla.xamarin.com/buglist.cgi?quicksearch=*). These bugs can cause not reproducible app crashes.
• The threading deviates from the known platform specific behavior. The Grand Central Dispatcher (Mac OS X and iOS) is not available for instance.
• Although an existing KeychainItemWrapper, the keychain access is unstable on iOS systems.
• XIB’s has to be modified on Xcode. Changes will be adopted by synchronization between Xamarin Studio and Xcode (IBOutlets etc.). If this process fails it has to be initialized manually.
Outlook
Xamarin Forms is a further attempt to transfer the platform specific UI code into platform neutral code. A nearly platform neutrality could be theoretically achieved by a new API which provides pages, layouts and controls. Unfortunately this is not sufficient for complex GUIs because a generic UI, based on the greatest common factor / similarities, will be established again.
Conclusion
As often the world is not black and white. Therefore Xamarin cannot be recommended unconditionally but it’s neither a further unsuccessful Cross Platform Development approach. The decision to use Xamarin depends on the project specific conditions and requirements. After our first huge Xamarin project we acquired the needed know-how to support you as a potential customer in the decision-making process.
A special thanks to my colleagues Tobias Baube and Christoph Bühler which personal experiences greatly contributed to the advantages and disadvantages in this post.
Author of original german version: Alexander Maier
