Animations in app development is something that, when done right, could elevate the user experience to another level. In this article I hope to give you the tools you need to create animations in your React Native app, all while keeping the Christmas spirit alive 🎅

To present these tools, I will exemplify the four most common methods for writing animations in React Native, and give you an understanding of when to use which method. In true Christmas spirit, we will create a wish list to Santa, and hope that the animations will get his attention and we get what we wish for!

If you want to follow along, I have created an example app using expo that implements all the animations I talk about in this article. Check it out here. The starting point of the example can bee seen below.

As you can see from the GIF, we have to wait some seconds before our wish list is fetched from the server. The app only shows a blank page in the mean time, leaving Santa confused whether he did something wrong. Let us fix that now!

1. Lottie

We can present Santa with a nice loading animation to give him some context of why the list is not showing up at once. To do so we can use Lottie, which is branded as a lightweight, scalable animations package that works with most platforms (web, app, email, ads, etc.). 

Using this package for loading static, vector based animations will make the loading time more fun and acceptable for Santa. All we have to do is to install and import the package, import a json formatted Lottie animation file, and conditionally render it while we are waiting for our data. The Lottie json files can either be created by yourself, or it could be downloaded for free from their website.

Using Lottie animations is also perfect to indicate successful (or unsuccessful) completion of tasks. Had our simple wish list app included a way to add new items to the list, a confetti animation to celebrate this action would be very enjoyable!

Combining Lottie with the React Native Animated API (described in 3.) also unlocks new possibilities like programmatically setting the frames of the animation. With this combination you could intertwine the loading and success animation into one smooth experience, by looping the loading frames until the action is complete, and then seamlessly finish with the success frames of the animation.

2. LayoutAnimation

Looking at the results from adding Lottie it certanly improves the experience for Santa. However, there is still an abrupt change between the loading animation and the appearance of the items in our wish list. We do not want to scare Santa with our long list, but rather make a smooth transition for him once the items are done loading. To make such an animation, we could fade the items in by using LayoutAnimation which is directly built into React Native. This can be achieved by simply adding this one-liner:

LayoutAnimation.configureNext(LayoutAnimation.Presets.easeInEaseOut);

right before we store the fetched wish list to our state. The configureNext function works by automatically animating views to their new positions when the next layout/re-render happens.

While easy to implement, LayoutAnimations have some drawbacks. Since the animation does not refer to a specific element on the screen, LayoutAnimations could have some weird side effects when not having complete control of when your re-renders happens. Therefore I would refrain from putting them inside useEffects with complicated dependency arrays, or inside components with many props that could trigger re-renders. Unless, of course, if you know what you are doing 🤷‍♂️

3. Animated

Even though this fade-in animation helps to ease Santas mind when looking at our large and expensive wish list, it is still kind of boring. Another drawback with LayoutAnimation is that you could only define one type of animation for the elements at a time. After all, it is just ment to automatically animate views to their new positions when the next layout happens, and not to do any super fancy stuff. And to impress Santa, we want to be a little fancy 💁‍♂️ 

If you want more control over your animations, the next step is to try Animated, which also is built into React Native. It lets you compose a set of animations that change animation values, which you attach to your components with the transform value in the style prop.

In our wish list we want to take advantage of the composability of Animated by introducing each item after one another, so that all the items is not shown at once. To make the animation more fun for Santa, we want to move the item in from the top while scaling it from zero to one. To give the animation one last touch, we want it to wiggle the item once the scaling is done. We first create one animation value each for translation, scaling and wiggle, like so:

We want to initiate the animation once the items load, so our animation composition will be placed in an useEffect, and started right away:

Our animation composition starts off with an Animated.sequence([...]), which starts its list of animations sequently, one after the other. Next we have an Animated.delay() that holds the animation still 200ms longer for each item down in our wish list. The Animated.parallel([...]) executes both the Animated.spring() and Animated.timing() simultaneously, which again scales the size of the item from 0 to 1 in 1000ms and moves its y-position from -1000 to its place. Lastly, the shake animation value is linearly driven from 0 to 1 in 1000ms.

The last step is to attach our animations values to our components with the transform value in the style prop. Both the scale and translateY are ready to be used, however the shake value needs one last adjustment. We need to transform the change in value from 0 to 1, into a change in z-rotation degrees. This is where interpolation comes in handy, as it solves this problem exactly:

Finally, all three animation values can be put into work:

You could argue that being this fancy might be to overdo it, however I think Santa will appreciate it over the simple fade-in animation 😊

4. Reanimated

