Libor Bešenyi (CTO)

Nowadays, many companies with proprietary Windows software face a challenge of how to get their know-how on the iOS platform. We have successfully verified every possibility in practice and we would like to share our experience.

Most Windows systems are built on the .Net platform. If we want to port these products to iOS, we have limited options, and each option has its advantages and disadvantages:

To better understand the complexity of the problem, let's see what the architecture of .Net application looks like:

We migrate only the application logic without user interface!

In principle, we cannot port .Net applications including UI and such port does not make sense anyway. Windows application can be web or desktop and mobile applications actually have their own operating philosophy and their own custom controls that have not yet been used in the existing system. Thus, we are reducing the volume of ported part to application logic.

XCode

If we find out that the application logic is not so complicated that it is necessary to use the existing code, we should certainly write iOS applications from the scratch and directly in XCode.

Xolution ICT recommends this option, if the situation allows it

Manual rewriting of a code (if applicable) is the only option. There are no instruments to port .Net code in Xcode:

• Objective C, although a relative of C# Syntex, but the lack of garbage collection (GC or references counter) prevents the automatic transcription of the code (perhaps there are tools to convert C/C ++), we have not verified these options)
• Swift is similar to C#, including GC, but the existing (open source) tools are generally unsuited to convert C# code > Swift

Summary:

 Impossibility to re-use the existing code

The need for additional know-how for Android version

 Fast, stable and nice looking application

Xamarin

In the case that we are not able to write a completely new application and it is worth to re-use the existing .Net code, the obvious choice is Xamarin.

If we can re-use the critical mass of .Net code, Xamarin is the perfect choice

Since there is the replacement for .Net layer in the form of MONO (or alternatively .Net core) running on iOS (and Android), it is not such a problem to replace the operating system, it is sufficient to replace the .Net layer:

However, we cannot avoid writing our own UI. This restriction puts emphasis on the quality of application that we want to port to iOS. If we have application layers (MVVM, MVC, MVP, ...), Xamarin is a great choice (some advice on how to save time in developing applications can be found here).

If we are not able to abstract logic from the UI, let’s start directly overwriting application into Xcode

With minimal changes, we were able to run the core of application written and tested on Windows on iOS. It was the hundreds of thousands of lines of source code that could not be copied to the Xcode within a reasonable time.

Xamarin also supports a cross-platform version that runs on Android as well as iOS. We verified this in practice. It really works, but the UI is very limited and the application speed does not match the native code (rather Html5 applications).

Cooperative Software does not recommend cross-platform applications of Xamarin (Xamarin Forms), if User Experience effect is important

But that does not mean that two Applications, one for iOS and one for Android cannot be written in Xamarin. It is double work but the it is not necessary to multiply the know-how.  Find out more tips.

Moderately limited UI capabilities in comparison to the XCode (nothing dramatic)

Ability to use know-how when writing Android applications

Quick and actually working solution

It is already free (read more here)

Html5 & JavaScript

An alternative to using Xamarin (on the same terms - that is enough of usable code outside UI) is using JavaScript. As C # and JavaScript are syntactically related languages and both use the GC properties, there are relatively functioning tools to convert C# code into JavaScript (e.g. SharpKit).

We cannot avoid writing our own UI. Here we face the problem that we cannot make use of the native API operating system. So we are limited in the use of devices such as the Camera. We can forget the requirements of customized operations with devices such as GPS, cameras and the like. We also encounter a problem with browsers that for security reasons do not have access to the API operating system (working with files, etc.).

We recommend avoiding this solution, although that does not mean that the solution is useless

Another, not only marginal restriction is the JavaScript itself. Xamarin uses the code tested in Windows applications and its quality is guaranteed at the level of the original application. During the conversion of the code into JavaScript many „new" errors arise. We can only come across these errors when we get to the given strand of the program during testing. If all branches of the code were not tested, we can say with certainty that the application stops working when the user uses such area in the code.

UI limited to properties of the browser (not OS)

The need for intervention in the original C# code

Susceptible to quality testing (property of JavaScript)

Investment in SharpKit license

Multi-platform solution (supports Android / iOS, though not painless)