DEV Community

shashank agarwal
shashank agarwal

Posted on • Originally published at pipfeed.com

8 lessons we learned building PipFeed mobile app

So I have spent my last 3 months building PipFeed.com. PipFeed is an 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 codemagic, 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 to 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 is the most important screen in your app

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 because of backward compatibility

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.

8) Have a clear 2-way communication channel with users

It is very important to have some way in which users can reach out to you. At first, we thought just asking our users to email us would be enough but I think around 5% of all users ever emailed us. That’s when we found Instabug. This is a really amazing tool and they provide a 2-minute installation. I think in all the tools mentioned here, this was the easiest to setup. We run all sorts of surveys including Net promoter Score surveys, survey to nudge users to upgrade etc. Also, Instabug lets users submit bugs reports and even vote on feature requests.

If you have a mobile app, it is very important to have a NPS survey. This is probably the one metrics VCs really care about.

Top comments (0)