In the last example, we take a look at the react-native-reanimated package. This package can do everything that Animated can, and even more, while still being notably more performant, even on low-end android devices.  

Both Animated and Reanimated are written in a declarative manner, however, Reanimated also handles interactions/interruptions in the animations directly on the ui-thread instead of having to translate over to the JS-thread. If you want to add interactions to your animations with Animated, you either have to resets the animation, or wait until the animation is finished.

To showcase the intractability of Reanimated, I have one last example in our wish list. It could often be hard to prioritize which gift you wish the most for, so in the last example we add a button that lets you rearrange the list at random by changing each items order prop-value. 

As you can see, it works in a very similar way to Animated, by declaring an animation value, declaratively changing the value (here with the withSpring method), and then creating the transform-style object to be injected to the Animated.View.

Pressing the button changes the order prop-value, which again animates the list as we expected! The beautiful thing about Reanimated is that we can interrupt the animation by pressing the button and changing the order again halfway into the animation. The library will then automatically start to animate to the new position, while keeping the items current speed in mind, so that the animation changes smoothly. Spamming the "Mix it up!" button show the items dancing around in a smooth manner, something which would not have been possible with Animated.

One last mention about Reanimated is that it couples extremely well with the react-native-gesture-handling package. Combining these two allows you too smoothly animate your components across the screen and still react to changes in gestures, like when they start or stop, or even running fine-tuned logic when the position or momentum changes.

What have we learned?

To finish this article, here is a summary of when to use each different type of animation method:

Use Lottie for static loading animations or as a fun way to indicate success (or failure)

Use LayoutAnimation to easily add simple animations to components where you know you have control over your re-renders

Use Animated to compose your own set of animations that are ment for some specific components only

Use Reanimated when your animations can be interrupted midway by the user, or if the animation is dependent on gesture handling

Now it is time for you to impress Santa with your animated wish list! 🎅

How to animate stuff in React Native 💫

Do you want to make an online multiplayer game, but don't want to struggle with making a server? Firebase might be your solution!

Whether you are making a game of your own design, or just want to implement your own version of chess, taking the step from two players sitting in front of the same computer to playing online might seem daunting. You need a server for that, right? And you’d really prefer it if you could just write game logic and make everything look pretty in React. Well, Firebase has got you covered – at least to an extent.

Use Firebase

Firebase is perhaps most known for being a place where you can quickly and easily deploy your first React app without having to spend any money. While ease of deployment certainly helps, the real value for your online game lies in Firebase’s Cloud Firestore.

Cloud Firestore is a NoSQL cloud database that offers data synchronization through real-time listeners, meaning any connected device can instantly receive all changes made to the database. To make your game fully online, all you have to do is write your game state to Cloud Firestore, make your clients listen to changes in said game state, and you’re golden!


For All your Multiplayer Needs

Setting up the database and connecting your React/Java/Go/Ruby/Flutter/Unity/…-application to it is very straightforward. Really – read the docs – you’ll be writing to your brand new Firestore in half an hour.

Your Firestore consists of collections, which contain documents, which again contain the data you will be reading and writing. Firestore having a NoSQL data model means you can write data exactly how you want: Documents go in – containing everything from simple strings to complex nested objects – and documents come out. Very handy when your game state attempts to get out of hand.

Using a chess game as an example, making a move might look something like this:

const gameRef = doc(db, 'gamesCollection', 'gameState1');
setDoc(gameRef, { C4: "White King", C3: null }, {merge: true});

The first line specifies the document called gameState1 in the gamesCollection-collection as the one we want to be writing to.
Writing the second line to the database would indicate the white king piece moves to square C4, leaving square C3.  Realistically, the gameState1 document contains fields for every square on the board, in addition to tracking things like who is the active player. The merge at the end of line 2 ensures only the C3 and C4 fields are updated, all others remain unchanged.

Setting up a listener to receive changes in real-time is just as simple

cons unsubscribe = onSnapshot(doc(db,'gamesCollection', 'gameState1'), (doc) =>     {console.log("Game state: ", doc.data());
}); 

Of course, instead of simply outputting the data to the console, you are now free to do whatever you want with – perhaps update your frontend to show the white king piece on square C4.

And that’s all there is to it. Write your game state to Cloud Firestore and set up listeners to receive changes and update your frontend immediately after your opponent makes a move.

Well … Perhaps not All

So, just slap a Firestore on it and you’re good? Well, depending on the type of game you are making, not necessarily.

