Shortly after Apple announced SwiftUI a twitter thread erupted discussing a hypothetical Sharp UI. It was positioned an alternative for declarative ui development, across Xamarin applications in C# or F#.
If Apple has SwiftUI, perhaps we’ll Microsoft rollout # UI (Sharp UI) for as a new method for building user interfaces in @xamarinhq apps with either C# or F# ?
— Michael Bui (@MaikuB84) June 3, 2019
What’s interesting is that both Google, with Jetpack Compose, and now Apple, with SwiftUI, have joined the modern evolution of app development by introducing a declarative way to define user interfaces. Declarative UI development has been around for a long time. For example, take any of a number of XAML based frameworks that Microsoft has produced (something completely missed by Martin’s post on What SwiftUI Means for Flutter who incorrectly claims declarative ui development was invented in React by Facebook).
So why now? Why is it that Apple, Google and Microsoft have all recognised that declarative UI is the way forward?
XAML as a Declarative UI
The back history of XAML goes way back to the WinForms days. It was common for developers to fight the IDE in order to wrestle control of the window layout. XAML was supposed to fix everything. It is not designed for humans (much the same way storyboards weren’t designed to be manually coded). XAML id designed for developer tooling such as Blend.
A few XAML frameworks later and what we find ourselves in Xamarin.Forms. The XAML is non-standard version. It is similar, yet in ways dramatically different from every flavour of XAML that predates it. The industry has moved on from trying to get previewers, such as Blend, to work. The developer community favours hot reload and the ability to adjust layout within a running app.
I’m sure that Xamarin.Forms will get there with XAML but is it too much of a liability? Should we look for an alternative?
Declarative UI in Code aka #CSharpForMarkup
Following down the discussion on the SharpUI twitter thread we end up discussing an alternative to XAML, which is declaring UI in code. This sounds awfully familiar to what SwiftUI or Flutter is doing, except this is for Xamarin.Forms.
Normally I would be against using declarative ui development in code as I feel that it becomes harder to separate the UI logic from the application logic. However, having spent time reviewing CSharpForMarkup I feel that it is a viable alternative to XAML and perhaps even removes a layer or two of the cognitive load Adam talks about
Cross Platform is the Future
At Built to Roam we spend a lot of time discussing app strategy with our clients. We often talk about the spectrum of app development options ranging from native all the way through to web. Almost the first thing we do is to discount and remove from discussion both native and web. If the client wanted a web experience, they would have gone to a web development agency, instead of come to us. We’re not going to recommend building a native application, even in Xamarin, when we should be considering cross platform options.
If you’re following the announcements about SwiftUI, or Jetpack Compose, sure go ahead and read up on them. Then pack them into their single platform box and put them back on the shelf. Take our your cross platform tool of choice (React Native, Flutter, Xamarin.Forms etc) and get back to building high quality amazing apps for both iOS and Android.
Nick Randolph @thenickrandolph
If you have an app and want to go cross platform, or are just starting you app development journey, contact Built to Roam.
1 thought on “Apple Introduces SwiftUI; So What?”