DEV Community: 👨‍💻 Perttu Lähteenlahti

Making Money with Your React Native App Throught In-app Purchases

👨‍💻 Perttu Lähteenlahti — Sat, 18 Jan 2025 21:28:05 +0000

This article is based on the talk I gave at the first React Native London conference in 2024 about app monetization and in-app purchases. While selling your app on platforms like MicroAcquire or setting a price tag in the Play Store/App Store are valid strategies, the former isn’t very repeatable, and the latter feels somewhat outdated. In-app purchases have become the modern way to monetize apps. This article covers what you need to know about in-app purchases, how to set them up in your React Native app, and insights from psychology and service design on creating a great in-app purchase experience.

Brief history of in-app purchases

Apple and Google introduced competing app stores toward the end of the 2010s. Initially, app stores followed a model similar to traditional software sales: users could try a free, limited version of an app, and if they liked it, they could purchase the full version and own it outright. This was the standard way software was sold. However, the shift toward continuous revenue streams eventually took hold, driven by the push for recurring income from customers. Perhaps influenced by this trend, Apple and Google both introduced their own in-app purchase frameworks, changing how apps are monetized.

Today we have in-app purchases for all major platforms and they are most used solution for monetising apps. There are also multiple different types of in-app purchases. Let’s go over them and then talk which one works for your app the best.

Consumables

Consumables as the name entails are project that you purchase in the app and consume after purchasing. For example coin packs in mobile games, which you comsume and then use to purchase in-game items, or so called token of gratitude purchases such as sponsoring the developer by “buying them a coffee”. In both cases the in-app purchase flow makes it clear that your money is to purchase something that is one time and ephemeral.

Mobile games are the best use case of consumables, as purchasing things is directly tied to the continued experience of playing the game, for example when your in-app purchases allow you to purchase potions to continue playing. Of course you could do something similar with limited use apps, if you have an app that allows user to create AI generated images, then every generation request could be handled as a consumable in-app purchase.

Non-consumables

Second type of in-app purchase is the non-consumable, which after purchasing stays with the users and never expires. If users uninstall the app, and later install it again, they can recover the non-consumable purchase as well. There are few ways which you can use non-consumables to monetize your app:

Upgrading from lite version of the app to full version. This way there is no need for a separate light version of the app in the app stores.
Unlocking an individual feature of the app, such as dark mode. This is similar to the gratitude purchase that consumables offer, as dark mode for example is not a feature user can’t live without (unlike developers would have you believe).
Mobile games also use non-consumable purchases to unlock for example clothing for the player character. Alternative to this is to create an in-game currency that is a consumable purchase which is then used to purchase clothing.

Non-consumables used to be a very common approach to providing limited/full-version unlock approach to apps. However the last type of in-app purchases, subscriptions, have mostly taken over this approach so let’s talk about those next.

Subscriptions

The last and most ubiquous in-app purchase type is subscriptions. In-app purchases provide both recurring subscriptions, that are billed once a month for example; but also non-recurring once, where your subscription is on only for the mentioned timeframe and does not get automatically billed again.

The point of subscriptions is of course to generate continuous revenue, and there a few reasons for this:

Almost everything nowadays is connected to a server, and servers cost money. You have to somehow recoup the monthly server costs and subscriptions is a lot easier way to do that than trying to estimate a fixed price and then making users buy the app for that price.
Software is no longer just the app, but quite often there’s a underlying service layer providing e.g. customer support.
Software moved from singular releases to continuous development. New features and bug fixes and released periodically.
Getting payed for your work. Whether you are a solo developer or part of a big company, monthly revenue is also what turns into your monthly salary (well, one can dream)

For these reason subscriptions have become so ubiquous. However building good subscription is not easy and a lot users are still rather subscriptions avoidant. It is not uncommon for example to come across following type of reviews in app stores:

“App solved my problem but requires a subscription to use the service more than 5 times. One star”

Because of how easy and likely it is for users to shy away from your app because it has subscriptions, creating great subscription experiences becomes crucial for making money with your app.

Understanding commissions

In-app purchases are just digital payments in mobile app context. However, the you we can’t just slap a Stripe payments into your app to monetize your services and content. Apple and Google both whant their pound of flesh in the form of a commission.

The ina-app purchase commission used to be 30% for both App store and Play store, with both programs offering a reduced 15% commission fee for the first one million in revenue if you enrolled in the small business programs. Going beyond that, and you’ll start paying the original 30% commission. This applies to all in-app purchases, but subscriptions have an additional term to them that makes longer running subscriptions more profitable: both Apple and Google take a reduced 15% commissions that user has been subscribing for more than a year.

To calculate how much money you get when a user pays 10 euros, you have to first deduct the value added tax of your market, and then deduct the commission based on the store and program you’re in. In case of Finland this is 25.5% VAT, which means you’re left with:

Deduct VAT (25.5%): €10 × (1–0.255) = €7.45
Deduct Apple’s commission:
If 15%: €7.45 × (1–0.15) = €6.33
If 30%: €7.45 × (1–0.30) = €5.22

So you’re left with €6.33 (15%) or €5.22 (30%).

However, if you’re in a European country, thanks to the new terms of the Digital Markets Act, you can opt-in for Apple’s new reduced commission rate of 17% for all apps, and 10% commission for businesses in small business programs. On top of this, if you’re using Apple’s in-app purchase system, then you need to add 3% on top of either of these to get the full commission. However, if your app downloads exceed over 1 million, you get an extra “Apple’s core technology” fee of 0.5 euros per every download per year. If you’re doing business in Europe you have some choice, but most likely it’s the easiest to get started with the traditional fee model.

Reader app status - circumventing the commission

There is no way to circumvent Apple and Google’s commissions if you’re selling digital services or monetizing your content through your app. Of course if you’re selling physical goods, such as food deliveries, then the in-app purchase rules don’t apply to you.

Alternatively you can also not sell anything in your app, but handle the sales through your own website, using for example Stripe. This is how Kindle and Spotify get around Apple’s limitations. To do the same you have to apply a separate reader app status. To get accepted requires putting your app to be behind a login, and users can only consume already purchased content in the app. All payments need to be done through a separate channel and there are some limitations on how you can direct the user to our own site to do it. Directly linking them into payment process for example will not work, but you can for example say:

“Go to the website to purchase subscription”

In-app purchases in React Native

Since React Native has been around 8 years already, there’s quite a lot of options for in-app purchase for it. For example

react-native-iap which has been around for sometime. A good choice for consumable purchases but slightly complicated for subscriptions which usually require server side events to manage the subscriptions well.

2.9k stars in GitHub
react-native-chargebee, a good choice if you’re in a situation where your payment infra already exists in Chargebee. From personal experience, the integration seems more like an afterthought for Chargebee, and its documentation is very confusing, with setting up being needlessly complex.

8 stars in GitHub
react-native-purchases, the iap package by RevenueCat. It’s solid, documentation is good, there’s extra stuff like paywalls, and you offer integrations with Stripe for example.

804 stars in GitHub

Both Chargebee and RevenueCat offerings are what you would call hosted options, meaning the package is not enough by itself, but instead you will be using their payment infra to manage payements and receipts. In the case of RevenueCat, it’s free to get started with but once you make over 2.5k dollars you start paying 1% commissions on all tracked revenue.

In most cases you want to go with this kind of an approach. Running your own server to manage in-app purchases receipt validation for example is quite the hassle. I recently worked in one project where we had to wire our own consumable purchases to the custom backend and to be honest, I would take almost anything over working with Apple’s in-app server APIs.

Setting up RevenueCat and App store and Playstore

In order for things to work correctly we need to do some configuration in RevenueCat and App Store / Play Store. Way things works is that Play Store and App Store need to have products in them that we then connect to RevenueCat. This is easier to explain by example so start navigate to your App store connect account and first create this subscription group

After creating the subscription group we need to add two subscriptions into it, and then add the translations. We don’t need so submit anything yet but it necessary to get into a stage that says “Ready to submit”.

You should end up with something similar to this once. Missing metadata means that you still have to fill in things, although the subscriptions should already show up in sandboxtesting.

Next step is to configure these in RevenueCat. You can do this manually or you can configure your App Store keys into RevenueCat and allow RevenueCat to import your products from App Store. Before we get into all that it’s important to note that RevenueCat offers quite a lot more configuration options for in-app purchases than Play Store and App Store, and they also use custom concepts for it. Let’s look at few of the key ones before continuing with the configuration:

