Once the “Discover” feature was stable, the web engineers that were originally involved with the React Native development went back to work on the web platform, and nobody was actively maintaining the React Native repository. This list of issues were issues that are specific to us and do not represent issues with React Native as a whole. IOS and Android app architecture with shared React Native component. Subsequently, we introduced “Discover” to our Android app, and our apps’ architecture roughly looked like this: “Discover” feature was initially introduced in the old version of our iOS app and our data showed that it performed admirably, hence we decided to bring it into the new iOS app as well. However, since most of the mobile engineers were focusing on rewriting the application, we decided to introduce React Native to allow web engineers to work on this feature separately. In parallel with the iOS app rewrite, we also wanted to introduce a new feature called “Discover”, where users can find various interesting contents inside our platform. This required a huge amount of effort and time that involves almost everybody in the mobile app team. In 2018, we decided to do a full rewrite of our iOS application. Why we adopted React Native in the first place In this article, we are going to talk about the reasoning behind our decision to adopt, and move away from React Native, and why we decided to adopt Kotlin Multiplatform in our mobile apps. This article was originally written in Japanese by my colleague 久保出雅俊.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |