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.
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 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
Impossibility to re-use the existing code
The need for additional know-how for Android version
Fast, stable and nice looking application
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).
Xolution 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)
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
UI limited to properties of the browser (not OS)
The need for intervention in the original C# code
Investment in SharpKit license
Multi-platform solution (supports Android / iOS, though not painless)