Entitlements — put simply this is the level of access user is entitled to. Your app could have multiple levels of entitlements that unlock different levels of features for example. In terms of real world examples, Netflix offers different subscriptions, which are similar to entitlements: basic one with 720p resolution and only one device, and family one with 4k and multiple devices.

Products are what RevenueCat calls the subscriptions and other in-app purchases you’ve set up in App Store connect and Play Store console. Products should match the subscriptions we’ve set up earlier.

Offerings allows us to map together different products and show them together. RevenueCat’s paywall functionality for example makes use of the offerings

Paywall is a method for limiting access to content, and RevenueCat offers a built-in functionality to create these and configure them remotely without any code.

Now that you understand these concepts you should understand the next steps for configuring our in-app purchases in RevenueCat dashboard. Due to having a monthly and yearly subscription for our app in App Store connect, we need to create two corresponding product, one entitlement that is connected to those products called Pro subscription, and one offering which will have both of those products. Once that is done, navigate to the Paywalls section of the tool and create our first paywall with the one offering we made.

You should now have the fundamentals building blocks for showing two subscription options in our React Native app. You can go ahead and customize the paywall to your needs. Once you ready, continue to next section which goes over the react-native-purchases configuration.

Adding and configuring react-native-purchases

React-native-purchases provides a lot of functionality out of the box without having to write a lot of code. You probably already have a project in which you’re going to configure your in-app purchases, but in case you do not, you can clone the repository below which contains the basic setup and the code examples we are going to go through next

Example project: plahteenlahti/buystuff

Everything begins with installing the necessary packages, react-native-purchases and react-native-purchases-ui. The latter will become more important later on when we start to work with the paywalls.

After installing all the necessary packages, we need to initialize the react-native-purchases module when mounting our app:

import { useEffect } from 'react';
import { Platform } from 'react-native';
import Purchases from 'react-native-purchases';

useEffect(() => {
  // Enable dev logging, you can remove this line
  Purchases.setLogLevel(Purchases.LOG_LEVEL.DEBUG);

  // Initialize the module using Platform.select
  Purchases.configure({
    apiKey: Platform.select({
      ios: 'your_ios_api_key',
      android: 'your_android_api_key',
    }),
  });
}, []);

It’s important to notice that apiKey is a single field but our Android and iOS apps have different key. Using Platform.select we can easily get around this. The API key is a public key so we don’t have to worry about the key getting bundled without our app.

With this done, we are ready to start restricting user access to the app and presenting paywalls.

Before purchase — Displaying a paywall

We are going to talk about the best possible way to structure you in-app purchase flow, which usually doesn’t start with instantly showing a paywall. However to keep the examples clear, let’s put aside for now and instead focus on the code implementation and not the UX.

As mentioned, paywalls are a way of restricting user’s acces to certain content or functionality in your app. Let’s say for example that user is trying to download a wallpaper app, and they press on the wallpaper they are intersted in seeing in full screen. Instead of opening in full screen, they are taken to a new screen which tells them to subscribe for 2.99€ a month. A prime example of a paywall. With RevenueCat, achieving similar functionality is very easy:

import RevenueCatUI from "react-native-purchases-ui";

export default function App() {
  const [showPaywall, setShowPaywall] = useState(false);

  return (
    <SafeAreaView style={styles.container}>
      <ScrollView style={styles.container}>
        <StatusBar style="auto" />
        {images.map((imageUrl, index) => (
          <TouchableOpacity
            key={index}
            style={styles.imageContainer}
            onPress={() => setShowPaywall(true)}
          >
            <Image
              source={{ uri: imageUrl }}
              style={styles.image}
              resizeMode="cover"
            />
          </TouchableOpacity>
        ))}
      </ScrollView>

      <Modal
        presentationStyle="pageSheet"
        visible={showPaywall}
        animationType="slide"
        onRequestClose={() => setShowPaywall(false)}
      >
        <RevenueCatUI.Paywall
          style={{ flex: 1 }}
          onDismiss={() => setShowPaywall(false)}
          options={{ displayCloseButton: true }}
        />
      </Modal>
    </SafeAreaView>
  );
}

In the code above I want you to pay attention to few things. First, in order to show the RevenueCat paywall you need the react-native-purchases-ui package that was installed ealier. Second is how I’ve structured the actual paywall. Whether to show the paywall or not is dependant on the showPayWall state. Later on we will tie this to react-native-purchases methods for checking user’s entitlements, but this simple approach is enough for now.

I wanted to display the paywall inside a modal that jumps on top whatever is on the screen and wrapped it in React Native’s modal component. In a more complex app you could make the paywall part of the navigation stack, which opens up more possibilities for displaying for it.

Once you’ve implemeted this part of the code, you should see the paywall you configured in RevenueCat. If nothing is showing up it’s time to check your configurations and the debug log for potential errors. Try also making changes to your paywall in RevenueCat’s dashboard and you should see them reflected on the app after a refresh. To test purchases you need to run the app on a real device and configure a sandbox testing account for that, see Apple’s up to date guide on how to do that here

After purchase — Checking user’s entitlements

Now that we have our basic purchasing flow set up using the RevenueCat’s paywall functionality, it’s time to check user’s subscription status i.e. are they entitled to the content they are trying to access. In RevenueCat this is done by calling the await Purchases.getCustomerInfo() and checking if the users active entitlements contain the entitlement that is required to access that content. CustomerInfo is catched by RevenueCat so it’s safe to call in multiple times, therefore the easiest way to implement entitlement checking feature is to create a custom hook:

import { useState, useEffect } from 'react';
import Purchases from 'react-native-purchases';

export const useAppContentAccess = () => {
  const [hasAccess, setHasAccess] = useState(false);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    const checkCustomerEntitlement = async () => {
      try {
        setLoading(true);
        const customerInfo = await Purchases.getCustomerInfo();

        // Replace 'pro_access' with the actual entitlement ID you set in RevenueCat
        const entitlementActive = customerInfo?.entitlements?.active?.['pro_access'];

        setHasAccess(!!entitlementActive); // User has access if entitlement is active
      } catch (error) {
        console.error("Error checking customer entitlement:", error);
        setHasAccess(false); // Default to no access on error
      } finally {
        setLoading(false);
      }
    };

    checkCustomerEntitlement();
  }, []);

  return { hasAccess, loading };
};

You can use this hook in all parts of the app that require checking the user’s access level to that subscription content like this:

import React from 'react';
import { View, Text, ActivityIndicator } from 'react-native';
import useAppContentAccess from './hooks/useAppContentAccess';

const App = () => {
  const { hasAccess, loading } = useAppContentAccess();

  if (loading) {
    return <ActivityIndicator />;
  }

  return (
    <View>
      {hasAccess ? (
        <Text>Welcome to the premium content!</Text>
      ) : (
        <Text>Please subscribe to access this content.</Text>
      )}
    </View>
  );
};

export default App;

You now have all the fundamentals building blocks for building in-app purchase flows in your React Native app. Let’s next look at the fundamentals behind good in-app purcase flows and a little bit of user psychology.

Psychology of good in-app purchase experiences

Getting user to buy

In app purchases are not the main use case of your app, you should not be spending time on building them, they bring no value to the users and I don’t think I’ve ever heard anyone say “I love building in-app purchases”. So sure, you can build your in-app purchases on anything you want, build your custom stuff for it if you feel, but keep in mind that no user is ever going to give you money or 5 star rating because your in-app purchase screen was artisanally made.

What you should spend your time instead is thinking of how to build the best in-app purchase flow. What I mean by that is thinking about the user goals and actions that lead them to first discover how your app solves their problems, and then commit to paying it to you. We should start by first thinking about what is the user problem our app is focused on solving for the user. That is after all why we’ve built the app originally. That functionality should of course be very visible in all the App store and Play store listings so so that users download the app in the first place. Of course it should also be so that main functionality is the easiest one to find from to find from both the store’s marketing as well as when the user opens your app the first time.

Once we have the problem clearly in mind it’s time to think about how we show that our app has that exact functionality that they are looking for. For this we have few options:

Can we allow the users to use functionality in the app and get results and then limit it. For example, in our wallpaper app we could maybe allow the users to download one wallpaper for free
Can we give the users a free trial of the full app? For example let’s say that when they subscribe for a month they get 1 week free during which they can cancel the subscription
Give something for free, a little bit more for some amount of money, and then give full access to everything for money. A ladder-esque approach where user becomes a more engaged customer as a function of feature amount

