Think Big, Act Small, Fail Fast and Learn Rapidly


Pros and Cons of Cross-Platform Mobile App Development

Key takeaways

  • Current implementation of cross-platform tools
  • Overview of popular cross-platform systems
  • How and where to benefit from cross-platform development
  • Common pitfalls and shortcomings of cross-platform apps
  • Comparison of different cross-platform approaches

The world has gone mobile. It has become a “must have” element for any organization, regardless of its size. Undoubtedly, some organizations can concentrate on only one mobile OS (operating system) and avoid all the other ones, yet it is important for many businesses to focus on a myriad of mobile devices with various operating systems. Gone are those days when you were satisfied with only having a mobile app. Today, it is important that the app must support Android gadgets, iPads, Windows Phone, Amazon Kindle, Tabs, BlackBerry, etc. 

One of the most challenging situations for app developers is, whether to develop a native mobile app or go for cross-platform. Of course, as a business, you require dealing with different types of customers who possess different types of devices. Therefore, you'd need to have a mobile app that could work seamlessly on almost all the platforms (i.e. Android, iOS, Windows, etc.)

What are cross-platform apps? 

In ideal scenario, cross-platform apps work on multiple operating systems with a single code base. There are 2 types of cross-platform apps:

  1. Native Cross-Platform Apps
  2. Hybrid ‘HTML5’ Cross-Platform Apps

Native Cross-Platform Apps

Every major mobile operating system has its own SDK (Software Development Kit) to create mobile apps. These SDKs also have preferred programming languages which are supported by the OS vendor. For example, for iOS, Objective-C and Swift are the preferred programming languages supported by Apple, whereas for Android, Java is the preferred language supported by Google. Generally, apps created with these languages using the official SDK are called as “native apps”.

However, it is possible to use APIs (Application Programming Interface) provided by the native SDK, in other programming languages which are not supported by the OS vendor. This is how “cross-platform” native apps are created. Generally, a third party vendor chooses a programming language and creates a unified API on top of the native SDKs provided by the various OS vendors. Using this unified API, it is possible to support multiple operating systems with a single code base. The third-party vendor generally provides an IDE (Integrated Development Environment) which handles the process of creating the native application bundle for iOS and Android from the single cross-platform codebase.

Since, the final app produced still uses the native APIs, the cross-platform native apps can achieve near native performance without any visible lag to the user.

Current State of Implementation

Though creating cross-platform native applications is possible today, the current state of implementation is far from complete. Most of the mobile apps are heavy on the GUI (Graphical User Interface) implementation side. Almost all the critical business application logic resides on the server which is accessed by the mobile via web services.

Since the User Interface (UI) and User Experience Design (UXD) of iOS and Android are quite different from each other, it’s not an easy task to create a uniform GUI wrapper on top of it. Though Xamarin and others have put in significant work on this front, it is far from perfect. It works well if you design your application to live within the framework’s limitation, however, if you need anything that doesn’t fit with the framework’s vision, it requires a lot of work to implement and requires writing platform specific code. To give you an example, in Xamarin Forms, it takes a lot more work if your designer chooses to give custom colored borders to text fields. As this is not obvious to the designer, once you have settled in on the design, the programming team needs to put in a lot of efforts to pull off this seemingly simple design. Xamarin is working hard to provide more advanced cross-platform UI components under their Xamarin Forms Labs project. But many components of this project are still under beta status.

One popular approach taken in native cross-platform development involves writing business logic and web service calls using cross-platform libraries while GUI related code is written with platform specific libraries. Depending on the application, this can allow 30% to 60% code reuse.

