If we could start counting mobile apps in the stores, we would probably see that many of them are, first and foremost, a branding exercise that the open web cannot satisfy. Institutions want you to have their icon on your pocket and to push notifications into your lock screen. And given how the adoption of the internet has been based on ignorance of how it works, people don't know and don't care about the difference between Android, iOS, and the web. I mean, users implicitly care about the differences if they affect their experience, but users don't pay for these branded apps, so what they really care about is just another bullet point that institutions are often unable to support. And, as one might expect, native development costs a lot more than hybrid.
Therefore frameworks like Flutter, Ionic, React Native, or even simply Cordova have a real need that justifies their success. But what do we see being offered by them? Do they support ignoring the differences between each platform to deliver a very similar experience across all of your users regardless of what device they carry? Are they relentlessly on top of possible breaking changes imposed by those who control each ecosystem? Because surely the job of these corporations is not to help hybrid apps thrive, in fact, they naturally create problems for them every year with changes in permissions, web views, etc. Hybrid apps are a hacky substitute for the open web, a common good that corporate ecosystems would like to co-opt or make obsolete as soon as possible. Of course, they want either exclusive apps or apps that need to generate revenue to support native development from which they can take a cut. If you are none of those, you are merely getting what you paid for your developer's license and that's not a relationship corporations want to maintain on equal footing. They want you to feel like it's a privilege to develop for their ecosystem and not just something you also generate a build for.
However, it seems that hybrid development frameworks prefer to focus on other problems. They even invest a lot into providing you with ways to make your app look different according to each platform, which is the opposite of what brand stakeholders want or even understand. What I might guess is happening here is that everything I said in the previous paragraph is not something you can base any viable project on. You can only focus on what you can control and a real promise of sustainable hybrid development is not something you can commit to. The rug will be pulled from under the next web view or the next permission to access the file system. And when that happens, frameworks cannot just stand there and say "well, it's XYZ's fault", they have to push that problem onto the shoulders of open source. In the end, native problems need to be overcome natively. Meanwhile, hybrid road maps can be filled with achievable things like having buttons with pixel-perfect similarity with those on native apps.
So, as you judge these frameworks, look behind the curtain and see how the issues that handle the usual native issues are evolving. Who is responsible for making sure that next year your app will still be able to access the camera and that photos will have the correct orientation? Who is making it easier for you to generate all the graphics platforms require for icons and splash screens? Who is providing feedback on what are the best workflows to get your apps currently published in stores? If you consider these wider questions, some differences between frameworks will still be there, but a lot of them will fade away. Also remember that, if native features are not an issue for your app, maybe it should just be a nice easily-accessible web app.
My particular experience with developing hybrid apps has been very much all about following the needs of event organizers. Events can be an excellent opportunity for web apps to shine. No need to install anything, the event is over after some nearby date, and the dynamic nature of its content is well served by a solution that is online first. However, push notifications can be very useful for both attendees and organizers. And that killer feature has driven event apps into the inevitable hybrid territory, at least for a wide majority of smaller brands. 2020 was indeed a surprising year for web-based events, but the companion mobile app is not going away. I will probably be writing more about all of them in the future. See you soon.
(Originally written on December 9, 2020)
Therefore frameworks like Flutter, Ionic, React Native, or even simply Cordova have a real need that justifies their success. But what do we see being offered by them? Do they support ignoring the differences between each platform to deliver a very similar experience across all of your users regardless of what device they carry? Are they relentlessly on top of possible breaking changes imposed by those who control each ecosystem? Because surely the job of these corporations is not to help hybrid apps thrive, in fact, they naturally create problems for them every year with changes in permissions, web views, etc. Hybrid apps are a hacky substitute for the open web, a common good that corporate ecosystems would like to co-opt or make obsolete as soon as possible. Of course, they want either exclusive apps or apps that need to generate revenue to support native development from which they can take a cut. If you are none of those, you are merely getting what you paid for your developer's license and that's not a relationship corporations want to maintain on equal footing. They want you to feel like it's a privilege to develop for their ecosystem and not just something you also generate a build for.
However, it seems that hybrid development frameworks prefer to focus on other problems. They even invest a lot into providing you with ways to make your app look different according to each platform, which is the opposite of what brand stakeholders want or even understand. What I might guess is happening here is that everything I said in the previous paragraph is not something you can base any viable project on. You can only focus on what you can control and a real promise of sustainable hybrid development is not something you can commit to. The rug will be pulled from under the next web view or the next permission to access the file system. And when that happens, frameworks cannot just stand there and say "well, it's XYZ's fault", they have to push that problem onto the shoulders of open source. In the end, native problems need to be overcome natively. Meanwhile, hybrid road maps can be filled with achievable things like having buttons with pixel-perfect similarity with those on native apps.
So, as you judge these frameworks, look behind the curtain and see how the issues that handle the usual native issues are evolving. Who is responsible for making sure that next year your app will still be able to access the camera and that photos will have the correct orientation? Who is making it easier for you to generate all the graphics platforms require for icons and splash screens? Who is providing feedback on what are the best workflows to get your apps currently published in stores? If you consider these wider questions, some differences between frameworks will still be there, but a lot of them will fade away. Also remember that, if native features are not an issue for your app, maybe it should just be a nice easily-accessible web app.
My particular experience with developing hybrid apps has been very much all about following the needs of event organizers. Events can be an excellent opportunity for web apps to shine. No need to install anything, the event is over after some nearby date, and the dynamic nature of its content is well served by a solution that is online first. However, push notifications can be very useful for both attendees and organizers. And that killer feature has driven event apps into the inevitable hybrid territory, at least for a wide majority of smaller brands. 2020 was indeed a surprising year for web-based events, but the companion mobile app is not going away. I will probably be writing more about all of them in the future. See you soon.
(Originally written on December 9, 2020)