Busting the Myths with Cross-Platform Xamarin
summary
Xamarin promises big code sharing but the reality is concrete: a public‑transport ticket app ends up with two heavy platform projects and a tiny shared layer; UI work often requires custom renderers per platform; a dynamic image loader causes a memory leak on a newer Android phone that forces native profiling and fixes; tooling requires a Mac to compile iOS and Visual Studio paired over the network; Xamarin.Forms reduces UI duplication but adds friction and limits platform control.
AI-written summary · about
chapters (21)
- 0:00Introduction
- 0:42Filip Ekberg
- 3:20Native compiled binary
- 5:27Misconceptions
- 7:00Theres no silver bullet
- 7:43C Sharp is not enough
- 10:50Understanding the different platforms
- 13:11Building apps for different platforms
- 14:32Platformspecific design guidelines
- 15:41What happens in our app
- 17:37The project
- 26:55C is not enough
- 27:55Universal Windows
- 28:19The Promise
- 28:45The Sad Faces
- 29:13Adding an abstraction
- 30:23Why add an abstraction
- 31:44Shared UI example
- 38:23Cochairing
- 40:31Benefits of crossplatform development
- 41:28Stamming
related talks
30mYear of the Xamarin.Forms
43mXamarin Forms: one technology to rule them all
11mMobile development in 2019: native versus cross-platform
47mEvolution of Xamarin.Forms!
18mCross-Platform Development as a Native Mobile Developer
21mBridging, Compiling, and Rendering: How Cross-Platform Frameworks Work
23m.NET MAUI: What on earth is this thing?
58mBuilding cross-platform mobile apps with Flutter.io