Someday, the lack of basic knowledge about mobile applications will probably become bad manners. In the meantime, let's talk about what kind of applications there are. Coming from afar, we can distinguish only three types: what is a native application, web application and hybrid.
Do you know what a native application is?
For the user, native applications are those that require installation. In general, this is true, as is the fact that such applications are developed specifically for mobile platforms (iOS, Android, Windows Phone). Therefore, the developer is required to have programming skills in a specific development environment (xCode for iOS, eclipse for Android).
The result is a pleasant appearance and seamless interaction of the application with the mobile OS. A native app is also far ahead of both a hybrid and web app when it comes to security. Such applications with the least resource consumption use the camera, microphone, accelerometer, player and other functions. Conventionally, a native application can be divided into two groups: applications that require an Internet connection, and offline applications.
Web apps are different from a native app
Using a regular website on a smartphone is inconvenient at best; at worst, the site’s layout falls apart, and after that it’s completely impossible to work with it. Web applications are created for the purpose of using a website from a phone. So, in essence, this is the same site optimized for mobile devices. Unlike a native app, web apps don't need to be installed - they run in your phone's browser. Therefore, absolutely nothing depends on the phone model (on the mobile platform, to be more precise). Also, regardless of the platform, web applications cannot work with native phone functions.
But what then is a native app compared to a mobile website? The line between a web application and a mobile site is very thin. And in this matter, it’s not just the users who are confused, but in some cases the developers themselves. But there is a difference. Conventionally speaking, the site contains more or less static information, and is something like a digital brochure. In a web application, the user can manage some part of this information - create their own pages, swap links, texts, etc.
So it’s easier to call everything that is commonly called online services web applications. A web application can also be called something that was once done in Flash, and now in HTML5.
Hybrid apps
A hybrid application is called hybrid because it combines some of the functions of a native application and a web application. This is a cross-platform application that can work with phone software. These applications, just like native ones, are downloaded from the application store, but the data is updated autonomously. Therefore, they always need an Internet connection - without it, web functions do not work.
What to choose? native app, hybrid or web?
Developing a hybrid app is cheaper and faster than creating a native app. But users won’t notice the difference anyway. Therefore, hybrid technologies are the most popular. Despite all this complexity, deciding on the choice of technology for developing an application is very simple. If your application cannot work without the native functions of mobile devices, if high data processing speed is very important (games, social networks, geolocation), then nothing better can be found than a native application. When speed can be neglected, a hybrid application is suitable. A web application should be created when the user does not need anything from you other than the information that he could get from his phone if he had the Internet.The following statement could easily come from someone who has just started learning Titanium:
JavaScript?! How's Phonegap? No, I'd rather make a native application.
Of course, I had similar conversations with clients when I was a freelance developer on Titanium. And of course, as a Developer Advocate, I hear this often when I start explaining Titanium to developers who are looking for a cross-platform solution for creating applications.
Titanium !== HTML
Every time I compare it to Phonegap (Cordova), Ionic, or anything else, I start shaking my head, waving my arms, and screaming loudly about how Titanium doesn't have HTML.Titanium applications are not websites that are miraculously wrapped in applications.
But when communicating with clients or less tech-savvy people who associate JavaScript with these technologies, thinking of HTML as just another technical term doesn't always help. Also, defining Titanium as something it is not is not entirely correct.
What do you mean by "Native" development?
In response, I began to ask:What makes an application native?
Maybe that's what...
- Is the developer using tools provided by Apple, Google and Microsoft?
- Is the developer using a platform-standard language?
- Does the application use building blocks (APIs) that the platform provides?
- Does the application perform as the user expects on this platform?
What is a good User Experience?
So what does platform-appropriate UI and UX mean? Well, first of all, we don't care about technology, only about what it gives us; How the application looks and feels to the user. Secondly, the behavior of the application depends on the platform.Looks and behaves as expected
iOS, Android and Windows have different design requirements (iOS , Android ,Windows) and if you build on them, your app will be more predictable and therefore easier to use.A great example is TabGroups. On Android, they are usually built into the Action Bar and will scroll if there are a lot of them. On iOS, the Tab Bar is located at the bottom and if you have more than five tabs, the fifth will lead to the screen for selecting the desired tab. On Windows, Pivot Tabs work almost like on Android, but they look a little different; they are not part of the Command Bar, which is located at the bottom of the screen.
So the technology that is used to develop a native application should not have its own UI controls, instead it should use those provided by the platform.
Titanium has cross-platform APIs for almost everything, and it always translates them into platform UI components. For example, Ti.UI.TabGroup will give you the result as in the picture above, but you will write one code (Alloy):
For those APIs that are not present on all platforms, we use namespaces such as Ti.UI.Android.CardView.
Common APIs where possible, platform-specific APIs where not. Always with respect to the target platform.
Feels expected
But there is another, less noticeable factor that affects UX. Interaction with the application should evoke the right feelings. What we mean by this is that the response time and visual response are what you expect from the platform.Historically, this has always been a big problem for cross-platform development. All solutions one way or another have some level of abstraction over platform APIs. This is a potential bottleneck. At Titanium, we spend a lot of time optimizing. Take ListView for example, it can be 60% more responsive than its ancestor, TableView.
In applications that use HTML, this continues to be a problem. The flat interface does everything to make these apps look good, but it doesn't take a rocket scientist to notice the difference in how the UI responds to interactions. Often it’s just “not like that,” and that’s the job of UX: to make it “like that.”
How to achieve great UX?
Above all else, you need a great developer. Bad apps can be made in XCode with Swift, so no doubt you can make them using any (cross-platform) technology. Use the right platform-specific UI components in the right places, avoid memory leaks, write cleanly and intelligently.Plus, use the building blocks at your disposal, don't imitate them. Remember, Titanium !== HTML and our 4 bullet points. We confidently believe that for native UX you need to use native UI and system APIs. To achieve point No. 4, you need to complete point No. 3.
That's why Facebook abandoned HTML applications and created React Native.
And yes, we at Titanium have had this since 2009.
Code Strong, Code Native... In JavaScript!
Hybrid and native development: comparable?
Hybrid applications or native (from the English native - native)? This is one of the most important questions that a software customer has when he needs to release a new application for consumer use.
Let's start by defining each one. A hybrid application, as it sounds, combines elements of both native (the application runs without any external support) and Web (the application runs using a browser and is typically written in HTML5) applications. The application borrows cross-compatible web technologies such as HTML5, CSS and Javascript and uses some of its own code to be more responsive to the user's device. Hybrid applications are placed inside their own application where the WebView of the mobile platform is located (the browser included inside the mobile application, so to speak). Simply put, a hybrid application is a website that is packaged in an original wrapper. Examples of brands using mashups include Amazon App Store, Gmail, and Yelp.
A native application is developed for a specific mobile operating system (Objective-C /Swift for iOS or Java for Android) and is optimized to take full advantage of all the platform's capabilities (camera, contact list, GPS, etc.). Essentially, a native application is implemented using the platform's own tools. Examples of such apps include Starbuck, Home Depot, Facebook (although some disagree with the latter).
Let's look at some important considerations that will help you choose between a native or hybrid app.
Development cost
Hybrid apps are developed for many platforms. Identical HTML code can be applied and reused on more than one mobile operating system. Simply put, when you order the development of a hybrid application, your final product will work immediately on most modern smartphones and tablets. This way, your development costs are significantly reduced.
Native app development, on the other hand, requires writing completely different programs for each unique device. Unlike hybrid programming, which borrows from previous HTML5 experience on the web, native programming is often considered more specialized. Thus, the cost increases, which is impractical for small companies and individuals.
Time
Hybrid apps are often popular with companies looking to get something to the mass market as quickly as possible. Again, since the same HTML code is reused across different operating systems and only part of the complex machine code needs to be rewritten, the application will be ready to run on multiple devices as quickly as possible.
If time is not a priority, then native development may be right for you. Otherwise, a hybrid would be preferable.
Updates
Hybrid development allows you to update content directly from the Internet. If there is no sudden change in functionality, then the updates are almost unnoticeable. Many of these updates may not be installed through the App Store. This makes fixing bugs and adding updates more efficient and less frustrating for the user. However, there is one caveat associated with web updates.
A situation may arise where an application targets features of a mobile platform that no longer works because the plugin is outdated. When this happens, you are faced with a dilemma - you must either remove the application feature or hire a programmer to write a plugin. The same scenario applies when new versions of the mobile platform are released. If you want your app to be able to take advantage of new features, you again task the developer with creating a plugin to host the update, or you can wait for the community to create one.
With native development, you can update your app to handle platform changes and take advantage of new features without relying on ongoing community support for your plugins or being dependent on community release cycles. For hybrid development, it is necessary to carry out comprehensive consideration of the reliability of plugins in order to avoid unpleasant surprises in the near future.
Users
From the native application you can easily use the wide functionality of your mobile device: camera, microphone, GPS and much more. However, the user learning curve is small.
Native applications are also usually developed for use when there is no Wi-Fi or the ability to receive data from outside. The hybrid can also work in autonomous mode, you'll just have slightly fewer options.
It is worth noting that the response speed, other things being equal, is usually higher for native applications. This is often felt by the user in a gaming environment that is dependent on graphics performance. This is true even when the hybrid app uses HTML5 Canvas and WebGL. The difference in speed is a fraction of a second – it’s up to you to decide whether it’s critical or not.
Safety
Hybrid critics may cite JavaScript injections or SSL vulnerabilities, but if you have secured your site, then this is not your concern. However, hybrid applications have more publicly available knowledge information, making the reverse engineering process more likely. They also depend on plugins, which make up an additional layer of code where a security vulnerability can potentially be found.
Native apps use their own security features without plugins. Thus, for applications that require a high level of security, native development may be more preferable. For all other business application needs, hybrid development offers a completely satisfactory level of security.
Cross-platform compatibility
It's simple here - This is where hybrid apps win: a native app developed for iPhone will not work on Android, and vice versa.
Conclusion
Are you looking for a definitive answer? The only thing I can tell you is that the best form of application development is the one that suits your unique needs. This will depend on your resources and the needs of your end user. Let me remind you that you can always contact me for program development; I can create an application in Java or C#. I also have experience developing for J2ME and Android.
*In this article, we're looking at web browser-based hybrid apps.
Native or hybrid - that is the question. To make the right choice, you need to clearly understand what each type of application is and what purposes it serves.
Interesting! According to statistics from Flurry Analytics, we spend 90% of all time on the phone in applications.
While each type has its ardent supporters, native and hybrid apps are breathing in each other's backs, making it difficult to pick a clear winner.
Having many years of experience in developing native and hybrid applications, I have thoroughly studied the features of both types. In this article we tried to collect main advantages and disadvantages of natives and hybrids, to make it easier for you to make the right choice.
HYBRID AND NATIVE APPLICATIONS
So, how do these two types of applications differ from each other?
Native app is native to each platform, be it iOS or Android, and is written specifically for it in a specific language.
Swift or Objective-C will be used to write a native iOS application. For native Android applications, Java or Kotlin are suitable.
However, according to statistics from VisionMobile, 47% of all native iOS apps and 42% of all native Android apps actually use HTML5 as well.
And here is an example of a native application:
The world famous e-commerce app Bounce was written by our developers in Swift for iOS and Java for Android.
The application is available in Apple Store And Google Play.
Unlike native hybrid apps are developed for both platforms simultaneously and written in a universal language.
You can get acquainted with hybrids using the example of our other application, widespread in the Western market - LASIK for online searching for surgeons and making an appointment.
The application is available in Apple Store And Google Play.
Let's take a closer look at each of the types and find out their deepest secrets. Let's start with two-faced hybrid applications.
PROS OF HYBRID APPLICATIONS
- Saving . If you are not ready to empty your wallet in pursuit of the perfect application, but want a simple application at an affordable price, then hybrid is your option. Just think how much you will save by creating one application for two platforms at once!
- Entering the market on 2 platforms at once . Since a hybrid application is written for two platforms at once, it reaches two markets simultaneously. Due to this, the number of potential users also doubles, along with the chances that your application will be downloaded. However, this is where the strengths of hybrid applications end, and it is worth paying attention to their weaknesses.
DISADVANTAGES OF HYBRID APPLICATIONS
- Impracticality . Even a well-designed hybrid app can quickly become outdated. Progress does not stand still, and application owners are trying to keep up with it. As soon as new technologies appear, each of the owners tries to add an outlandish function to their application as soon as possible. Unfortunately for hybrids, it will take 3 to 6 months to change the framework and add new functionality to it. Only then will developers be able to improve your application too. In native applications, innovations can be added immediately after they are announced.
It is unlikely that our application will be in demand among users if it turns out to be of poor quality and unstable:
According to statistics, almost half of all users immediately remove boring and poorly designed applications from their smartphones and install other, better competitive applications in their place.
- Low speed . Often, hybrid applications are web pages that are not particularly efficient, for example, in scrolling heavy content: pictures, animations, etc.
Scrolling – vertical or horizontal scrolling of a page.
In addition, hybrid development based on web layout undergoes various compilations, which also reduces the speed of the application and does not please users at all.
Compilation is the process of translating a high-level programming language (PHP, Java, JavaScript) into machine language.
- Design challenges . If you want the look of your app to match the professional and well-researched system design of each platform, be it iOS or Android, you will have to design for both operating systems separately. iOS and Android apps have their own unique design standards, and since a hybrid app doesn't meet these standards, its appearance will have to be adjusted to fit the appropriate framework. It turns out that at the end of the work you will receive only one application, but you spent time and money on two.
- Source code insecurity . One of the serious disadvantages of hybrid applications is their insecurity. While a native app may be encrypted before being released to the official store, a hybrid app remains “naked.” Since many hybrid applications are based on an HTML page, it costs nothing to look at its source code and understand how the application itself works. At a minimum, your code can be stolen. At the most, an attacker can use your application for his own selfish purposes, for example, to obtain private information and data about the application.
ADVANTAGES OF NATIVE APPLICATIONS
- High quality . A highly specialized native application developer will write you clean, unique code. Many years of development experience and clear standards for native iOS & Android applications will help you create a high-quality product with wide functionality and reduce the risk of bugs to almost a minimum.
- Low probability of rejection for placement in App & Play Stores . Since a native app initially meets the standard requirements of a particular platform, it is unlikely that you will encounter any problems when launching your app on the official App Store and Play Store.
- 100% use of UX design . Modern users are spoiled by colorful, detailed interfaces, and simple, standardized applications are unlikely to interest them. It is in native development that UX design is used 100%, which allows you to create a high-quality and interesting application. With a hybrid app, you get a standardized interface across both platforms.
- Variety of development tools . Thanks to many years of experience in developing native applications, there are a huge number of different frameworks, templates and other proven tools that will allow you to make your application unique, individual and stable.
- Large developer community . And of course, when developing a native application, you are unlikely to encounter a problem that no one has solved before. This means that you won’t have to spend extra time searching for a suitable solution, but will be able to turn to the experience of other programmers.
DISADVANTAGES OF NATIVE APPLICATIONS
- Price . As they say, free cheese is only in a mousetrap. A native application is a unique, high-quality product, the creation of which requires a lot of time and, of course, a highly qualified developer with many years of experience. Therefore, such an application costs accordingly.
INTERESTING FACT
You will be surprised when you find out what it really is developing a native iOS application costs less than a hybrid . Don't believe me? See for yourself!
When developing a native application, you have a huge variety of tools included in the SDK of a particular platform. That is, all you need is to use these tools in your native application.
In the case of a hybrid, you just have to hope that there is an adaptation for one or another native tool based on the framework chosen for hybrid development.
If there is no such tool, you will either have to wait for it to appear, or consider alternative frameworks, that is, there is much more hassle with a hybrid.
Based on this, it turns out that, create one native iOS app is cheaper than one hybrid iOS app.
If we compare the development of a hybrid application and two native ones, the price of the hybrid will be lower, as expected, because in a hybrid application the backend and frontend are suitable for two platforms at once.
In a native application, you need to develop two separate frontends that meet the generally accepted standards of each platform.
Hence the prices:
HYBRID iOS APP– $11.5K
HYBRID iOS + Android APPS
$12.5K
NATIVE iOS APP– $10K
NATIVE iOS + Android APPS
$18K
However, if you look closely, you will notice that the cost of native applications is not much higher than the cost of hybrid ones.
Now think about whether to save money when developing one application or not? Or maybe make two native ones at once?
After all, both the appearance of the application and how convenient and high-quality it will be are very important for users.
WHICH APPLICATION SHOULD I CHOOSE?
In this case, you will be 100% sure that the money was not wasted and as a result you will receive exactly the application that you ordered.
SO ,
Choose a hybrid app if you want to get:
- simple application
- application for two platforms at a budget price
- 1 application with the ability to quickly enter two markets (ios/Android)
Choose a native app, if you need:
- professional application that meets all standards of the selected platform
- complex application with wide functionality
- high speed application
Now that you know everything and more about native and hybrid apps, you can easily make the right choice.
Make all your wildest dreams and ideas come true with .
» Alexander Kuznetsov wrote a column for VC about the differences between native applications and cross-platform ones, in which he explained which type of development would be preferable in certain circumstances.
Application time
As a rule, any business going online follows the following scenario: first the company launches a website, then it is adapted for mobile devices, and if there is an increase in traffic, it makes sense to gain a foothold among the owners of mobile gadgets, and the company releases an application.
There is no point in comparing a mobile site and an application - the second definitely wins due to the breadth of its capabilities and responsive interface, which is much more comfortable to interact with via a phone or tablet. In addition, the application can work without a constant Internet connection.
Whether your business is based on sales, service, or education, today it is impossible to ignore the time people spend in front of mobile screens.
This article is intended to talk about two approaches to application development - native and cross-platform.
Each approach has its own specifics, which critically influence the final result. And in order to facilitate understanding between the customer and the developer, I would like to talk about what both approaches are, analyze their advantages and disadvantages, destroy established stereotypes about development and answer the main question: how to make a choice in favor of one or another approach based on the principle of expediency .
Native approach
Native apps are those that you encounter from the first day you use the device. These are the default browser, email client, address book, alarm clock, calendar and other standard programs.
If developers, in the process of writing an application, use the programming language adopted for a specific platform, be it Objective-C and Swift for iOS or Java for Android, such an application will be called native (from the English native - native, natural). “Natives” can access all services, services and gadgets of the phone: camera, microphone, geolocator, accelerometer, calendar, media files, notifications and so on - in general, they fully settle in and feel at home.
Cross-platform approach
Imagine a mobile site that doesn't always need the Internet, and from a design point of view it is closer to mobile applications than web pages. This is roughly how cross-platform applications can be described.
They are often created in markup and styling languages (HTML, CSS and JavaScript), just like mobile sites. Logically, this action is justified by the fact that, after all, all Internet content is HTML pages. Such applications are written simultaneously for all platforms and are adapted to most devices, because they mainly use a browser engine to operate.
Most specialists who create such applications use the PhoneGap framework. Its peculiarity is that it allows the application to access the hardware and software capabilities of the platform. Cross-platform development is also possible using technologies such as Xamarin, Unity and others, but they are not as popular for application development as web technologies.
Hybrid apps
As you can see, the bar for entering the more than promising field of mobile application development has dropped significantly. Someone might think that now layout designers who do not go beyond proven HTML and CSS will take the bread away from real programmers. Others see a cross-platform approach as the future, in which application development time and costs will be completely optimized. There will be arguments on both sides explaining why this rather than another development approach is correct.
But when we are talking about solving certain problems, it would be more effective to combine these approaches - to use the cross-platform advantages of HTML to design content, and make menus and controls that require speed of responsiveness native, spending a minimum of effort, time and budget. Such applications are called hybrid. In this case, only the volume of native code determines which approach is more appropriate for application development.
What situations lead to a fusion of approaches? Let's say that a client needs a simple news feed with nothing but text and images. Based on this task, the developer decides to use a cross-platform approach. But if after some time the customer wants the application to store a large amount of data or process sound and graphics, the task becomes more complicated. For these purposes, you need to write native code for each specific platform, and what was once a completely cross-platform application turns into a hybrid one.
It is a common misconception that behind any icon on the user’s desktop there is a native application waiting. This misconception has taken root so deeply that even in professional circles people are guilty of using formulations of a high degree of absurdity such as “native phongap application”. But even a shortcut for a website can be displayed on the desktop, so the icon does not guarantee anything, and either a native application or any other could be on the other side with equal probability.
Comparison of approaches
The supply market is growing. Mobile application sales statistics show that from year to year gadget users are increasingly changing standard services to alternative ones. Thus, the native task manager is replaced by Wunderlist, the email client is replaced by the Mailbox application, Evernote turns out to be preferable to standard notes.
It is important for the customer to know the advantages and disadvantages of each approach and not to raise expectations when making a choice. It would be appropriate to conduct a comparative analysis based on a number of criteria.
Platform dependency
One might get the impression that a cross-platform application is equally comfortable on all platforms, even the most unpopular ones. A caveat is required: for this belief to be true, a piece of additional code may have to be written for each platform. In the case of native applications, you can count on them to work perfectly, but each platform requires developing its own version.
Interface design
It is impossible not to touch upon guidelines in the context of mobile application development. Guidelines are valuable instructions from platform manufacturing companies to mobile application developers, aimed at adjusting their design and functionality to standards. Guidelines are the foundation on which the psychology and comfort of platform users is based. Simply put, interface elements have a familiar appearance and layout.
The language environment in which native applications are developed has the necessary tools to create an interface that is familiar to the user. Another situation with web technologies: to make a cross-platform application similar to a native one, you will have to put in a lot of effort. Various cross-platform frameworks (Framework 7, Sencha Touch, Kendo UI, Ionic and others) help to imitate a native interface with varying degrees of reliability, but most often the responsiveness, animation speed, effects and design will be different. This is what the next paragraph is devoted to.
User Experience
The first thing a user expects from his application on a subconscious level is responsiveness. The user’s action is immediately followed by a response, page scrolling and animation proceed smoothly and without freezing. Cross-platform applications in this regard are significantly inferior to native ones, and if you don’t beat around the bush, they slow down, and this is their main problem.
The user is also confident that every control element, every icon will have a standard appearance and position on the application screen. These standards will be different for different platforms, and if a cross-platform application is made according to iOS guidelines, then this will cause discomfort to Android users, and vice versa.
One of the most striking examples is the Back button: this is a typical Android function that has no analogue on iOS. Therefore, when you create a cross-platform application, there can be only two compromises in this situation: either the design is the same for both platforms, and users of one of them are forced to adapt, or you create two different designs, taking into account the characteristics of each platform. Essentially, in the second case, two applications are created, but in the same cross-platform language.
Restrictions
A native application, written for a specific platform, feels like its full-fledged inhabitant, gaining maximum access to all devices and services of the device. When designing a cross-platform application, the developer takes into account only the capabilities of the framework, which imposes its own limitations.
It can also create a problem that frameworks have many versions, and the older the version, the more restrictions there are. In any case, not all features of the platform are open to cross-platform applications. There is not always a need for full integration - its depth depends on the tasks that the application must solve.
Safety
For all popular browsers, there is a standard secure data transfer protocol - HTTPS. But if a special level of encryption is required, the solution to this problem falls on the developer. Ensuring reliable data protection is only possible with native development, since it is associated with mathematics, and such operations require the most efficient use of hardware resources.
Service and support
Comprehensive maintenance of native applications for two platforms (searching and fixing errors, updating and any minor changes) on average takes twice as many resources due to the need for at least two different specialists (iOS and Android). A cross-platform application can be managed by one developer.
The cost of mobile development and the time spent is entangled in misconceptions and myths, and therefore I would like to address these issues separately and, if not dot the i’s, then at least contribute to this.
Fast and cheap cross-platform development - myth or reality
Cross-platform development is cheaper, which is explained by the smaller amount of work compared to native development. But even here there are pitfalls, which can only be seen by understanding the principles of pricing.
You should always remember that time and cost are governed by the complexity and level of quality of the task. Let's say that to develop a cross-platform product we have one specialist who knows HTML, CSS, JavaScript and has experience working in PhoneGap. One specialist is one abstract unit of resource (for example, one person-month).
To work on a native application, two such resources are required - iOS and Android. As a result, it takes two person-months to complete a native project, and one and a half to complete a cross-platform project.
A fair question would be: “How come - one and a half? Why not one?” Alas, in practice, a cross-platform application that works well on iOS will work poorly on Android - all browser engines have their own specifics, and as a result, optimization for Android may take another half a person-month.
Based on the above, the cost of mobile development was calculated in the case of native and cross-platform approaches, presented in two tables. The results in Table 1 are based on the average hourly rate of freelancers from the freelansim.ru and fl.ru databases in rubles, in Table 2 - the average hourly rate of freelancers and studios from the international upwork.com database in dollars.
When we compared approaches according to several criteria, we said that the degree of integration of an application into the platform is determined by the complexity of the problem solved by the application. Using a particular template or ready-made solution can be a fairly cheap way to make an application, as long as the capabilities of the template or solution are sufficient to perform a specific task.
But there is a nuance
And it lies in the structural features of the application. Most often, it involves the presence of a server part, where application users save data and through which they exchange it with other users, and this also requires financial investments. Working on it can take up to a third of the total development time, and it increases if it is necessary to create an administrative panel for convenient data management.
Summary
You should resort to native development if:
- your application requires free access to all resources and services of the phone;
- you want to get the most responsive application;
- the application must be able to work offline;
- your application should make the most of the device's hardware.
Your option is cross-platform development if:
- you are ready to put up with low responsiveness;
- the application does not involve complex animation and does not perform calculations;
- The application requires constant Internet access to download content;
- you need to quickly get to market to test the idea;
- you have a website and want to turn it into an application for a minimal price.
Individual circumstances always lead to the choice of one strategy or another; no article provides a universal answer.
Our material rather provides general introductory information to help the customer and developer establish a dialogue in a language that is understandable to both.
The final decision should be made after consultation with the developers. The more arguments you hear regarding a particular approach, the better.
If you have any questions, feel free to ask them in the comments - the answers to them will help supplement the article. We also encourage experts on the topic to share their point of view.
