Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Modern Mobile Development: Native vs Cross-Plat...

Modern Mobile Development: Native vs Cross-Platform

A question every mobile app project has to ponder is: do we want to go native, or do we want to use a cross-platform framework? And if we go the cross-platform route, which framework better suits our needs?

The choice is never easy, and requires a holistic understanding of the project’s needs, and the specific strengths and weaknesses of each approach. No two products are alike, no two companies are alike, and as such, there is no absolutely right answer. On the other hand, there are potentially many “wrong” answers that we need to identify. So, how to choose? As the common refrain in software engineering goes, “it depends”.

This session aims to give you the knowledge and tools necessary to make the best possible choice for your product, not just from a technical point of view, but also considering the impacts on the teams and the company. By covering some of the history of cross-platform frameworks, and identifying the unique pros and cons of each potential approach, we’ll reach a better understanding of the question itself, and get ready to make one of the most impactful choices for your product.

---

You can find links to the recording and slides on the talk minisite: https://go.sebastiano.dev/qcon-2022

Sebastiano Poggi

April 04, 2022
Tweet

More Decks by Sebastiano Poggi

Other Decks in Programming

Transcript

  1. Scope ‣ Goal: help you choose ‣ Agenda ‣ Preconditions

    for success ‣ Understanding mobile ‣ Native or cross-platform ‣ Pick a cross-platform stack
  2. “It depends” ‣ Everything in this talk may or may

    not apply to you ‣ Apply common sense
  3. Terminology Native app Cross-platform app Uses native build tools Android:

    Kotlin/Java/C++ iOS: ObjC/Swi Non-native build tools Potentially uses web tech Same tech across OSes Neither runs in the browser
  4. Why are you here? ‣ You want a mobile app

    ‣ Greenfield vs The Big Rewrite™ ‣ Tech debt ‣ Pre-existing team ‣ Recovering from failure
  5. Teams ‣ No full-stack engineers in mobile ‣ Mobile devs

    dislike backend work ‣ …and vice versa ‣ Information/knowledge silos ‣ Misalignment and misunderstandings
  6. Product vs Tech ‣ Different chains: ‣ Mobile reports to

    CPO ‣ Web and backend report to CTO ‣ Mobile as nobody’s child ‣ Management doesn’t “get” it ‣ Tech not built for it
  7. Not all tech is created equal ‣ Web is almost

    always ahead ‣ Mobile comes later ‣ Web is straightforward ‣ Mobile can exacerbate org issues
  8. Nobody likes failure ‣ Failure causes management frustration ‣ Blaming

    games ‣ Tech stack as way to shi responsibility ‣ Wrong choices for the wrong reasons
  9. Bad apps exist… ‣ Bad choices —> bad apps ‣

    Don’t force choices, evaluate assumptions ‣ Tech stacks don’t always work 1:1 on mobile ‣ Reach outside comfort zone ‣ Ensure higher-ups’ buy-in
  10. Help them, help your business Users don’t care about the

    tech They just want to get stuff done
  11. Before you (re)start ‣ Ask the tough questions Can you

    satisfy your users with a high quality, responsive website?
  12. Before you (re)start ‣ Ask the tough questions ‣ Use

    data to drive decisions ‣ Focus groups, user studies, etc ‣ Trust the data ‣ Even when you don’t like it
  13. Scoping and responsibilities ‣ Who owns mobile? ‣ Align with

    rest of tech if possible ‣ Think about your users ‣ What do they want to do? ‣ Define app scope and what’s not in it
  14. Capability vs capacity ‣ What can your existing teams do?

    ‣ Any native mobile devs? ‣ Do they want to do cross-platform? ‣ Ensure platform-native capability ‣ You’ll need it
  15. Capability vs capacity ‣ Most apps require OS interactions ‣

    If your app doesn’t, consider a website ‣ “Website apps” waste resources ‣ E.g.: ReactJS dev team doing mobile? ‣ Somewhat different tech and tools ‣ Native knowledge required
  16. Team participation ‣ Involve your devs in the choice ‣

    Listen to their fears ‣ Provide safety ‣ Avoid chasing tech fads ‣ Spikes are good ‣ …but can deceive
  17. Commitment ‣ In for the long run ‣ Big investment

    ‣ Huge switching costs ‣ Tech and skill lock-in ‣ Change of tech means rewrite
  18. The native advantage ‣ Native is always “be er” ‣

    Be er performance ‣ Be er integration and support ‣ More consistent with the OS ‣ More APIs/features ‣ Tooling is constantly improving
  19. Not all is rosy ‣ Native is more expensive ‣

    Dedicated team per OS ‣ Infrastructure & processes ‣ Different CI setups ‣ Different deploy and publishing
  20. The cross-platform pragmatism ‣ Native may not be the best

    for you ‣ Cross-platform may be “enough” ‣ Vastly improved over the years ‣ Some dev experience advantages ‣ Prefer strong, non-native design language
  21. A fictional app case study ‣ Wearables company ‣ Do

    they need an app? ‣ Do they need a native app?
  22. A fictional app case study ‣ Wearables company ‣ Do

    they need an app? ‣ Do they need a native app? ‣ Using the OS APIs heavily?
  23. A fictional app case study ‣ Wearables company ‣ Do

    they need an app? ‣ Do they need a native app? ‣ Using the OS APIs heavily?
  24. A fictional app case study ‣ Wearables company ‣ Do

    they need an app? ‣ Do they need a native app? ‣ Using the OS APIs heavily? ‣ Can users achieve their goals?
  25. A fictional app case study ‣ Wearables company ‣ Do

    they need an app? ‣ Do they need a native app? ‣ Using the OS APIs heavily? ‣ Can users achieve their goals?
  26. A fictional app case study ‣ Wearables company ‣ Do

    they need an app? ‣ Do they need a native app? ‣ Using the OS APIs heavily? ‣ Can users achieve their goals?
  27. The main choices React Native Xamarin Flu er ‣ From

    Facebook ‣ Derived from ReactJS ‣ Share skills/code with web team ‣ Built on JavaScript and npm ‣ 3rd party supports desktop/wearables/tv/…
  28. The main choices React Native Xamarin Flu er ‣ You

    can make B2C apps with it ‣ Plenty of “big” RN apps ‣ Performance has some limitations ‣ Custom UI needs per-platform implementations ‣ Famous cases of apps abandoning it
  29. The main choices React Native Xamarin Flu er ‣ From

    Microso ‣ Used to be paid, now it’s free and OSS ‣ Uses C# tools and NuGet, “full stack” ‣ Unique UI approach ‣ Xamarin.Forms or native views
  30. The main choices React Native Xamarin Flu er ‣ Wraps

    and exposes platform-native APIs ‣ Limited support and tools ‣ Best for internal and unsophisticated apps ‣ Very enterprise-oriented ‣ Unsuitable for B2C apps?
  31. The main choices React Native Xamarin Flu er ‣ From

    Google ‣ Quickly rising in popularity ‣ Lots of investments & marketing ‣ Great 1st party integrations (Firebase) ‣ Uses Dart and Pub
  32. The main choices React Native Xamarin Flu er ‣ Mobile,

    desktop, web, embedded ‣ No WatchOS and tvOS ‣ Full-stack: backends in Dart ‣ Best-in-class testing capabilities ‣ Dev audience skewed to Android
  33. A sense of scale Cordova React Native Flu er Ionic

    Xamarin Titanium/Appcelerator 1% 5% 11% 14% 15% 20% 1% 4% 8% 6% 12% 17% iOS (App Store) Android (Google Play) Source: AppFigures.com RIP
  34. Numbers can deceive Source: Statista.com Flu er React Native Cordova

    Ionic Xamarin PhoneGap Kotlin MP 2% 4% 11% 16% 16% 38% 42% 2% 6% 14% 18% 18% 42% 39% 0% 11% 26% 28% 29% 42% 30% 2019 2020 2021
  35. Numbers can deceive Source: Statista.com Flu er React Native Cordova

    Ionic Xamarin PhoneGap Kotlin MP 2% 4% 11% 16% 16% 38% 42% 2% 6% 14% 18% 18% 42% 39% 0% 11% 26% 28% 29% 42% 30% 2019 2020 2021
  36. Numbers can deceive Source: Statista.com Flu er React Native Cordova

    Ionic Xamarin PhoneGap Kotlin MP 2% 4% 11% 16% 16% 38% 42% 2% 6% 14% 18% 18% 42% 39% 0% 11% 26% 28% 29% 42% 30% 2019 2020 2021
  37. Numbers can deceive Source: Statista.com Flu er React Native Cordova

    Ionic Xamarin PhoneGap Kotlin MP 2% 4% 11% 16% 16% 38% 42% 2% 6% 14% 18% 18% 42% 39% 0% 11% 26% 28% 29% 42% 30% 2019 2020 2021
  38. Another fictional case study ‣ Investment (fintech) company ‣ Do

    they need an app? ‣ Do they need a native app?
  39. Another fictional case study ‣ Investment (fintech) company ‣ Do

    they need an app? ‣ Do they need a native app? ‣ Using the OS APIs heavily?
  40. Another fictional case study ‣ Investment (fintech) company ‣ Do

    they need an app? ‣ Do they need a native app? ‣ Using the OS APIs heavily?
  41. Another fictional case study ‣ Investment (fintech) company ‣ Do

    they need an app? ‣ Do they need a native app? ‣ Using the OS APIs heavily? ‣ Can users achieve their goals?
  42. Another fictional case study ‣ Investment (fintech) company ‣ Do

    they need an app? ‣ Do they need a native app? ‣ Using the OS APIs heavily? ‣ Can users achieve their goals?
  43. Another fictional case study ‣ Investment (fintech) company ‣ Do

    they need an app? ‣ Do they need a native app? ‣ Using the OS APIs heavily? ‣ Can users achieve their goals?
  44. Another fictional case study ‣ Which cross-platform framework? Strong in-house

    ReactJS team Strong in-house .Net team Using Firebase services
  45. Another fictional case study ‣ Which cross-platform framework? Strong in-house

    ReactJS team Strong in-house .Net team Using Firebase services
  46. Another fictional case study ‣ Which cross-platform framework? Strong in-house

    ReactJS team Strong in-house .Net team Using Firebase services Lots of custom UI
  47. Another fictional case study ‣ Which cross-platform framework? Strong in-house

    ReactJS team Strong in-house .Net team Using Firebase services Lots of custom UI
  48. Another fictional case study ‣ Which cross-platform framework? Strong in-house

    ReactJS team Strong in-house .Net team Using Firebase services Lots of custom UI Flu er
  49. ‣ Unit testing ‣ More or less a solved problem

    ‣ UI testing ‣ Easier in Flu er (widget tests) ‣ Native, React Native use per-platform tools ‣ Xamarin too, but custom Testing on mobile
  50. ‣ Instrumented tests ‣ Slow, runs on virtual/physical devices ‣

    Cloud services exist, but expensive ‣ Complex to set up and maintain ‣ Workarounds: more unit testing ‣ Specialised mobile CI solutions Testing mobile UI on CI
  51. ‣ Bad choices will not be immediately clear ‣ RN

    apps abandoning RN a er years ‣ Flu er may turn out the same ‣ Keep an eye on the progress ‣ Failure will be expensive… ‣ …but stopping early will help Review decisions
  52. Sort out organisation and teams 2. Create the right environment

    Make data-driven decisions 1. Understand if mobile can work for you
  53. There is no silver bullet 3. Assess the compromises Sort

    out organisation and teams 2. Create the right environment Make data-driven decisions 1. Understand if mobile can work for you
  54. Hopefully this talk helped you 4. Make the right choice

    and GO! There is no silver bullet 3. Assess the compromises Sort out organisation and teams 2. Create the right environment Make data-driven decisions 1. Understand if mobile can work for you