After a few weeks of trying out Jetpack Compose and SwiftUI, the declarative UI toolkits introduced by Google and Apple this year, I have a couple of notable similarities and differences in the two toolkits, as at today.
I understand it is weird to compare two ideas coming from two different platforms, but since they both appear to originate from the same thinking box and they both solve similar problems, I will let it pass. It is not a thug of war between Jetpack Compose and SwiftUI, just comparison.
So, shall we?
Requirements
Jetpack compose requires Android Studio 4.0 and API level 21 while SwiftUI requires Xcode 11 and iOS 13. Well, that sounds simple but it’s not. Xcode 11 is over 7gb while Android Studio is just a little above 1gb in size. iOS 13 as a constraint is a bit crazy, but then we know Apple for that. API level 21 for android is still very much considerable. Right?
Hot Reload
SwiftUI does what I can refer to as ‘Hot Reload’. Your changes reflect on the preview canvas immediately without you refreshing. Jetpack compose, on the other hand, requires you to click a refresh button after making changes. I really hope this is fixed soon.
Modifying Views
SwiftUI provides multiple ways of modifying your views, through code, inspector or the canvas itself, all always in sync. Meaning, if I modify something on the canvas or in the inspector, it automatically generates the corresponding code for me, and vice-versa. With Jetpack compose, you have just your composable functions to modify your views from. So sorry.
Readability of Souce Code
Text, Button, etc which are in-built components of Jetpack compose are basically built out of composable functions also, which makes it easy to go down into the source code and see how each param is listed and how they work. In-built views in SwiftUI came about in a similar way, called Primitive views, however with less readable source code. Eew!
Auto-generation of Previews
Previews for SwiftUI views are automatically generated when you create a new ‘SwiftUI View’ and are named based on the name of your view, so less possibility of similar preview naming and better readability. Jetpack Compose also create composable preview functions for you, which is cool. But uses a certain paradigm; creates preview functions with the “DefaultPreview” and in a case where one exists, it appends numbers (1,2,3,…) to the name, which is umm okay (you can rename it), but can be made better.
Multiple Previews
Both Jetpack Compose and SwiftUI can show multiple previews at the same time, which is really nice. Say you want to preview your views in both light and dark mode or you will like to see your views with the font scaled. Kudos to the teams.
Live Preview
SwiftUI Live Preview is a blessing! You don’t want to have to run on a simulator to simulate a button click or any other interaction with the views right? Yeah, that’s what Live Preview brings about. In case you don’t know, Live Preview enables you to interact with the views right in your IDE without having to run the app on a simulator. So cool. You can’t do that with Jetpack Compose for now. I don’t know if that is coming soon, but I really hope so.
“Compose”
Both Jetpack Compose and SwiftUI make use of the word, “Compose”. Lol yeah. Glad I can use the word to express myself in both, like “Have you composed the Button?”, “After composing the Card, you can place it together with the Text in a ZStack”. Cool right?
Drag and Drop
Ah yes, one more thing. With SwiftUI you can still drag and drop views from the Library into your code or into the canvas. Cool! Unfortunately, Jetpack compose doesn’t have support for such, you have to write everything in code. Not bad, just…you know.
All said and done, both toolkits are really cool and will transform the way we develop our apps. Lots of updates are still being added to the platforms. Watch out for more. There is a lot to learn!