Popular Native Cross-Platform Frameworks

    1. Xamarin: A California-based software company, which now is backed by Microsoft, founded in 2011. Xamarin uses C# as the main language for the cross-platform development. C# is a statically typed language with mature tooling and IDE support. Also, many big companies have C# programmers already in their in-house IT departments. So,  enterprises tend to regard Xamarin as a good investment.
    1. Appcelerator Titanium: One of the earliest players in this domain. They launched iOS support in 2009 while Android support was added in 2012. Appcelerator Titanium uses JavaScript as the main language for development and aims at bringing familiar web development paradigms to native mobile application development. However, it somehow didn’t capture the mainstream attention but lots of applications development is happening on top of it. Appcelerator also has a proprietary paid MBaaS (Mobile Backend as a Service), which it is pushing more. In the early days, Titanium had quite a few issues which were discussed widely in the blogosphere. This may also have hampered its adoption.
    1. NativeScript:Like Titanium, NativeScript aims at making web-like programming available to app development. NativeScript was announced by Telerik, a company which is famous for its suite of GUI components for enterprise applications in 2014. It uses JavaScript as the main development language. Native script also supports TypeScript, Angular and uses CSS for styling. Compared to the other technologies mentioned above, NativeScript is relatively new but it has a lot of potential.
    1. QT: QT is one of the oldest cross-platform desktop development libraries around, released 21 years ago, in the year 1995. They added support for cross-platform iOS and Android applications in 2013. QT uses C++ along with QML (Qt Meta Language or Qt Modeling Language- it’s a markup language similar to HTML) to create cross-platform applications. However, QT GUI components, by default, don’t follow the look and feel of iOS and Android. Also, C++ is not an easy programming language because of its huge syntax, manual memory management and standards compatibility issues. However, in the hands of experienced C++ programmers, QT can be quite productive.
  1. RubyMotion: RubyMotion is the main language for the development. One of the early players in this domain. When first announced in 2012, it was for iOS only, but supports both iOS and Android, since 2014. Rubymotion requires separate GUI code for iOS and Android, however, business logic can be reused across-platforms.

Hybrid ‘HTML5’ cross-platform Apps

Mobile apps are essentially GUI applications. Most mobile apps depend on backend web services for large parts of their business logic. Roughly speaking, in mobile apps, especially in the business process automation domain, almost 60% of the code deals with creating and managing the GUI.

iOS, Android and Windows Phone, all have a very advanced browser component in their SDKs. By leveraging this WebView component, programmers are able to use standard HTML5 web technologies to design and program parts of their application. So in the end, the application is composed of at least a native frame and HTML/JavaScript executed in a WebView – which is why they are called “hybrid”. Application features which need sensor input like geolocation, camera or lower level functions like accessing the file system usually use some JavaScript-to-native bridge provided by the hybrid application framework.

 The image below shows the architecture of a typical hybrid application:

Cordova / PhoneGap

