7 things I learned from building a mobile app for the first time
So I have spent my last 3 months building PipFeed.com. PipFeed is a A.I. powered curated reading app. Think of it as when Pocket met Medium.
I am an ex-AWS engineer and my main language of choice is JAVA but I can code in PHP, python, js etc.
The backend for PipFeed is in JAVA with a few services in python, node.js & PHP. In January 2020 I learned Flutter and built the mobile app for PipFeed using it.
This is my first experience building a mobile app and here are some of the learnings that I would like to share with you all.
### 1) Have a CI/CD
For mobile apps, it is extremely important to have a CI/CD. We use code magic, it ties up nicely with our Flutter ecosystem. Mobile apps need a lot more work to release like signing, bundle, etc etc.
P.S. I still don't have a CI/CD for my backends and I deploy my AWS backend from my laptop using Cloudformation templates.
2) Mobile apps crash a lot
As compared to websites, backend code, and stand-alone software, mobile apps fail and throw exceptions a lot more. There are all sorts of errors like network errors, some image fails to load etc.
To make the app stable, we had to add a lot of exception handling, null checks, and mostly retries in almost all network calls.
3) Distributed logs
We use Sentry & Crashlytics to manage and catch all our exceptions & logs. We really love the service and it has a nice pricing model. We have now integrated our backend in JAVA with Sentry.
4) Analytics is everything
We use a mix of firebase, mixpanel & AWS cloudwatch for our analytics. Analytics on mobile is a bit harder as everything you want to track requires a code change. Also, that would mean a lot of network calls for each event.
We found a way and moved the analytics to our backend system. So on an action like read, like, comment, etc when there is a database update, we trigger lambdas using AWS DDB stream and send metrics from there to other services. This helps us reduce the overall number of network requests and makes it easier to have the logic out of the mobile app.
5) It's so hard t A/B test
As compared to any other software A/B testing is really hard on mobile. With websites you can have a version that people will see when they visit your URL with mobile your users will have a whole mix of versions, devices, screen-sizes and a lot more variables. So we are still figuring out how to do this.
Implementing A/B testing is harder in mobile as we need to create two separate code blocks and use firebase remote config or something similar to run once code block for some users and another for some other.
6) Login/SignUp
The most important piece of code in your mobile app is your login/signup page.
We learned this the hard way. We never paid much attention to our sigun/login page but when we analyzed the analytics we saw that from all the people who "installed" the app only 60% were actually signing up.
Hence we now do rigorous testing of our signup page. After so much work we still keep finding a lot of bugs/error in our login & signup flow.
7) Updates are harder
With AWS, I am used to pushing to Production almost every other day. But with mobile, you need to take care of backward compatibility a lot more.
Like we have a bug in our app where a blog will show as being "unfollowed" even when the user is following it. This was caused by two bugs with one being in the mobile app and another in our backend. Now if I fix the backend bug the current mobile app will break. So what we do? We fixed the bug in the mobile app and after around 15 days or when 90% of users have updated to the latest app, we will push fix to the backend.
That's all for now. These were the learning I have had from working on mobile apps for the last 3 months. I hope these are helpful to the community.
Do checkout PipFeed. It's both in the play store and app store and let me know what you guys think.
P.S. I have used "We" in this post but it's just me who built PipFeed. I felt a bit narcissistic to write "I" so many times so I used "We".
