SwiftUI, Apple's preferred UI toolkit, promises seamless integration across all Apple platforms, including of course iOS and macOS. This article delves into some challenges of using SwiftUI in a cross-platform context and suggests practical ideas for solutions.

SwiftUI’s declarative syntax enables developers to write concise and readable code. A simple SwiftUI view, such as the one below, demonstrates its elegance:

This code renders a basic text view, but how it appears can vary significantly between platforms and the underlying frameworks will differ. On iOS and iPadOS the SwiftUI renders using UIKit, while on macOS AppKit is used. All transparent for the developer, some of the time.

Common Challenges in Cross-Platform SwiftUI

Layout and User Interface Adaptation

The primary challenge in in cross-platform development is ensuring that our UI looks great on all devices. Thus responsive design is key and in SwiftUI ResponsiveView is a powerful responsive tool.


The goal of ResponsiveView is to adapt its content based on the current environment, such as device type or screen size. This is particularly useful in a cross-platform context where we might want different layouts or functionalities on an iPhone, iPad, and Mac.

First, we’ll define a ResponsiveView that changes its layout based on the device being used. For simplicity, let's consider a layout that switches between a vertical stack (VStack) for iPhones and a horizontal stack (HStack) for iPads and Macs.



We can now use ResponsiveView in our SwiftUI views. Here's an example where we create a simple view with two text elements that will be arranged differently depending on the device:

In this example, on an iPhone, the texts will be stacked vertically, while on an iPad or Mac, they will be aligned horizontally.

We can further enhance ResponsiveView to respond not just to device types but also to other environment properties like size classes. This allows for even more granular control over the layout and presentation based on the current context:



This enhancement uses the horizontalSizeClass to determine the layout, providing a more responsive design that adapts to various screen sizes and orientations.

Platform-Specific Features and Capabilities

Each Apple platform has unique features. For instance, macOS supports menu bars, while iPhones offer haptic feedback. To complicate things further, SwiftUI on iOS is based on UIKit while the older AppKit is used on macOS. As such, APIs will differ even when offering the equivalent functionality. Using conditional compilation, as shown below, we can tailor experiences for each platform:


Xcode will even highlight the code path of the current compilation target.

However, as shown in the screenshot above, spreading these compiler directives across our code base can be messy and steal focus from what really matters: the business logic of our app. Luckily Swift’s system for extensions og typealiases comes to the rescue.

Consider the common functionality of copying content to the plattforms pasteboard. macOS use NSPasteboard from AppKit, while iOS uses UIPasteboard. First we create a common typealias for both platforms:



Then we write an extension on CommonPasteboard:

Thus the functionality of coping text will be the same on both platforms:

Performance Optimization

Performance can vary across devices. Profiling SwiftUI apps on each target platform is essential to identify and resolve platform-specific performance bottlenecks.

Testing on real devices is also crucial. While simulators are useful, they can't perfectly replicate the performance and user experience of actual hardware. A watch is not a Mac and vise verca.

Working with Previews

SwiftUI's preview feature allows us to see near real-time UI changes as we change the views of our app. A lot can be said about working effectively with previews, but in a cross-platform context the important part is to validate how our views look on different platforms.

Luckily SwiftUI has com a long way in this regard. By using PreviewProvider and .previewDevice() we can see how our app looks on multiple devices at the same time.

Consider this app:



As shown in the screenshot above, this view and prewiew will show the app on an iPhone. But what if we want to see the app on an iPad simultaneously? That’s easy! Replace the #Preview-code with:





Conclusion

Cross-platform development in SwiftUI has great potential for code re-use and simple techniques go along way towards creating a maintainable code base for apps targeting multiple Apple platforms. With the help of responsive design and flexible previews, only the app’s functionality remains and how hard can that be?*

* It’s the hardest part.



Cross-platform SwiftUI

Oneshot er smarttelefonens digitale engangskamera, utviklet for å møte kostnads- og miljøutfordringene assosiert med tradisjonelle engangskameraer. Slik har veien med utviklingen av min app, fra behov til produkt, vært.



Spenningen rundt venteprosessen, en fascinasjon for retro-uttrykket og ta vare på fysiske minner, er noen av grunnene fotobutikkene oppgir som årsak for den populære engangskamera-trenden. Appen jeg har laget, kalt Oneshot, er engangskameraet du alltid har i lomma. Bildene kan du ikke se før et album er fylt opp, med kun ett forsøk på hvert bilde. Fotoalbum kan deles med venner og fysiske kopier kan bestilles.


