How to Prepare a Cross-Platform Application Development - ByteScout
  • Home
  • /
  • Blog
  • /
  • How to Prepare a Cross-Platform Application Development

How to Prepare a Cross-Platform Application Development

Mobile devices such as smartphones, tablets, smart TV, and more general objects, are growing super fast last decades, they are more and more powerful, smart, and more connected to become essential tools in our daily life.
For some of us, mobile devices app programming looks like very hard and inaccessible stuff for one or some reasons. Hopefully, for you, we will help you to get ready to enter the future world of cross-platform development. This article contains a set of valuable advice that any newbie should acknowledge before doing the first step in this vast business. We assume that you have a little background in programming but this is not really mandatory for the next.

What is a cross-platform programming

There are several vendors in the market, three well-known and well established of them are iOS (for Apple), Android (for Google), and Windows Phone (for Microsoft). We talk about cross-platform programming when we want our app to target more than one vendor.

Cross-platform is

One code, multiple targets… The fact is not to have a specific code/project for each vendor, the goal is to write one common code and run it anywhere regardless of which platform your app will be deployed. This is the stuff of dedicated frameworks like Xamarin, ReactNative, Apache Cordova… to translate the original code to a native or hybrid app.

Native or Hybrid app?

We talk about the native app when the actual output running on the device is exactly the same as it comes from the vendor binaries. Your app will communicate with the device through specific APIs. APIs are essentially from Android SDK, iOS SDK, Windows Phone SDK, etc. A hybrid app is a mix of two styles: the container may be a native app but the content is displayed to the user inside a web view. A web view is a component supporting standard HTML5/Javascript like a normal web browser. Native apps are much powerful because they can access to all features exposed by the device (or to whatever the vendor allows us to use) while hybrid apps can’t really interact with the device features and be not able to use the full potential of the device hardware.

Vendor APIs

Each vendor exposes to developers a set of APIs to access device capabilities such as calling, messaging, contact listing, GPS capability, security, I/O operations, etc. There are so many APIs per vendor and the best way to know all of them is to go to the vendor API documentation.

Tools for cross-platform app development

At the beginning each vendor demands developers to use only a specific programming language and APIs in order to deploy the app to the vendor’s device. For example, if someone needs to build an iOS app, he needs to have a good skill on Swift or UIKit API programming language. This process becomes tedious in terms of app maintainability, the company needs to maintain as many separate projects as targeted platforms. To cope with this approach several projects arise from the community to bring the simplicity of cross-platform programming. At the same time, the goal is also to allow developers to use their actual skills to write programs and to generate the native binaries without any knowledge of any specific vendor programming languages. The most distinguishable projects are :

  • Xamarin – supported by Microsoft using c# or f#;
  • React Native supported by Facebook using modern HTML5, Javascript, ReactJS;
  • Ionic based on Apache Cordova and using HTML5, Javascript, AngularJS.

From intermediate language to native output binary

This is a very complex process under the hood. However, you can picture it as the following:

a) We assume that we are going to use Xamarin – the same applies to React Native or Ionic, only IDEs differ;

b) You write your program in C# using Visual Studio and use Xamarin SDK in order to call Xamarin API. Xamarin SDK is a set of provided libraries that allows you to operate at the high-level interface. It means that you don’t care about what devices or operating systems are really installed on the final target. At this stage, you just call the unified APIs and let the framework generate the right component at the end. c) The first part of compiling is the same as any .NET compilation process from the C# source code;

c) The first part of compiling is the same as any .NET compilation process: from the C# source code then the intermediate language output and finally the just-in-time instruction;

d) Xamarin cross-platform tools then act as a bridge between the last output of the previous step and the native tools to generate specific formats and calls the platform package builder (like ADB for Android) to generate the final .apk or .ipa archive;

e) Finally, it deploys to the vendor’s emulator or directly to a physical device;

f) At the end of the day, the end-user only sees your program running on every platform.
After you’ve made up your’s mind to the one suiting well your business, it’s time to discuss hardware devices investment.

How to choose the right hardware devices

iOS and Android are the most common platforms in the market and you have certainly envisioned deploying your app on the AppleStore or on Google Play store. When you’re targeting an Android device you can use either a PC or Mac device. Android devices are more accessible than Apple or Windows phone devices, Apple keeps the control of devices very closed so you must be aware of this restriction. In Android, you just have to turn on Developer Mode option on your device, connect it to your computer, and from the IDE you can choose to deploy directly to it.
However, when you’re targeting Apple devices, you need to have access to a Mac build host, this is a mandatory piece of Apple hardware (MacBook, iMac, Mac mini… where XCode was installed) reachable from your network in order to publish and test your app.

What is the role of a Mac build host

Before the *.ipa (the same as *.apk in the Android world) can be deployed to an Apple device, it needs to be signed by a trusted agent. To be a trusted agent, you need to subscribe to the Apple developer program and register your mac there, create a profile, and provisioning with devices. Once approved your mac can now be signed itself to your package. This is the role of a Mac build host.

You don’t need necessarily to do your development task on the build host, you can always use a Windows computer. But when the time comes to deploy the app, you need one reachable build host from your network. You submit all your package to the build host (it’s actually a very complicated process under the hood hopefully for us most of all the IDEs can do all the stuff for us). Then the build host gets back to us with the signed package. Unfortunately, there’s no workaround, if you want to develop the iOS app you need to have access to a build host.

