SwiftUI is a powerful tool, but the Android version is better. Why here
If you’re an Apple developer then there’s no doubt you’ve seen and heard all about SwiftUI, Apple’s new declarative framework for building apps that run on iOS, iPadOS, macOS, watchOS and tvOS.
But what you may not know is Android Too Kotlin has a brand new declarative framework for building application interfaces. A beta version of Jetpack Compose was announced at Google I/O in 2019; In the same year Apple announced SwiftUI.
You might not even know that Google recently took Jetpack Compose out of beta and officially released version 1.0. To quote from the press release:
Today, we’re launching version 1.0 jetpack designAndroid’s modern, native UI toolkit helps you build better apps faster. It’s stable, and ready for you to adopt into production.
About what you would expect. But it’s the next line that tells the real story.
We’ve been developing Compose in the open for the past two years with feedback and participation from the Android community.
And He Just one of the many reasons why Jetpack Compose beats SwiftUI. Here is the complete list.
- platform version independence
- open source community
- release cycle
- public roadmap
note that none Most of these things are related to actually using Jetpack Compose to write code. Overall, I like the syntax and functionality of SwiftUI.
But ease of use has a lot to do with the fact that Android developers can actually Use To create Jetpack Compose app.
Adding Jetpack Compose to a project is as easy as that. Just make some changes to your application’s gradle file and the required dependencies will be added to your project.
SwiftUI is of course even easier to use. Just use the correct version of XCode and import the SwiftUI header and you’re good to go. Well… I mean… that plus the minor fact that you’ll probably need to accommodate your application’s minimum supported version of iOS.
You can only target iOS 15, right?
I wrote about it again Again, But the fact of the matter is simple. All SwiftUI features, functionality, and bug fixes are tied to a specific version of iOS. Duration. full stop.
So, for example, if you want to use some of SwiftUI 3.0’s highly innovative new features like text field tabbing and pull-to-refresh, you’ll need to target iOS 15. Only The supported version of iOS that your application will run on.
Or if you need lazy lists, or state management that actually works as expected (@StateObject), you can go all the way down to iOS 14.
No problem, is it? I mean, your existing customers on iOS 14 and 13 and 12 and 11 will be happy to upgrade or ditch their old phones and devices, right?
Jetpack Compose, on the other hand, supports Android up to SDK 21. That’s Android 5 (Lollipop), released in 2014!
Which means Android developers can start using Jetpack Compose in their existing applications today. And do so without leaving anyone behind.
The majority if iOS developers, on the other hand, look forward to using the current version of SwiftUI to… what? 2023?
open source development
As mentioned, Jetpack Compose is an Android open source project, supported by a large and vocal community of developers.
SwiftUI, on the other hand, is developed in-house by Apple, with little to no transparency or feedback.
Jetpack Compose is an unbundled toolkit that is part of Google’s Composite android jetpack Set of software components for Android developers, but no need to use any other Jetpack components or have your clients have the latest and greatest version of Android
SwiftUI is, again, tied to a specific version of iOS.
Jetpack Compose was released as a public beta at Google I/O in 2019, and has Several releases of Compose and its components have been published since then.,
There have been three official releases of SwiftUI, each tied to iOS 13, 14, and 15 respectively.
you can also take twitter and Speak directly to developers on the Compose development team,
Apple? Well they have a developer forum where you can ask questions.
Obviously, they’ll be largely ignored, but at least you can ask them.
As mentioned, Jetpack Compose was released as a beta in 2019, but several companies have already shipped products built with Compose, or that integrate interfaces built with Compose. .
In addition, the Jetpack Compose library has been updated regularly with new features, functionality, and bug fixes, and those updates have made their way out into the world.
Apple? Yes, once a year, with iOS 13, 14, and 15.
I have written many articles on SwiftUI problems and issues…
And every single one of those issues are still with us today. But who knows? Maybe they’ll be okay next year…
To be fair, Apple has gotten better with this, but for years many of SwiftUI’s support pages have ended up in dead-end placeholders.
However, Google, and as shown in the “Join the Compose community” screenshot above, is actively looking for community help in refining and improving the Jetpack Compose documentation.
Can you imagine Apple doing this?
No. Neither am I
Apple, as we all know, is a secretive organization. The entire developer community knew — or, at least, hoped — that Apple would fix some of the more glaring holes in how SwiftUI worked and add essential, missing functionality when it released iOS 15.
But they were largely expectations, as no one knew what features Apple was working on, or what to expect.
Google, on the other hand, has published a public roadmap that shows what’s available, what’s coming and when it’s expected to arrive.
The sad thing is that it didn’t have to be like this. Apple already had a proven model for how to involve its developer community in guiding and shaping technology critical to its future success.
I am talking about Swift and Swift Evolution.
Want to extend Swift to do something new? Write a Swift Evolution pitch and let the community discuss it.
Want to fix a bug in the compiler? Well, you have to know what you are doing, but you can do this.
Want to see what’s coming? Follow Swift evolution and see what is accepted in the language.
Apple had a chance to do just that with SwiftUI.
And they didn’t.
Apple’s SwiftUI could have had community involvement.
Apple could have made SwiftUI a package that could be bundled and downloaded with your app, allowing many of SwiftUI’s latest and greatest features to be supported on iOS 14, or 13, or 12.
they certainly did No do that.
Some readers point out that Apple enjoys a much higher iOS adoption rate than Android. And it’s totally true. But even this is not entirely relevant to the discussion.
Let’s use one of our client’s apps as an example. Sure, eventually All those users will be migrated to the latest version of iOS. But if today’s metrics are anything to go by, by this time subsequent years About 85% of that base will be on iOS 15.
That leaves 10% on iOS 14 and 3–4% on iOS 13 and 1–2% on iOS 12.
In percentage terms, these numbers don’t seem that high. But if you have a major app with 10 million users, 5% of that number is 500,000. And you try to make the case to management that they should give up half a million customers so we can play around with some cool new language features.
go ahead. I’ll wait
I’ve spent a lot of time bashing Apple and SwiftUI in this article… and it really hurts to do so.
I’ve written a few personal apps and coded in SwiftUI, and I love it. It’s concise and elegant and I want nothing better than to use it in my corporate and enterprise applications.
But I can’t.
And that hurts.
All Apple developers can start the next phase of app development on iOS and iPadOS and macOS.
But most of them can’t.
And that hurts.
And the sad part is that both you and I and Apple know that this should not have happened.
Google, and Android and Jetpack Compose all demonstrate vividly that this didn’t have to be the case.
Swift Evolution shows that this did not have to be the case.
But it is.
And that hurts.