Life cycle of in-app purchases

Depending what you’re selling in your app, the customer journey is always different. One time purchases and continuous subscriptions pose different challenges for the customer journey. For time sake I’m only going to use subscriptions as an example of how to map your customer journey:

User discovers app
User discovers the value promise of the subscription
User decides to commit to buying subscription
User decides to increase spending in the app
User churns, ends subscription

Of course in an optimal world the user never churns out, but in real life people run out of money, their priorities change, or your app stops being valuable. Only the last one is something you directly improve. For the other parts you can only provide a stellar experience, so the problems you’re trying to solve becomes how to support users in all parts of the customer journey:

Highlight new value of the app
Offer free trials
Offer discounts on longer subscription
Highlight how old purchase is pro-rated

Summary

You’ve made it to the end, to recap you should now have a pretty good understanding of in-app purchase on different platforms, the options for doing that in React Native, example of in-app purchases using Revenucat and react-native-purchases, and the user psychology of a good in-app purchase experience. With these you should be able to create a basic in-app purchase flow that converts users to paying users. If you’re interested in learning more I suggest looking at RevenueCat’s developer documentation which contains a lot good information and technical aspects of in-app purchases.

I built a React Native App to Manage Netlify Hosted Sites

👨‍💻 Perttu Lähteenlahti — Wed, 10 Feb 2021 20:33:43 +0000

Today I'm announcing Netli.fyi a small app that helps you to manage your Netlify sites on the go. It's built with React Native and uses the Netlify API to show you your Netlify sites, builds logs, deployments, and form submissions.

Despite being mostly a mobile developer, I built quite a lot of websites and web apps with Gatsby, Publish, and NextJS during the last two years. The majority of these are hosted by Netlify, because I love the ease of use it provides: deploy previews, form submissions and functions work exactly like I would want them to. The Netlify site is pretty good for managing stuff with a desktop browser. However I needed something to make it faster to do while on the go, so I ended up building Netli.fyi

// Detect dark theme var iframe = document.getElementById('tweet-1359597977980047363-424'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1359597977980047363&theme=dark" }

The app is built with React Native and makes use of the following packages

react-navigation
react-native-svg
react-native-vector-icons
react-native-app-auth

When it comes to future features, I'm currently working on making it possible to redeploy sites from the app, see Netlify functions related information. In addition to I think some kind of iOS home screen widget would be a pretty nice addition, and after thinning the app a little I think I could a subset of features into an Apple AppClip as well which would make it easier to try the app.

The app is available for both iOS and Android for the price of a cup of tea, but you can also enroll in the open beta programs for either platform to give the app a try. I would love you to try the app and give feedback on what features you would like to see 🙂

I made the React Native app I've been building for the last year open source

👨‍💻 Perttu Lähteenlahti — Mon, 31 Aug 2020 20:11:41 +0000

TLDR: here's react-native sleep tracking & sleep coaching app that I've been building

In January 2019 I took a big leap into startup entrepreneurship and started building an app that could provide advice on how to improve your sleep based on your sleep tracker's data. When I started building it I had very little experience with React and even less experience with React Native. Because of having so little experience, I was afraid to make the code publicly available despite wanting to do it so from the start.

Few weeks I finally found the courage to clean the project and switch from private Gitlab repo to a public Github repository. You can find the full code here. I've tried to provide all the necessary instructions on how to run it locally, but there might be a few mistakes on my part here and there. Please let me know if/when you come across them.

hello-nyxo / nyxo-app

The repository for Nyxo React Native app, a personal sleep tracker and sleep coach

Nyxo App – Better Sleep 💤💤💤

Download iOS • Download Android • Contact • Nyxo Newsletter

What is Nyxo App

Nyxo is a mobile application for improving your sleep. Its built with React Native, AWS Amplify, styled-components, and Redux. Nyxo provides the following features:

Sleep tracking, with support for multiple different trackers
- Google Fit
- Apple Health
- Oura
- Withings
- Fitbit
- Polar
Sleep trends and sleep diary
Nyxo Cloud: backup your sleep data and coaching progress, and access it from nyxo.app
4 week sleep coaching program
Ask experts, if you have any questions we have the professional sleep coaches to help
And more

The plan is to develop Nyxo further and allow contributions from everyone. If you want to for example build a new sleep visualization or add support for new sleep tracker, we will gladly welcome a pull request of that :)

Can

…

View on GitHub

Why this project might be interesting to you?

As mentioned I built it with React Native, while originally having very little experience on it. I would like to say that I've improved a lot since starting out, so in a way this project works as a timeline of how I learned to build stuff with React Native. There are parts in the project where the code is really ugly, but also parts where I'm a little proud of it even.

To give a little rundown of the app here's what it can do:

Import sleep data from the following sources
- Apple Health
- Google Fit
- Oura
- Garmin
- Polar
- Fitbit
- Withings
Save data to Apple Health
Create trackable habits
Show stats based on sleep: bedtime window, average sleep, sleep trend, shortest night, longest night, etc.
Save data to Nyxo Cloud Service, which is built with Aws Amplify
Display content about sleep from Contentful
Works on both iOS and Android

There also some more boring features, which you can explore better by downloading the app from either App Store or Play Store. One really crucial thing that is missing is onboarding, which I'm hoping to add as soon as possible.

Tech

The app is built with the following stuff:

AWS Amplify: S3, Cognito, AppSync, DynamoDB, Aws Lambda
React Native
Redux, reselect, redux-offline
react-native-reanimated
react-native-svg
Intercom

Continuity

This is project is also very much alive and I'm contributing to it daily. If you like the app, I would really appreciate it if you give it a star either in Github or in App store / Play store. It would mean a lot to me, and make my whole week :)

PS.

I've also built another app during the past year. This app also doubles as a website for Nyxo, as it's built with Gatsby, Amplify, TypeScript, Styled-components, and react-query. You can find that project below:

hello-nyxo / nyxo-website

Nyxo website, built with Gatsby, AWS Amplify, React and TypeScript

Nyxo Website – Better Sleep 💤💤💤

Download iOS • Download Android • Contact • Nyxo Newsletter

This is the website that powers nyxo.app. It's built with the following tools:

Gatsby
React
styled-components
aws-amplify
Netlify

🚀 Quick start

1. Install the Gatsby CLI.

npm install -g gatsby-cli

2. Setup AWS Amplify + environment variables

In order to develop the site, you need to create file called .env.development in the root of the project. The contents of the file should we following:

INSTAGRAM_API_TOKEN=YOUR_KEY
INSTAGRAM_BUSINES_ID=YOUR_KEY
GTAG_ID=YOUR_KEY
GOOGLE_ANALYTICS=YOUR_KEY
CONTENTFUL_SPACE_ID=YOUR_KEY
CONTENTFUL_ACCESS_TOKEN=YOUR_KEY
CONTENTFUL_ENVIRONMENT=YOUR_ENVIRONMENT
MAILCHIMP_ENDPOINT=YOUR_KEY

We use Contentful so serve our coaching data. When development you can use our public testing environment by placing the following values in it:

CONTENTFUL_SPACE_ID=2bj8pq0ood89
CONTENTFUL_ACCESS_TOKEN=7yCg2oVBg-kQAhPrNTI0935HDiUJ7FYlUyIwM3Tspgg
CONTENTFUL_ENVIRONMENT=public

Our Instagram component will most likely complain that it can fetch data, because you're missing the required tokens. We are working on how to disable this. For now you should be able to skip…

View on GitHub

Nyxo.app Now Available in Both Finnish and English

👨‍💻 Perttu Lähteenlahti — Fri, 14 Aug 2020 08:53:24 +0000

Starting today, all of the materials we've produced about sleep, such as the lesson and exercises, are available in Finnish and English. We've supported both of the two aforementioned languages in the Nyxo mobile app since the beginning. Still, our website has mostly been in English. However, starting from today, you can easily change the language in the top navigation. In addition to this, we are now capable of supporting additional languages as well, and you can contribute to the translation in our repository.

There are a few things we hope to accomplish with this:

Better support for our Finnish customers. Our biggest market is still Finland; for a reason, we see that it is crucial to provide support and coaching materials in that language.
Better SEO performance. We hope that finally, supporting two languages throughout the site will boost our search engine position.
Open the way for more translations. Now that our source is open, everyone is welcome to provide additional languages, and we can also commission new languages if a certain market it requires. One example of this is supporting Swedish, the second official language here in Finland.