Problemet med dagens engangskamera er at det er dyrt å fremkalle, lite miljøvennlig og utilgjengelig. Kameraene kastes gjerne etter bruk og noen fotobutikker sender kameraene til utlandet for bildefremkalling. Dette ønsket jeg å gjøre noe med!



Slik Kom Ideen 💡

I løpet av studietiden merket jeg at jeg gjentatte ganger fotograferte de samme motivene for å få det perfekte bildet. Dette endret seg da jeg begynte å bruke polaroide- og engangskameraer. Jeg ble fascinert av ideen om å ta et bilde for så å legge kameraet til side. Mitt fokus skiftet fra å jakte på det perfekte bildet til å heller fange det unike øyeblikket. Det å ta bilder som jeg ikke kunne se før fremkalling var alltid like spennende. Dette resulterte ofte i overraskelser over bilder jeg hadde glemt at jeg tok. Å dele disse øyeblikkene med andre var en glede, og de utvalgte printede bildene ble en integrert del av leilighetens veggdekor.



Men jeg innså at hobbyen min med engangskameraer ble kostbar, med utgifter over 3000 kr for kameraer og fremkalling. Som student i Datateknologi ved NTNU, fant jeg inspirasjon til å utvikle en løsning. Dermed ble appen "Oneshot" til. Navnet speiler appens essens, at hver bruker har kun én sjanse til å ta hvert bilde. Det er historien bak hvert bilde som teller, ikke nødvendigvis det perfekte utseendet. Dette reflekterer engangskameraets sjarm, og viser at skjønnhet ofte ligger i det uperfekte.

Løsningen 📱

Gjennom Spark og Aneobidraget, en støtteordning for entreprenørskap blant studenter, fikk jeg innvilget økonomisk støtte for en printer, masse kvalitets printerpapir, og en Adobe Lightroom lisens for å skape det ultimate retrofilteret. Bildet under er fra min pitch til Aneo.



Oneshot er en app for å ta bilder som hjelper deg å tenke mer over hva du tar bilder av. I likhet med et engangskamera kan du ikke se bildene dine før en forhåndsbestemt albumstørrelse er nådd, noe som gjør at hvert bilde blir mer spesielt. Med appen kan du søke etter og legge til venner, og når vennskapet er etablert, kan man utforske hverandres album. Appen tilbyr å jobbe med flere album samtidig som "Roadtrip" og "Sommer". Mens et tradisjonelt engangskamera med fremkalling og digital kopi koster rundt 482 kr, tilbyr Oneshot et 25-bilders album for kun 69 kr – syv ganger billigere! Bestiller du et album, mottar du bildene i en pakkeløsning inklusiv en remse skoletyggis for enkel opphenging.


Den tekniske løsningen 💻

Applikasjonen er utviklet i React Native Expo og Expo Application Services med Firebase Firestore for lagring av data. Det er utnyttet flere tjenester fra Firebase som Cloud Functions, Remote Config, Crashlytics, Analytics, Hosting, Authentication og Storage.


Oneshot ble utviklet i React Native Expo, ved hjelp av Expo Application Services (EAS). Expo fungerer som et omfattende rammeverk for React Native-applikasjoner, tilbyr verktøy og tjenester for rask oppstarts- og utviklingsprosessen uten krav om manuell konfigurasjon av native kode. Det inneholder også en rekke innebygde APIer og komponenter. EAS forbedrer utviklingsopplevelsen ved å tilby skybaserte tjenester for effektiv bygging, distribusjon og oppdatering av applikasjoner. En stor fordel med EAS er muligheten til å skape og integrere egne native moduler, en funksjon som tidligere ikke var tilgjengelig i Expo på grunn av deres begrensning til forhåndsdefinerte APIer og moduler. Som en nyutdannet utvikler fant jeg at den omfattende konfigurasjonen var en utfordring, noe som ledet meg til å velge Expo. Dette valget angrer jeg ikke på, takket være den omfattende dokumentasjonen og et aktivt community med godt utviklede komponenter fra Expo-teamet. Med integreringen av EAS har jeg også oppnådd betydelig fleksibilitet, noe som har tillatt meg å utvide applikasjonen med komplekse native moduler.