Firestore lends itself well to a certain genre, namely board games or slow-paced strategy games with a relatively low frequency of discrete actions and a relatively low number of moving pieces. While Firestore largely provides updates in real-time, it is still a database, and having two or more players competing for several writes a second can certainly lead to a responsiveness players might find lacking.
A high number of moving pieces isn’t a problem in and of itself – though your wallet might disagree. Firebase’s pricing model is based on the number of reads and writes made, so think twice before you deploy Chess 2: Sparta with 300 pawns! Still, if money isn’t an issue it should theoretically be possible to implement something as complex as the Civilization games.

If, however, you are looking to implement a new fast-paced shooter, I’m afraid Firestore will not be able to help as much. While tracking continuous 3D movement and ballistics in a database certainly is an interesting challenge, I believe that is a task best left as an exercise to the reader.







Serverless Online Multiplayer with Firebase

This is the carol of how a co-worker and I created the same app using 4 different frameworks: Flutter, React Native, Xamarin Forms and SwiftUI. We did this to answer the age-old question: “Which mobile application framework is the best?” and to learn for ourselves the pros and cons of different approaches. We also polled a lot of colleagues on their experiences, including authors of some of Norway’s most used and important apps. Read on to learn our and Norway’s favorite mobile application framework!

At Bekk we have multiple communities of practice (CoP) each year. In 2021, I, together with my colleague Ina Bjørnestad, joined the community called the App Factory. The end-of-year goal for most of the App Factory members was to ship an app to the App Store or Google Play for the very first time, but since both Ina and I have shipped multiple apps in the past we’d rather try something new. I’ve used Xamarin since 2011 and Ina was well versed in the ways of React Native and we could never agree on the same framework to use. Then it hit us, instead of limiting ourselves to create an app using only one framework, we would instead build the same app 4 different times using some of the most popular frameworks out there. Then we could compare and contrast our experiences and perhaps agree on the best one.

The app we chose to create was called Top or Not and its premise was simple: if you randomly and without forewarning find yourself in an unknown area of Norway, our app will show you the nearest mountain to climb using the map. It should also be possible to mark summits as favorites and to search for them by name. The data was stored in Postgres and served over a REST-API powered by the excellent Supabase.

Creating this app 4 times gave us multiple points of comparison:

The getting-started experience

How easy it was to implement the app’s design

Maturity and ease of use for the framework’s component libraries

Choice of programming languages

Recommended patterns

Speed and chillness of implementing features

The frameworks were:

Flutter, Google’s new mobile offering using Dart

React Native, Meta’s excellent frontend framework, now reworked for mobile using Flow or TypeScript (fancy JS).

Xamarin Forms, Microsoft’s offering with C# for logic and optionally XAML for UI and layout. This will be superseded by .Net MAUI next year, but the same skills can be utilized

SwiftUI, Apple’s preferred way of writing their version of cross-platform apps running on almost all new Apple devices, but understandably off-limits for Android.

So, what did we learn?

General experiences

It should come as no surprise that none of the frameworks was the silver bullet. We encountered roadblocks, difficulties and stunning lack of progress using any framework. What flabbergasted us the most was not only our own problems, but that during one hackathon each and every member of the CoP was stuck for a long time on different problems. Everyone! No issue was the same, but it often had something to do with versioning of frameworks and libraries. Both iOS and Android are ever-changing and just keeping up with their updates was a task in and of itself.

Creating robust CI-pipelines for testing and automatically shipping beta versions of apps were also difficult. Although tools like Fastlane has excellent documentation and online services like App center exists, putting them to use for the first time proved time consuming and error prone for everyone involved.

Flutter

Flutter has the best documentation of the bunch. The docs are so good that answers to many questions can be found there instead on Stack Overflow. The official getting started guides were enough to get us going.

Flutter uses its own widgets to draw the UI and layout proved easy enough since we both were familiar with React from before.

Components exists for many popular use-cases and it’s of course possible to write your own. Some components, like the Mapbox-integration, lacks customization present in other frameworks, but this is not surprising as Flutter is the new kid in town.

Dart is modern language, easy to learn if you know C#, Java or JavaScript.

Flutter is a reactive, pseudo-declarative UI framework, supporting many different app architectures.

Flutter supports hot reload and hot restart, making the developer experience quite nice and feedback loop short.

React Native

React Native presents you with a choice beforegetting started: Which CLI should you use to setup your development environment, Expo CLI or React Native CLI? Expo is the easiest for developers new to mobile development, while React Native CLI requires Android Studio and XCode (on the Mac). Expo wants to do everything from JavaScript/TypeScript, while React Native makes it easy to create bindings against native frameworks. Both approaches let you hit the ground running if you know React from the web.