Before going into details on how the additional languages where implemented, I want to thank Pietari Nurmi and Kayla Gordon for translating and fixing the existing translations.

Technical Aspects When Converting to a Multi-language Page

The nyxo.app site has been built using GatsbyJS, a static site generator. We've written previously about using Gatsby in our blog, and overall find it a very exciting piece of technology to work with. However, localization with Gatsby is not the easiest thing to achieve, and we have tried to do it previously, but the amount of work has just been too much for the benefit.

This time we decided to try it again after coming across gatsby-plugin-react-i18next. Using it made the whole localization project almost painless (we did have some problems with getting it to play nicely with the pages created using our content management service). What makes this plugin different from other Gatsby plugins is that it uses react-i18next, which is most likely one of the best options for handling localization.

Our site uses this plugin, with JSON translation files to translate all the UI texts, such as the ones appearing inside buttons, and on most pages which are coaching lessons or exercises. Our sleep coaching materials are fetched from Contentful, and then using the custom page creation function, we create individual pages for all languages. Currently, this means that Gatsby generates close to 500 pages, 250 in each of the currently supported languages. Adding for example, two more languages will massively increase the amount of generates pages. However, as long as the amount of generated pages stays under 10k, all should be good. Over that, we will most likely need to start considering an alternative solution.

We will most likely write a more detailed guide on how you can do this yourself, but in the meantime, you can peek at the code in our repository.

Still to come

There are still some things missing as well. For example, blog posts are currently only available in one language and don't even support multiple versions of the content. There might also be some missing translation around the site, due to the number of unique pages we have. If you notice something, you can open a ticket in our repository.

Nyxo.app website is now open-source

👨‍💻 Perttu Lähteenlahti — Fri, 07 Aug 2020 08:58:35 +0000

Hello world!

Today and I'm very excited to announce that we have just open-sourced the Nyxo.app website, that means this one. This is the first step in a larger project of making all Nyxo products open source. In the future, we will open-source more the things we've built here at Nyxo.

What is Nyxo

In case this is the first time you've heard about Nyxo, let me introduce what we do. Founded in 2019, we build products to help you sleep better because we believe that sleep is the cornerstone of a healthy, happy, and fulfilling life. Our strategy for doing this is to provide something we call sleep coaching. Sleep coaching, which incorporates your sleep data to drive a four-week coaching program. Because we use data such as sleep records, heart rate, and daily activity to influence what type of coaching lessons and exercises are right for you, we work hard to support various sleep and activity trackers. You can also take part in the coaching without buying any tracker because the journey to better sleep, should not require an expensive upfront purchase.

We also strongly believe that a tightly knitted connection to sleep and behavioral research is the only way to develop coaching. Many in our team have a background in cognitive science or psychology, and we actively drive to be science-driven.

Why We're Going Open Source

Since founding Nyxo, we've been planning to build the product in public and allow everyone to contribute to it. However, because we are building products that employ the user's well-being data, we were concerned about how privacy and security would work in open source settings. However, as time has shown, obscurity does not equal security, and when you're product makes use user's private data, you have to be transparent how that data is used. We've concluded that the best way to tackle both of these subjects is to be as open as possible. It will allow users to understand better how their data is used in our products and also allow us to learn from other people interested in contributing.

We also strongly believe that open source will allow us to build better products, solve more problems. Innovation, both radical and incremental, is not born out of a void, but out of interaction with the real world. Building a product that everyone can contribute to is a perfect way to do this.

Last but not least, we believe that open source will make Nyxo more resilient against time. This is the only way the product can outlive it's original creators, and the also the way to do things faster.

Contributing

If you're interested in contributing to this website, you can find the repository for this website at here. All contributions are welcome, and we want contributing to our projects to be a fun and enjoyable experience for everyone. Contributing to Nyxo goes beyond pull requests and coding. We are happy to receive a variety of contributions, including the following:

Submitting new feature ideas
Submitting enhancements, designs, or bug fixes
Reporting bugs or issues
Blogging. If you're writing about the things we care about: sleeping, science, and technology, we would really love to have you on our blog. We accept previously released blog posts as well.
Contributing to the coaching materials we provide
Providing scientific backing to the coaching. If you're a researcher in the area of sleep and/or well-being, we would love to collaborate with you to create more coaching lessons and exercises. We would also love the highlight your research in our blog

Coming Soon

As mentioned, this is just the first step. In the coming weeks, we are hoping to make the Nyxo mobile apps for Android and iOS open source as well. They're built with React Native, and we are quite proud of some of the things we've been able to achieve with that platform, but there are also things we would like other people to look at. There's no hard deadline for this, but we are hoping to do this before September.

Build a Clock Face with SVG in React Native

👨‍💻 Perttu Lähteenlahti — Sat, 13 Jun 2020 12:12:19 +0000

In this article, we are going to look at how to draw a nice-looking analog clock face by using react-native, react-native-svg , and styled-components. The clock is going to tell time, tick, and have support for dark and light themes.
This is based on the work I’ve done on Nyxo, where we should a clock face as the base for showing your sleep data. I’ve been getting some questions on how to create something similar, which is why I wrote this guide to create them yourselves. If you just want to get your hands on the code, it’s here.

Getting started

Let's start by initing a new project. You could very well do this with Expo, but I prefer to use the ejected version of so React Native, so we are going to use the react-native-cli and the TypeScript example project to get started:

npx react-native init helloClock  --template react-native-template-typescript

after that, let's install the only external library, we need: react-native-svg.

npm install react-native-svg

Then we need to navigate to ios folder and install required pods:

cd ios & pod install cd -

You can now run the project:

$ react-native run-ios

Folder structure

I'm going to structure the project in the following way:

HelloClock
├── index.js
├── App.tsx
├── components
│ ├── Hand.tsx
│ ├── ClockMarkings.tsx
│ └── Clock.tsx
├── helpers
│ ├── geometry.ts
│ ├── time.ts
│ └── useInterval.ts

Polar and Cartesian Coordinates

Now to the bread and butter of this article so how to convert time to coordinates on SVG.

We can think of clock times in degrees, i.e., 12 am and 12 pm clock being the same as 0° and 6 pm and 6 am being 180°. We could, of course, use radians as well, but for me, at least degrees feel more familiar. A coordinate system which uses angle and reference point to determine a point on a plane is Polar coordinate system.

Converting time to Polar coordinate systems is relatively simple. Let's say we, for example, want to determine the angle of the minute hand on a clock in degrees when we know the number of minutes to be 30. If one full revolution is 60 minutes and one complete revolution is 360°, then dividing 30 minutes with 60 and multiplying that with 360 gives the same number of minutes in degrees, which is 180. Let's implement that with code into the time file:

export function polarToCartesian(
  centerX: number,
  centerY: number,
  radius: number,
  angleInDegrees: number
) {
  const angleInRadians = ((angleInDegrees - 90) * Math.PI) / 180.0;

  return {
    x: centerX + radius * Math.cos(angleInRadians),
    y: centerY + radius * Math.sin(angleInRadians),
  };
}

Building the Clock Component

Let’s start the UI stuff by cleaning up the App.tsx file so that it only has a StatusBar, SafeAreView the <Clock>-component:

// App.tsx
import React from "react";
import Clock from "./components/Clock";
import styled from "styled-components/native";

const App = () => {
  return (
    <>
      <StatusBar barStyle='light-content' />
      <SafeAreaView>
        <ScrollView
          centerContent={true}
          contentInsetAdjustmentBehavior='automatic'>
          <Clock />
        </ScrollView>
      </SafeAreaView>
    </>
  );
};

const ScrollView = styled.ScrollView`
  flex: 1;
  background-color: black;
`;

const SafeAreaView = styled.SafeAreaView`
  background-color: black;
  flex: 1;
`;

const StatusBar = styled.StatusBar.attrs(() => ({
  barStyle: "light-content",
}))``;

export default App;

Let’s not save the file just yet, but instead, start working on the Clock, ClockMarks, and Hand components. Import Dimensions from react-native and Svg-component from react-native-svg and make the Clock return a square SVG with the side of the squares being the same as the width of the mobile phone's screen by using the Dimensions helper:

// Clock.tsx
import React from "react";
import Svg from "react-native-svg";
import { Dimensions } from "react-native";
const { width } = Dimensions.get("window");

