Modern mobile app development began with the first iPhone. Even though Progressive Web Apps were the first to be proposed for the device, they had some pressing problems. They were sluggish, and it was hard to create native-looking interfaces.
Apple released a remedy quickly after their announcement: an iOS Native SDK. Fast-forward to 2021, and creating native apps is the default. They are simply faster, and more performant than their non-native rivals.
Speed is the ultimate feature of all apps. Mobile apps that can steadily maintain the steady 60 frames per second threshold without any rendering lags feel the best. One has to ensure any breaks are not longer than 400 milliseconds.
Naturally, the easiest way to achieve the goal is to use the programming language that will be evaluated directly by the phone’s OS. In other cases, your instructions have to be first translated to get picked up. This is a rather costly process, and it is not the fastest.
Objective-C and Java are not the most well-liked languages in the world. In the most recent Stack Overflow survey results from 2020, 44% of developers declared they “loved” Java, with Objective-C earning a measly 23%. Respondents count as loving the language if they are “developing with the language […] and have expressed interest in continuing to develop with it.”
In comparison, Kotlin earned a respectable 62.9%, with Swift earning 59.5%. The language from JetBrains fixes many issues that plagued Java, such as the fact that the newer language handles “null” values much better, and the fact that one can avoid writing a lot of “boilerplate” code.
Swift can also be seen as a big step forward when comparing it to its predecessor, Objective-C. For one, the language is statically typed, which can catch bugs ahead of time. Furthermore, the company behind the language shares that the new language is up to 2.6 times faster than the previous one.
Additionally, Apple is constantly improving the language. This year, during the WWDC, the legendary company from Cupertino has announced a few exciting features of the language and the wider iOS development ecosystem. The language utilizes memory better now. It will automatically reclaim memory quicker than before.
You may now write async/await code, making non-blocking code easier to write. Three, and the “structured concurrency” (concurrency is referring generally to the execution of code at the same time), and the improvements around the area will surely excite all Swift developers. The new additions allow for safer, and problem-free implementation of faster apps.
We have talked about Kotlin in the past — Jan Radzikowski, Android Developer at ITMAGINATION has shared his positive opinion on JetBrains’s programming language in the past in our weekly series 360° IT Check:
I would say that Kotlin suits me much better than Java, but I’m speaking from the Android Dev point of view. The first benefit that comes to my mind is legibility. Kotlin is quite concise and could be used in such a manner that you can read it almost as a novel.
Another advantage Kotlin has over Java is that null references are controlled by the [Kotlin's type] system (NullReferenceException anyone?). You don’t have to annotate them at all.
From the specifics, there are no raw types, which in my opinion makes the language more consistent. What else?
- Lambdas and inline functions
- Extension functions! - they make a huge difference and improve readability and coding speed (when used correctly, of course)
- The concept of primary constructors
- Data classes
- Objects and how Kotlin deals with Singletons
To end with, coroutines are a major benefit. They are a great way to replace the RxJava library and to be able to write easy-to-read and thread-safe asynchronous code.
The takeaway from this section is simple — the native development experience is improving constantly, thanks to the new languages.
Not all APIs are available to developers writing PWAs or hybrid apps. Every so often, one has to find an alternative solution to their problem, or write native code. All in all, at the end of the day, if you are forced to develop natively, then you might as well go all in, right? Especially that we are not talking about access to advanced functionality. E.g., to implement calendar event creation in React Native, you have to call Swift and Kotlin code from your JavaScript — there is no other way.
As we mentioned before, your users will be the most familiar with the design of other apps, not yours. One can easily leverage that fact by designing your app to give users the same feedback, work similarly, and utilize the same visual patterns. Where do people spend the most time? Inside system apps, of course.
If you are writing code, using native patterns is the default option. By default, your app will feel much more familiar; in-place.
This is not so obvious when you are writing an installable web app, or a cross-platform app. Web apps cannot use native UI elements, while some cross-platform frameworks, such as Flutter, forgo the option of native elements, in favor of rendering custom components, using Flutter’s Skia engine. Of course, there is React Native, which uses native elements; however, it does not implement all of them.
If you are planning to embrace a truly native approach, it means you will have to write the same app twice. Once using Swift, and once using Kotlin. Of course, algorithm implementations can be more or less the same across languages, and therefore you do not spend literally twice the time on development. You may experiment with using data that your apps receive from a server as a way to determine what’s on the screen.
A few years ago, Airbnb described how they have experimented with server-driven apps as part of a series on “[s]unsetting” React Native, and moving to the native development. Server-driven apps are apps that render screens based on the data that phones receive from the backend. As a result, your code on all platforms looks, and feels more or less, the same while cutting down a lot of time on development. That is about as far as good news goes. Platform-specific bugs still will occur, creating different problems on each OS, and the need to hire platform-specific developers still will drive the costs up.
Native apps will be the fastest. They will also feel the most familiar to your users. It does not come without certain trade-offs. The development time will certainly be longer. They are also much more expensive to develop, as you need more people, and resources to write the same app twice.
Native apps, Progressive Web Apps, or Hybrid Apps — we are here to help you develop your app.
.jpg)
.svg){kind=small}
