I Built the Same App with 6 Different Frameworks

The world of mobile app development is complex and expansive.

If you're starting a new project, you likely feel overwhelmed by all the options.

So you decide to do some research to figure out what's the best tool for you.

According to Google's AI overview,

Flutter is best for "high-performance" apps,

whereas React Native is best for "near-native performance".

Kotlin Multiplatform and SwiftUI,

despite actually being native frameworks,

include no mention of performance at all.

And if you want to know which framework is the best,

it's all of them.

If you're skeptical about these claims,

you can do some deep research using real human opinions from real human developers on Reddit.

"Is Flutter slowly dying?"

"Is React Native really that bad?"

"Jetpack Compose is a great idea, but poor implementation."

"Why is NativeScript so dead?"

"Is SwiftUI really the future?"

Hell, I've even contributed to the pool of collective knowledge.

If you watched my video about React Native,

you may have noticed that I was very careful not to endorse any particular mobile app framework.

That's because I legitimately don't know which one is the best.

But today I'm going to fix that.

In this video, I'm going to build the same app with six different frameworks

and give my opinion on which framework you should be using for your projects.

The app I'm going to be building is a simplified version of the Reddit app.

It'll only display the top posts for each subreddit in the past 24 hours.

This way, I won't be tempted to waste time scrolling endlessly looking for more news.

If you didn't know,

you can add ".json" to the end of a Reddit URL to get the posts in JSON form.

I assume there's some rate limit when doing this,

but since I'm fetching about 50 posts total,

I'm going to fall well below the rate limiting threshold.

I kept it extremely simple because I am going to build this six separate times.

I'm going to evaluate each framework based on installation complexity,

debugging experience,

state management,

and any roadblocks that come up during the development process.

So let's get started.

SwiftUI was created in 2019 by Apple to replace their existing UIKit framework.

So you could say SwiftUI is the "new native" framework for iPhones.

It took me about 1 hour and 50 minutes to build my app,

which isn't very fast,

but keep in mind that this is the first framework I used.

The binary size is 1.8 MB,

and the startup time is 0.683 seconds.

I would take these startup time measurements with a grain of salt

since I'm only using a sample size of one app launch.

Here are the good parts about SwiftUI.

SwiftUI is native code for iPhone,

so that avoids all of the problems that come with foreign function interfaces and interfacing between something like

Dart or JavaScript and the actual native code.

The SwiftUI preview system is pretty sophisticated.

So you can see here this `#Preview` macro

that allows you to specify what you want shown in the preview on the side.

For demo purposes I'm showing the preview in the iPhone simulator,

but you can also have it work live on your actual phone.

And this preview isn't just a static preview.

You can click on things and actually have them send requests and store state and that sort of thing.

So if you want to teleport to some state in your app,

you can set up your preview in such a way that you don't have to click through your user interface

to get to the state that you want to test.

Another cool thing are these "Canvas Device Settings",

where you can set the color theme to light or dark,

or change from portrait to landscape mode,

or make the text bigger or smaller,

which is very important for accessibility

because a lot of people with vision problems will make the text bigger on the operating system level.

The way SwiftUI does state management is awesome

because you don't need any third-party package to actually make it work.

And it's basically using a lot of compiler magic

to give you all of the safety guarantees and to make everything clean and simple.

It's kind of hard to explain if you haven't seen how it's done worse,

but we're going to see that later.

So you put this `@Observable` property wrapper on your class,

and this essentially marks all the fields on that class as being state.

And SwiftUI tracks which state on your observable that you actually use,

so it'll only re-render the view when that specific field that you're using changes.

So it's kind of idiot-proof, like you can't really mess it up.

I'm sure someone in the comments will tell me how they messed it up,

but it's easily the simplest state management I've seen in a front-end framework.

A really cool thing about Swift as a programming language is the way it does exception handling.

So you can see here that I have this compiler error saying:

"Call can throw, but it is not marked with 'try' and the error is not handled".

So the compiler tells you which lines of code can actually throw exceptions.

So in my code, I catch the exception and set the error message.

But let's say you didn't want to do that.

Maybe there's nothing you can do with the exception.

So instead, you can put `try?`, which is kind of like "try or null",

and then you can see here we get another compiler error.

That's because now `redditResponse` is an optional type, right? It's a nullable type, it could be null.

So this makes way more sense than if you look at something like TypeScript or Dart or C# or

most other programming languages.

Here are the bad parts about using SwiftUI.

There's no way of taking your SwiftUI app and making it run on Android devices.

So you're going to need to use a different framework for Android.

You're also not going to be using Swift for your backend if you have a backend for your app.

The Xcode AI integration doesn't have access to your file system.

So if you want something like Claude Code to search through all of your files or run command line tools,

and Xcode comes with certain command line tools that you can use to build and deploy your app.

So you don't have access to those within Xcode itself.

And I would say in general, there's a lot of things about Xcode that are not the best.

Like a really obvious one is in the AI integration.

I can highlight the code in the response, but I can't highlight the code in the prompt.

