The Lazy Coder Series: What’s Still Broken in Mobile Dev in 2021?

Zorayr Khalapyan
4 min readMar 26, 2021

We have made good progress in simplifying mobile dev 📈, but we are still years behind web. I wanted to cover some themes I uncovered while working on my latest mobile app, mostly centered around iOS social spaces, but some of the themes do translate well to the greater ecosystem.

I hope in the future we can decrease these barriers and unlock even more global creative potential! You shouldn’t need a degree and 6 months to launch what you’ve imagined!

Lack of Bootstrap for Mobile

SwiftUI, Flutter, Jetpack Compose are leading the wave of declarative UI frameworks allowing us to build significantly more UI with significantly less code. This is actually a game changer; anyone that has swapped out a 1,000 line UITableView implementation for a 5 line List can attest to this!

As a quick analogy, imagine if you had to make fries — imperative code would say, “1. Buy potatoes, 2. Peel potatoes, 3. Fry potatoes,” whereas declarative code would just say, “fries” and let the framework figure out how to make it.

At facebook, we had at the time fairly revolutionary framework called ComponentKit, but it relied on C++ interop which limited wider adoption. All the declarative frameworks are still fairly new, have rough edges and lots of stability issues, but I fully it is the future. RIP UIKit, it won’t be missed.

But where does this let developers? Yes, we can write UI faster, but roughly 90% of apps are built of the same interface. Some portion is provided by the UI libraries, but a vast majority still needs to be built by hand. Not only the UI portion, but also the service layer that handles it

Take for example, profile photo uploader — do I really need to build the 1,000,000th profile photo uploader screen in 2021? Probably not. I should be able to use a bootstrap equivalent with some minor hosting service that gets the job done just well.

Same with contact upload, invites flow, badging, notifications, etc. larger lego pieces would be helpful. I suspect there is a decent business to be made by selling individual SwiftUI snippets built from good templates.

The wave of declarative UI frameworks means that view extractions are super simple. People already compile giant lists of views, but the poor curation means that you have more misses than hits and the only way forward is trial & error. 😢

An interesting question is why this still doesn’t exist? 🤷‍♂️ The answer is probably not very intuitive or obvious!

Difficult Maze of Moderation

For any moderately successful app, moderation is a real issue. There are two types of issues I have encountered personally, (1) content moderation — should this piece of content be visible in the app, (2) user moderation — should this particular user be allowed to continue using the product?

For content moderation, you can easily build something in Retool or Airtable, but it will require your 24/7 hour attention, which is just not practical. The time difference in between our team in the Bay Area and our launch site in Sydney, AU meant that most of the time the content would get approved 6 hours after it was created 😢

If the content is more on the offensive side, think your stereotypical 🍆 pics, HiveModeration is a super cool tool. It will detect offensive content from videos to audio, but the more community style moderation still needs to be built on top.

The second problem is actually even worse. There are few abusers, but they will abuse with vengeance. How to detect these people and actually kick them out is a hard problem. We would auto-ban them immediately, but other companies have 3-strike policies that use sophisticated weighting methods for different offenses.

You can ban their email, but they can login with phone number. You can ban their phone number, but they still use VoIP numbers! Banning on IP addresses is even more complex. This is a problem.

I am curious why a facebook style reporting flow company doesn’t yet exist. Something that would combine user reporting flow with a three strike policy.

Lack of Good Login Abstraction

There are three problems here: (1) writing login systems, even with Firebase, is time complex (2) analytics, dashboarding, error logging is manual and error prone i.e. figure out why x% are dropping off? (3) edge case handling is usually not well handled; from blocked users using different email addresses infiltrate to people just forgetting they already have an account and creating a new one 🤦‍♂️

I spent a few weeks building and debugging phone number, facebook and apple login systems that work together and integrate with firebase. To this day my login system has a 10% drop off, I suspect some of it is organic, but large portion is from oddities of login systems.

Recent acquisition of auth0 by otka leaves room for newcomers to reimagine login systems for mobile. I shouldn’t talk to sales to setup login, it should just work.

What else?

As I was writing this, I realized there is just too much ground to cover. Companies that provide solutions for specific verticals like a recent launch of Space to simplify social audio will keep growing and power the the new wave of mobile products. Flutter and Expo.io make strong strides towards cross platform mobile development, introducing their own ecosystems. Mobile is definitely not dead, it’s growing.

--

--