The component-based approach is easy to learn and quite powerful. Pain-points include state management, as always, but many solutions and patterns exist to mitigate that problem. React primitives render to native platform UI, meaning your app uses the same native platform APIs other apps do.

React Native libraries are plentiful and typically installed from the npm registry using a Node.js package manager such as npm CLI or Yarn Classic.

TypeScript and Flow are supported as default languages and JavaScript people will feel right at home.

React Native lets you hit the ground running if you know React from the web. It’s easy to separate program functions into independent and interchangeable blocks called modules, enabling co-working and partitioning of the app.

Hot reload is of course supported and the write-build-run cycle is blazingly fast.

Xamarin Forms

Xamarin Forms comes with Visual Studio both for Windows and Mac. The built-in templates are good starting points and Visual Studio, for Windows especially, is a great IDE.

UIs can be created using premade controls, which binds to their native counterparts, written in C# or XAML. XAML is a declarative XML markup language custom made by Microsoft for doing UI-layouts. For beginners, learning XAML can be daunting, but everything you can do in XAML can also be done in pure C#.

.Net makes it easy to utilize its extensive library of packages and component through NuGet. Since .Net is popular on the server as well, this enables you to easily use the same code and models between server and app if you so choose.

Even though Xamarin supports other languages too, like F#, C# is the language of choice. An excellent choice!

Microsoft recommends using the MVVM (Model-View-ViewModel) pattern, using bindings between ViewModels in C# and Views implemented in XAML. But Xamarin is flexible and patterns like MVU are also easy to implement.

Hot reload is, for now, only supported using XAML. Also, the app must be built before its first run since .Net is a compiled platform. The XAML designer which ships with Viusal Studio is mostly useless IMO.

SwiftUI

SwiftUI is Apples native offering and ships with XCode for Mac. No Windows or Android options here, just install XCode and you’re good to go.

Foregoing real hot reload in favor of a working visual designer, the UIs is declaratively written using Swift. If you remember to add test data, the views are actually rendered as they will appear in the app. A welcome change from the designers of yore.

Packages written in both Swift and Objective-C are available through CocoaPods and mixing in both native UIKit and libraries written in Objective-C is simple enough to do.

Swift is easy to learn and use and has finally gained something reminding of stability while still being improved every year. Apple’s release cadence coincides heavily with their yearly WWDC event, giving developers a full year to come to terms with changes in the language.

Both MVVM and MVU are easy to use with SwiftUI, and examples and tutorials are plentiful.

Since this Apples own way of writing apps, updates to the OS itself breaks SwiftUI more seldom than the other three frameworks. The designer works well and SwiftUI has the fastest loop if you enjoy testing on real devices.

Community responses

As our one more thing, we asked 63 expert mobile developers on their experiences using different frameworks. Red is “Which framework do you use today?” and blue is “Which framework would you choose if starting a new mobile project today”.

React Native was the currently most popular framework, while Flutter was the most alluring. Some also want to try SwiftUi, but that leaves Android as another story entirely. Xamarin is used reluctantly by some but is still popular.

We also asked if people would recommend a framework to a friend or colleague, thus enabling us to calculate a net promoter score for each one:

Even though each framework was more recommended than not, SwiftUI won by a NPS of 85 which is exceptional. Flutter with its 50 is also well liked, while React Native and Xamarin lags a bit behind.

Conclusion

Does that mean that SwiftUI for iOS and Flutter for Android is the way to go? No! Choose the mobile application framework that best suits your team and your surrounding organization’s skills and technology goals. Focus on what the app should do, for whom and why it should do that. With that in mind, the app can be made using any framework:

For iOS, SwiftUI proved easy to understand and Swift is a nice enough language.

For .Net shops, or people like me who just love C#, Xamarin and shortly .NET MAUI lets people utilize existing skills in a different context.

React is a super popular frontend framework with a broad reach thus making React Native a safe choice for frontend-heavy shops.

Flutter is the up-and-coming contender and has the best documentation of the bunch.

The last hurdle for any app is to be actually accepted in an app store. Which have rules. Many rules, and some of them seemingly random and esoteric. Do yourself a favor and read and understand these rules before designing and implementing your app to lessen the possibility of having done work in vain.

If you want to learn even more and you understand Norwegian, a video of a talk we held on this very subject is available on Bekk’s Vimeo account.

Creating the same app using 4 different frameworks

Swift is mostly known as «that language people use to make iPhone apps». And while the two certainly are a good match, Swift is not really tied to the iPhone anymore. Let’s see how it performs as a language for making cross platform CLIs!

