App development or Application development is usually divided into two types: Web App and Native App development. Both of these two modes have their own advantages. Whether to use Native App development or Web App development has always been the focus of debate in the industry. However, with the development of HTML5 and the popularization of cloud services, it is becoming a trend to use HTML5 for Web App development. Users can choose according to application characteristics and needs, or choose a mixed mode of the two.
Today mobile apps are becoming more and more popular, and what to choose whether native App or web app development has become a concern for many businesses. This article will analyze and explain which App development is suitable for the situation.
Table of Contents
Difference between Web and Native app development
Native App Development
Native App development is what we call the traditional App development mode (an app that is specifically built for smartphones). This development is developed with different languages and frameworks for different smartphone operating systems such as IOS and Android. All the UI elements, data content, and logical framework of the application are installed on the mobile terminal.
Web app development
Web App development is a framework-based APP development model (HTML5 APP framework development model), which has the advantage of cross-platform development. This model usually consists of two parts: “HTML website + Application client”. You only need to install the framework part of the application, and the data of the application is fetched from the cloud and presented to the smartphone user every time the browser/app is opened.
Differences between Native App Development and Web App Development models
Web App needs to develop an “HTML cloud website (Frontend)” and “Backend“. This type of application presents the following characteristics:
- Every time the App is opened, the UI and data must be obtained from the cloud server through the App framework.
- If smartphone users cannot access the Internet, they cannot access the data in the application.
- The Web App cannot call the hardware devices of the mobile such as voice, camera, SMS, GPS, Bluetooth, gravity sensor, etc.
- The access speed of the Web App is limited by the Internet access of the mobile terminal, and each use will consume a certain amount of mobile Internet traffic.
- The installation package of the web app is small and exquisite, including only frame files, and a large number of UI elements and data content which are just stored in the cloud.
- Web App users can access the latest real-time cloud data every time.
- Web App users do not need to update the applications frequently.
Native App needs to develop a “cloud server data center” and “App client”. In short, this type of Application presents the following characteristics:
- Whenever there are any changes in the app you need to update the application.
- The installation package of a native application is relatively large, including UI elements, data content, and logical framework.
- Smartphone users can access previously downloaded data in APP applications even if they cannot access the Internet.
- The App can call the hardware devices of the mobile terminal such as voice, camera, SMS, GPS, Bluetooth, gravity sensor, etc.
- The new function of the application update involves submitting to each application store for review each time.
Which one you should choose Web App or Native App development?
The Web browser is ubiquitous. The mobile browser is currently the only platform that supports access from various devices. Like the desktop Web, the mobile Web supports various standard protocols. Mobile Web is also the only platform for developers to publish mobile applications, which effectively connects various mobile interactions with desktop tasks; while developing Native Apps can make full use of the characteristics of devices, which is often done by Web browsers. Less than, so for a product itself, Native App is the best choice. The following sections discuss some of the main features of NativeApp.
When should choose Native App?
1. Pay for the app
There’s nowhere that says developers can’t charge a fee for a mobile web app, but for some reason, it’s often thought that a web app can’t or shouldn’t be charged. Due to historical reasons, paid services on mobile devices have encountered two obstacles:
2. Payment method
Entering a credit card number on a mobile device is cumbersome, and there’s no security on many older devices. A typical way is that if you need to charge for your application, you can reach an agreement with the operator to let the operator charge for your service on your behalf. This also means that you need to reach cooperation with multiple operators.
Another approach is to save the user’s credit card information on a secure website. Users can purchase application services by logging into the website. This process is less than ideal, as it means users can no longer purchase services directly from their mobile devices.
3. Mandatory share
Mobile operators will be commissioned. No matter whether the app is released through the operator or through the mobile device, they all provide a charging mechanism for the application. These operators and mobile devices will extract part of the revenue, and then give the rest to application developers, which also means that developers must abide by their market rules. It is usually very difficult to adapt to the market rules of operators and requires a lot of human resources. In comparison, the market rules for mobile devices are much simpler, but there are also many difficulties.
Applications and services that interfere with the interests of operators and mobile device developers will be blocked. In the past, sites that weren’t run by carriers and mobile device developers could have been shut down if their revenues were too conspicuous, but recently, that’s rarely happened.
If you want to charge for your Native App, then you have to accept this reality – you have to abide by other people’s market rules, and you have to give up some of the revenue.
4. Develop games
If you want to develop a mobile game, then you need to develop a Native App. Games are resource intensive and require many device APIs or platform APIs. Although there are currently several games developed entirely using Web technology that occupies a certain market share, they are still negligible compared to the Native App market share. Game users have high requirements for the visual and operational effects of applications. Although the mobile Web provides some simulated experience, it is still far from meeting the needs of users.
When developing a mobile game, you need to carefully consider which platforms your app needs to support. Fortunately, there are many tools that can help you push your game to multiple platforms, but it still takes a lot of manpower and material resources to complete these tasks.
5. Use the location function
The next function is the positioning function, which can determine the user’s current location information through GPS or signal detection. In the past, the user’s location information could only be viewed through Native App APIs, but now most mainstream mobile browsers have embedded W3C Geolocation API. Devices with WebKit installed, such as iPhones or Androids, or devices with Opera or Mozilla browsers, can obtain user location information.
I believe that the positioning function will bring many new applications for Web technology. If the Web browser can be properly used, Web developers can use the user’s location information and other content to develop more exciting applications. While this is not technically too difficult, it is subject to privacy protection regulations. We think of the web browser as the user’s entry point into the World Wide Web. Adding the positioning function means that some sensitive information is introduced into the website, which may lead to serious consequences. However, the location information displayed in the location-aware application must be authorized by the user. Of course, the user has the right to prohibit the application from publishing its own location information.
6. Use the camera
Cameras offer many possibilities for your application. In the past, mobile MMS (Multimedia Messaging Service) was used to process mobile photos. In other words, after you take a photo, you need to use MMS to send it to a server, and the server will process the photo accordingly and notify you of the result of the processing. This process is very time-consuming and quite complicated, and there is no guarantee of reliability.
By accessing the camera, Native App developers can simplify the process of taking pictures. Users can do some simple processing on the photos directly on the client side, and only upload the photos to the server when necessary, and it is transmitted through reliable HTTP. The W3C is working on an API to access the camera, but it hasn’t been officially integrated into the browser yet.
In many types of mobile apps, the camera is very useful, such as the story application, the short film shooting application, etc., the camera can be used to capture many important moments. In the near future, we can see that as long as a certain sign is photographed by the camera, the application can automatically complete the language conversion on the sign – this technology has begun to become popular in Japan.
7. Use sensors
Now more and more mobile devices have added a sensor function, which can sense the physical speed and gravity of the device, and transmit the perceived data results to the device. This device is often used to discern whether the setting has been flipped, and the application automatically adjusts the orientation of the screen based on the information received.
Sensors can be used to help users increase their sense of reality when interacting with the device; most mobile devices are handheld, and the application can adjust the content screen according to the orientation of the device, such as flipping the screen, or detecting physical movement, and can guess accordingly the environment in which the user is located. Take a simple example: For example, if the user is walking, the sensor can detect a slight movement or speed, and at this time, the user can be provided with a user interface with a large font, making it easier for the user to see the content on the screen.
However, developers should not rely too much on sensors, because sensors cannot distinguish which interactions are intended and which are not. Every mobile interaction needs to pass a “transport test”. When designing your interactions you must consider the user in a crowded car or train. Consider whether your app can properly handle the user shaking the mobile device if the user is in a crowded subway or driving a car. Usually, most developers don’t take these factors into consideration. Make sure to design an alternate solution for each task to handle mobile interactions in special scenarios.
8. Access the file system
If your application needs to save data locally, then you need to develop a Native App. For example, you want to save the user’s address book, phone or E-mail information, or save data obtained from other devices.
Accessing the file system often involves issues of security and user privacy protection. Malicious applications may modify data on your mobile device. A virus-carrying application can use the network of connections on the mobile device to spread the virus to many other mobile phones. Before the mobile application authentication mechanism was adopted, this kind of thing often happened.
On the other hand, mobile devices are becoming more and more personal, and a large amount of users’ personal information, as well as user’s friend information and business information, are stored on the mobile device. It’s a good idea to develop applications for this private information. But this also has certain risks, and using the data stored on the mobile device can provide users with more targeted services.
Developers must keep in mind that access to a user’s private data is only possible with the user’s authorization. We have seen many apps that use a large amount of users’ private data without user authorization, and are mistaken for spam or phishing apps, even though these apps are originally providing some very useful services. People’s misunderstanding of your application will affect the promotion of your service. If the operator receives too many complaints about your application, your service may be terminated, and other applications may even be implicated.
It is critical when accessing the file system not to access any user’s private data without the user’s authorization and this point is often ignored by most applications. W3C is developing relevant standard APIs for mobile developers, but the work has not yet been completed.