How to choose your mac computer

As said earlier you need to have access to a Mac computer in order to develop iOS apps. Here arises a lot of questions from the newbie: which model to choose? at what price? investing in a new or second-hand Mac? If the budget is not your concern, you can invest in the latest new Mac, the latest is always better in terms of performance, capabilities, and compatibilities. Unfortunately, all the latest Apple computers are always very expensive and most of us can’t afford to buy one.

Fix your budget

Before seeing any ads you have to define the maximum amount of money you want to put in. The price of a Mac computer may be very different depending on the model, the year of release, the configuration, and so on. You can choose one of the following models: MacBook Pro, Mac mini, MacBook Air, Macbook retina for laptops (in this article, we’ll not discuss desktop devices because they are quite expensive and huge power consumption).

Which model to choose?

Let’s recall that the actual role of a Mac device is to act as a build host. We don’t need to use it to host all our development tools. It is just here for signing the package binary before the deployment. In order to do that, the build host should have XCode priorly installed. XCode can be downloaded for free from the Apple store (a free apple developer account is needed to download it).

A common question that can be seen on the web is when people ask for the best choice between Macbook vs Mac mini. Mac mini is a little alloy box (actually it is just the central unit) where was packaged a powerful set of configuration. It is the cheapest stuff over all the Mac models, you can get one good second hand as from $300.

Thus, some people argue that it is the best choice. However, you need to acknowledge that Mac mini doesn’t come with any additional accessories so you’ll certainly have to buy a keyboard, a mouse, and some connectors to plug in the device to a monitor.

MacBook is a well-known laptop from Apple and is very interesting for development purposes. They are powerful, lightweight, compact, silent, all-in-one devices and have good battery autonomy and less power consumption. Apple released several MacBook models, in this article, we’ll definitely advise you to deal with those having CPU core iXXX models. At the time of writing, September 2017, we think that former models with core 2 Duo processors are too old for modern projects (essentially when requiring a lot of multithreading).

Mac mini is the slimmest declination of MacBook and essentially designed for light usage. Despite that, it can be used as a full Mac build host. The price is approximately $500 in second hands devices. iMac is a desktop apple device and have the unit central behind the screen. One of the iMac’s benefits is the screen dimension which gives maximum visual comfort for those in front of the screen.

In mid of the year 2017, my choice went to the MacBook Pro mid-2012 for the following reasons: – mobility and autonomy: I need something that is easy to bring with me. That choice definitely eliminates the Mac mini option and any desktop computer – performance: rather than having a modern light device I prefer having a compact one that can handle much more loads.

The Macbook pro totally satisfies this condition compared to the Mac mini. – Budget: Last but not least. Since Macbook Pro mid-2012 is an older version compared to the next generation with retina monitor, the price is more affordable because I got mine for $300. The configuration is also interesting: Intel core i7 2.5, two SSD storage 1TB, 8 GB of RAM, optical DVD/RW drive, 192 battery cycles, and the 15-inch screen.

My feedback after 01 months working on MacBook Pro mid-2012 I didn’t regret my choice and I can tell that it was one of the best deals I’ve ever realized (even if there are few dents on the body). The computer itself can take a lot of loads, works silently, I didn’t notice any overheating moment and I’m able to install the latest Apple software. It is just amazing and perfect. It quickly adopted it as my daily computer. I have to note that its SSD storage also speeds up my work.

The power consumption is also minimal. When I use my windows computer with Visual studio and Android/iOS emulator simultaneously opened it consumes approximately 100watts, however, the same process takes only 20-25watts on the MacBook.

Having a MacBook is a good thing but is that enough for cross-platform development?

One limitation of MacBook is that you can’t use it if you’re targeting windows app or UWP platforms. The reason is that Microsoft didn’t open up the process for non-Windows platforms OS. So if you want to publish the app for Android, iOS, and Windows devices you need both mac and pc computers. Only Android is quite flexible because you can use either mac or pc. Each platform has also its own emulator.

Emulators allow us to test our app without having a real device. Although Android’s emulator executes exactly the same behavior as the android Rom device, windows and iOS emulator is not really executing the same behavior and the best practice always recommend that you need to test your app on a real device before publishing to the marketplace. One of the reasons is to see how the app behaves on different screen resolutions.

One of the reasons is to see how the app behaves on different screen resolutions. We all know how many kinds of devices exist on the market and they are quite expensive especially for Apple devices. Rather than having them all on your desk, I suggest you have one or two of them to test the basic functionalities. Testing on a real device will help you in your app submitting process.

12-Extra cost You also need to acknowledge the fact that you have to pay prior to publishing your apps on each marketplace. For google play store, the actual price is $25, one-time registration no lifetime. For iOS a developer license is $99 / year for individual developer and $299 for the company, the enterprise profile gives you some additional features like self-signing your app or using your own repository. The registration fees for Microsoft app is $19 one time registration for individual developer and $99 for the company profile.


About the Author

ByteScout Team ByteScout Team of Writers ByteScout has a team of professional writers proficient in different technical topics. We select the best writers to cover interesting and trending topics for our readers. We love developers and we hope our articles help you learn about programming and programmers.