const Clock = () => {
  return <Svg height={width} width={width}></Svg>;
};

export default Clock;

Now when we save, nothing should appear on the screen. This is because SVG itself has no visible parts. Let’s continue by adding the ClockMarks to communicate the minutes and hours. First, let’s define how many ticks we want. Let’s write those values above the Clock component:

// Clock.tsx
import React from "react";
import Svg from "react-native-svg";
import { Dimensions } from "react-native";
const { width } = Dimensions.get("window");

const { width } = Dimensions.get("window");
const diameter = width - 40;
const center = width / 2;
const radius = diameter / 2;
const hourStickCount = 12;
const minuteStickCount = 12 * 6;

const Clock = () => {
  return <Svg height={width} width={width}></Svg>;
};

export default Clock;

We don’t want the clock to take the whole space of the screen, so we define the diameter to be the width of the screen minus 40. Then we want the clock to be in the center of the screen, so we divide the width of the screen with 2, and last we also need radius, which is, of course, half of the diameter.

For hours we want 12. In analog clocks, there are usually five divisions between every hour tick, and that’ How we are going to do it as well. However because because because we will keep the spacing between minute ticks consistent, it means that one of the minutes marking is going to overlap with every hour, we are going to add one extra tick and then multiply that by the number of hours, which equals to 72 minute markings

Creating the Clock Divisions

Not let’s put the values to use by creating the clock face values. Create a new file ClockMarkings.tsx. The ClockMarkings.tsx is going to contain the clock divisions for both hours and minutes. The component is going to accept props for radius, center point, minutes, and hours. Radius and center are going to be used to determine the arc on which the divisions will be placed and hours and minutes are going to tell us how many tics we want.

// ClockMarkings.tsx
import React from "react";
import { G, Line, Text } from "react-native-svg";
import { polarToCartesian } from "../helpers/geometry";

type Props = {
  radius: number;
  center: number;
  minutes: number;
  hours: number;
};

const ClockMarkings = (props: Props) => {
  const { radius, center, minutes, hours } = props;
  const minutesArray = new Array(minutes).fill(1);
  const hoursArray = new Array(hours).fill(1);

  const minuteSticks = minutesArray.map((minute, index) => {
    const start = polarToCartesian(center, center, radius, index * 5);
    const end = polarToCartesian(center, center, radius, index * 5);
    return (
      <Line
        stroke='white'
        strokeWidth={2}
        strokeLinecap='round'
        key={index}
        x1={start.x}
        x2={end.x}
        y1={start.y}
        y2={end.y}
      />
    );
  });

  const hourSticks = hoursArray.map((hour, index) => {
    const start = polarToCartesian(center, center, radius - 10, index * 30);
    const end = polarToCartesian(center, center, radius, index * 30);
    const time = polarToCartesian(center, center, radius - 35, index * 30);

    return (
      <G key={index}>
        <Line
          stroke='white'
          strokeWidth={3}
          strokeLinecap='round'
          x1={start.x}
          x2={end.x}
          y1={start.y}
          y2={end.y}
        />
        <Text
          textAnchor='middle'
          fontSize='17'
          fontWeight='bold'
          fill='white'
          alignmentBaseline='central'
          x={time.x}
          y={time.y}>
          {index === 0 ? 12 : index}
        </Text>
      </G>
    );
  });

  return (
    <G>
      {minuteSticks}
      {hourSticks}
    </G>
  );
};

export default ClockMarkings;

We use the hours and minutes variables to create arrays that match in length to the division count we want. Then we map those arrays to return Svg lines and make use of the polarToCartesian function we created earlier to the get correct position of the tics on the arc. I also added the Text tag so we can have nice numbers on the clockface. Because the array starts from zero, instead of using the index to render the number, in that case, it switches it with 12, so that our clock has number 12 on the top instead of zero.

Now if we add the ClockMarkings component to the Clock component and pass the variables for the clock face from earlier, we get something that looks like this:

Creating the Clock Hands

The clock is nothing without the hands so let’s make those next. Create a new component called Hand.tsx in the components folder with the following code:

// Hand.tsx
import React from "react";
import { Line } from "react-native-svg";
import { polarToCartesian } from "../helpers/geometry";

type Props = {
  center: number;
  radius: number;
  angle: number;
  strokeWidth: string;
  stroke: string;
};

const Hand = (props: Props) => {
  const { center, radius, angle, stroke, strokeWidth } = props;
  const { x, y } = polarToCartesian(center, center, radius, angle);

  return (
    <Line
      x1={center}
      y1={center}
      x2={x}
      y2={y}
      strokeWidth={strokeWidth}
      strokeLinecap='round'
      stroke={stroke}
    />
  );
};

export default Hand;

This component is a lot simpler than the Clock markings because it’s only a single SVG line. We use the function polarToCartesia from earlier and pass down the angle from Clock.tsx to this component, as well as the strokeWidth and stroke variables which we going to use to make the hands for seconds, minutes, and hours to differ from each other.

import React, { useState } from "react";
import Svg from "react-native-svg";
import { Dimensions } from "react-native";
import ClockMarkings from "./ClockMarkings";
import Hand from "./Hand";
import { useInterval } from "../helpers/hooks";
import { getTime } from "../helpers/time";

const { width } = Dimensions.get("window");
const diameter = width - 40;
const center = width / 2;
const radius = diameter / 2;
const hourStickCount = 12;
const minuteStickCount = 12 * 6;

const Clock = () => {
  let [time, setTime] = useState(getTime);

  useInterval(() => {
    setTime(getTime);
  }, 1000);

  return (
    <Svg height={width} width={width}>
      <ClockMarkings
        minutes={minuteStickCount}
        hours={hourStickCount}
        radius={radius}
        center={center}
      />
      <Hand
        angle={time.seconds}
        center={center}
        radius={radius}
        stroke='red'
        strokeWidth='1'
      />
      <Hand
        angle={time.minutes}
        center={center}
        radius={radius}
        stroke='white'
        strokeWidth='5'
      />
      <Hand
        angle={time.hours}
        center={center}
        radius={radius}
        stroke='white'
        strokeWidth='7'
      />
    </Svg>
  );
};

export default Clock;

You could now use this component to make a clock look like something in the picture below. However, because our clock hands don’t accept time yet, you would need to calculate the correct angle for the time you want to display. So let’s continue by creating a couple of helper functions that will allow us to turn time values into coordinates for our clock.

// time.ts
export const to12hClock = (hour: number): number => {
  return hour > 12 ? hour - 12 : hour;
};

type TimeObject = {
  hours: number;
  minutes: number;
  seconds: number;
};

export const getTime = (): TimeObject => {
  const date = new Date();
  const hours = (to12hClock(date.getHours()) / 12) * 360;
  const minutes = (date.getMinutes() / 60) * 360;
  const seconds = (date.getSeconds() / 60) * 360;
  return { hours, minutes, seconds };
};

Let’s go over what the functions do. The to12hClock function is just a small helper to convert 24 -hour clock to 12-clock when getting the hours with the getHours function of JavaScript Date. The getTime function is also quite straight forward. Each time the function is called it creates a new Date object and then uses the native time functions and simple mathematics to convert those to degrees.

Let’s also create a new useInterval hook, that we can then use to periodically create new time for our clock. Here’s the code for it:

// useInterval.ts
import React, { useState, useEffect, useRef } from "react";

// From Dan Abramov https://overreacted.io/making-setinterval-declarative-with-react-hooks/
export function useInterval(callback, delay) {
  const savedCallback = useRef();

  // Remember the latest callback.
  useEffect(() => {
    savedCallback.current = callback;
  }, [callback]);

  // Set up the interval.
  useEffect(() => {
    function tick() {
      savedCallback.current();
    }
    if (delay !== null) {
      let id = setInterval(tick, delay);
      return () => clearInterval(id);
    }
  }, [delay]);
}

Modify the clock component to use our new getTime function with the useInterval and useState hooks and we ourselves a clock that ticks!

// Clock.tsx

import React, { useState } from "react";
import Svg from "react-native-svg";
import { Dimensions } from "react-native";
import ClockMarkings from "./ClockMarkings";
import Hand from "./Hand";
import { useInterval } from "../helpers/hooks";
import { getTime } from "../helpers/time";

