The Preface

It was mid-2017, and I was neck deep firefighting the closing stage of an App in social-media domain for a client. It was a Tuesday, and we had made all the essential planning for the GoLive on Thursday. We were all set to sign-off on the development phase; but then how often have things gone 100% as per the plan?! At the last moment the client came in with a request to change some essential aspects of the landing page. We quickly discussed the feasibility of the change-request, and came to a conclusion that the design change requested by the client was not possible with out-of-the-box available widgets that too for both Android and iOS in the given timeframe. Fortunately we were able to convince the client to move the change-request to the next phase, and went live on that Thursday. However, I had now noted the fact that customising the inbuilt widgets (buttons, textviews, etc.) quickly was somewhat painful.

For every App I implemented until mid-2017 had a backend with 2 main components: framework + database. The business/App logic was written in the chosen framework, and the data was stored into the database. Here the backend team had to undergo a tedious task of setting up a server, installing the framework-database, and connecting the database. We had observed that even for some of simplest of the Apps we had to undergo this setup cycle, which at times was time consuming for small projects.

Once the App development cycle completes, the next step is to upload the App to PlayStore(Android), and AppStore(iOS) respectively. I used to keep a buffer of 2 days just for uploading the App to the respective platforms, as there were quite a few pre-upload steps (certificate/key management, snapshot upload, beta-platform-upload etc.) that needed to be completed before the App submission was successful. This was quite tedious especially when there are multiple people working on it.

The Buildup

The Firebase AppFest Pune’17:
In summer of 2017 we started our very first internship program. Intention was to work on some innovative problem statements to potentially provide a sharp(er) edge to our day-to-day App development process. The interns and me were working on Tesseract OCR to automate retrieval of meaningful data from travel itinerary PDFs. While working on Tesseract, we came across Tesseract’s better version i.e. GoogleVision. After some successful trials, we decided to build an App for this; and had setup a Django based backend for the same. It was around the same time that Google Developer Group (Pune) announced ‘Firebase AppFest’. I had read about Firebase a year ago, but this time it seemed way too interesting. We decided to attend the Firebase AppFest. After attending this one day event I was pretty sure that we needed to get acquainted with Firebase, and add it to our App development technology stack.

As of today Firebase provides out-of-the-box support for:
1. Realtime Database
2. Cloud Firestore
3. Hosting
4. Authentication
5. Cloud Functions
6. Cloud Storage
7. Notifications
8. AdWords/AdMob
9. Performance Monitoring
to name a few…

In early 2017 I had started getting my feet wet with React Native since we had received requirements for App development work with pressing timelines and budgets. The factors of short timelines and small budgets gave a very little scope to invest in two separate native Android and iOS teams. While reading about React Native, I had also come across another mobile app SDK named Flutter by Google. After watching one of the Google I/O 2017’s talk which gave a demo of Flutter concepts, I knew I had to start getting hand-ons with Flutter.

Flutter attracted my attention since:
1. Everything is insanely customisable! Right from paddings, themes to navigations; everything is customisable. In a sense it breaks away from the ‘Cookie Cutter’ App frameworks. Hence, it is a very designer friendly SDK. (No more rejecting UI team’s design just because the inbuilt widgets don’t support it)
2. It works with Firebase like a charm! Hence, no more investing time on backend server+database setups just for getting a working datastore for the App.

There are a host of other obvious reasons for Flutter’s existence which you can read here.

Voila…the recipe is here!

Come July’17 one of my mentors (of my internship days) pinged me to ask if I would like to work on a Flutter+Firebase based product for a stealth mode startup based out of SanFrancisco. How often do you work on some technology stack as a self-study, and get to work on the same for an actual interesting product! I readily took this opportunity as I knew this was an awesome chance to learn how gaming industry and it’s supporting tech. industry works.

Over the last 3 months I also got acquainted with Fastlane, an automation tool for Android and iOS deployment. I was awestruck just contemplating how many hours I could’ve had saved, had I known about Fastlane for uploading and releasing the App. Bye-Bye to investing a whole day for generating screenshots, dealing with code signing, and releasing applications on PlayStore and AppStore! Fastlane, you’re a charm!

Each day of past 3 months I’m learning new concepts, features, and tricks.
Flutter and Firebase too are improving in terms of their features, efficiency and ease-of-use. I hope that this technology stack matures in coming days, and provide a much promised simplistic, effective and efficient approach to App development.

• Peace \m/