?Visit our website and join the waiting list!
Our app is coming soon!
When the idea about the FitRadar mobile app was clear and first user requirement draft created our team started to think about the software design. And one of the first questions that rose up was – what platforms should FitRadar app target. After analyzing the market we came to conclusion that the first version should be available on Android and iOS devices. Very naturally first idea was to go for cross-platform solution by using mobile phone WebView and implement the app as HTML5, CSS, Javascript app. We started to explore this approach and discovered that it will not allow us to cover all the user stories, and we rejected this approach, but we turned to Cordova mobile development framework and Xamarin, and very quickly realized some potential pitfalls, that could stop or slow down customer base growth:
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)
2) MVVM and databinding (https://medium.com/tech-travelstart/android-data-binding-mvvm-4888eb73a25d, https://codeburst.io/swift-mvvm-two-way-binding-win-b447edc55ff5)
3) RxAndroid / RxSwift (https://github.com/ReactiveX/RxAndroid, https://github.com/ReactiveX/RxSwift)
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:
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.