Apache Cordova which was originally named as PhoneGap (launched in early 2009) is the most popular hybrid cross-platform framework. It supports most of the major modern smartphone operating systems. Since in hybrid cross-platform frameworks HTML and CSS are used to create GUI, almost all of it can be used across different operating systems. With libraries like framework7 ( it is also possible to support the underlying operating system's default look and feel using CSS-based themes.

In hybrid applications the HTML, CSS and JavaScript code is shipped along with the application. Therefore, there is no delay in loading the UI related code, like you would experience it when loading websites over the network. On modern powerful phones, it’s possible to create a snappy UI with HTML5 technologies. Especially for B2B apps, it’s possible to have 85-90% code reuse across-platforms with Cordova.

The image below which will help to put all the mobile app development options in single perspective:

To summarize, here are the pros and cons of the cross-platform mobile app development:

Pros of cross-platform mobile app development

    1. With careful planning around 50%-80% code reuse can be realized across-platforms. This results in faster development and reduced costs.
    1. Cross-platform development provides more benefits during the maintenance period. If a bug is found in a common codebase it needs to be fixed only once.
    1. Unit tests are required to be written only once for the common code, hence the saved budget can be used to write more thorough unit tests.
    1. It is possible to use existing programming talent rather than learning platform specific development language.
  1. Ideal for B2B apps and business process automation apps, where time to deployment and efficient utilization of resources is more important than sleek look and feel.

Cons of cross-platform mobile app development

    1. In general, phones are not as powerful as desktops when it comes to raw processing power. Many mid-level and entry level phones don’t have enough hardware power to perform smooth HTML5 animations. Because of this HTML5 hybrid apps can lead to sluggish UI on low and mid range phones.  Also since browser components have evolved with the operating systems, it’s relatively painful to support operating systems which are more than three years old.
    1. Rendering modern HTML and CSS which uses advanced features like gradients requires a lot of CPU and GPU resources. Thus, HTML5 based apps consume significantly more battery compared to native apps or native cross-platform applications.
    1. Usually, HTML5 hybrid apps depend on callback-style programming to communicate with native plugins, which makes the code unnecessarily complicated. Also for some tasks, this might lead to impractically slow solutions.
    1. Native cross-platform app SDKs are not mature yet. GUI needs to be coded multiple times to obtain platform specific look and feel.
    1. Many successful apps are developed as native apps (either Android or iOS) because designing and building an app for multiple platforms with platform-specific user experience is too difficult. This is due to all platforms defining their own human interface guidelines and supporting them with a single code base turns out to be very challenging.
  1. Mobile operating systems are evolving at a very rapid rate. Every year there are more and more features being added. This creates more work for the cross-platform SDK vendors who need to bring out new versions of their SDK within a short time after the release of a new operating system version. Sometimes, it also requires a lot of work on the developer’s part to upgrade an app to newer versions of the cross-platform SDK.

To conclude this in one line, even though native app development offers 100% platform compatibility and smooth performance, for B2B solutions and for business process automation projects, native cross-platform or HTML5 hybrid application development techniques can offer good enough performance in a more cost effective manner.



Tạp chí Lập trình – Khi trả lời câu hỏi “Lập trình mobile khác gì với lập trình trên nền tảng PC?”, thì có đến khoảng 90% các bạn lập trình viên sẽ nghĩ ngay đến 2 vấn đề “Memory’ – Bộ nhớ và “Performance’ – Tốc độ xử lí. Điều này rất dễ giải thích vì các bạn đều biết mobile là một thiết bị với giới hạn về tốc độ xử lí của chip (CPU) và dung lượng bộ nhớ trong (RAM).

Nhưng trong bài viết này tôi sẽ đề cập đến một vấn đề khác cũng không kém phần quan trong trọng và thực sự là khác biệt của lập trình mobile. Đã có rất ít bạn khi mới làm quen với lập trình mobile để ý. Đó là vấn đề “Competition” – cạnh tranh. Để có một ứng dụng tốt thì nhất định phải giải quyết được cả 3 vấn đề trên.

Vậy Competition trong lập trình mobile thể hiện như thế nào? Tôi sẽ lấy các ví dụ và cách giải quyết bài toán trong Android để giải thích khái niệm này.

Vì trong một bài viết không thể nói hết được một vấn đề lớn của lập trinh mobile nên tôi chỉ mong có thể giải thích khái niệm và cơ chế hoạt động chứ không quá đi sâu chi tiết về coding.

TH1 : Các bạn đang nghe nhạc thì có một cuộc gọi đến. Nhạc sẽ tắt để bạn có thể trả lời cuộc gọi. Sau khi cuộc gọi kết thúc nhạc sẽ lại tự động được bật lên.

Trong tình huống này ứng dụng nghe nhạc đã phải tạm dừng để ưu tiên cho ứng dụng gọi điện được hoạt động. Khi kết thúc cuộc gọi thì ứng dụng nghe nhạc sẽ lại được hoạt động trở lại. Điều này không phải do hệ thống tự xử lý mà được xử lý trong ứng dụng nghe nhạc. Nếu bạn muốn tạo ra ứng dụng nghe nhạc của riêng mình thì đây là một điều cần chú ý nếu không người dùng sẽ vừa phải nghe nhạc và vừa nghe điện thoại J

Tương tự với các game, nếu bạn đang chơi game mà có cuộc gọi đến thì game của bạn sẽ phải tạm dừng, sau khi kết thúc cuộc gọi màn hình chơi game sẽ được hiện ra với một menu có nút resume để bạn chơi tiếp.

TH2:Khi các bạn vào ứng dụng contact, chọn call tới một contact các bạn sẽ thấy một danh sách các ứng dụng hiện ra (Call, Viber, Skype, …) bạn phải chọn một trong các ứng dụng để call. Tương tự với các trường hơp bạn mở môt SMS hay Mail mới. Tại sạo như vậy?

TH3: Bạn đang lượn lờ Facebook bằng điên thoại và ra khỏi khu vực có wifi. Ứng dụng Facebook sẽ thông báo “No Internet Connection’ để thông báo với bạn rằng mobile của bạn không còn kết nối với wifi nữa. Bạn sẽ ko view thêm được bất kì comment hoặc message nào nữa. Tại sao ứng dụng Facebook lại biết được khi nào mobile của bạn không còn kết nối với wifi?

TH4:Bạn đang xem một quảng cáo sản phẩm trong một ứng dụng. Bạn thích sản phẩm này và muốn liên hệ với cửa hàng đặt mua. Bạn click vào số điện thoại của cửa hàng bên dưới sản phẩm. Và thế là mobile của bạn calling đến số điện thoại đó. Và ‘a lô, xin chào bạn đến với cửa hàng….’. Tại sao ứng dụng quảng cáo sản phẩm lại có thể gọi ra ứng dụng call như vậy.

Để giải quyết tất cả các trường hợp cạnh tranh này Android đã đưa ra một khái niệm Broadcast Receiver. Vậy Broadcast Receiver là gi?

Broadcast receiver là một thành phần android cơ bản nó cho phép ứng dụng của bạn đăng kí lắng nghe các sự kiện của hệ thống hoặc của các ứng dụng khác.

Nôm na như sau, trong Android có một thành phần giống như đài truyền hình (broadcaster), nó có nhiệm vụ phát sóng (send) các sự kiện (events) tới các ứng dụng (broadcast receiver or receiver).

Các sự kiện (events) ở đây có thể là các sự kiện của hệ thống như incoming call, new SMS, low battery, wifi ON/OFF, Screen lock/unlock, time zone change… hoặc sự kiện do các ứng dụng thông thường tạo ra. Như vậy ngay ứng dụng của các bạn cũng có thể phát ra các sự kiện và broadcaster sẽ gửi nó đến các ứng dụng có trên thiết bị.

Để ứng dụng của bạn nhận được các sự kiện từ broadcaster như trên thì bạn phải biến ứng dụng của bạn thành một receiver. Có 2 cách để đăng kí một ứng dụng trở thành receiver.

Cách 1: đăng kí trong file AndroidMenifest.xml của ứng dụng

<receiver android:name=".MyWifiReceiver">
        <action android:name="" />

Intent-filter định nghĩa ra một loại message thông bao sự kiện trạng thái wifi thay đổi (WIFI_STATE_CHANGED) và đoạn code xml trên đã đăng kí ứng dụng nhận các thông báo liên quan đến sự thay đổi trạng thái của wifi.

“MyWifiReceiver” là một class extends BroadcastReceiver class và bạn phải overwrite hàm onReceive(). Class MyWifiReceiver sẽ nhận và sử lí intent-filter trên trong hàm onReceive()

Cách 2: đăng kí trong code, sử dụng hàm Context.registerReceiver()

context.registerReceiver(new BroadcastReceiver() {
    public void onReceive(Context context, Intent intent) {
        try {
            int wifiState = intent.getIntExtra(WifiManager.EXTRA_WIFI_STATE, WifiManager.WIFI_STATE_UNKNOWN);
            switch (wifiState) {
                case WifiManager.WIFI_STATE_DISABLING:
                    // DO SOMETHING HERE
                case WifiManager.WIFI_STATE_DISABLED:
                    // DO SOMETHING HERE
                case WifiManager.WIFI_STATE_ENABLING:
                    // DO SOMETHING HERE
                case WifiManager.WIFI_STATE_ENABLED:
                    // DO SOMETHING HERE
                case WifiManager.WIFI_STATE_UNKNOWN:
                    // DO SOMETHING HERE
        }catch (Exception e) {
},new IntentFilter(WifiManager.WIFI_STATE_CHANGED_ACTION));

Bạn cũng có thể gỡ bỏ đăng kí broadcast receiver bằng hàm Context.unregisterReceiver()

Có rất nhiều các sự kiện mà ứng dụng có thể đăng kí lắng nghe như đã nói ở trên và mỗi loại sự kiện sẽ tương ứng với các action khác nhau. Bạn có thể tham khảo trong link sau.

Bây giờ tôi quay lại giải 4 trường hợp đã nêu ra ở trên để cho các bạn có hình dung thực tế hơn.

TH1: Ứng dụng nghe nhạc sẽ phải đăng kí một receiver để lắng nghe sự kiện incoming call và end call.

<receiver android:name=".PlayerReceiver">
        <action android:name="android.intent.action.PHONE_STATE" />

Xử lí khi bắt được sự kiện incoming call va end call trong class PlayerReceiver

public void onReceive(Context context, Intent intent) {
    String state = intent.getStringExtra(TelephonyManager.EXTRA_STATE);
        //Phone is ringing à Stop service play media
    }else if(state.equals(TelephonyManager.EXTRA_STATE_OFFHOOK){
        //Call received
    }else if (state.equals(TelephonyManager.EXTRA_STATE_IDLE)){
        //Call Dropped or rejected à Restart service play media

TH2:Khi các bạn vào ứng dụng contact, chọn call tới một contact các bạn sẽ thấy một danh sách các ứng dụng hiện ra (Call, Viber, Skype, …) bởi vì tất cả các ứng dụng trên đều đăng kí nhận sự kiện outgoing call của hệ thống. Vì vậy khi bạn chọn call tới một số nào đó trong contact thì cả 3 ứng dụng này đều có nhận được message outgoing call và tất cả đều có thể start để thực thi cuộc gọi. Lúc này hệ thống sẽ đưa ra danh sách các ứng dụng trên cho người dùng lựa chọn. Nếu úng dụng của bạn đăng kí nhận sự kiện ACTION_NEW_OUTGOING_CALL thì nó cũng được hiện thị trong danh sách ứng dụng trên cùng với Call, Viber, Skype,…

TH3: Ứng dụng Facebook đã đăng kí nhận sự kiện WIFI_STATE_CHANGED vì vậy khi Wifi bị tắt hoặc device đi ra khỏi khu vực có wifi thì ứng dụng sẽ nhận được sự kiện này và hiển thị thông báo “No Internet Connection”.

TH4: Bạn click vào số điện thoại của cửa hàng bên dưới sản phẩm. Và thế là mobile của bạn calling đến số điện thoại đó. Lúc này ứng dụng của bạn sẽ gửi đến hệ thống (broadcaster) một message với action là ACTION_CALL. Hệ thống (broadcaster) sẽ gửi message này tới các ứng dụng. Ứng dụng nào đăng kí xử lí message này thì sẽ được mớ. Trong trường hợp này ứng dụng call sẽ được start. Và người dùng có thể gọi đến số điện thoại ghi trên quảng cáo. Thật là đơn giản phải không. Tương tự như vậy bạn có thể gọi ra các ứng dụng khác như SMS, Browser, …có sẵn trên thiết bị.

Bạn cũng có thể tự định nghĩa ra các sự kiện của riêng mình và gửi chúng đến các ứng dụng khác có trên thiết bị hay chính các ứng dụng khác của bạn. Tôi có thể gợi ý cho các bạn một ví dụ sau.

Bạn có 2 ứng dụng đọc sách và từ điển. Trong ứng dụng đọc sách có thể gửi message do bạn đinh nghĩa ra tới hệ thống (Broadcaster). Hệ thống sẽ gửi message này tới tất cả các ứng dụng nhưng chi có duy nhất ứng dụng từ điển của bạn đăng kí nhận xử lí message này. Và thế là ứng dụng từ điển của bạn được mở khi bạn đang đọc sách.

Tôi xin dừng lại ở đây và hi vọng với các giới thiệu tổng quan ở trên các bạn đã phần nào hình dung ra cơ chế hoạt động của broadcast receiver và một số tình huống cơ bản hay gặp khi làm việc với nó. Các bạn có thể tham khảo kĩ thuật chi tiết hơn trong các link bên dưới đây.