![]() ![]() But they realize their full potential if you do choose to share code across platforms (write all components only once), such as with using React Native Web. Nativewind or Tamagui have become viable options, even to be used in monorepo approach (with two separate apps write all components twice). It should already here be said that modern libraries for cross-platform styling (like Nativewind or Tamagui), and for cross-platform navigation (like Solito or react-native-url-router) challenge the aforementioned traditional principle that you should not share UI Render code (styling, animations, navigation) across platforms. ![]() A possible monorepo starter kit with this approach is react-native-universal-monorepo or create-t3-turbo. But on the other hand, it might be a good solution if you expect your native and web products to intentionally diverge over time. The consistency and simultaneous release of new features/UX would also need to be manually kept in sync by developers, which may be challenging over time. That may afford users, who use or switch between several platforms, a more inconsistent experience. The downside is that look-and-feel across platforms may unwittingly diverge (native mobile vs. The benefit is that users on a platform will get a look-and-feel closer to what they are used to. Monorepo: You could share some amount of code between the native and web codebases, notably:īusiness logic, state management, some configuration (translation files, TS types, URL endpoints, currency conversion etc.), API calls, formatting request/response data, and authentication.īut you would traditionally not share UI Render code (look-and-feel, like: styling, animations, navigation).New native features unique to a platform (either iOS or Android) can typically not be utilized until an equivalent feature is available for the other platform (and someone makes a RN library that utilizes the two). Native features later: You'll have to wait for RN implementations of new native features released on each platform (or implement them in RN yourself), and potentially also for bugfixes of RN builds.App startup/bootup time with the new Hermes engine that React Native uses is likely fast enough (you can achieve sub-second bootup).React Native can even run on Windows and MacOS too, not only mobile.(But Apple wants you to go through the App Store review process for significant changes to the app, outside of bug fixes etc.) If using Expo OTA / EAS Update you could push out app updates to all clients immediately, without having to go through the App Store review process (which may take days or up to 2 weeks) or risking that users don't download the update.2x codebase (must write and maintain 2 codebases), but "learn React once".App startup time is likely faster, since no need to load third party framework (like React Native or CapacitorJS).Example: shared element transitions first came to native, then were replicated on the web. Native features faster: Quickest path to utilizing native features/UX improvements once they are released, no need to wait for a third party implementation.the Android developer can't work on a new feature at the same time as the iOS developer, due to having to work on fixing a bug in a previous release. Platform specific bugs is another reason the experience may vary across platforms, and for development across platforms to get out of sync (e.g. Different times for App Store review process for iOS and Android might also cause delay. iOS) while waiting for the implementation be completed on another (e.g. So if you want to release the same feature on all platforms at once, you might need to stall a release on one platform (e.g. This can be hard, since the difficulty of implementing various functionality can vary across platforms, and developers might have varying skill level and efficiency. ![]() Must maintain 3 codebases, and keep feature releases in sync.A shared skillbase is desirable for synergy in knowledge sharing, and for flexibility: easier for all developers to pitch in where it's needed or if someone is sick. Hiring might be more difficult (specialized/smaller talent pool), as well as more difficult to create a cohesive company skillbase.Must know and use 3 programming languages: Swift for iOS, Kotlin for Android, and JS for web.The webapp (HTML+CSS+JS) is not reused on native. Note that this article is mostly geared towards (senior) developers and CTO's, although others should be able to get an overall impression from it as well. There I also compare and suggest some best-in-class starter repos, to quickly get you started. ![]() You could also skip to my recommendation at the end. Let's list them and detail some important factors and gotchas with each approach. What are the general approaches to build an app that runs both on mobile and on web/desktop? ![]()
0 Comments
Leave a Reply. |