Native Development Without Double Cost

A talk I presented at the Mobile DevOps Summit 22. In this talk I show ways to optimize native development to ensure that developing an app for the iOS and Android platforms natively doesn't mean that you have double the cost.

Transcript

1. Mobile DevOps Summit 2022 Native development without double cost
2. About me 2 ‣Founder / CEO at Egeniq ‣ Solution architect ‣Media apps ‣Dutch COVID-19 apps ‣Organizer of Appdevcon
3. Native vs Cross Platform
4. Native vs Cross Platform - Benefits ‣Native benefits ‣How the platform vendors intended it ‣Direct integration of device features ‣An Android UI that Android users expect ‣An iOS UI that iOS users expect ‣Best performance ‣No leaky abstractions ‣Small binaries ‣Large development ecosystem ‣Long term support 4 ‣Cross platform benefits ‣One codebase to rule them all ‣Common abstraction of device features ‣The same UI on all platforms ‣(Unless you spend additional time) ‣Not limited to iOS/Android ‣e.g. Flutter on web
5. Native vs Cross Platform - Drawbacks ‣Native drawbacks ‣2 codebases to maintain ‣Needs separate testing for Android and iOS 5 ‣Cross-platform drawbacks ‣3 stacks to master ‣Needs separate testing for Android and iOS ‣The same UI on all platforms ‣Feels ‘off’ to experienced users ‣Performance ‣Lack of longevity ‣Cordova now considered ‘legacy’ ‣ReactNative losing ground to Flutter ‣Reduced older OS version support
6. Seeking best of both worlds Can we harness the benefits of native, while gaining some of the benefits that cross-platform offers? 6
7. What we want to avoid 7 iOS Android 1 1 + 2 Architecture Development Testing
8. Shared Architecture
9. Android and iOS development paradigms are converging 9 Java Objective-C Years ago….
10. Android and iOS development paradigms are converging 10 Java Objective-C Kotlin Swift Coroutines Async/await Compose SwiftUI MVVM
11. Shared Architecture Approach ‣Shared Architecture Approach: ‣An iOS and Android engineer cooperate on the technical design: ‣One datamodel for Android and iOS ‣One definition of business logic ‣One approach for backend integration 11
12. Shared Architecture Approach 12 Conceptual Data Model Model layer ViewModel layer View layer
13. Shared Architecture Approach 13 Conceptual iOS Android Data Model Model layer ViewModel layer View layer Compose Views SwiftUI Views ViewModel ViewModel Repositories / Models Repositories / Data Classes Core Data / SQLite Room / 
 SQLite
14. Impact on project 14 iOS Android 0.70 0.70 + 1.7 Architecture Development Testing Shared 0.30
15. Asynchronous Development
16. What is asynchronous development? 16 iOS Android Develo p feature A Develo p feature B
17. What is asynchronous development? 17 iOS Android Develo p feature A Develo p feature B Port feature A Port Feature B
18. Impact on project 18 iOS Android 0.65 0.65 + 1.5 Architecture Development Testing Shared 0.20 feature A feature B feature C feature D port A port B port C port D
19. Shared Core
20. Shared Core Approach 20 iOS Android Layouts / Views Xibs / ViewControllers ViewModel ViewModel Repositories / Data Classes Storage { } Swift Kotlin { Some shared language
21. Shared Core Approach 21 iOS Android Layouts / Views Xibs / ViewControllers ViewModel ViewModel Repositories / Data Classes Storage { } Swift Kotlin { Some shared language Device features Device features { Swift }Kotlin
22. Options for shared cores ‣Shared core could be written in: ‣Kotlin Multiplatform ‣C / C++ ‣Go ‣Rust ‣… 22
23. Shared Core - Kotlin Multiplatform 23 Kotlin Multiplatform: ‣No need to add a 3d stack ‣Development could be handled by the Android devs ‣Is specifically created for the ‘shared core’ use case
24. Shared Core - Others 24 C / C++ ‣ 3 stacks to master ‣ Relatively complex ‣ Very performant ‣ Small footprint ‣ Tough to find devs Go ‣ 3 stacks to master ‣ Bigger binaries ‣ Popular language ‣ Good performance ‣ Easy to learn Rust ‣ 3 stacks to master ‣ Good performance ‣ Suitable for backends too ‣ Tough to find devs
25. Impact on project 25 iOS Android 0.4 0.4 + 1.4 Architecture Development Testing Shared 0.6
26. Combine all the things!
27. Impact on project - all 3 optimisations combined 27 iOS Android 0.30 0.30 + 1.2 ? Architecture Development Testing Shared 0.60 feature A feature B feature C feature D port A port B port C port D
28. Learnings 1.2 is a bit ambitious ‣Methods aren’t fully complementary but overlap ‣If shared core pushes the native code mostly to the UI, then the porting effect of async development is damped a bit In our experience a 1.3-1.6 factor is definitely feasible! 28
29. Other Considerations
30. Other Considerations: a project is more than app development ‣Consider the total size of a project: ‣4 person project + separate iOS / Android devs = meh. ‣Additional cost factor of doing native (without the optimisations in this talk) = ~ 2 ‣60 person project + small number of programmers , doing +2 devs to be able to remain native = sure, why not. ‣Additional cost factor of doing native (again without optimisations) = ~ 1.03 30
31. Other Considerations: skills gap ‣The cost of native vs cross platform is also determined by: ‣Existing skills in team ‣E.g. a team coming from web development will be faster in React Native ‣Nature of the project ‣A throw-away… marketing… ui-only project will benefit more from cross platform ‣A strategic app with years of support will benefit more from native 31
32. The Future We do research into optimised native development: 32 We will continue to share our findings /learnings
33. Thank you! Questions? ivo@egeniq.com Ivo Jansch @ijansch