Purpose & Goal
I’d love to say that I cherish each of my projects equally as if they were my children… I wouldn’t want to value one of my kids more than the others just because they ended up more successful (that certainly wouldn’t make me my parents’ favorite).
But unlike kids, we build projects with a specific goal in mind, we want them to reach others. When I was building Blue Coin Tracker I expected it to only reach a few people in my immediate community. However, as luck would have it I found that I had created an app that people were looking for! Hundreds of users downloaded my app, a youtuber I idolized featured it in a video, and some journalists even wrote articles on it. Eventually dozens of reviews came in and people were pleased with the experience. It was such an exciting time for me as a fledgling developer!
I was overjoyed that so many cool people were enjoying my app, but it soon became clear that a lot of other people were not…
I received message after message on github, youtube, and reddit asking me “Is there any way to use this on my iphone?”, “on my computer?”, or “on my ancient Android?” and for the most part all I could say was no. It was impossible for about half of my potential user base to give it a try!
People were genuinely disappointed, and so was I! That was the first time I was faced with the limitations of developing for the Android/iOS bubble. If my goal was to reach people, then standard mobile development was not the way.
I wasn’t quite sure what that could be until I finally found React. Suddenly it felt like the web was my oyster! After years, I was finally ready to give my favorite child (😅) the love it deserved.
The following is what I learned porting my Android app into React.
Why I Turned to Web Development
WYSIWYG: Illusion of ease
One of my favorite parts of Android Studio development was the miraculous drag and drop visual “Layout Editor”. The idea is so appealing. Intuitively anchoring elements in a layout with your mouse, choosing flow direction with a key press, adjusting sizing sliders in real time. It’s almost too good to be true! hmm…
Programmatic styling in comparison is very very daunting as a beginner developer; there are so many rules, hundreds of strange mysterious rules! Even now after years of working with CSS I still face daily oddities that force me to confront insanity like styling a div with overflow:none repositioning its position:absolute children (). So yeah… It was hard to pass up the ease a WYSIWYG (What You See Is What You Get) design system promises.
Somehow though, despite using this ‘god-send’ system, building the mobile UI took me forever to get right. I remember battling to position my elements the whole time. Rebuilding the UI in React without my WYSIWYG training wheels, would I have a harder time? Actually, no! It was much more fun designing the same (if not improved) UI this time around. But how?
Having granular control over the way I styled individual elements eliminated so much headache. It finally clicked for me that most interface systems, including Android’s XML styling system, are built with rules inspired by the attributes established by css. The layout editor does nothing more than hide them out of view. Obfuscating them doesn’t make the design process easier but rather ends up making it that much more mysterious. Instead of floundering against the uncertain constraints of an OS’s layout editor, working directly with the programmatic rules of a styling system provides you with the freedom to create anything you can dream of.
Design Rigidity
While learning the ins-and-outs of Android Studio I was frequently warned about the difficulty of building custom base components. Developers are pushed to use Android’s pre-packaged components or Google’s design libraries such as Material UI.
Initially though, that was actually one of my favorite aspects of working within the framework. The Material UI team did an amazing job of creating beautiful accessible elements that just worked. When you have no experience with UI design, styled components are a god-send. They allow you to focus almost entirely on the backend while still providing your users with a professional quality frontend experience. It works great, until it doesn’t.
By the time I built another app, Heart Tracker, the android scene had changed. Jetpack Compose, a reactive UI framework very much inspired by React, was gaining popularity and I was very interested. However, with this new UI framework, the impressive catalog of Material UI elements Google had amassed was no longer usable. Jetpack Compose developers were stuck with just a few dozen base components to construct our apps. Some designs simply cannot be implemented under those limitations and the user experience suffered accordingly.
For my web app port however, I constructed and designed each UI element from scratch. React has its own share of fantastic styled component libraries (including Material UI) but I still opt to design my own components.
While the average dev’s eye for design may pale in comparison to a professional design team’s, the tradeoff is worth it for the experience and control you get back.
Components I added in the port, like my photo/video toggle, would have been frustrating to make work with nothing more than a styled UI library. And hey, maybe once I complete CSS for JS Devs I’ll have what it takes to leave styled components behind forever!
Confined ecosystem
With web development there are so many ways to tackle a simple problem. Need to store data locally? You can use local storage, cookies, or open a “Save File” prompt with just a few simple lines of code.
Android development is not such a friendly experience. Many problems have a single cumbersome solution. For storage tasks, many actions require you to configure permission requests, the intricate rules of which are changed frequently as the OS updates. I found myself spending so much time scrutinizing tutorials to determine if they could actually be for the exact Android API version I was building for.
When developing the original Android app, I found myself forced into handling storage using Android’s “Room” database, an abstraction of SQLite. How it was to learn a brand new database API to handle no more than 120 locally stored boolean values. Android’s closest analog to localStorage, SharedPreferences, was unsuited for the frequent data access the app required so I used it only for the app’s settings.
I frequently found myself in this position, forced into a corner to solve problems exactly as the Android framework felt was best. It was suffocating to be confined by Google’s strict ecosystem.
Web development on the other hand provides you with so much freedom that it’s almost overwhelming! You find yourself with a blank canvas and so many frameworks, libraries, and strategies to tackle a problem that you can find yourself paralysed by the possibilities. As such, the hardest part of starting out in web development very well may be unraveling it all, figuring out what you don’t know that you don’t know! But with every stone you turn, the possibilities open up! There is no such thing as a one size fits all solution in web development.
So when I handled this issue in my rebuild I was happy to give my 120 booleans the consideration they deserved when I popped them in where they belong 😁. With web development, I’ve felt so much more freedom to determine the level of complexity required to solve problems within my projects. That is a serious blessing.
Post Launch frustrations
When my rebuild was complete I was able to almost instantly share it with the world. It’s something that’s easy to take for granted but it really is a miracle of our modern world. This is yet another pain point for mobile development. Submitting your app for approval with the Google Play Store is nerve wracking! The process can take weeks, and in the end Google might just determine that actually your app doesn’t require access to the permissions you’ve requested and leave your app dead in the water.
After my mobile app launched, several users requested a way to backup and load their data but difficulties with android permissions demotivated me from implementing the feature. Free from that overhead, I implemented that feature in my web port and now users can easily transfer data!
Once your mobile app is finally in the hands of your users and you inevitably receive your first bug report, uploading a patch through the Play Store can take days to be approved and reach your user’s device. In my experience, months or even years later, users will report bugs you’ve long since solved because their app never updated.
Since I launched my web port, I’ve had to fix several bugs, and it’s so relieving to know with certainty that every single one of my users were updated instantly.
A few months after launch when bug reports slow down or stop entirely you might be convinced that you’ve made your final update. For web development this can actually be the case! If it works well on an older browser you can be confident it will work on a newer one too.
Android development does not allow a project to rest. Every few months Android prompts developers with do or die dilemas. Every single one of my apps has been taken down a handful of times over the last few years. From contentions with my fully offline app’s privacy policies to required manifest updates to support newer devices, many unnecessary wrenches have been thrown into the smooth operation of my apps.
It’s relieving to know that as long as I host my web project, nothing can get in the way of reaching my audience.