I love Swift. It hits that sweet spot between ergonomically pleasing and good safety features. It’s not too unforgiving (I’m looking at you, Rust), and at the same time manages to produce relatively safe code. It can certainly crash, that’s for sure, but the compiler catches enough of the errors I usually make to make me confident that my code just might work.

Let’s take Swift out of its safe harbor called iOS, and instead throw it into the ancient land of terminals. We’ll end up with a small CLI where we convert input text to a hash. We will support MD5, Sha1 and Sha256 hashes.

I have managed to run this on macOS and Windows through WSL2, so it’s cross platform enough for me. Swift wasn’t exactly born cross platform though, so there are no guarantees that it will run on your platform. If you are unsure, just try!

Now, enough with the warnings. I’m a big fan of git style CLIs with sub commands, so let’s make something like this:

In other words, the format of our CLI is <command> <subcommand> <input>.

Let’s get straight to it. The only thing you need installed is Swift Package Manager. Start up your terminal and generate a project

This gives you a bare bones project, and if you run it with swift run, you’ll be presented with the age old "Hello, world!".

Swift Argument Parser

We could of course parse arguments manually, but I’d rather let a library take care of the nitty gritty argument parsing details, and end up with readable and understandable code instead. Luckily, Apple has a library called swift-argument-parser which is both pleasant to use and supports a wide range of CLI styles: sub commands, options, arguments and flags. To install it, simply open up Package.swift, add it to your package dependencies and your target dependencies. Your Package.swift file should look something like this

This is all we need – the next time we use swift run, our library is installed. Now, open up Sources/hsh/main.swift and wipe away everything. Replace it with

Run it with swift run – and be amazed! You have just installed a library, put it to use, and got the exact same output as you did before you started – amazing! That is job security right there!

Luckily, there’s more to it. If you run swift run hsh --help, you will get automatically generated help for your little CLI. If you run it with some unexpected argument, you’ll also be told so, and told what to do instead.

Let’s take it one step further. We want our CLI to support the sub commands md5 and sha1 – this is, appropriately enough, implemented by configuring our command with sub commands, which refer to two new structs:

There are a couple of things to note here:

We removed the run() function in our Hsh struct. This makes the help text we get from --help the default output. I like this – it makes our CLI more discoverable and helpful!

The sub commands themselves are ParsableCommands as well. I don’t know why, but this really resonates with me.

Pop open your terminal once again, and run swift run hsh. This time, you’ll see your shiny new commands under the SUBCOMMANDS section. Try running them as well to see that everything is working properly.

Swift-crypto

Sooo. Where do we go from here? Well, we could always make md5 and sha1 actually do something useful. I have absolutely no intention what-so-ever of implementing these hashing algorithms myself (I could try to convince you I know how, but.. yeah, no), so let’s add a cross platform library which does this for us. Open up Package.swift and add this line to your topmost dependencies block

And this line to the dependencies block inside the executableTarget block

Let’s start by printing the md5 hash of a static value. To do so, we first need to import the Crypto library by adding import Crypto to the top of Sources/hsh/main.swift. We then replace the run() function in the Md5 struct with this

As you can see, Crypto really does all the hard work here. The only weird thing going on is the convertion to a string on the last line, which is due to the way Crypto represents the hash internally. It turns out there are better ways of storing hashes than as strings, which is what I have done since I started programming 15 years ago. Who could have known.

Try it with swift run hsh md5 if you want, or keep on coding if you’d rather hash an argument passed to your CLI! This is really easy with swift-argument-parser. First, add these two lines to the top of your Md5 struct

And then change "my-string" to value in the run() function. Congratulations – you now have the Md5 generating CLI of your dreams! Try it with swift run hsh md5 my-string (or something cooler – I don’t know). Try it without giving it an argument as well and see what happens!

Adding Sha1 support is just as easy. Start by adding the same @Argument... property to the Sha1 struct as well, and change its run() function into

(side note: seeing this while I write this blog post, the two run functions are.. strikingly similar. Could we perhaps generalize this somehow? )

Now, try running swift run hsh sha1 my-string as well, and see your wonderful CLI present you with an amazing sha1 hash as well!

For completeness, I have a fully working Sources/hsh/main.swift file here. Take a look if your stuck on something, or my wonderful explanation skills didn’t quite make it.

If you enjoyed this, there are plenty more hashing algorithms you could implement in the Crypto library. Or perhaps you could make your CLI more general, and implement other useful developer tools as well?

App Development

How to animate stuff in React Native 💫

Serverless Online Multiplayer with Firebase

Creating the same app using 4 different frameworks

Cross platform CLIs with Swift