const { width } = Dimensions.get("window");
const diameter = width - 40;
const center = width / 2;
const radius = diameter / 2;
const hourStickCount = 12;
const minuteStickCount = 12 * 6;

const Clock = () => {
  let [time, setTime] = useState(getTime);

  useInterval(() => {
    setTime(getTime);
  }, 1000);

  return (
    <Svg height={width} width={width}>
      <ClockMarkings
        minutes={minuteStickCount}
        hours={hourStickCount}
        radius={radius}
        center={center}
      />
      <Hand
        angle={time.seconds}
        center={center}
        radius={radius}
        stroke='red'
        strokeWidth='1'
      />
      <Hand
        angle={time.minutes}
        center={center}
        radius={radius}
        stroke='white'
        strokeWidth='5'
      />
      <Hand
        angle={time.hours}
        center={center}
        radius={radius}
        stroke='white'
        strokeWidth='7'
      />
    </Svg>
  );
};

export default Clock;

Theming the Clock

Supporting a dark mode is almost a must these days. So let’s stylize our clock a little and add a dark mode.

Let’s start by creating a themes.ts file in the root of the project and with the following contents:

themes.ts;

import { DefaultTheme } from "styled-components/native";

declare module "styled-components" {
  export interface DefaultTheme {
    style: string;
    bgColor: string;
    primaryColor: string;
    secondaryColor: string;
    accentColor: string;
  }
}

export const lightTheme: DefaultTheme = {
  style: "light",
  bgColor: "white",
  primaryColor: "#333",
  secondaryColor: "#555",
  accentColor: "#4a5aef",
};

export const darkTheme: DefaultTheme = {
  style: "dark",
  bgColor: "#111",
  primaryColor: "#fff",
  secondaryColor: "#CACACA",
  accentColor: "#4aefd5",
};

I’m going to use four colors in this case. To get TypeScript support, I made a custom theme declaration. If you want to learn more about that, I have written about it earlier here.

Then we need to convert some of our existing components to use those theme variables instead of the previously set colors. This is what it should look like in the App.tsx

// App.tsx
//...ealier App.tsx code

const ScrollView = styled.ScrollView`
  flex: 1;
  background-color: ${({ theme }) => theme.bgColor};
`;

const SafeAreaView = styled.SafeAreaView`
  background-color: ${({ theme }) => theme.bgColor};
  flex: 1;
`;

const StatusBar = styled.StatusBar.attrs(({ theme }) => ({
  barStyle: theme.style === "dark" ? "light-content" : "dark-content",
}))``;

Let’s also change the styling of the clock markings and the clock hands so that with the dark theme we change the stroke and fill colors in the following way:

// ClockMarkings.ts

const Minute = styled(Line).attrs(({ theme }) => ({
  stroke: theme.secondaryColor,
}))``;

const HourLine = styled(Line).attrs(({ theme }) => ({
  stroke: theme.secondaryColor,
}))``;

const HourNumber = styled(Text).attrs(({ theme }) => ({
  fill: theme.primaryColor,
}))``;

// Clock.ts

const Seconds = styled(Hand).attrs(({ theme }) => ({
  stroke: theme.accentColor,
  strokeOpacity: "1",
}))``;

const Minutes = styled(Hand).attrs(({ theme }) => ({
  stroke: theme.primaryColor,
  strokeOpacity: "0.5",
}))``;

const Hours = styled(Hand).attrs(({ theme }) => ({
  stroke: theme.primaryColor,
  strokeOpacity: "0.8",
}))``;

You will need to change the props on the Hand component so that the stroke and strokeOpacity are passed down to the underlying SVG component. You can find the full code on how that is done here.

End Result

Now you should have a ticking clock that respects the user’s preferred theme. If you wanted to improve this, you could animate the hand movements.

Static Sites in Swift: Getting Started With Publish

👨‍💻 Perttu Lähteenlahti — Fri, 22 May 2020 17:24:28 +0000

A few days ago, I accidentally stumbled upon Publish, a static site generator that uses Swift as the language for building websites. Despite not being a Swift developer, I thought this sounded quite awesome. So I decided to try if the time I've spent playing around with SwiftUI could be enough to get up and running with a static site built with Swift.

Why Use Swift and Publish?

Just because something is cool, does mean it's worth doing, and the same applies to building static websites with random languages. Now Swift is hardly a random language. Most people might know it as the "Apple's programming language", and building iOS and macOS apps is what it's mostly used for. However, a lot more has been accomplished with Swift in recent years, after Apple open sourced the language. One of these areas where there's quite a lot of Swift usage is server-side, and a lot of cool server-side projects have already been built with Swift.

Being a mostly React and React Native engineer, I'm not the best person to talk about why use Swift to build stuff, having used it so little myself and not knowing all the pros and cons of the language. But let's just say that even from an outsider's perspective, Swift is a pretty good programming language. It has the usual perks of being a modern language, meaning that it borrows a lot of concepts from existing languages which makes it easier to pick up. On top of that, it also seems to be quite a performant language (based on this slightly old, slightly arbitrary benchmark)

What about Publish then? What makes it good? Looking at the repo and some of the examples sites built with it, it seems that Publish really excels in being quick to get started with, but still allowing you to tweak many things. The basic Publish setup for example comes with RSS, Markdown support, and sitemap, which the most important parts for building a static site. It also supports themes, which you write in Swift using something called Plot, an HTML theming engine from the same author as Publish.

Installing the command line tools

Let's start by installing the command line tools by cloning the Publish repository and then running make:

$ git clone https://github.com/JohnSundell/Publish.git
$ cd Publish
$ make

If you're not that familiar with the make command, it's a part of Make build automation tool that automatically builds programs and libraries from the source code. In order to use make command you need to have Apple developer tools installed. You can install them by running :

$ xcode-select --install

You should now have the Publish command line tools installed.

Creating a New Project With Publish

Let's continue out by making a new directory for our project, navigating to it, and then running publish new

$ mkdir swift.lahteenlahti.com
$ cd swift.lahteenlahti.com
$ publish new

After this a new Publish project will be initialized for you. You can open the Package.swift file in Xcode if you want to use that for development, or you can use something VS code. Let's look at what makes up our new static website:

|-- swift.lahteenlahti.com
|   |-- Content
|       |-- posts
|       |-- index.md
|   |-- Resources
|   |-- Sources

Sources

In this folder you can find your project's main.swift file, which defines some of the basic properties of your website, such as name, language, URL and description. We are going to look at customizing your Publish site in a separate post, so let's leave this file untouched for now.

Content

In the content folder you can find your content in markdown format.

Resources

This folder is empty for now but is later used for theming the project. In the Publish repository you can see that it contains the default FoundationTheme's styles.css file.

Building the Site

To turn all these files into a static website you need to build the project, which you can do by running the following command:

$ publish run

After this you see the Output folder being generated and Publish init a Simple PHP server to serve your site to localhost:8000. If you go that address, you should now see your site. Cool!

Publishing to Netlify

One of the coolest things with static websites nowadays is how easy it is to publish them. Just put your code in Github or Gitlab repository, give Vercel or Netlify access to the repository, and done. I've been using both Netlify and Vercel (haven't yet had a chance to try Gatsby Cloud) to publish my sites, most of which have been built with Gatsby, and they support a variety of different static site generators. But how about something built with Swift?

You could always run the build command on your own computer, and make Netlify serve the already static stuff, but this would kind of defeat the purpose of using a deployment service such as Netlify. However, it turns out that Netlify has support for Swift. Let's make our static blog see the outside world by publishing it with Netlify.

First, signup for a Netlify account if you don't already have one, and next make a new Github or Gitlab repository and allow Netlify to use that. I would also add the Output folder to gitignore. After this you only have to configure the build settings:

Publish Directory should be Output
Build Command should be swift run

That's literally it! if you now go the URL provided by Netlify, you should soon see your blog there.

What's Next?

I'm personally trying to move towards more native development, so playing around Swift in a context that I'm more familiar with (web) is one way to build on top of existing knowledge. The Publish project we made in this quick tutorial is something I'm going to use to keep track of my upcoming 100daysofSwiftUI journey. In future articles, I'm going to look at how style your Publish blog, and how to add stuff like code snippets.

TypeScript Configuration For styled-components In React Native

👨‍💻 Perttu Lähteenlahti — Sun, 10 May 2020 14:09:14 +0000

Using Styled-components with React Native is great. Where it really shines in my opinion is theming. However, wouldn't it be cool if you get type-checking for the themes you've created, as well as auto-complete for the theme variables? So that when you're writing something like this:

