Last week I finally decided to dive headfirst into the realm of mobile app development. I won’t lie, I’ve attempted this several times in the past, but the results have either been mediocre or I gave into human nature and found myself back within my comfort-zone of full-stack web development, provisioning servers through command line and basking in the luxury of continuous delivery; because building for mobile is just plain frustrating and slow (🙈) … atleast until now.
Things that had to get done in 3 days:
- Build backend server — (running on AWS Elastic Beanstalk) ✅
- Design and develop the app — using React Native ✅
- Build for iOS and Android (eject, link and other platform specific stuff) ✅
- Launch TestFlight beta ✅
- Debug and improve 🙅♂️
Note: The two days didn’t include the the iterative improvements and bug-fixes that followed after releasing the beta. I was also too excited to sleep between the two days.🤷🏼♂️
Would you like to learn something new everyday?
I’m yet to come across anyone that’s yet to answer that question with a resounding “NO”. But, in reality it’s a habit that’s hard to put into practice simply because everyday life gets in the way and it’s tough to manually break learning down into smaller chunks that could be consumed daily. Yet, we somehow always find ourselves aimlessly scrolling though snap-stories, instagram feeds and other social media more than a few times a day. We’ve been working on tackling this problem for the better part of a year at AlcamyHQ.
Last month, the awesome folks at Product Hunt (Ryan Hoover ❤️) launched Sip, a simple app that sends you one tappable summary of tech stories for the day. I fell in love with the concept of ‘once-a-day’ and the snap-story like format that people are so used to. Sip quickly took over as my primary source of tech-news over the likes of scrolling through Twitter, Hacker News and other tech news sites. But the key takeaway was; could you use a similar format for mobile teaching?
Hacking a Snapchat-story-esque format that people are already used to, and leveraging it productively to build a sustainable learning habit.
I already knew building for mobile wasn’t going to be a cake walk. Everything from setting up your environment to getting a hang of React Native and the process for launching on the Apple App store & Google Play store were relatively foreign to me.
What the app needed to accomplish:
- Display a feed of lessons
- Users should be able to click into a lesson and tap through the slides to learn it. Lessons should turn grey (for ‘opened’) once completed
- Send a daily notification to users with a new lesson
Tech & services stack:
- Backend REST API and admin panel: Build using Laravel 5.6 for PHP and deployed on the AWS Elastic Beanstalk (thanks to AWS Startups). Setup included 2 x EC2 servers running the web application + MySQL database and a load balancer that I didn’t really need; but would definetely come handy if I wanted the server to scale quickly in the future.
- OneSignal: For sending push notifications.
My (planned) timeline:
- Start within my comfort-zone; build the backend API and web interface first. Get it live and running on AWS — dip.fyi
- Follow the React Native documentation to setup a basic app and run it on the simulator
- Figure out how to store data fetched from an API on mobile devices (correctly… coz that’s important and I’m responsible)
- Figure out how to send push notifications
- Figure out how to properly sign, build and publish the app on the App store
How I prioritized, so I could get things done as fast as possible!
Day -2: Pre-development
Signup for the Apple Developer Program and Play Store Console. I heard these take time; so I applied for them a few days before my 2-day execution window. Setting up an Apple Developer account took 2 days to get approved by Apple, it was much faster with the Play Store.
Tip: Plan to apply for the Apple Developer Program a full week ahead of when you want it. There’s a phone verification step and company verification through Dun & Bradstreet (if you’re registering as an organization).
Day 1: 5 hours: Backend
Built the Backend and web view. I’ve spent years building for the web, so this was a piece of cake. For anyone looking to build a REST API for your app I recommend going with Node.js, Laravel or a service like Firebase (via Google Cloud).
Developer problems: I ran into a bug while trying to deploy on AWS and had to spend almost half a day trying to fiure it out with support; while that was happening I continued with my process…
Day 1: 3 hours: Figuring out React Native
Spent a good 2–3 hours looking for React Native CLIs or boilerplate apps and sample code that could get me going faster. Turns outs that was a mistake; I knew too little about React Native to use any of the CLIs or boilerplates. So I scrapped that approach and decided to follow the tutorial from the official documentation.
Tip: Before you go any further, setup Git on the entire folder and commit frequently. You will mess-up multiple times, and when you fail to trace back any changes you’ll be glad you could go back.
Day 1: 6 hours: Building the basic app
Following the official tutorial was definitely the right idea. I progressively figured out how to create components and route between screens.
Tip: ‘Eject’ the app as soon as you create it and follow any platform specific instructions and setup as you build on the React Native app.
Day 2: 6 hours: Learn how to fetch and store data
Once I figured out adding screens and setting up a list view, I need to fetch data from an API, store it and present it as a list.
Day 2: 5 hours: Make the app launch-ready
There’s big gap between a bare-bones functional React-Native app and getting it production ready. Most of the process of ‘ejecting’ your app and getting it ready to build for iOS and Android are well documented. Things I had to do:
- Ejecting the app for iOS and Android
- Installing Xcode and Android Studio
- Linking libraries and adding platform specific code; for example there’s a bunch of things you need to do to get notifications working correctly for iOS and Android.
- Figuring out how to sign the code correctly and get it ready for the respective platforms
- Designing and adding app icons and a splash screen (those blank logo-screens you see while the app loads)
Day 3: 6 hours: Finishing touches and marketing
Last minutes changes, writing marketing copy and designing preview images for the app. Setup a Product Hunt Ship to manage beta and early access users.
I think this went as well as it could have gone. I was done with most of the app in about two and a half days, followed by a lot of finishing touches.
One of the largest ‘mind’ hurdles creators have to overcome is just hitting publish and sharing their work with real users. There’s always time to iterate and obsess over little features; but the goal should always be to get real feedback from real isers and build based off that.
Hopefully you can help us test out DIP! (–you’ll learn something new every day at the same time!)
Call to action ✅
Give DIP a shot? ❤️