- right now the user requirements are mostly set by business owners and testers and not that much by potential users. But when the app will acquire the first customers their feedback will play big role in defining the app’s next version feature set. And even if cross-platform solution could satisfy are needs now, in the future we could run in to the situation where cross-platform solution won’t be able to provide the features, performance or design that users are asking for. And that in turn will lead the project to stagnation.
- our app is not just an attachment to the main business but it drives the business, therefore it should meet the highest user expectations.
- native apps usually have greater visibility at app stores and often get better user ratings and recommendations. This is essential for a good APP Store Optimization (ASO) positioning. Mostly because designing and building an app for multiple platforms with platform-specific user experience is too difficult
Once we agreed on the native approach we needed to decide with which platform to start and how to share the work done for one platform with other platform. We started to explore different approaches and technologies that would allow us to reuse the artifacts to some extent. As for now there is no magic technology that would allow us to convert Android app into iOS app or vice versa, therefore the approach we chose is to separate as much as possible the platform dependent code like UI from platform independent code like view models, business models and logic and data access code. And in such way we hoped that conversion of one language code base to another one could be be done faster. After exploring and comparing several approaches and technologies the several stood out among the others as the ones that work on both platforms:
1) Clean Architecture (https://medium.com/@dmilicic/a-detailed-guide-on-developing-android-apps-using-the-clean-architecture-pattern-d38d71e94029, https://github.com/sergdort/CleanArchitectureRxSwift)
The main idea was to make the platform specific code as lean as possible and shared code as similar as possible on both platforms. It would allow us easy and quickly convert the shared code from one platform language to another. It turns out that the solution structure, app layers and the idea of common code and platform specific code separation was similar to one used by Xamarian (https://developer.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/part_3_-_setting_up_a_xamarin_cross_platform_solution/). The idea that we could speed up development just by using one common language in this case C# was very attractive. And therefor we decided to revise our decision regarding the native approach. We talked to other software development teams that have experience in delivering apps using Xamarin and the here is what they shared with us:
- it works – you can create cross-platform app using one code base, but whether it saves time and money really depends on the project, because
- the code you share between platforms is only about 50-70% from all the code, the rest is platform specific code and it has to be written for each platform separately
- the development time for non out of the box platform specific features increases, since not all nice and useful third party libraries have Xamarin bind/port.
- developers have much less help at their disposal to tackle a problem faced during the development. The Xamarin community is much smaller than Android or iOS. It means it could take more time.
- the deployment of app even to a real device is much slower comparing with native app deployment. And again it means that the development process is slower.
And once again we came to the same conclusion – the cross-platform benefits in our project will not outweigh the potential risks it could introduce.