Strategies for building a dual-platform mobile app
Want your app to coexist on iOS and Android? Here are a few tips to speed up your process and make it happen.
Today we’re proud to announce that hell has frozen over and Hello Weather for Android is here! It has all of the same great features as our iOS app, plus a few Android-only exclusives too. If you’re an Android user or you know someone who is, go check it out — it’s really great.
This release is a huge accomplishment for us. We’re a couple of native app novices who barely managed to make ONE decent app on ONE platform. So how the heck did we do another?
How the heck we did it
We’ve been working on Hello Weather in our spare time for about 3 years now. We have a loyal fanbase, and the app makes enough money to cover our expenses and an occasional pizza (that’s probably more profitable than most Silicon Valley startups!) Apple even featured us in the App Store. It’s gone quite well.
We wanted to make an Android version too, but Trevor and I are busy, lazy iPhone users. The prospect of maintaining apps for two platforms sounded like a lot of work, and we were sure we’d end up neglecting Android. That made us reluctant to do it.
A friendly Droid enters the scene Indeed that was the case until our boring (awesome) programmer friend Dan Kim got sufficiently irritated with the sad state of Android weather apps. To ease his own pain, he started making a rough port of Hello Weather that he could use on his Pixel. With the basics in hand, we decided it’d be cool to team up and finish the job, so Dan officially joined the scrappy Hello Weather crew.
Having a real app developer on deck has been a stark contrast to our usual totally-winging-it approach. We completed the Android app in just 2 months of tinkering — a far cry from the long 2-year gestation period for the iOS version.
Dan’s fantastic, but that’s not the only reason we were able to do this so quickly. We also made a bunch of smart architectural and philosophical decisions that gave him a big head start.
Here’s our special recipe for dual-platform app nirvana.
1. Dead simple tools.
Under the covers, Hello Weather is a basic Rails app, and simple bare-metal iOS and Android apps. There’s no fluff whatsoever — no React Native, no extra frameworks, no microservices, or any other layers of abstraction.
This makes everything small, straightforward, and easy to work on. It even all lives together in one little Git repo:
This is especially critical when you can only spare a few hours a week to work on a thing. Every single piece of tech you add is a dependency you’ll have to configure and maintain later.
Do you want to spend your time making complex parts work together? Do you want to sort out arcane bugs in 3rd party libraries? Do you want the hassle of upgrading lots of moving parts when new OS releases come out every year?
In case it wasn’t clear: NO YOU DO NOT. The basics are hard enough. Focus on the real problem you care about, then get rid of absolutely everything that’s in the way.
2. Stock UI components.
We use 100% stock components for our native UI. Whatever Apple or Google provides out of the box, that’s our jam. This is a big time savings because we’re not making custom interfaces that don’t need to be custom anyway.
Instead, we infuse our own styling and personality to make the stock stuff feel premium. (This has the added bonus of making the app HIG-friendly and intuitive.)
3. WEBVIEWS WEBVIEWS WEBVIEWS.
Hello Weather started as a hybrid native/web app (for the weather forecast view) and we kept that setup to this day. Over time we’ve added more features, like an optional fan club with in-app payments, and a special membership card you get when you join.
We originally tried making those screens native, but it proved to be difficult. We couldn’t get the various elements laid out quite right, and we were worried the whole thing would be inflexible if we wanted to change it later.
So rather than wasting precious time figuring that out, we made those screens webviews too. That cut our effort by 80% or more, and from the customer’s perspective it doesn’t matter at all.
Fast forward a year: the Android app inherited all the fan club stuff by reusing those same webviews — zero additional work needed! Once again our efficient laziness paid off.
Here’s another example. Our Rails app is in charge of telling iOS what color theme to render, based on the time and temperature that’s being shown.
When it came time for Android to do that, we already had all of the core infrastructure ready to plug right in:
Your mileage may vary depending on the kind of app you’re building, but if you can swing it, you’ll save countless hours of work with this hybrid web approach.
4. Maximize team independence.
The problem with being a tiny team where everyone has very little time is that it’s hard to schedule anything. Trevor might be on holiday in Mexico while I’m working on some stuff, or I’ll be putting a kid to bed when he has a rare free evening.
To help, we’ve taken steps to reduce our co-dependence. We added a special developer mode inside the apps, which gives us a way to quickly try new stuff internally without exposing it to customers.
Now I don’t have to generate test builds if I’m making webview changes — I just flag things as dev-only in the Rails app, flip a switch, and the new stuff is on my phone in short order.
This way we can all do our own work on our own time, test new stuff in the real world, and only sync up when we absolutely have to.
5. Say no to everything you don’t want to do.
This is a spare-time passion project, not something we have to do. The operative word there is passion. If we’re not having fun, it will just die out, because nobody wants to do sucky uninteresting work in their free time.
That means we’re extremely strict about only doing what we want.
At one point we debated supporting Android 5.x devices. They still comprise about 50% of the Android market, but it’s a pain for us to test and support older hardware, and that audience will only diminish over time. Within two minutes we chose to skip that pain and simply require Android 6+. We’ll be a premium app for newer devices — it’s fine!
The result is that our work is always 100% fun. I often fiddle with the app instead of watching an hour of TV or some other mindless time-wasting thing I’d be doing otherwise. It’s a goofy pastime where you get to explore whatever you’re into that day, and that’s the best.
Our overall philosophy might seem untenable if you work for a Real Company that has Actual Stakeholders, but maybe it’s not.
Think about it — do you really have to do everything you feel obligated to do? You might be able to eliminate a lot more aimless crap than you think.
Be on the lookout for everything you can not do. The more fun things are for you, the better your product will be. You might even be able to make TWO apps with all the time you’ll save. 😁