const Text = styled.Text`
  color: ${({ theme }) => theme.primaryColor};
`;

Then you wouldn't have to remember if whether the primary color was written as primaryColor or primary_color, Instead your editor tells you what theme variables stored inside the theme object you've created.

Well good news, you can easily achieve this by using the Typescript interface merging to override the default theme that comes with styled-components (more info how declaration merging works can be found here, and here). Here's how to achieve that:

To access the theme in our app, we need to first setup ThemeProvider and the pass down our custom theme inside it.

// App.tsx
import React from "react";
import { ThemeProvider } from "styled-components/native";
import Navigation from "/navigation";
import { lightTheme } from "/styles/theme";

const App = () => {
  return (
    <ThemeProvider theme={lightTheme}>
      <Navigation />
    </ThemeProvider>
  );
};

export default App;

We create the theme file and merge the declaration of DefaultTheme provided by styled-components with our own definition. Then we tell our themes to use that interface.

// theme.ts
import { DefaultTheme } from "styled-components/native";

declare module "styled-components" {
  export interface DefaultTheme {
    primaryColor: string;
  }
}

export const lightTheme: DefaultTheme = {
    primaryColor: #333;
    secondaryColor: #666;
};

export const darkTheme: DefaultTheme = {
    primaryColor: #fff;
    secondaryColor: #cacaca
};

That's it

Now every time you use the theme variables it comes equipped with TypeScript's typing powers. Even better, if you're using for example VS Code, it automatically provides you with auto-completion for the theme variables.

How to Fix 'VirtualizedLists should never be nested inside plain ScrollViews' Warning

👨‍💻 Perttu Lähteenlahti — Thu, 20 Feb 2020 17:04:42 +0000

When developing with React Native and nesting FlatList or SectionList component inside a plain ScrollView your debugger might display the following warning:

VirtualizedLists should never be nested inside plain ScrollViews with the same orientation
- use another VirtualizedList-backed container instead.

This warning pretty much tells what is about. What is doesn't tell, is why this is bad and how to fix warning (other than changing the orientation of the nested VirtualizedList but that is not always possible). Let's look at how why this happens and how to fix it.

Why nesting VirtualizedList inside a plain ScrollView is bad?

Virtualized lists, which means and are performance-optimized which massively improves memory consumption and performance when using them to render large lists of content. The way this optimization works is that it only renders the content that is currently visible in the window, usually meaning the container/screen of your device. It also replaces all the other list items same sized blank space and renders them based on your scrolling position.

Now If you put either of these two lists inside a ScrollView they fail to calculate the size of the current window and will instead try to render everything, possibly causing performance problems, and it will of course also give you the warning mentioned before.

How to fix this warning the right way

The fix to this warning is simpler than you think: get rid of the ScrollView, and place all the components that surround the FlatList inside ListFooterComponent and ListHeaderComponent.

Let's see how this works in practice. In this example, we have an app where the user can scroll through different recipes. The main view consists of a ScrollView and inside that view, we have a collection of components such as a header, a footer, some text, and a cover photo. It looks something like this:

const Main = () => {
  return (
    <ScrollView>
      <CoverPhoto src={images[0]} />
      <Title>Welcome</Title>
      <Text>Take a look at the list of recipes below:</Text>
      <Footer />
    </ScrollView>
  );
};

Now say we want to list all the recipes under last Text element using FlatList after which it would look something like this:

const Main = () => {
  const renderItem= (item, index) => {
    return (
      <Recipe
      key={index}
      recipe={item}>
    )
  }

  return (
    <ScrollView>
      <CoverPhoto src={images[0]} />
      <Title>Welcome</Title>
      <Text>Take a look at the list of recipes below:</Text>
      <FlatList
        data={recipes}
        renderItem={renderItem}
      />
      <Footer/>
    </ScrollView>
  );
};

This will then, of course, give you the warning that was mentioned before, and you will also not be able to use the performance features FlatList has. That is why we are going to get rid of the ScrollView completely and instead use the ListFooterComponent and ListHeaderComponent props like so:

const Main = () => {
  const renderItem= (item, index) => {
    return (
      <Recipe
      key={index}
      recipe={item}>
    )
  }

  return (
    <FlatList
      LisHeaderComponent={
      <>
        <CoverPhoto src={images[0]} />
        <Title>Welcome</Title>
        <Text>Take a look at the list of recipes below:</Text>
      </>}
      data={recipes}
      renderItem={renderItem}
      ListFooterComponent={
        <Footer/>
      }/>
  );
};

Both props only accept one component so we wrapped the components in the ListHeaderComponent with Fragments. But there you have it, no more warnings and everything still looks the same.

This article originally appeared on my personal blog

Successful Rapid Prototyping With React Native

👨‍💻 Perttu Lähteenlahti — Sun, 29 Dec 2019 00:00:00 +0000

This is a transcript of a lightning talk I gave at React Day Berlin in 2019. You can watch the talk here, and download the presentation slides here. All the links and resources are available at the end of this transcript. This post originally appeared on my personal blog

But before we go into all that, I want to give a little introduction to myself. So the reason for my complicated name "Perttu Lähteenlahti" is because I'm from Finland, which is by the way celebrating its Independence Day today. I'm a developer/designer at a company called Nyxo, where we build personalized sleep coaching programs in a mobile app format.

The reason I know a lot about prototypes is because I've taken part in around 70 hackathons, which are, in a way, prototyping competitions. I've won about 40 of those, so I've been moderately successful.

But let's get to the subject at hand, so why prototype? Reasons for doing that could be simply that:
You're starting from scratch
You want to try out new technology
You're unsure of the path the product is going to take
Generally speaking, prototyping is something you do every time you're unsure what you're supposed to do. That's precisely the place where I started about a year ago when I was hired by two university research to commercialize their sleep research. I went to the first meeting, and the conversation went a little like this:

Researchers: "build us a product."

Me: "can you be more specific?"

Researchers: "build as a product that is nice to use and makes money."

I was like that doesn't make it any more apparent, but then I decided that I might as well start by building a prototype.

I ended up building these three prototypes. In the one you see on the left of the picture, we decided to experiment with how people would like to see their sleep data. What kind of presentation types work and which do not.

In the middle one, we tested out how you should provide sleep coaching content, which means, e.g., how to show exercises and lessons that are engaging and interesting to go through.

And on the right one, we tested that if you could make sleeping into a game so every night you would try to sleep better than your friends and that way compete against your friends.

When I was researching how to build these prototypes, I had one hard requirement: I have able to take part in the coding as well. Because I have a background in design and web development, native iOS or Android weren't a viable option. React Native turned out to be a kind of a perfect solution for that. But not just because it's suitable for prototyping but because I could also use it to build the end product. This transition is possible because building with React Native is relatively straightforward to build with it. It's also really fast to build with it, and it's even faster to deliver and measure everything.

Building

Let's look at why is building apps with React Native is so swift. For starters, the are many great UI kits such as react-native-paper. I like to build UIs myself. Mainly because I will then know how every component is built, and can then use them more effectively. In general, React Native allows you to build cool stuff fast just because you can employ your existing skills from React and JavaScript so much.

Delivering

What is maybe even cooler is delivering fast. React Native's capability to deliver fast actually saved our butts when we were testing one of our pilot products with the largest life insurance company in Finland. One Friday I got an email that said:

"hey, this feature we agreed on doesn't work for me."

Reading that email, I was like we never agreed on that feature. It was never supposed to be in this pilot. However, instead of arguing over email, I instead decided to try if I could fix things without anyone noticing. So during the weekend, I built the feature and released it before Monday. Without React Native that would not have been possible, because the usual way you do it through App Store connect and Play Store is really painful it takes many days for Apple to look at but using Codepush we were able to update the code. The users didn't even notice that the feature was missing. The following Monday I got an email saying "sorry it might have been my device that it didn't work."

Expo is a pretty good solution, also offering you the same capabilities of pushing your code over-the-air as CodePush.

Last but not least, there's also react-native-remote-config that is part of React Native Firebase. It isn't as powerful as Codepush or Expo, but still allows you to make changes on the fly, but only in the configuration as you can change the JavaScript bundle by using this. It is still worth considering, especially if you're already using Firebase in your project.

Analytics

