Updated 01/03/24: Mux Real-Time Video and Mux Studio have been deprecated. Learn more. Links to examples using those products have been removed from this post.
React is a fantastic tool for building apps. I’ve used it extensively on many projects over the past decade. When it was released, React continued the trend of bringing web development into a new era with its declarative syntax, state handling, and component structure.
But as Steve Jobs once said, “great artists steal.” And steal they did when Apple took great ideas from React and built SwiftUI.
In fact, I find SwiftUI even more fun to work in than React.
SwiftUI is like the assembled Voltron of app development tools, in contrast to the rickety Frankenstein’s monster that React has become. I blame JavaScript developers. We are notorious for having many different tools to do the same thing. There’s a mountain of dependencies underlying even simple React apps. And that leads to complexity, fragility, and potential vulnerabilities.
As a longtime JavaScript developer myself, I’m glad we have options. But sometimes I just want to build an app instead of spending an afternoon fighting a bundler. With SwiftUI, the batteries are included, and we don’t have to spend a lot of time solving the same problems over and over.
I don’t intend this to be a direct comparison of React and SwiftUI. React is generally used for web app development, and SwiftUI is for native app development on Apple products. But I do think it’s valuable to see what else is out there and consider how we want to make our lives better as app developers. And if you’re a React developer who’s never tried SwiftUI, you may actually have an easier time picking it up than you think. Here are a few things I like about SwiftUI over React.
Styling is built in
Styled components and CSS Modules and className — oh my. As with everything in JavaScript land, you have options, but sometimes you just want to make a button pink.
I loved styled components when they first came out in 2016 (I still do, in fact). I made presentations to my coworkers predicting styling web apps would never be the same because we no longer had to use the two worst features of CSS: global variables and inheritance. We could just style a component in the same file in a little template literal at the top of the page 🤯🤯🤯.
But hear me out, dear reader: What if a perfectly good styling system was just built in? For instance, SwiftUI has Image, Button, and Text views (views are the SwiftUI equivalent of React components) that you can simply call style methods on, like background or padding. I found it easy to pick up thanks to my familiarity with CSS.
State management is built in
SwiftUI has robust state management out of the box. Using the @State property wrapper, you can turn variables into state that re-renders the view on changes, just like React’s useState hook. Oh yeah, and no weird array dereferencing to get the value and the setter. Plus, SwiftUI supports more than single state variables; it supports objects with multiple properties. You don’t even have to include an experimental library like Recoil or a convoluted system like Redux. In fact, you don’t have to include any kind of dependency for state management. Just use the complete solution that comes with SwiftUI. It even has a Context equivalent called Environment. For more information, refer to Apple’s official documentation or this article.
A declarative syntax that isn’t XML
Why are we putting HTML in our JavaScript? I realize this point has been debated since the very early days of React, and plenty of tooling has been built to provide seamless support for JSX. But it feels like a dead end to me. Browsers are never going to natively support JSX. We’re always going to need extra tooling to handle it.
Bundlers, linters, and IDE tools all have to accommodate this syntactic sugar made to look like HTML. New developers to React have to learn this bizarre approach of putting HTML, but not really HTML, into their JavaScript. Instead of XML with closing tags and attributes, why not just use a familiar syntax like functions with parameters? This is what SwiftUI does. It feels more natural to me, and it doesn’t require any extra tooling.
Storybook out of the box
The Canvas! Holy crap! I’ve been doing my best Bob Ross impression while writing SwiftUI, because I can write pretty little Views and immediately get a preview in Xcode. It’s basically like if Storybook was built into your IDE and worked seamlessly without any extra dependencies. Preview your Views in dark mode and on different screen sizes. Interact with your Views while you preview them. Feed mock data into your Views. The SwiftUI Preview in Xcode is fantastic for developing Views for your app!
Swift is my type of language
Isn’t it cool how TypeScript adds types to JavaScript? Wouldn’t it be even cooler if types were built in without extra tooling? Don’t get me wrong, TypeScript is amazing. It’s an incredible feat of engineering considering how much work has been put into the compiler and how much code has been written to adapt libraries to use types. But the bigger a project gets, the more complicated it is, and the more likely something with this bolted-on type system will go wrong. I’ve gone weeks into a project and needed dependencies that just don’t have type annotations. I’ve had libraries become incompatible with my app because of TypeScript version mismatches. I want types in my view and state code and I want them out of the box.
There goes my heart
So there you have it. Those are the differences I noticed when building apps in SwiftUI after many years of building React apps. Even though SwiftUI builds native apps on Apple platforms and not the web, this experience has really expanded my perspective on how much better app development could be. If you want to try it out, I recently wrote this guide for building a real-time video app with SwiftUI. If you want to skip straight to the code, check out this SwiftUIExample that demonstrates the Swift Spaces SDK for iOS. Happy coding!