10 Tips for Successful Cross-Platform Mobile App Development

Learning how to correctly develop apps across platforms such as iOS, Android and Windows is an important skill that can help developers get ahead and stay ahead.

In this image, you can see the Evernote mobile app running on iOS 8, Android 4.4.4 and Windows Phone 8.1. These screenshots were taken at the same time and are showing the main screen of the app, logged in as the same user, so the data is exactly the same. However, as you can see, the user interface is completely different across the platforms. Still, they are each beautiful and well-designed in their own right. Before you design your apps, take a step back, learn how your target platforms work and implement your branding around their specific parameters.

Think about your cross-platform design strategy before you start building your apps. That way you can have a more realistic sense of what can be reused and what can’t. Expecting 100 percent code reuse isn’t reasonable because it not only means you’d have very little control over your app’s UI/UX, but also most likely means that your app would look exactly the same across all target platforms; again, not ideal. Of course, some people think this is the ultimate goal of a cross-platform tool, but that’s misguided. That’s the goal of a Web browser. High reusability, however, is desirable with your app’s logic.

When developing cross-platform apps, build your code completely abstract, as if it were a Web service. Build all your programming logic completely independent from the screens or even the platform on which it will be running, making all of your programming modules platform-agnostic—but most importantly, reusable—across platforms. Then you can build the native user interfaces, which will consume these “local Web services.” Using this architecture, you can make sure that all the user interface code is completely decoupled from the logic, and both can flow independently. With this approach, it doesn’t make any difference if you’re using a TabbedBar on iOS or a ViewPager on Android because, after all, the user interface code is simply a consumer of your app logic.

iOS tabs have a built-in “NavigationController,” which allows you to have multiple levels of navigation inside each tab. Android Tabs, however, are shallow and should have no in-tab navigation. To illustrate this, here is how the Facebook app for Android was approaching this incorrectly (it has since been fixed). This slide shows the former Notifications Tab of the Facebook app for Android (left). As per Android design guidelines, tapping on the back button in the main screen with tabs should kill the app. Now, if you click on any of the notifications on the Facebook app, you’ll see what’s illustrated on the right. Facebook was trying to use iOS-style functionality that provides in-tab navigation, but it ended up being confusing and counterintuitive. As a rule of thumb, don’t try to force navigation inside your Android tabs. Doing so will break the operation of the back button and make your app feel awkward.

The tab example on the previous slide is just one reason why it’s important to know your target platforms. The best way of knowing what’s available to your app, and what you should and shouldn’t do, is to read each platform’s user interface guidelines. Unless you own devices with the all of the operating systems you’re targeting and use them on a daily basis, it’s hard to thoroughly understand their behavioral and visual similarities and differences. Most developers need to take the time to read the guidelines in full.

If you’re a programmer and there’s a graphic artist on your team, or you’re working as a contractor/freelancer for an agency that is giving you mock-ups of the app to be built, learn to work with them and educate them. Help them to understand that each platform has a native way of displaying information, laying out screens and implementing navigation, and that these differences go far beyond Android having a back button and an Action Bar. Mobile platforms are different, so by definition your cross-platform apps will look slightly different across platforms. This can take some education, but it’s worth it to avoid misunderstandings.

There’s no need to reinvent the wheel when it comes to building mobile apps. Before you get started, look around for prebuilt modules that can save you huge amounts of time but still deliver the same level of functionality. With native iOS apps, you can use CocoaPods; with Android there’s the Gradle dependency manager, which offers a similar solution.

Don’t let your personal preferences influence the design, functionality and quality of your cross-platform apps. Even if you love iOS, don’t show more commitment to your iOS app, leaving behind your Android users. Learn to love each platform with their strengths and limitations. Learn to compare them but not criticize them. They are all good in their own right and in their own contexts. Always try to build the best possible app for the platform you’re targeting.

Since your app by definition will have both cross-platform and platform-specific code and components, make sure you test often. If you’re using a cross-platform framework, don’t spend days working on the Android version, to then run it on iOS and realize the object positions are off, fonts need adjusting or your app is simply crashing on load. Test often, so if something breaks on one platform, you can immediately identify the problem.

Your user is the most important consideration when it comes to building your app. Always be a user of the target platform and know how the platform works. Then use your app so you can experience it for yourself. Also look around, examine other apps, compare and analyze as honestly as you can. When you’re testing your own app, ask yourself: Would I use this app? Does this app feel right? Make sure it conforms to your own quality standards. If you love your app, most likely your users will love it, too.