Before becoming a product designer/developer, I was a carpenter for seven years. There we used the mantra "measure twice" a lot. However, when I transitioned to the technology world, this mantra turned into a "measure everything". Measure what the user is doing, how long they are doing it, and what they are doing. Because in prototyping, your progress is only as good as results and feedback you get you. To do that, use the following tools.

Amplify analytics from AWS

Firebase Analytics

App Center Analytics (we use this mostly)

Here is also one hack that reveals some hidden user behavior. Wrap all the components with different components and make them emit and analytics event when the user clicks them. It allows you to understand which parts of the screen users are pressing, and for example, reveals if they consider something to be clickable that is not. In our case, it showed both UX problems as well and potential new features. However, please don't do this in production; it's terrible for accessibility.

This concludes my lightning talk on Successful rapid prototyping.

Build fast with
- React Native Paper
Deliver fast
Measure everything.

This article originally appeared on my personal blog

Checklist for releasing React Native apps

👨‍💻 Perttu Lähteenlahti — Thu, 31 Oct 2019 09:34:02 +0000

Releasing to App store

Getting your mobile app published in the App Store is simple in theory but tedious in practice. During the past nine months, I've sent several versions of the Nyxo app to be reviewed by Apple. Almost every time Apple has rejected a new version of the app, it has been because of some minor thing. That is why I decided to write a checklist for releasing your app to the App Store. Many of the items on this checklist can be automated using, for example, Fastlane, something I will write a separate setup guide and checklist later.

Before bundling the app

Increment the build number or number version
Because archiving the app takes some time, it's better to check this every time you start the archiving process.

Check the app for crashes and bugs
- Apple is, at times, very thorough in their app review. Check especially that your app works on iPad, even if you don't plan to support the device that is the device Apple uses for testing
No broken links
- If you're linking to content outside of your app, check that those links also work as Apple rarely checks them as well.
Remove placeholder content
Check that your app doesn't mention 'beta' or any other words that could signal that the app is incomplete
- Apple is very strict about this. Remember to also check everything
Check permissions
- Check that your info.plist includes all the permissions your app requires.
Check localizations and translations
- Check that you're not missing any translation key/values. Apple only tests the English version

Things to check in App Store Connect

Check app name and localizations
- Check this especially if you've recently changed the name of the app in App store in any way
Check keywords and keyword localizations
- It is good to update the keywords periodically, as it can potentially boost your App store search hits a lot.
Check in-app purchase sections
- Check the names and descriptions of your in-app purchases
- If you're offering subscriptions, remember to check that your app description contains a mention of these and the prices; otherwise, Apple will reject your app
Check that your screenshots are up to date
- If you've updated the UI of your app, always update the App Store screenshots as well.
Check you app description text
- Pay attention to the "text above the fold." Because the user has to click to expand it to see the rest of it.
Check that your update text is compelling
- "What's new" is one of the first things users see when they open your app's product page, which is why it's essential to make it highlight all the new features you added in this release.

After releasing the app

Notify users that you've updated the app
- I like to automate this part with IFTTT, which allows you to for example automatically tweet when the new version your app has been released
Post to your channels and ask them to download/update to a new version of your app
- Downloading the app can boost its position on Apple's chart, which is always good - Also don't be too shy to ask the people to know to rate your app, as it will improve its position in the Apple search
Prepare for the next release
- Ship early, ship often

These are the main things I check with every release. If you feel something should be included, leave a comment. You can also make you use of the checklist tool I've built for this, which allows you to actually check all the items on the list. You can find that here. I will write a similar checklist for the Google Play Store, as well. However, I will first need to get to know it better.

This post originally appeared on my dev blog perttu.dev

Running React Native apps on specific iOS simulators

👨‍💻 Perttu Lähteenlahti — Thu, 31 Oct 2019 09:13:42 +0000

Testing your app on multiple devices and screen sizes is a must. Luckily React Native makes this relatively quick to do. If you're developing React Native apps for iOS you're most likely familiar with this command:

react-native run-ios

In most cases, that command opens up the iPhone X simulator. Instead, if you want to open your React Native app in a specific simulator you can also add the wanted device name with the simulator flag like this:

react-native run-ios simulator='iPhone 8'

And it will open up the iPhone 8 Simulator. You can get the full list of available devices with the command

xcrun simctl list devices

And here's a list of all the available devices available for testing:

react-native run-ios --simulator="iPhone 5s"
react-native run-ios --simulator="iPhone 6"
react-native run-ios --simulator="iPhone 6 Plus"
react-native run-ios --simulator="iPhone 6s"
react-native run-ios --simulator="iPhone 6s Plus"
react-native run-ios --simulator="iPhone 7"
react-native run-ios --simulator="iPhone 7 Plus"
react-native run-ios --simulator="iPhone 8"
react-native run-ios --simulator="iPhone 8 Plus"
react-native run-ios --simulator="iPhone SE"
react-native run-ios --simulator="iPhone X"
react-native run-ios --simulator="iPhone XR"
react-native run-ios --simulator="iPhone XS"
react-native run-ios --simulator="iPhone XS Max"
react-native run-ios --simulator="iPhone 11"
react-native run-ios --simulator="iPhone 11 Pro"
react-native run-ios --simulator="iPhone 11 Pro Max"
react-native run-ios --simulator="iPhone XS Max"
react-native run-ios --simulator="iPad Air"
react-native run-ios --simulator="iPad Air 2"
react-native run-ios --simulator="iPad"
react-native run-ios --simulator="iPad Pro"
react-native run-ios --simulator="iPad"

I'm getting "Could not find iPhone X simulator" or similar error message when running this command

At times you might run into problems with this command. This error message, for example, is quite common:

Could not find iPhone X simulator

Error: Could not find iPhone X simulator

This error is often caused by updating to a new Xcode version, which doesn't include the iPhone X simulator any more, which is the default for react-native-cli. This problem should disappear when you pass the simulator flag and another device than iPhone X.

This was a quick and simple guide to running on different iOS simulators when building React Native apps. I wrote this because I found myself googling different device names too often. I hope that you find it useful. 🙂

This post originally appeared on my dev blog perttu.dev

DEV Community: 👨‍💻 Perttu Lähteenlahti

Making Money with Your React Native App Throught In-app Purchases

Brief history of in-app purchases

Consumables

Non-consumables

Subscriptions

Understanding commissions

Reader app status - circumventing the commission

In-app purchases in React Native

Setting up RevenueCat and App store and Playstore

Adding and configuring react-native-purchases

Before purchase — Displaying a paywall

After purchase — Checking user’s entitlements

Psychology of good in-app purchase experiences

Getting user to buy

Life cycle of in-app purchases

Summary

I built a React Native App to Manage Netlify Hosted Sites

I made the React Native app I've been building for the last year open source

hello-nyxo / nyxo-app

The repository for Nyxo React Native app, a personal sleep tracker and sleep coach

Nyxo App – Better Sleep 💤💤💤

What is Nyxo App

Can

Why this project might be interesting to you?

Tech

Continuity

hello-nyxo / nyxo-website

Nyxo website, built with Gatsby, AWS Amplify, React and TypeScript

Nyxo Website – Better Sleep 💤💤💤

🚀 Quick start

1. Install the Gatsby CLI.

2. Setup AWS Amplify + environment variables

Nyxo.app Now Available in Both Finnish and English

Technical Aspects When Converting to a Multi-language Page

Still to come

Nyxo.app website is now open-source

Hello world!

What is Nyxo

Why We're Going Open Source

Contributing

Coming Soon

Build a Clock Face with SVG in React Native

Getting started

Folder structure

Polar and Cartesian Coordinates

Building the Clock Component

Creating the Clock Divisions

Creating the Clock Hands

Theming the Clock

End Result

Static Sites in Swift: Getting Started With Publish

Why Use Swift and Publish?

Installing the command line tools

Creating a New Project With Publish

Building the Site

Publishing to Netlify

What's Next?

Links

TypeScript Configuration For styled-components In React Native

That's it

How to Fix 'VirtualizedLists should never be nested inside plain ScrollViews' Warning

Why nesting VirtualizedList inside a plain ScrollView is bad?

How to fix this warning the right way

Successful Rapid Prototyping With React Native

Building

Delivering

Analytics

Checklist for releasing React Native apps

Releasing to App store

Before bundling the app

Things to check in App Store Connect

After releasing the app

Running React Native apps on specific iOS simulators

I'm getting "Could not find iPhone X simulator" or similar error message when running this command