Building for iOS and Android at the same time
Workflow strategy & takeaways
Most teams start off with the question “Which platform should we build for first?” Choosing the platform can either be a business decision or driven by which platform the majority of your customers are using. It makes sense to lead with one platform and then build out the other. You’re able to stay focused on one experience, optimize for the team’s literacy in a specific language and you can test features on one platform before moving to the next.
But what if you were to build a greenfield iOS and Android app at the same time? This becomes challenging. Product needs to have 2 parallel backlogs, design needs to have an understanding of each platform’s design patterns, and engineering velocity and complexity will fluctuate feature-to-feature.
Although it’s more difficult to build for both platforms at the same time, there is some upside. You can potentially go-to-market faster, make engineering choices with a holistic view of both platforms and prevent rewriting logic that’s on the client.
Below are a few takeaways if you’re going to build for both platforms in parallel:
1. Lead with one platform
Even though your building for both platforms at the same time, one team should be ~2 weeks in front of the other. Product can test new working software, and the engineers, who are trailing by 2 weeks, will consume endpoints that are more stable.
2. Cross team pair and collectively own the backend
I highly suggest cross-team pairing between iOS and Android engineers. Each team will become more aware of the other team’s progress and the developers will have a shared knowledge of the technical decisions that the team has made. Pairing will also give engineers collective input on those technical decisions — which enables them to make the best choices that satisfy both teams.
3. Logic on the server and not on the client
The majority of the logic for your application should be on the server and not on the client. This prevents rewriting logic that already exists and makes it easier to scale to different platforms.
4. Adhere to native interaction and design patterns
iOS and Android users have a mental model of their system specific interactions. Know the difference between each platform’s UI elements and controls. Don’t try to retrofit a dialog or alert into a view if it goes against the platform’s design paradigm. Creating custom components is costly and hard to maintain. You should only deviate when you can justify that it provides enough value to the brand or experience of the app.
5. Understand ecosystem constraints
iOS and Android native APIs are different. Something that is trivial to an engineer on iOS may be very difficult to implement on Android. Be conscious of the delta between both platforms. This will effect engineering velocity and technical decisions along the way.
Thoughts
Very few people will use your app on both iOS and Android devices. Most people will only have one device. The core utility of your app should maintain feature parity but the overall experience of your app can differ from platform to platform.
Let me hear your thoughts, opinions — Follow me @PaulFarino