Applikasjonen bruker dokumentdatabasen Firebase Firestore for lagring av data, sammen med en rekke andre Firebase-tjenester som Cloud Functions, Remote Config, Crashlytics, Analytics, Hosting, Authentication, og Storage. Valget om en serverløs applikasjon førte meg til Firebase-økosystemet for å komme raskt igang, men lite visste jeg at dette skulle vise seg å bli en bjørnetjeneste. Nå som det er utviklet et fullverdig sosialt nettverk med massevis av relasjoner ser jeg nå at det kaaaaaanskje hadde vært greit med en relasjonsdatabase 🙃 I tillegg har jeg erfart at Firestore og Firebase generelt har ganske høye priser. Dette krever økonomisk kodeutvikling som minimerer antall CRUD-operasjoner for å holde kostnadene nede.


Planen videre 🌼

Til nå har Oneshot vært populær blant venner og deres nettverk. Jeg er spent på å se om flere ønsker en rimeligere og mer tilgjengelig løsning enn tradisjonelle engangskameraer. Jeg har ikke noen kunnskap om markedsføring så om du leser dette og har noen tips til hvordan hadde jeg satt utrolig stor pris på om du sendte meg en melding! På den tekniske fronten ser jeg for meg å automatisere printeprosessen. Slik at hver gang en bestilling kommer inn, vil den automatisk bli printet og sendt ut. 

Ditt Digitale Engangskamera

Det er lite som er like inspirerende som å kunne løse sine egne problemer med teknologi! Les om hvordan jeg, som ivrig toppturentusiast, har tilgjengeliggjort snøskredvarselet fra varsom.no som app til Garmin-klokker.

Når vinteren kommer, og det endelig kommer snø i fjellene, drar jeg på tur. Aller helst med toppturski på beina. Og når man går på topptur er det veldig lurt å ha kontroll på skredvarselet! NVE publiserer daglige skredvarsler for de fleste regioner i Norge mellom mellom 1. desember og 31. mai årlig på varsom.no, og disse varslene kan være livsviktig informasjon som bidrar både i turplanlegging, og til å ta trygge valg underveis på turen.

Inspirasjon 💡

Varsom tilbyr allerede apper for å lese skredvarselet på mobilen, men når eks-kollega Jonas Follesø lagde en app for å vise skredvarselet på Apple Watch, fikk jeg inspirasjon til å lage en app for Garmin også, siden jeg har vært fan av Garmin sine klokker helt siden jeg kjøpte min første fēnix for mange år siden.

Jeg hadde også flere ganger irritert meg over at Varsom sin iOS-app ikke synkroniserer varselet offline til telefonen. Det gjør at det er litt vanskelig å sjekke varselet ute i felt eller på parkeringen, hvis man skulle ha glemt å sjekke det før man drar hjemmefra. Derfor var en av hovedprioriteringene for appen min at varselet skulle synkroniseres til klokka, slik at man kunne få lest det også uten internett.

Monkey C, monkey do 🐒

Da jeg startet på prosjektet hadde jeg ingen tidligere erfaring med klokkeprogrammering av noe slag, og da iallefall ikke Garmin sitt økosystem. Det ble derfor tidlig klart at prosjektet kom til å ha en relativt bratt læringskurve. 

For å programmere apper til klokkene tilbyr Garmin en SDK som benytter et hjemmesnekra programmeringsspråk som heter Monkey C 🐵. Monkey C er litt som om Javascript og Java fikk et barn sammen, så heldigvis føles språket relativt kjent hvis man har programmert med noen av de før. Visual Studio Code er den anbefalte IDEen å bruke, og Garmin har en offisiell plug-in som anbefales brukt til utvikling. Totalt sett har det gått veldig greit å komme i gang med, bortsett fra to ting: Minne og skjermplass.

Minne 💾

I tillegg til utfordringene med programmeringsspråk og SDK, ble det også ganske raskt klart at et av hovedproblemene med å få appen til å kjøre, kom til å være tilgjengelig minne på klokkene. Jeg ønsket å støtte så mange klokker som mulig når jeg først var i gang, og ble da raskt klar over at mange av de litt eldre klokkene har særdeles begrenset minnekapasitet. Noen klokker har så lite som 20kb(!) tilgjengelig minne når appen kjører. 

Så på grunn av dette ble det raskt klart at jeg ble nødt til å skrive et proxy-API mellom Varsom sitt API og klokkene, slik at klokkene ikke gikk tom for minne når de spurte Varsom om skredvarselet. I tillegg måtte appen tilpasses relativt grundig slik at jeg ikke gjorde for mye fancy greier samtidig, og gikk tom for minne 💥. 

