Common mistakes in cross-platform development
The best way to learn is to make mistakes. Each mistake builds up experience. And experience has value only if it is shared. Here are a few things that I learned while developing applications.
File Name
Weird as it may sound, File naming will affect you in the weirdest way possible if you are not careful. Because most OS’s don’t behave the same way. For example, Any UNIX based OS would have a case-sensitive file name. Means Linux, iOS, Mac would recognize Image.png and image.png as two different files. While Windows and Android recognize both as the same file. Now, how this cause a problem? For starters, if you saved a file using capital and trying to read the file using lower case Windows and Android will work as intended even if the mistake is from your end. But in the case of iOS, Linux, Mac you will get “file not found” exception. Maybe after a few hours of smashing your hair to the wall, you will realize it was a simple typo on a string. One good practice would be never hardcoding your strings in. Always keep separate classes to manage these strings. And make them read-only. This will eliminate any kind of typos. Also, it makes changing strings a lot easier. Another type of error you will get into if your development team is using different OSes. Git pushes and pull’s would really get messy if you make a mistake in naming. If you have a class name called “Calculator.cs” and it’s pushed in git. And someone from the UNIX side decides to change it into “calculator.cs” and pushes it to the git, you will end up with 2 separate files on UNIX and only one file on Windows. If you ever decide to have multiple development environments it would be wise to keep these in mind.
Design
One of the fundamental reasons you would like to develop a cross-platform application is that you would like to code only once and deploy everywhere. Now here the challenge comes. Let’s just stick with mobile devices for now. And by mobile let us start by discarding Windows Phones. So we have iPhone and Android at our hands. Now here are some fundamental points that need to be addressed properly. We are doing generalization. Focus on things that both worlds have.
Navigation: iOS doesn’t have navigation buttons. Android provides navigation buttons physically or virtually. So if your design doesn’t have a navigation system built into it, you are probably going to regret when you are trying to deploy on iOS because you will have to re-design a few parts which could have been avoided altogether if proper design decisions were made. It’d be wise to have navigation built into the UI. So you can totally ignore Androids extra navigation features and still function properly in iOS.
Notch: Now almost every new phone has a notch. and each one of them is different. A new headache for the designers. Android system is very generous you can basically tell the OS specifically not to draw outside of the safe area and it will create a blank border around the notch. No design change is required also it doesn’t really look bad. But in iOS not only there’s no such option but also they literally forbid you to do such a thing. You have to consider notch in your design. So yeah if you are planning code once route best course of action would be to have a proper design idea for the notch. It’s not something you can ignore. The good news is iOS does have API’s to let you know the area of the notch just like Android. So yeah It’s possible to dynamically handle this on both platforms.
Plugins
Eventually, you will need to use some sort of 3rd Party Library in the project. First of all, you need to ensure that it’s cross-platform builds are available or the source. For example, I wanted to use renowned Newtonsoft JSON or now known as JSON.NET for serialization and deserialization in one of my projects. I just grabbed the DLL file and went to code. After building it for android it worked as intended but for iOS, it didn’t. It took me a while to realize why this happened. iOS requires me to use IL2CPP as scripting backend and it used AOT compilation whereas Android’s MONO backend used JIT compilation. But the plugin I used was compiled using JIT. That’s why It wasn’t working on iOS. I had to find an AOT compiled version for the iOS. Finally, it worked. So be careful when you are using 3rd party libraries for your cross-platform application. It might not be plug-and-play. Alternatively, you can target only AOT as android supports it too that way you won’t have to worry about multiple libraries builds. This is only required if you are using C# otherwise you would probably end up using NDK anyway which will force you to AOT.
Hardware
In case you are planning to use devices sensors like Accelerometer or the Magnetometer you need to be a bit careful. Something that works fine on android might not work on iOS. Something might more initialization time than the other. So test your code on both types of devices until you are sure it works on both platforms.
Environment
In a sense, it doesn’t really matter which OS you use to develop your application. But in case you are specifically targeting iOS as a deployable platform you should use a Mac. Here’s why you need XCode to build for iOS. and XCode is only available for macOS. Almost every too you need to develop is available on Mac. Even Visual Studio is on Mac now(Well a version of it is). Well anyway, this will save you a lot of time. Because you won’t have to switch back and forth for each time you need to build your application for iPhone to test. Otherwise, you will find yourself in a very bad position when building for iOS. You can still build APK in macOS so there’s no problem in developing Android applications in there. Since you have Visual Studio and .Net Core you can easily develop .net applications too. Yeah, Microsoft has become really generous about their platform and caring a lot about Opensource Cross-Platform development. In summary, I recommend using macOS for cross-platform development if you are planning to deploy anything on iOS.
NOTE: You can still build executables for macOS from other OS.
