Based on the experience of Karlo Karagic, Senior Android Developer, and Andrej Krizmanic, Senior iOS Developer, we compiled a list of Mobile App Development Trends 2022.
The trend came with the rise of React, or specifically React Native - and it is now here to stay. But let's back up a little bit. What is declarative (UI) programming?
There are tons of articles and definitions online, but we will try to give you our understanding. We would call it an abstraction layer built on top of the imperative style of UI. It is not concerning itself with how to build the UI but what you want to build.
What made declarative UI building so popular is the question of state and state management. We are moving more towards reactive programming where the state is immutable. Mutating variables is starting to become taboo. As such, this spilt over to the declarative UI approach where we would rather rebuild parts of the UI than mutate them.
A nice bonus we get with a declarative way of creating UIs is that developing for different platforms tends to look similar, and as such, it can be effortless to switch from Swift UI to Compose, and even to Flutter and React Native (Bob Ross would call it a “Happy little accident”).
In the case of Android and iOS, declarative is already here but you are not too late to the party. Many people are still reluctant to even try it out. We are here to tell you to give it a shot. It takes a bit to wrap your mind around it but it's a fun and enjoyable experience.
The intent of this section is not to tell you to go for native or multiplatform, but to show you where the mobile tech is moving towards. As such, it will be a high-level overview of the status of the market.
Let’s start with native mobile application development. It is more expensive and more work to maintain your creation, as you need to work on two completely different codebases. There are cases where this is pretty much your only option, or the best option, though. For example, native is the better solution for apps leveraging native APIs and hardware as well as high-performance apps (numerous animations or heavy rendering or both). This also applies to apps which can pivot to many different directions and could evolve out of the scope of some functionalities of multiplatform solutions (for example a social media app that implements Augmented Reality features). The last use case we want to showcase is when you need the ultimate control over the native app. There is no way to customize the app more than to use the native tools for it.
React Native is a huge player in the cross-platform development area. It is a bit barebones with its included widgets in tools, but there are a lot of libraries out there to help you with it. However, there is an awesome article by the Airbnb team on why they ditched React Native and we recommend you read. Even one major company left the ecosystem, the popularity train did not stop or slow down. React Native is not going away any time soon as you may easily find talent in its web-based React community - currently the most popular tool on the web development front by a large margin.
The next tool is Flutter. It is right up there with React Native as the multiplatform leader. It is loved by developers, backed by Google and packed with high quality features. Its downside is, it’s on the complete opposite spectrum of React Native. Instead of JavaScript/TypeScript it uses Dart. It is a language used pretty much exclusively for Flutter, and other use cases fade. The language is not bad by any means, but it fails to come near to the popularity of modern languages, which is a shame, because it’s well-designed, and it feels as if Java and JavaScript had a child.
Finally, we have the new player, Kotlin Multiplatform Mobile (KMM). It has a bit different view of things. Unlike Flutter its goal is to share only the core app logic while the UI code is delegated to native languages. What it means is you write your app's logic with KMM (in Kotlin) and then when you get to the UI part you delegate the iOS functionality to Swift, Android to Kotlin/Java and if you are going for desktop/web, Compose Multiplatform. Compose Multiplatform is another tool. It is also written in Kotlin and is based on new Compose technology which is just now trending in the Android world as the next UI tool.
Native is not going anywhere, but multiplatform will still apply pressure. There was never this much choice in quality tools for going with shared code for various platforms. The trend here is going in the favor of at least trying out one of the multiplatform solutions to keep up with modern times. Also, with some experience and planning, maybe you can even utilize them both at the same time (the trick is to know when to use what).
With foldable device sales skyrocketing (300% growth 2020 - 2021) it looks like the market is giving a clear signal about what will the next big thing be. Android is currently at the forefront here with Samsung leading the pack. Google even released a new flavor of their OS called Android 12L to better accommodate tablets and foldables. Not many apps are optimized for foldables, yet, as we are still not too sure how to utilize them properly. Not to go into too much detail here, it looks like these new tools are still not in the minds of developers, but with these sales numbers, we can surely expect users to start demanding better support for their foldable devices.
One must ask: what about Apple? There are always rumors, of course. The word on the street is that we could expect an Apple foldable device sometime in 2025, although there is contradicting information on the type of foldable (a hinge behind the screen or not). Patents are not a foolproof way of looking at future products, but it deserves a mention. Apple is currently holding multiple folding-related patents. The most interesting for mobile developers is what the Cupertino-based company will do on the software front as well. Maybe we are looking at a combination of iOS and iPad OS? Maybe we will get iFoldOS?
Developers should be concerned. This is not only giving us a multitude of new screen sizes to work with, but also completely new aspect ratios and a huge number of combinations of different multitasking windows (and transitions between the states). The full list is not final yet as we only have a handful of models right now. We can also expect new and wild designs and ideas.
As you have probably heard there were some lawsuits happening where Epic Games (Fortnite guys) argued Apple and Google are showing monopolistic behaviour by forcing their 30% on every purchase made in Fortnite. Epic Games lost this lawsuit, but it did make some changes. Both Apple and Google, shortly after it, lowered their fees from 30% to 15% for the first million $ made by the app. You can read up on it in more detail here. They of course didn't do it because of their altruism but more to improve their image and ease the pressure from regulators. It didn't exactly work though as the regulators are doubling down on making Apple allow sideloading of apps.
Why should we care? Google has allowed it since the beginning of time, so it isn’t something completely unreasonable for Apple to start doing. Also, the user bought the device and as such should be allowed to do whatever he wants with it even if it is a risk (99% of users won’t ever do it anyways). There are rare cases where sideloading apps makes sense and that is to circumvent location restrictions or when it is the only option. So, let’s track back to the Fortnite case. What they did was allow Fortnite to be installed on Android devices ONLY via their webpage and that way they have avoided paying Google a 30% fee on every transaction inside the app. All considerations aside, Apple is unlikely to open the App Store even a little bit, unless they will be forced to by law or by court. Miracles sometimes happen, so maybe the “iCompany” will change its mind?
We are so used to distributing our apps via Google and Apple stores that we may forget this doesn’t have to be the case. They bring some value, but should we feel ok that there is currently a duopoly in the area? Users are used to going straight to their app stores to install an app. Maybe they will get used to installing PWAs?
Progressive Web Apps (PWAs) are at least as old as the iPhones. Steve Jobs pitched such an idea during his presentation when he revealed the first mobile phone from Apple.
Even though that was a long time ago, they never really took off. That could be changing, though, as devices of today are much more powerful than those we had in the past. Moreover, people’s interest in the installable websites seem to be close to an all-time high. That’s what Google’s data suggests, at least.
The old, perhaps forgotten player helps all developers to package their websites as PWAs, and distribute them to Google’s Play Store, Microsoft’s Windows Store, and Meta’s Quest. What company could it be? Microsoft! You’d think that web apps distributed to app repositories would be a niche solution. You couldn’t be more wrong! Companies such as Twitter, Facebook, and TikTok did so, and are getting spectacular results. Tinder reduced their app from 30MB to 2.8MB, Alibaba saw a 30% increase in traffic on Android, and people who installed Trivago’s app engaged with the website a whopping 150% more.
What’s with iOS? We don’t have great news here. Unfortunately, even though they were the first to suggest the idea, they are now among the biggest blockers of the adoption of the tech. Safari, and other web browsers on iPhones, does not support installing the app (“A2HS”). It’s also behind Firefox and Chrome in implementing the newest Web standards. As such it’s hard to expect the Californian company to start supporting Progressive Web Apps anytime soon.
PWAs are coming back like a forgotten fashion trend. The interest in them peaks, as companies developing these apps may target most modern operating systems with the same interface across all platforms, easier installations, and (perhaps most importantly) no commissions.
Many companies rely on business models based on users’ data. In the past users were left in the dark without knowing exactly what data is being collected by which company.
Facebook (saying Meta would be better, but just the privacy and data collecting labels stick better to the name “Facebook”) and Google (Alphabet, same reasoning as above) are probably by far the most notorious ones. We will mention Apple here, as it has a direct impact to way, more than just the mobile industry. Let’s be honest here, arguably we often find Apple sitting on the opposite side - advocating for privacy and using it as a key differentiator in the market.
What happened recently that feels as such a dramatic pivot?
Let’s start with Facebook. It was at the F8 event in 2019 when Mark Zuckerberg opened the event talking about privacy and making a statement “The future is private”. That coming from the CEO of Facebook was a surprise to many. Meta with all its products was headed into an evolutional direction that would bring trustworthy and transparent take on privacy.
Later, what seemed like impactful change came from Apple when they required approval by the end user for cross-site tracking with IDFA. But it doesn’t stop here. When “Privacy Labels” were introduced, it was fun reading stories about what app has the longest list of all the data that’s been collected. Many notorious apps broke their bi-weekly update routine and took extensive time before publishing a new update and expose their tracking practices in Privacy labels.
We know the phrase for quite some time now “if you’re not paying the product, then you’re the product”, but it seems now even Google recognizes users know it and is promptly following suit by introducing its version of privacy centric features (Privacy labels on the Play Store, Privacy Dashboard, etc.).
Mobile developers now more than ever need considering accessing private information only when it’s really needed and transparently expose all the sensitive information an app might access.
In 1998, the world was introduced to a new short-range wireless technology - Bluetooth. Fun fact, it got its name from a Viking King, Harald “Bluetooth” Gormsson, it was intended as a placeholder name, but history got in the way. The logo of the technology are the initials of the king.
Bluetooth was, and is, the de facto standard in Mobile short-range communication (NFC is an honourable mention for a short range). For the longest of times, it had a few issues, mainly range and power consumption. It of course got better as time progressed and the technology evolved until 2010, when we got introduced to Bluetooth Smart, or as you may know it Bluetooth Low Energy (Bluetooth LE; BLE). They dropped the name to not confuse people, luckily.
Bluetooth 4.0 or Bluetooth LE lost some bandwidth but gained significant improvements in power consumption (uses up to x100 times less power). So much so that it became a viable solution for many IoT devices. It also brought a big change to the mobile device market where battery life is crucial. From now on we have Bluetooth (or Bluetooth classic - we will use this term to be more explicit) and Bluetooth LE under the same umbrella.
The evolution continued until 2016 when we got Bluetooth 5.0 with its increased range and speed. There was now an option to have speed on parity with Bluetooth classic at the expense of range and vice versa. This made Bluetooth much better but still, it was not enough for the audio segment. That’s why, Bluetooth Classic was still widely used for audio streaming (mobile, and BT speakers). That is until version 5.3 hit in 2021 (announced in 2020 but revealed in 2022). Now we have a viable solution for audio streaming with Bluetooth LE Audio. It also gives bonus features like streaming one-to-many, and many-to-one broadcasts (Auracast).
So why should you, as a developer care? With better features came better API. In other words, it made our lives easier. On Android, Bluetooth LE comes with built-in profiles for the common use cases (heart rate, biking, sports etc.) vs having only one predefined profile to choose from, in the past. Threading is now handled for us, too, and we don’t have to use broadcast receivers anymore. The tech is just a lot nicer to work with.
We may be done with Bluetooth Classic for good. It is more power hungry, with less range and the same bandwidth as its LE counterpart. Bluetooth LE will keep on evolving and we are excited to see what it brings. It will probably stay as the standard in this area for a long time but do keep in mind a new technology called Passive-Wi-Fi which could bring a revolution.
Let’s look at the current situation, the in-car experience has been evolving a lot since 2014 when Apple announced CarPlay, and Google showed us Android Auto a year later. These two are the two ways how we’re streaming our mobile experience from our phone directly to our infotainment systems in our cars. It’s important to say that this experience in controlled by our phone, whether we’re using an iPhone or an Android phone respectively. Car manufacturers have in big part adopted the technologies. We’re used having it all just a connection away, whether we connect to USB or have the privilege of a wireless connection. I’m saying privilege here, because the wireless option is still not as common as wired connection.
We may, therefore, use our “loved” voice assistant to control our music, podcasts, make phone calls, start park meters, etc.
But this year we’re looking at many new things on the horizon. Besides Android Auto, Google has also been developing Android Automotive OS, an open-source operating system designed to be used in vehicle dashboards. Although it was announced in 2017 it’s still rare to see in new cars. The key difference is that Android Automotive OS is an operating system installed on a vehicle's dashboard that does not need an Android phone to work. It integrates much better with vehicle data and can even control your AC, seat heating etc. as well as provide access to your music and navigation app of choice. Many manufacturers signed agreements to start selling vehicles with Android Automotive in 2023. The list expands beyond Audi, Volvo, Renault-Nissan-Mitsubishi, Ford, Honda, BMW, General Motors, etc..
And looks like Apple had also in mind a tighter integration with vehicle data with the ability to control the AC, seat heat, etc. With that in mind they announced CarPlay2, as an upgrade to CarPlay features in almost every way. This will of course force car manufacturers to adapt to these new features and changes. We’re expecting new vehicles supporting CarPlay2 in late 2023. The new features will support expanding the CarPlay experience over all vehicles screens as well as accessing vehicle data, controlling vehicle settings etc. That will include displaying widgets, unlocking the car with your phone (and presumably your smartwatch) as well as sharing your digital car key with friends.
The days of basic car infotainment systems seem to be numbered. Developers need to prepare for all-new immersive car experiences, which gives them a lot to work with.
As you have probably noticed, the world is trying to rethink our lives by being more mindful of the waste we all generate. Mobile devices are not exempt from it. We have started seeing chargers disappearing from the boxes (an increase in profits is just a happy accident) and a higher focus on extracting rare minerals from discarded/old/broken devices.
What does the green evolution have to do with software? Samsung just announced it will support their latest devices with OS updates for 4 years instead of 2. We have seen Google Pixels be viable devices for a long time with OS and security updates. As the mobile market matured, phones are not automatically obsolete every couple of years and people are hanging on to them. These updates will give them even more time away from the landfills.
Not to omit Apple here, they are much better regarding OS updates, device lifecycle and recycling than Android for a long time now. Using 5- or 6-year-old iPhones is completely normal which is much rarer in Android land.
The future is green(er), and people change devices much less often. Think about that when setting the target OS for your app.
Is there a better feeling than the one of a fulfilled expectation? When we’re expecting a parcel to be delivered, or when we’re waiting for the pizza delivery guy, or when we’re just hoping someone (or at least as many as possible) gives us a like for something. A familiar sound of a notification on your phone might create a spark in our eyes. So, we start using our phones by embracing notifications for our apps. Till the point we get too much of it. And then what? We have a problem. Users get upset about notifications and start blocking them. There are also people, who get overwhelmed with notification sounds: such as the people who are on the spectrum of autism.
Luckily both Google and Apple understand this situation and are giving us notifications options designed to bring back the excitement we once had.
On Android, the most welcomed recent change is perhaps the default opt-in mechanism for notifications. Now an app can send notifications only after the user gives their consent. No more obtrusive interruptions for you.
Apple is probably more notorious for having a more conservative approach to how apps can interrupt users. Recently we got some welcomed changes, such as: the ability to direct notifications to the Notification Summary; a place that allows to interrupt our attention only at the times we define. Having different types of “do not disturb” (called Focus modes) allows us to set different rules when we allow specific app notifications. We can have a work time focus and allow Skype and Teams notifications to interrupt us only during working time, but not when we’re at our home.
Furthermore, if a notification is getting in our way too often, we have handy options right where the notification is displayed, to change our consent and pause the interruptions. On top of it all, if we feel like getting too many interruptions and want to decrease the number of notifications, we already have notifications statistics in the “Screen Time” tab waiting for us.
Nowadays a notification can also become live and continue to show updated content in real time. Say you are waiting for that pizza delivery. On an iPhone, a notification can update itself, instead of flooding a user with countless follow-up notifications. On iOS that feature is called “Live Activities”.
Users are now more empowered to control what notifications are getting, when, and from which apps. We don’t have to be spammed by the constant jingle noises that distracted us, and in some cases, harmed us.
You can probably guess it, but iOS is a more tailored and designed experience than Android in general. This also applies to the accessibility area (though this situation is changing).
iOS was traditionally light years ahead, but Android is closing the gap. There are now even features available on Android that are not yet implemented in the Apple ecosystem. Even so, iOS is still the more polished and intuitive in this regard, whereas Android is a bit all over the place with its many OEMs and customization options.
What do the users say? They prefer the iOS. Keep in mind that Android phones vastly outnumber iPhones, while the number of users requiring special accessibility tools is the same on each platform. That number was more skewed in Apple’s favor in the past, which is a testament to Android making some improvements in this regard.
Finally, as the two most popular platforms give us more tools to help people with disabilities, it is up to us developers to implement those functionalities best to our abilities. Do your best and keep in mind that if you don’t adapt your app to everybody, there will be thousands, if not millions, who will be glad to use your competitor’s application.
Every new major release of an OS (Android 13 or iOS 16) brings new features and creative solutions (such as automatic image description and door detection) as well as constant improvements to existing functionalities. The future looks to be within reach for everyone, not the able-bodied, exclusively.
.jpg)
.svg){kind=small}