Det var egentlig ganske artig å forholde seg til at man har en minnebegrensning, siden det er sjeldent man tenker på minnekostnaden av programmeringen man driver med i det daglige.

Skjermplass ⌚️

En annen interessant problemstilling når man jobber med klokke som flate, er mengden tilgjengelig skjermplass. I det daglige er jeg vant med å å jobbe på vesentlig større flater, og jeg trenger egentlig aldri å tenke på om det jeg vil vise får plass på skjermen eller ikke. På klokker er det helt motsatt: Man har nesten ingen plass til å vise den informasjonen man vil.

Et skredvarsel består av flere deler. Det viktigste er selvsagt selve faregraden, som går fra 1 til 5, samt en beskrivende tekst. Men det er også en annen veldig viktig del av varselet: Aktuelle skredproblemer.

Skredproblemene for et gitt varsel sier noe mer spesifikt om hvilke farer som befinner seg i fjellet. Hvilke himmelretninger er farlige, hva slags type skred er forventet, og hvor høyt eller lavt må man befinne seg for å være i faresonen. Det var viktig for meg å få med disse skredproblemene inn i appen når jeg først skulle vise skredvarselet på klokka, og jeg ble derfor nødt til å legge inn en stor innsats for å få vist en oppsummering av skredproblemene uten at all skjermplass ble brukt opp.

Betaling 💸

Når jeg først måtte etablere en backend for å kunne støtte appen, bestemte jeg meg for at jeg ville ta litt betalt dersom den skulle ut til massene, slik at jeg kunne få dekket serverkostnader og litt til uten å gå i minus. Jeg endte derfor med en sum på 30kr per år for å bruke appen. 

I motsetning til Apple og Google, tilbyr ikke Garmin noen direkte måte å ta betalt for apper på i sin app store, så det må man ordne selv.

Jeg hadde ingen erfaring med integrering mot betalingsløsninger, men Vipps virket som et naturlig alternativ, siden omtrent alle har det, og det er veldig enkelt for brukere å gjennomføre betalinger. Jeg integrerte derfor med Vipps som betalingsløsning, og i høst har jeg også integrert med Stripe, slik at også folk som ikke har Vipps kan få skaffet seg appen.

Backend ⚙️

Appen består av to deler: Selve klokke-appen, og en backend som ligger på skredvarsel.app. Backenden fungerer som API for klokka og frontend for betaling av abonnement.

Backenden er skrevet i .NET, med PostgreSQL som database, og Hangfire for å kjøre periodiske jobber for å synkronisere mot Vipps. Frontendløsningen er en veldig enkel React/Vite-app, som bruker Chakra UI som komponentbibliotek. Backenden integrerer med Vipps Recurring og Stripe Subscriptions for å gjennomføre betalinger, og man kan logge inn med Vipps, Google eller Facebook.

Ønsket mitt når jeg lagde backenden var å bruke flest mulig kjente teknologier, siden jeg allerede hadde mer enn nok med å lære meg Garmin SDKen og Monkey C for å lage klokkeappen.

Både appen og backenden er åpen kildekode, og kildekoden kan finnes på GitHub.

Status 🏔️

Jeg begynte å jobbe med appen i februar 2023, og satte meg et mål om å prøve å få lansert før skisesongen var over. I starten av april fikk jeg ut første versjon, og etter litt blæsting på diverse Facebook-grupper for toppturer, fikk jeg raskt mine første brukere. Jeg var også så heldig å få en artikkel om appen min i Fri Flyt, noe som virkelig satte fart på nedlastingene. 

Jeg har lært masse om både klokkeprogrammering, små skjermer, minneoptimalisering, og integrasjon med betalingsløsninger. Alt i alt har det sålangt vært et veldig givende prosjekt, og det har gitt meg kunnskap som jeg allerede har fått bruk for i jobbsammenheng.

I tillegg til å kontinuerlig støtte nye klokker, har jeg i fremtiden planer om å få inn støtte for å automatisk velge region basert på GPS-posisjonen til klokken, samt støtte planlagte endringer som Varsom innfører rundt skredvarslingsregioner i 2024/2025 sesongen.

I skrivende stund har appen litt over 500 brukere, og ser ut til å fungere fint for de aller fleste. Den støtter omtrent alle Garmin-klokker som er lansert de siste 5 årene, og henter automatisk skredvarselet hver time hele vinteren. Så hvis du skal på topptur i vinter, ta en titt da vel?

Du finner mer informasjon her ➡️ skredvarsel.app

Skredvarsel for Garmin ⛷️⌚️

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?