And so if I want to go back and re-prompt it with a slightly different prompt,

I have to type everything out again, which is really stupid.

And there's things like that all over Xcode.

It's not the best editor experience.

And the only reason I'm not bashing it more is the fact that we do have AI integration,

so you have the option of mostly talking into a text box rather than actually having to deal with Xcode.

But overall, my feeling on SwiftUI, I give it a thumbs up.

Jetpack Compose was created in 2021 by Google to replace their existing "native code" for Android.

JetBrains, the company that develops Android Studio,

decided to release their own version of Jetpack Compose, called Compose Multiplatform,

that can also build apps for iPhone.

For my app, I'm going to use Compose Multiplatform

to see whether it's viable for building iPhone apps.

It took me 2 hours to build my app,

which was a little bit longer than it took me to build with SwiftUI.

The binary size is 36.9 MB,

and the startup time is 0.483 seconds.

Here are the good things about Compose Multiplatform.

Jetpack Compose is native code for Android,

which has the same benefits that SwiftUI has for iPhone.

However, Compose Multiplatform isn't native to iOS,

so I'm not actually getting those benefits here.

Compose Multiplatform has previews similar to SwiftUI.

The features are somewhat different, but I would say that overall they're still very useful.

The state management is built into the framework itself,

so there's no need for a third-party solution.

I wouldn't say it's super intuitive, though.

Like this `remember` of a `derivedStateOf`

that listens to a `mutableStateListOf`

which triggers a recomposition

when one of its `data class` entries

is replaced with a `.copy` of itself.

Despite how much of a mouthful that is to say out loud,

I do think it's a sensible way of doing state management.

I also like that they have data classes built into the language,

as well as this object keyword for creating singletons without defining entire classes.

Here are the bad things about Compose Multiplatform.

There are six non-Git-ignored build-related files

at the top level of my project,

but my actual code is seven levels deep into the folder structure.

And I know this is petty,

but the naming of this thing is awful.

Kotlin is made by JETBrains,

whereas JETpack Compose is made by Google.

Kotlin Multiplatform is not a UI framework.

It's literally running Kotlin code on multiple platforms.

And Compose Multiplatform is a generalization

of Jetpack Compose that runs on iOS.

Remember that Google AI overview I showed you at the beginning of the video?

These terms are so conflated that even the AI gets them wrong.

Finally, since Compose Multiplatform is relatively new,

the ecosystem for packages is relatively small.

You'll probably need to implement some Swift or Objective-C on your own to get things done.

Overall, I think Compose Multiplatform is a good choice for building Android apps,

but it definitely wouldn't be my first choice for building an iPhone app.

I guess if you already know and use Kotlin elsewhere,

you'll find it pleasant to work with.

.NET MAUI, or the Multi-platform App UI,

was created in 2022 by Microsoft as a new coat of paint on top of Xamarin.Forms,

which in turn was created all the way back in 2014.

From what I can tell, the original intention of Xamarin.Forms

was to help developers port their apps to Windows Phone.

It took me only 1 hour and 20 minutes to build my app, which I found extremely surprising.

The binary size is 47.6 MB, and the startup time is 0.667 seconds.

Here are the good parts about .NET MAUI.

Here are the bad parts about .NET MAUI.

Upon successfully installing MAUI, VS Code gave me this pop-up telling me that MAUI was not found.

When I tried to run my app, I got an error that told me I needed to downgrade Xcode,

even though I'm pretty sure I get locked out of Xcode if I don't upgrade.

The original file names I used for the subreddit icons were invalid because they contained uppercase letters.

MAUI uses XML files to specify the UI, then binds the stuff from the XML files into C# code.

This is horrible because the XML and C# files can get out of sync very easily if you rename variables.

Now I'm sure there's some Microsoft employee somewhere about to jump out of his seat

to tell me you can use pure C# without any XML in MAUI.

To that employee, please update the `dotnet new maui` command that you proudly display on your home page,

because that's where the XML came from.

Also please add a `.gitignore` file to your starter project.

At least state management is straightforward.

(I'm not typing this out lol)

Overall, I have no real complaints about .NET MAUI

because I don't have to use it.

React Native was created in 2015 by Facebook to make cross-platform app development easier.

From nearly the very beginning, another company called Expo developed a meta-framework,

also known as Expo, as a batteries-included way of developing React Native apps.

It took me only 40 minutes to build my app, which is at least twice as fast as anything I've tried so far.

The binary size is 32.1 MB, and the startup time is 0.483 seconds.

Here are the good parts about React Native.

If you're a web developer, you'll find it relatively easy to get started with React Native.

TypeScript has a massive ecosystem of packages, many of which are unrelated to mobile development,

but are nevertheless useful for things like sending network requests,

interfacing with on-device SQL databases, and more.

With React Native, the AI is noticeably more accurate when following instructions,

which saves a ton of time not needing to tell the AI to fix its mistakes.

Expo provides a way for you to deploy apps to your iPhone without using a MacBook.

Basically, they created this app called Expo Go that loads your JavaScript into their app.

It has some limitations related to native code,