1. COVID
   This first point probably surprises no one. For most, this year has brought massive changes to their lives. For me, though, it didn't change anything. Maybe it's because Finland handled the whole situation relatively well. Or perhaps it is just that life, in general, is a lot easier for a privileged white male, and even things like a global pandemic can't change that. It tells a little bit about my social circles' size when I say that nobody I genuinely know caught the coronavirus this year. Maybe I've just been fortunate (knocks on wood)?

2. Nyxo
   This was a challenging year for Nyxo. Last year ended on a positive note, taking part in TechCrunch Disrupt, getting a small business loan approved, and then COVID hit. We lost some clients: all the work we were doing with airlines evaporated instantly, some clients stopped answering emails entirely, and some asked to talk again in the autumn. We applied for Business Finland COVID funding but got almost nothing (later, I found out that companies doing half the revenue we had received over ten times as much funding). My co-founder had just flown to San Francisco to explore that option but was forced to fly back after just two weeks. Eventually, we also had to lay off the people we had hired at the beginning of the year. That was hard.

   It remains to be seen what happens next. We've managed to get some of the momentum back, but we are still far from what we had a year ago. I'm going to write a separate post about Nyxo at a later time, and I certainly hope it's not an obituary, but you never know with these bootstrapped startups (you either succeed or you die). If you want to help, trying out the app, giving feedback, and leaving an App Store review is something I would really appreciate.

3. Your boy's got a bachelor's now
   Yeah, so I finally have something to show for my studies this year, after managing to submit all the required papers for completing a Bachelor's of Science in cognitive science. I know this will surprise some people because most have probably thought that I have a degree in something already. Thing is, I started studying cognitive science in 2013 and managed to complete almost both master's and bachelor's degrees in two years, but I didn't. I was so caught up in other things, such as building companies, that I didn't even have time to submit my bachelor's thesis to be reviewed despite it being finished. This year I realized that my parents might never witness me graduate, so I decided to put some of my time into completing my studies (I personally don't see them as being that valuable anymore, I might write about why in the future). I still need to finish up my master's thesis, but I hope to get that done in the spring now.

4. Spending more time with my parents
   This year I've focused more time on spending time with my parents, which is weird because a few years ago, my only reason for visiting them was to check up on the apartments I own in the city they live in. Not because we were on bad terms or anything, I was just in the wrong place and felt going there as a burden. But this year I've spent more time with them. They're getting older, and eventually, it will be too late to spend that time with them, so better do it now.

5. Loneliest year?
   Maybe it's COVID, or maybe it's because I don't have too many friends, I've felt very lonely this year. Depressingly so. It could also be an age-related thing; I'm turning 30 next year. Maybe it's just how it works. Maybe it's because I'm a miserable person to be around. Maybe it's my bad personality and the fact I'm not good with people. Maybe it's Maybelline.

6. Six years of 60 hours a week
   Since 2014 when I stopped studying full-time, I've worked an average of 60 hours a week. Sometimes this has meant studying and working full-time at the same time, sometimes it has been working two jobs simultaneously (once even three jobs for a short period), but mostly it's been because I've worked a day job while building a company. This year is no different; however, I'm starting to see that this will no longer work. The cognitive strain seems to be too much. Next year I might dial down on the workload a little and spend more time being bored.

7. A great year for falsely thinking you're great at investing
   This year has been tremendously great for my savings and investments. So great that I've started to consider selling all my stocks and even some apartments (I bought two more this year, bringing the total number of managed apartments to four). At the same time, I even noticed how people, in general, seem to be more interested in investing, which is a good thing but also makes me a bit skeptical if we're approaching the top of the roller coaster and things will soon start looking a lot scarier.

8. Reading and writing more
   Earlier this year, my goal was to speak at more software development conferences (I did my first ones in 2019 and liked the experience a lot), but COVID ruined that plan, so I decided to write some software articles. That has been a mild success, so I might do more of it in the future.

   I also read more this year (about 100 books, 30 more than last year) and plan on spending more time in the future reading. This year, I hit a bit of a slump with reading and had only read four books in June before I again found the interest to continue reading. Let's see if I have something similar next year or if I'm finally able to get to my goal of reading ten books a month 😄

9. Cyberpunk 2077 (and gaming in general)
   I haven't been gaming in a long time, but this year I decided to change that and bought the new Xbox Series X, and boy, did it change my evenings. I've been having almost as much fun playing as I did 15 years ago. Cyberpunk 2077 is also great; I don't care what others say. I'm going to post some of my thoughts about the game at some point.

10. VC fatigue
    I'm not sure what the reason behind this is, but I'm getting tired of VCs and startups a little. It seems always to be the same people getting funded. It's not as interesting as it used to be, and I don't think anyone's really "making the world a better place." Nyxo was the first actual startup I founded, and it was a great exploration of why the Finnish VC scene is so male and white. This year we didn't really speak with any investors; I guess they lost interest in us or we lost interest in them.

11. Queen's Gambit and chess
    Found a new hobby this year: chess. All thanks to Queen's Gambit (I'm guessing a lot of people can say the same). Before the show, I had never played in my life. Now I'm both playing and reading about strategy.

12. Living those teenage dreams
    When I was a teenager and had just gotten my driver's license, I used to envy other people who were driving new cars (or even had their own vehicles). The only car I had access to was my father's truck. But this year my dad and I decided to buy a new car together (for him, I don't particularly appreciate driving)—an all-electric Volkswagen e-Golf. The teenage Perttu is very happy to finally have access to a car from this decade (my dad is also pleased, which is nice).

13. Pretty fucking good at React Native
    I've coded a lot this year. I've built new apps, large component libraries, refactored some of my old projects, and built some truly novel stuff as well (for example, a cross-platform renderer for mobile and web using React Native, as well as a few App Clips by cramming React Native inside that tiny space). I applied for a few jobs out of curiosity, and it turns out I'm pretty fucking good at what I do. For me, that kind of feedback is a big thing because three years ago, I still considered myself mainly a designer who does code, but now it's the other way around.

14. Eames lounge chair
    This is going to sound shallow and materialistic, but one of the highlights of this year for me was buying an Eames lounge chair. It's the most beautiful thing I've ever owned, and I've found myself spending more time at home to sit in it. I've desired this chair for five years now and finally decided to get it after all this time. I can die (happy) now.

15. Losing all interest in moving to the USA
    A year ago, if someone had asked where I want to be in 2 years, I would have said, "living and working in the USA." But this year changed my mind on this matter. Reading about all the stuff happening there—poor handling of COVID, racism, white supremacy, the healthcare clusterfuck, Republicans (even from an outsider's perspective, Mitch McConnell seems like a pawn of Satan)—has chipped away all my interest. I don't think Biden's election will change this in the short term either, so it could be that one of my biggest dreams just died this year.

16. Helping others
    I've tried to spend more time helping others this year. I should probably do more in this area, but offering help doesn't come easily to someone who is afraid to ask for help themselves. So I'm saying now, if you need help with anything, no matter if it's work-related or not, I want to help. Just ask, I will most likely say yes.

17. Lottery
    This year I noticed a very weird behavior which isn't like me at all: I've put around 30 euros into taking part in the weekly lottery. For those who don't know, one of my family members suffers from gambling addiction, and it's also the reason I stay away from all forms of luck-based games that involve money. I've also studied a lot of statistics, so I should have a pretty good understanding of the minuscule odds. Despite this, there have been times this year I've thought that winning a million euros from a lottery would certainly help. And what is so bad about a small lottery ticket? And even though one of my friends says that the lottery is essentially about spending a few euros to dream, I don't think I should continue doing it. I'd rather lose my money the old-fashioned way: paying taxes.

18. Year of inactive lifestyle
    There's one word that well describes the change from the previous year: sedentary. I've been so inactive this year that it's almost embarrassing. Although the situation is what it is, this isn't the way to go forward. I'm not much for New Year's resolutions, but if I had to make one, it would be to focus more on exercise and stuff. Maybe if I work less I can fit more exercise into my week?

19. What happened to summer?
    Not sure if I'm the only one who felt that there was no summer? I mean, it was warm and all, but somehow it felt like the summer lasted for three weeks and then it was back to rain and darkness.

20. Not the worst year, not the best year
    Looking at everything going on around the world, I must say I'm in an incredibly privileged position. Yet, I feel like I should have accomplished more this year.

What is The Developer Menu

When running a development version of a React Native app, you can access a special Developer Menu by either shaking your device (if you're running the app on the device instead of simulator) or by using the following keyboard shortcuts:

• iOS Cmd ⌘ + D
• Android Cmd ⌘ + M

Doing either of these commands or shaking the device (by device I mean your phone, don't shake your laptop) should reveal menu that looks like this:

Here's a what all of these items in the list do

1. Reload
   Refreshes the application by loading the latest JavaScript code bundled by the Metro Bundler.

2. Open Debugger
   Opens a new browser tab for debugging JavaScript code using Chrome's developer tools.

3. Open React DevTools
   Opens React DevTools for debugging the app's React component hierarchy.

4. Show Inspector
   Opens an inspection tool for examining and modifying the layout and style of React Native components.

5. Show Inspector
   Allows inspection of UI elements by tapping on them to see detailed information.

6. Disable Fast Refresh
   Disables the Fast Refresh feature, which automatically reloads the app upon saving code changes.

7. Configure Bundler
   Provides options to configure the Metro Bundler used in the React Native app.

8. Show Perf Monitor
   Displays a performance monitor with real-time stats like FPS and CPU usage.

Customizing The Developer Menu

You can also add your own items to the Developer menu. React Native comes bundled with The DevSettings module which exposes methods for customizing the options in the menu.

Import DevSettings from react-native:

import { DevSettings } from 'react-native'

Call the static addMenuItem() in the part of the code you want. It takes two required parameters, title string and handler function. The title is used also as a key, so it needs to be unique for every item you add:

DevSettings.addMenuItem('My custom action 1', () => {
  console.log('Custom action pressed')
})
DevSettings.addMenuItem('My custom action 2', () => {
  console.log('Custom action pressed')
})

You can add as many items as you want into the Developer Menu as the list is scrollable. I personally like to wrap the addMenuItem() calls inside __DEV__ check so that they only work in dev mode (the developer menu is not included in production builds in any case so this is in a way just for readability, say for example if a person not familiar with React Native is wondering where this code goes.):

if (__DEV__) {
  DevSettings.addMenuItem('My custom action 1', () => {
    console.log('Custom action pressed')
  })
}

• The hook will try to run with a query that has no userID, leading the backend to reject it and return no data/error message on null format userID
• Typescript will complain about userID possibly being undefined or null

The first one is easy to fix using Apollo GraphQL hooks skip option. However as that does not validate the type, this leads to TypeScript complaining that you're trying to pass a null value to a field that does not accept one (as was in our case). To get around this our team had decided to use non-null assertion with the exclamation mark:

// eslint-disable-next-line @typescript-eslint/no-non-null-assertion
const { data } = useRandomQuery({
  variables: {
    userID: userID!,
  },
  skip: !userID,
})

Now this works all the way until someone assets a variable as non-null but forgots to add it to the skip section, leading to runtime errors or unexpected behavior.. Also, since our project is relatively mature and enforces several linting rules to capture these kinds of things, people had started adding a lot eslint-disable-next-line @typescript-eslint/no-non-null-assertion comments into these hooks. I think that you should try to always figure out a way around disabling a rule if you're disabling it more than once in your codebase.

To fix this I created the following function:

type NoUndefinedField<T> = {
  [P in keyof T]-?: NoUndefinedField<NonNullable<T[P]>>
}
/**
 *
 * @param args query variables for Apollo graphql query
 * @returns either skip: true or variables: NoUndefinedField<TVariables>
 */
export function variablesOrSkip<TVariables>(
  args: Partial<TVariables>,
): { skip: true } | { variables: NoUndefinedField<TVariables>; skip: false } {
  const hasInvalidValues = Object.values(args).some(
    (value) => value === null || value === undefined,
  )

  if (hasInvalidValues) {
    return { skip: true }
  } else {
    return { variables: args as NoUndefinedField<TVariables>, skip: false }
  }
}

What this function does, is that it checks if any of the passed variables are null or undefined by iterating through them, and if any of them are, it will return the skip parameter as true. This is how to use it:

const { data } = useRandomQuery({
  ...variablesOrSkip({ userID }),
})

Now if it turns out that userID is undefined or null for some reason the query is not run and you don't end up with nasty or embarrassing problems in productions. Most of the code probably makes a lot of sense but I want to highlight this part:

type NoUndefinedField<T> = {
  [P in keyof T]-?: NoUndefinedField<NonNullable<T[P]>>
}

This code here is not my invention, but instead something I found while searching for a way to remove undefined and null values from the returned type which led me to come across this Stack Overflow discussion about removing null or undefined values of a type

So yeah, I was there to give a talk. This time about how to monetize your app with in-app purchases. Funnily enough, when I submitted the talk, I wasn’t working at RevenueCat yet, a company whose entire thing is in-app purchases. So this wasn’t meant to be some “toot my own horn, sponsor-y kind of talk,” but it definitely had the building blocks to become one. Mainly because the truth is, RevenueCat isn’t just the biggest thing in the room when it comes to in-app purchases–it is the room.

I’ll talk a bit about how I think I managed to avoid making it feel like a corporate pitch, but also just want to recap this conference, which continues to be my favorite to date (to be honest, it’s actually tied for first place with ChainReact, which is an unbelievably well-crafted conference).

Speakers Dinner (Wednesday)

As mentioned, I came almost directly from Tokyo to Krakow, with a small 4-hour layover at Helsinki airport. I finally landed around noon at Krakow's airport and took a taxi to the hotel the organizers had booked for the speakers. Puro Hotel; the hotel picked by Software Mansion, the conference organizers; didn't disappoint. Well, the gym could have had dumbbells over 14kg, but that's just the meathead in me talking. Otherwise, it was a lovely hotel and served well from Wednesday through Saturday.

I had managed to sleep decently on the flight from Tokyo to Helsinki, thanks to business class seats, so I didn't need a nap. What I did need was to catch up on work and, surprisingly, laundry. I found the nearest self-service laundromat (who knew these make for wonderful co-working spaces) and joined some calls with teammates to get up to speed on the avalanche of things that had happened at RevenueCat while I was away. In traditional RevenueCat fashion: basically a few month's worth of updates packed into two weeks. I ended up doing catchups and calls basically right up until the speakers' dinner at 19:00.

The speakers' dinner was held at Software Mansion's office, just like at RTC.ON last September. Great vibes, good drinks, and solid food. It's funny how many familiar faces you run into at these conferences. Like, I've run into Rafael Mendiola at almost every React Native conference I've been to in the past year. I ended up chatting with some new people too, like Jani Eväkallio, one of the two MCs (to my knowledge), who got his speaker video intro recorded just before me. Oh and Jay Meistrich!

I wish I could have stayed longer but I really had to excuse myself when I started yawning while listening to a pitch. Sorry about that, it wasn’t you, it was just my jet lag.

Conference day 1 (Thursday)

Thanks to jet lag, I woke up at 7. Had a solid hotel breakfast and went for a quick run to get some energy out before diving into a full day of nerding out. Since my talk was going to be the last talk of the conference (on day two), I could take Thursday pretty easy and just enjoy the talks and connect with people.

The main venue is this old brick building in the middle of Krakow’s old jewish district. The venue is sizable, and you can catch the talks from pretty much every part of the venue which is nice. The jewish district is full of great little restaurants and street food vendors, so even if you for some reason skip the food they serve at the conference (I don’t think you should), you will not be disappointed.

I spent the day mostly attending talks, and chatting with Expo folks. Favorite talks of the day ended up being:

• Life After Legacy: The New Architecture Future, by Nico Corti and Riccardo Cipolleschi.
• Legend List: Optimizing for Peak List Performance by Jay Meistrich
• WebGPU === High performant 3D animations in React Native, by Krzysztof Piaskowy.

Others were great as well, I don’t think there was a single one that I didn’t get something out of. Talks at App.js are really good (he says while being one the speakers himself; talk about implicit self-praise). I have no idea how the speakers are picked, but I’m guessing that the developers at Software Mansion have something to do with it?

Conference day 2 (Friday)

The last day of the conference started with a little bit of a scare when I opened my laptop and for some reason Mac’s Spotlight couldn’t find my presentation at all. It wasn’t in Keynote either. I resigned almost immediately and was fully ready to spend most of my day redoing all the slides. However while having breakfast I discovered the Keynote presentation on my phone. I have no idea what it was doing there.

My talk was the very last one of the conference, which to be honest is not the best spot to be since everyone is already itching to get to the after party and start drinking. In the worst case a lot of people have already slid back to their hotels to get ready for the evening. In this case the audience was still mostly there, and energy was good to talk a little bit about in-app purchases.

This talk follows much of the same structure I gave at React Native London end of last year, with the first part focusing on the unique aspects of in-app purchases, and the last focusing on implementation. However I ended up including more statistics about how well React Native apps monetize. Gradually revealing the following points:

"React Native apps make more money… …than Flutter apps …and native apps."

got the response I was hoping for. All the insights about the state of monetization of React Native are based on RevenueCat’s State of Subscription Apps 2025 report, which you should read if you want to uncover industry secrets such as what length of subscriptions should you use with health and fitness apps for example.

Otherwise talk went well, of course there’s still room for improvement and I would kinda like to make a live coding demo at some point. That could be for example showing how I add the necessary code parts and update the paywall in RevenueCat’s paywall editor and how those changes magically get updated on the app. However that would require stripping some fundamental info about subscriptions from the talk, so might need to rethink the whole structure to make more time.

Oh I ran into some Finns after the talk. SOK people, if you’re reading this, I have a bunch of ideas on how to add in-app purchases to your apps. Let's chat.

After the closing ceremony, the afterparty kicked off at the Museum of Japanese Art and Technology, which as a place is great. Due to its size it allows for many different types of spaces, from dancing to casual conversations. Well I mostly just enjoyed the latter ones, no dances for me. Ended up staying late enough, and just chatting and drinking with people.

Conclusion

Great conference! Had even better experience than last year, and last year was also stellar. I will definitely apply to talk again next year. Just have to come up with a unique topic, since although in-app purchases are a nice topic, I would in all honesty talk about something else that has less risk of being a sponsor talk.

You can by the way watch all the talks already from the live stream for day 1 here, and for day 2 here. My talk is on day 2 at this time.

Last, huge thanks to Software Mansion for organizing another amazing event. Already looking forward to next year; and maybe, just maybe, without jet lag.

Having sharing images when distributing your content around the web can really help with more people noticing your content. A picture pops out more from a text-filled Twitter feed. Social images with brand styling also help capture your audience's attention, as they might recognize your brand colors and fonts better than just a random image in their feed.

You can quite easily add this functionality to your website by altering a few meta tags and finding an accompanying image for every page on your blog. But what if you don't want to use photos? Or perhaps your website has hundreds of pages and finding a good photo for each page—or creating them yourself individually—just isn't a viable strategy. In this case, you can look into creating an automated process to generate these images.

In this tutorial, we're going to look at how to generate social sharing images automatically by building a custom Gatsby plugin that uses Jimp, a Node.js image manipulation library. Our sharing cards will display the title of our blog post, the most relevant tag, and the estimated reading time. The tutorial consists of five parts:

1. What are OG-tags and why use them
2. Setting React Helmet to support OG-tags and Twitter tags
3. Modifying the blog-post template to support tags and reading time
4. Creating the social sharing image template
5. Building the gatsby-plugin-og-images plugin

What are OG-tags and why use them

OG-tags (Open Graph tags) are meta tags in your page's <head> that social platforms use for link previews. When someone shares a link to your blog post on Facebook, LinkedIn, or other platforms, these tags tell the platform what title, description, and image to display.

Twitter also supports its own set of tags (Twitter Cards), and for maximum compatibility, you'll want to implement both.

The basic OG tags you need are:

• og:title — The title of your page
• og:description — A brief description
• og:image — The URL to the preview image (1200×630 pixels is ideal)
• og:url — The canonical URL of your page
• og:type — The type of content (e.g., "article" for blog posts)

Setting React Helmet to support OG-tags and Twitter tags

Let's start by modifying our Gatsby site to support OG-tags and Twitter tags. First, install the required packages:

npm install react-helmet gatsby-plugin-react-helmet

Add the plugin to your gatsby-config.js:

module.exports = {
  siteMetadata: {
    title: "My Blog",
    description: "Thoughts on building things.",
    siteUrl: "https://example.com",
    twitterUsername: "@yourhandle",
  },
  plugins: [
    `gatsby-plugin-react-helmet`,
    // ...other plugins
  ],
}

Now create or update your SEO component at src/components/seo.js:

import React from "react"
import { Helmet } from "react-helmet"
import { useStaticQuery, graphql } from "gatsby"

export default function SEO({
  title,
  description,
  pathname,
  image,
  article = false,
}) {
  const { site } = useStaticQuery(graphql`
    query {
      site {
        siteMetadata {
          title
          description
          siteUrl
          twitterUsername
        }
      }
    }
  `)

  const {
    siteUrl,
    title: defaultTitle,
    description: defaultDescription,
    twitterUsername,
  } = site.siteMetadata

  const seo = {
    title: title || defaultTitle,
    description: description || defaultDescription,
    url: `${siteUrl}${pathname || "/"}`,
    image: image ? `${siteUrl}${image}` : `${siteUrl}/og/default.png`,
  }

  return (
    <Helmet title={seo.title} titleTemplate={`%s | ${defaultTitle}`}>
      <html lang="en" />
      <meta name="description" content={seo.description} />

      {/* Open Graph */}
      <meta property="og:url" content={seo.url} />
      <meta property="og:type" content={article ? "article" : "website"} />
      <meta property="og:title" content={seo.title} />
      <meta property="og:description" content={seo.description} />
      <meta property="og:image" content={seo.image} />

      {/* Twitter */}
      <meta name="twitter:card" content="summary_large_image" />
      {twitterUsername && (
        <meta name="twitter:creator" content={twitterUsername} />
      )}
      <meta name="twitter:title" content={seo.title} />
      <meta name="twitter:description" content={seo.description} />
      <meta name="twitter:image" content={seo.image} />
    </Helmet>
  )
}

This component handles both Open Graph tags for Facebook/LinkedIn and Twitter Card tags. The image prop will be the path to our auto-generated OG image.

Modifying the blog-post template to support tags and reading time

To display the tag and reading time on our OG images, we need to ensure this data is available. Install the reading time plugin:

npm install gatsby-remark-reading-time

Add it to your gatsby-config.js:

module.exports = {
  plugins: [
    {
      resolve: `gatsby-transformer-remark`,
      options: {
        plugins: [`gatsby-remark-reading-time`],
      },
    },
  ],
}

Now update your blog post template at src/templates/blog-post.js:

import React from "react"
import { graphql } from "gatsby"
import SEO from "../components/seo"

export default function BlogPostTemplate({ data, location }) {
  const post = data.markdownRemark
  const title = post.frontmatter.title
  const description = post.frontmatter.description || post.excerpt
  const tags = post.frontmatter.tags || []
  const primaryTag = tags[0] || "Blog"
  const readingTime = post.fields.readingTime?.text || "5 min read"

  // This path will be generated by our plugin
  const ogImage = post.fields.ogImage

  return (
    <>
      <SEO
        title={title}
        description={description}
        pathname={location.pathname}
        image={ogImage}
        article
      />
      <article>
        <h1>{title}</h1>
        <p>
          {primaryTag} • {readingTime}
        </p>
        <div dangerouslySetInnerHTML={{ __html: post.html }} />
      </article>
    </>
  )
}

export const pageQuery = graphql`
  query BlogPostBySlug($id: String!) {
    markdownRemark(id: { eq: $id }) {
      id
      html
      excerpt(pruneLength: 160)
      frontmatter {
        title
        description
        tags
      }
      fields {
        slug
        readingTime {
          text
          minutes
          time
          words
        }
        ogImage
      }
    }
  }
`

Creating the social sharing image template

We want our social sharing cards to follow a consistent theme, with only the text changing between posts. Create a base template image:

• Dimensions: 1200×630 pixels (the standard OG image size)
• Include: Your brand colors, logo, domain name, and any decorative elements
• Leave space: For the title, tag, and reading time text

Save this template image to static/og/template.png in your Gatsby project.

For the text, we'll use Jimp's built-in fonts initially. If you need custom fonts, you can create bitmap fonts (.fnt files) using tools like Hiero or BMFont.

When designing your template, measure the pixel offsets from the edges where you want the text to appear. You'll need these values when positioning text in the plugin.

Building the gatsby-plugin-og-images plugin

Now for the main event: building a custom Gatsby plugin that generates OG images during the build process.

Plugin folder structure

Create the following structure in your Gatsby project:

plugins/
  gatsby-plugin-og-images/
    package.json
    index.js
    gatsby-node.js

package.json

{
  "name": "gatsby-plugin-og-images",
  "version": "1.0.0",
  "main": "index.js",
  "dependencies": {
    "jimp": "^0.22.12",
    "mkdirp": "^3.0.1"
  }
}

Run npm install inside the plugin folder to install the dependencies.

index.js

This file just needs to export an empty object:

module.exports = {}

gatsby-node.js

This is where the magic happens. The plugin will:

1. Find all Markdown posts during the build
2. Generate an image for each post at public/og/<slug>.png
3. Add an ogImage field to each post node so templates can query it

const path = require("path")
const fs = require("fs")
const mkdirp = require("mkdirp")
const Jimp = require("jimp")

function safeFileName(input) {
  return input
    .toLowerCase()
    .replace(/[^a-z0-9]+/g, "-")
    .replace(/(^-|-$)+/g, "")
}

async function generateOgImage({
  outputPath,
  title,
  tag,
  readingTime,
  templatePath,
}) {
  const image = await Jimp.read(templatePath)

  // Load built-in fonts (you can replace with custom bitmap fonts)
  const titleFont = await Jimp.loadFont(Jimp.FONT_SANS_64_BLACK)
  const metaFont = await Jimp.loadFont(Jimp.FONT_SANS_32_BLACK)

  // Layout constants - adjust these to match your template
  const LEFT_MARGIN = 80
  const TITLE_TOP = 110
  const TITLE_MAX_WIDTH = 1040
  const TITLE_MAX_HEIGHT = 240
  const META_TOP = 420

  // Print the title (with word wrap)
  image.print(
    titleFont,
    LEFT_MARGIN,
    TITLE_TOP,
    {
      text: title,
      alignmentX: Jimp.HORIZONTAL_ALIGN_LEFT,
      alignmentY: Jimp.VERTICAL_ALIGN_TOP,
    },
    TITLE_MAX_WIDTH,
    TITLE_MAX_HEIGHT
  )

  // Print the tag and reading time
  const metaText = `${tag} • ${readingTime}`
  image.print(metaFont, LEFT_MARGIN, META_TOP, metaText)

  await image.writeAsync(outputPath)
}

exports.onPostBuild = async ({ graphql, reporter }, pluginOptions) => {
  const templatePath =
    pluginOptions.templatePath ||
    path.resolve(process.cwd(), "static/og/template.png")

  if (!fs.existsSync(templatePath)) {
    reporter.panic(
      `[gatsby-plugin-og-images] Missing template image at: ${templatePath}`
    )
  }

  const result = await graphql(`
    {
      allMarkdownRemark {
        nodes {
          id
          frontmatter {
            title
            tags
          }
          fields {
            slug
            readingTime {
              text
            }
          }
        }
      }
    }
  `)

  if (result.errors) {
    reporter.panic(
      "[gatsby-plugin-og-images] GraphQL query failed",
      result.errors
    )
  }

  const posts = result.data.allMarkdownRemark.nodes
  const outDir = path.resolve(process.cwd(), "public/og")

  await mkdirp(outDir)

  reporter.info(
    `[gatsby-plugin-og-images] Generating ${posts.length} OG images...`
  )

  for (const post of posts) {
    const title = post.frontmatter.title || "Untitled"
    const tag = post.frontmatter.tags?.[0] || "Blog"
    const readingTime = post.fields.readingTime?.text || "5 min read"

    const slug = post.fields.slug || safeFileName(title)
    const fileName = safeFileName(slug.replace(/\//g, "-"))
    const outputPath = path.join(outDir, `${fileName}.png`)

    try {
      await generateOgImage({
        outputPath,
        title,
        tag,
        readingTime,
        templatePath,
      })
    } catch (e) {
      reporter.warn(
        `[gatsby-plugin-og-images] Failed generating image for ${slug}: ${e.message}`
      )
    }
  }

  reporter.info(`[gatsby-plugin-og-images] Done.`)
}

exports.onCreateNode = ({ node, actions }) => {
  const { createNodeField } = actions

  // Add ogImage field to Markdown nodes so templates can query it
  if (node.internal.type === "MarkdownRemark") {
    const slugField = node.fields?.slug
    if (!slugField) return

    const fileName = safeFileName(slugField.replace(/\//g, "-"))
    createNodeField({
      node,
      name: "ogImage",
      value: `/og/${fileName}.png`,
    })
  }
}

Adding the plugin to your site

In your main gatsby-config.js, add the plugin:

module.exports = {
  plugins: [
    {
      resolve: `gatsby-plugin-og-images`,
      options: {
        templatePath: `${__dirname}/static/og/template.png`,
      },
    },
    // ...other plugins
  ],
}

Now when you run gatsby build, you'll see images generated in public/og/ and your blog posts will automatically include the correct OG image meta tags.

Usage with Contentful

If you're using Contentful instead of Markdown files, you'll need to modify the GraphQL queries. In the onPostBuild function, change the query to:

const result = await graphql(`
  {
    allContentfulBlogPost {
      nodes {
        id
        title
        tags
        slug
        body {
          childMarkdownRemark {
            fields {
              readingTime {
                text
              }
            }
          }
        }
      }
    }
  }
`)

And update the onCreateNode function to handle Contentful nodes:

exports.onCreateNode = ({ node, actions }) => {
  const { createNodeField } = actions

  if (node.internal.type === "ContentfulBlogPost") {
    const fileName = safeFileName(node.slug)
    createNodeField({
      node,
      name: "ogImage",
      value: `/og/${fileName}.png`,
    })
  }
}

Testing your OG images

After building your site, test your OG images using these tools:

1. Twitter Card Validator — Test how your cards will appear on Twitter
2. Facebook Sharing Debugger — Debug and preview Facebook shares
3. LinkedIn Post Inspector — Check how LinkedIn will display your links

These platforms cache OG images aggressively, so use the debug tools to force a refresh when testing changes.

Conclusion

Automating OG image generation saves time and ensures consistency across your blog. With this plugin, every new post automatically gets a branded social sharing image without any manual work.

The key benefits:

• Consistency: Every post follows your brand guidelines
• Automation: No manual image creation needed
• Dynamic content: Title, tags, and reading time are always up to date
• SEO improvement: Better social previews lead to higher click-through rates

Feel free to customize the plugin to match your design—adjust the font sizes, positions, colors, and add any additional elements you want on your cards.

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 next the 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 is based on the work I’ve done on Nyxo, where we show a clock face as the base for displaying your sleep data. I’ve been getting some questions on how to create something similar, which is why I wrote this guide to help you create them yourselves. If you just want to get your hands on the code, it’s here.

Getting started

Let's start by initializing a new project. You could very well do this with Expo, but I prefer to use the ejected version of 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 navigate to the ios folder and install the 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: how to convert time to coordinates on SVG.

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

Converting time to Polar coordinate systems is relatively simple. For example, to determine the angle of the minute hand on a clock in degrees when the number of minutes is 30: if one full revolution is 60 minutes and one complete revolution is 360°, then dividing 30 minutes by 60 and multiplying that by 360 gives the same number of minutes in degrees, which is 180°. Let's implement that in the geometry.ts 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 work by cleaning up the App.tsx file so that it only includes a StatusBar, SafeAreaView, and 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;

Next, we’ll work on the Clock, ClockMarkings, and Hand components. In Clock.tsx, import Dimensions from react-native and the Svg component from react-native-svg. Make the Clock component return a square SVG with the side of the square being the same as the width of the mobile phone's screen 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;

When saved, nothing will appear on the screen since SVG itself has no visible parts. Let’s continue by adding the ClockMarkings to communicate the minutes and hours. First, define how many ticks we want by writing these values above the Clock component:

// Clock.tsx
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;

Now let’s create the ClockMarkings component in ClockMarkings.tsx and render the hour and minute ticks:

// 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((_, 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((_, 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;

Now if we add the ClockMarkings component to the Clock component and pass the variables for the clock face, we get a basic clock face.

Adding alt texts

In the article's images, provide meaningful alt attributes for better accessibility:

<Image src={ClockMarkings} alt="Illustration of clock markings showing hours and minutes" />

<Image src={Clock} alt="Completed clock face with hands showing time" />

Human behavior is driven by incomplete data and methods to turn that data into action and perception. Take, for example, our eyes, which do not actually construct a complete high-resolution picture of our surroundings despite that we experience it so. Instead, that image is filled with noise, missing large chunks, and top of all also inverted. Yet, we can use this incomplete data to navigate the world and successfully perform complex behaviors in it. Based on research in cognitive science, it has been theorized that this results from organisms' innate ability to carry out statistical inference. This hypothesis is commonly referred to as the Bayesian brain hypothesis, and the theories concerning posit that our minds and brains are near-optimal in solving a variety of tasks (Bower and Davis 2012).

As mentioned by Bowers and Davis (2012), this conclusion that human behavior is close to the Bayesian optimal is exciting as it positions our behavior in a surprising and counterintuitive state of actually being optimal. They continue that this surprising claim has gathered a wide array of research during the years but not that much criticism as highlighted by a 2013 paper by Marcus and Davis.

This article aims to collect and review the criticism surrounding the Bayesian approach to the brain. The first part will focus on further introducing the concept of Bayesian inference in the brain. The later parts will aim to review and provide a concise framework of literature on criticism surrounding the Bayesian brain hypothesis.

Introduction to Bayesian theory

Before further analysis of the criticism concerning the Bayesian brain hypothesis, it is worthwhile to cover the fundamentals of both Bayesian statistics as well as their application in cognitive science and neuroscience.

Bayesian probability

In the Bayesian inference models of cognition, cognition is viewed as a process of drawing inferences from observed data (Marcus and Davis 2013). This inference is governed by Bayes's theorem, where A is the hypotheses being investigated, and B is the data that has been observed then states that for every hypothesis,

In this equation, P(Aᵢ| B) is the posterior probability of hypothesis Aᵢ when data B has been observed. P(Aᵢ) is the prior probability of A being true before observing any data, and P(B|Aᵢ) is the likelihood, that is, the conditional probability that B has been observed when Aᵢ is true. This theorem then states that the posterior probability is proportional to the product of prior probability and prior probabilities. In research, the data is usually information available to the human reasoner, priors are the initial state of knowledge, and hypotheses are the conclusion the reasoner draws from these (Bowers and Davis, 2012).

Bayesian brain hypothesis

On the most general level, probabilistic theories of the mind, such as the Bayesian theories in cognitive psychology, make the assumption that brains perform statistical inference on noisy and ambiguous information (Bowers and Davis, 2012). Most Bayesian theories describe the goal of the computation, why that computation is appropriate, and the logic of the strategy. What they don't take into consideration are the mental presentation and processes employed in solving the task. The fundamental goal of the approach is to determine what the optimal solution should look like, and use that to provide important constraints on theories of the brain (Bowers and Davis 2012).

At the same time that the Bayesian approach has gathered interest in cognitive science, the Bayesian approach has also become prominent in neuroscience (Bowers and Davis, 2012). The general idea behind the theories in neuroscience that employ the Bayesian approach is that populations of neurons are capable of representing uncertainty in the form of probability distributions and also capable of performing Bayesian computations (Bowers and Davis, 2012). The criticism surrounding this claim is inspected later in this paper.

Criticism surrounding Bayesian methodology

Criticism on post hoc practices

A notable criticism surrounding Bayesian inference in psychology comes from the appearance of post hoc practices in studies that have aimed to show the mind as a near-optimal engine of probabilistic inference. In their 2013 paper, Marcus and Davis name two closely related problems: task selection and modal selection, as a reason for concern. They see that these two problems undermine the conclusion of cognition being optimal or driven by probabilistic inference.

Criticism of task selection

According to Marcus and Davis (2013), human cognition can seem near-normative when the circumstances are correct while failing to appear so in others. They use a study of physical reasoning by Battaglia, Hamrick, and Tenenbaum as an example (Battaglia et al., 2013). In this study, participants were asked to predict how a tower of blocks would fall. Based on these results, the researchers proposed that humans' physical judgments are a form of probabilistic inference. However, according to Marcus and Davis, a substantial amount of previous studies have shown different results for other physical judgments. The aforementioned example highlights how research surrounding Bayesian inference suffers from generalizability: models fit a subset of tasks of the same problem space. According to Marcus and Davis, this could be the result of probabilistic-cognition literature disproportionately reporting success leading to a distorted perception of the applicability of these approaches.

Marcus and Davis continue that this risk of favoring probabilistic theories of cognition is elevated by the practice of selecting from a broader range of domains instead of diving deeper into one challenging domain. They conclude their criticism of task selection in Bayesian inference by proposing that an attempt to understand the competing mechanisms would possibly be a more enlightening approach.

Criticism of model selection

Related to the problem of task selection is the problem of selecting the models. Every model depends heavily on the choice of probabilities which can come from real-world frequencies, experimental subjects' judgments, and mathematical models (Marcus and Davis, 2013). In addition to the selection of probabilities, a number of other parameters need to be set either by basing the model on real-world statistics; by choosing the model or tuning the parameters to better fit the experiment at hand, or by using purely theoretical considerations, which can sometimes be quite arbitrary.

Each of these choices for constructing a model can become problematic for the model's real applicability (Marcus and Davis, 2013). Real-world frequencies, for example, maybe heavily dependent on what dataset is used. Another subject of problems is how the fit of the model to a certain data set is contingent on how the priors are chosen. To highlight this, Marcus and Davis use Griffiths and Tenenbaum's (2006) study where participants were asked to predict the length of poems, of which they were read a small section and then provide the information on what line that was. The priors for this study were based on the distribution of poem lengths in an online corpus of poetry. The results of the study made Griffith and Tenenbaum suggest that "people's judgements for . . . poem lengths . . . were indistinguishable from optimal Bayesian predictions based on the empirical prior distributions". However, Marcus and Davis (2013) see that the actual fit and the model was actually not in fact as close as the study had suggested, as "it requires no great knowledge of poetry to predict that a poem whose fifth line has been quoted must have at least five lines". The actual fit of the model was overestimated because of how priors were chosen.

Marcus and Davis (2013) conclude their criticism by arguing that probabilistic models such as the Bayesian approach have not yielded a robust account of cognition that would be applicable across tasks. Yet, they also see the Bayesian approach as a useful tool, albeit not one that one-size-fits-all solution.

Bayesian theories against traditional non-Bayesian approaches

While Marcus and Davis' (2013) challenge the robustness of the Bayesian approach and how models and tasks are selected, it does not contrast the probabilistic approach to other approaches of studying the brain and mind. How promising the Bayesian approach is when compared to more traditional non-Bayesian approaches to studying mind and brain is discussed in Bowers and Davis' 2012 paper.

Bower and Davis (2012) argue that the evidence supporting the Bayesian approach is rather weak, with proponents of the Bayesian approach having reached quite different conclusions on the basis of the same evidence. Similar to Marcus and Davis (2013), Bowers and Davis also see that the selection of priors and likelihoods can arbitrarily be altered to provide a better fit, providing an additional point that it makes Bayesian models difficult to falsify. The paper also argues that the Bayesian approach is too rarely compared to the non-Bayesian approaches, such as heuristic or adaptive theories of the mind. As the last major point of critique, Bowers and Davis argue that there is very little data for supporting the notion of collections of neurons performing Bayesian computations.

Bowers and Davis (2012) conclude their paper by arguing that it is not clear how the Bayesian approach provides additional insights into the nature of mind and brain when compared to non-Bayesian approaches. They instead see that the result of the Bayesian approach has been a collection of Bayesian just-so stories, in which mathematical analyses can be used to explain almost any behavior as optimal.

Criticism against Bayesian theorizing

Equally strong criticism has been raised on how Bayesian approaches are used to theorize in cognitive science. In their 2011 article, Jones and Love (2011) subdivide Bayesian theories into two philosophies: Bayesian fundamentalism and Bayesian enlightenment. Bayesian fundamentalism firmly clings to the principle that human behavior is explainable through rational analysis: once a given task is correctly reduced to environmental statistics and goals, human behavior in that task will be found to be rational. This approach places too much emphasis on the mathematical and computational power of probabilistic inference, without moving towards more substantial theoretical development (Jones and Love, 2011). According to Jones and Love (2011), most of the research surrounding the Bayesian approach falls into the category of Bayesian fundamentalism.

In contrast to Bayesian fundamentalism, Jones and Love's Bayesian enlightenment goes beyond the dogma of rational analysis, actively integrating with other avenues or inquiries in cognitive science (Jones and Love, 2011). They see this as an approach that does aim towards more substantial theoretical development.

Jones and Love's (2011) view the Enlightened Bayesian view as being capable of taking the more interesting aspect of the Bayesian approach; which include the algorithms by which inference is carried out and the representations on which those algorithms operate; seriously as psychological constructs and evaluate them according to theoretical merit rather than mathematical convenience. They conclude their criticism on Bayesian theorizing by predicting that the Bayesian approach has much to contribute as long as it is developed in a way that does not eliminate the psychology from psychological models.

Conclusion

The probabilistic approach to the brain can be seen as a widely applicable approach, but one of which research and results need further inspection and review, as can be concluded from the criticism reviewed in this paper. The criticism has primarily focused on how the selection of models and tasks has contributed to overpromising models. Another large part of criticism has been the subject of how Bayesian methods are used to theorize in cognitive science. Despite the reviewed criticisms, the Bayesian approach is seen as a promising approach, as long as the limitations of it are understood and it continues moving towards more substantial theoretical development.

References

• Battaglia, P. W., Hamrick, J. B., & Tenenbaum, J. B. (2013). Simulation as an engine of physical scene understanding. Proceedings of the National Academy of Sciences, 110(45), 18327–18.

• Bowers, J. S., & Davis, C. J. (2012). Bayesian just-so stories in psychology and neuroscience. Psychological Bulletin, 138(3), 389.

• Jones, M., & Love, B. C. (2011). Bayesian fundamentalism or enlightenment? On the explanatory status and theoretical contributions of Bayesian models of cognition. Behavioral and brain sciences, 34(4), 169.

• Griffiths, T. L., & Tenenbaum, J. B. (2006). Optimal predictions in everyday cognition. Psychological science, 17(9), 767–773.

• Marcus, G. F., & Davis, E. (2013). How robust are probabilistic models of higher-level cognition?. Psychological science, 24(12), 2351–2360.

This article is not however so much about the future of 3D, but instead about an interesting phenomenon in human perception caused by 3D displays called crosstalk. Many of us have most likely encountered crosstalk at least once in our lives, but due to the

Introduction – Crosstalk and Technological Context

Stereoscopic three-dimensional (3D) screens are generally better at creating a greater immersion with the displayed content, thus enabling richer experiences. The difference in immersion compared to more traditional two-dimensional screens (2D), comes with the help of binocular depth. However, 3D dimensional displays do not actually display content in three-dimensional space, but instead rely on to projection of different image to each of the eyes, they have a possible problem of inducing various visual artifacts that cause discomfort and degradation of the Quality of Experience. One of these visual artifacts is crosstalk, an effect caused by another eye’s half-stereoscopic image bleeding into the other eye. This paper will focus on explaining the causes of crosstalk and how the human visual system understands it by concentrating on literate regarding crosstalk. A couple of different technologies used to create three-dimensionality will be inspected on their relation to crosstalk and the other definitions of crosstalk. This article will also look at studies conducted on measuring crosstalk, the perceived experience of crosstalk on different people, and the different levels of crosstalk. I will conclude this essay by introducing methods and ways of combating crosstalk in 3D displays.

But what is crosstalk then, and what causes it? To understand crosstalk phenomena, we have to first understand how 3D videos are created and how they can be viewed on different display technologies. The basic structure of creating 3D video is to use two cameras when filming a scene either by using two real cameras or by using two artificial cameras, a standard method in digital animation. This leads to having two different recordings of the same scene, but from a slightly different angle. This is mostly the same as how human eyes work, we are actually seeing two different views of the same world, which are eventually combined into a single image through stereopsis. To create the illusion of two different views and the illusion of depth on a display, the display has to show different views on top of each other. The key technologies of 3D displays have to do with combating this problem.

Understanding the technologies used to achieve the 3D effect is vital as crosstalk differs between different technologies. The difference of crosstalk on different technologies is inspected more closely later; however, this is done to a limited degree. One of the most well known 3D technologies is called anaglyphic 3D, which uses color filters in displaying different view to each eye. The filtering is usually achieved by wearing a pair of glasses with red/green filters on them. Another similar but more widely used method is using polarized filters (polarization-multiplexing) to filter the correct image to each eye. This and the former are both method cheap and achievable with passive, no electricity using glasses. There are also active methods, such as using an eclipsing method of blocking the view of the other eye (time-multiplexing), and interference technology of displaying two different images with two different wavelengths of light. Worth mentioning is also the possibility of autostereoscopic displays, which enable stereoscopic viewing without glasses.

Definition of Crosstalk

Now that we understand the technological context, explanation of crosstalk is more tangible. Crosstalk is essentially produced by imperfect view separation, leading to a proportion of one eye’s image to be seen by the other eye as well (Xing 2012). This definition is good enough for communicating the general concept of crosstalk. However, for scientific conversation, it is much too ill-defined. In the following parts, the term and definition of crosstalk are subject to closer inspection.

Well known and widely used in the literature of stereoscopic displays, crosstalk as an effect is also known by other names and spellings (Woods 2011) such as cross talk, cross-talk, leakage, extinction, extinction ratio, 3D contrast, and even x-talk. In addition to these the term ‘ghosting’ is often used interchangeably, but according to Woods, the first separate definition for ghosting comes from Lipton in 1987 (Lipton 1987, Woods 2011). Lipton’s definition of ghosting and crosstalk are refined in a publication from 2009, where crosstalk is “incomplete isolation of the left and right image channels so that one leaks or bleed into the other” and ghosting is defined as being the subjective perception of crosstalk” (Lipton 2009). Woods also points out a definition made by Huang et al. in which System crosstalk describes crosstalk, while Viewer crosstalk is used to address the subjective experience of it, i.e. ghosting (Woods 2010).

To be used as a metric, crosstalk has to be defined mathematically. Woods et al. mention in their article that there exist two different mathematical definitions for ‘crosstalk ratio’ (Woods 2011). They also point out that unfortunately, there exist several papers quoting crosstalk values, without specifying which definition is used. This serves to strengthen the need for a standardized definition of crosstalk ratio.

Woods et al. define crosstalk in its simplest form as a function of leakage divided by signal multiplied by hundred (Woods 2011), illustrated in the formula below.

In this formula, leakage means the maximum luminance of light that leaks from the unintended channel to the intended channel, and signal means the maximum luminance of the intended channel. The measurements for luminance are achieved by measuring the level of black in the intended channel and the white in the unintended channel, which corresponds with leakage. In the same manner, signal correspondence is achieved by measuring the level of white in the intended channel and the level of black in the unintended channel.

Woods et al. also point out two other mathematical definitions, which agree with this basic definition; however, for the sake of this paper’ scope, those definitions are not presented here. These two definitions can be found from articles by Chu et al. and Hong et al. (Chu 2005, Hong 2010). However because the earlier mathematical description of does not take into consideration the effect of black level, Woods et al. introduce another mathematical definition where the non-zero black level is taken into account by subtracting the black level luminance, all illustrated below.

Technological Factors Affecting Crosstalk

Different 3D inducing technologies have different levels of crosstalk as crosstalk exists in almost all stereoscopic displays, an exception to this being the ones using Wheatstone and Helmholtz approach, which however do not conform to today’s requirement of flat-panel display and are therefore left out of the scope of this paper (Daly 2011). Nevertheless, crosstalk is a primary concern in developing stereoscopic display systems (Daly 2011).

One technology that is especially prone the crosstalk is anaglyphic 3D, whose main benefits are simplicity and cost. However, anaglyphic 3D’s main disadvantage in addition to crosstalk is its inability to depict full-color images (Woods 2004). Anaglyphic 3D systems are much rarer in these days, as active time- and polarization-multiplexed approaches tend to work better with lesser quality control. The level of filtering in anaglyphic 3D systems can vary considerably between different manufactured glasses, resulting in varying amounts of crosstalk (Woods 2004). Woods et al. list properties that cause crosstalk in the anaglyphic 3D system in their 2004 paper. These are:

• Display spectral response – crosstalk is caused by the display’s primary color band overlap with each other significantly, making it difficult to separate those colors with color filters.
• Anaglyph glasses spectral response – crosstalk is caused by color filters of the anaglyph glasses pass light that is from an undesired domain, for example when passing also higher wavelength light.
• Image compression – crosstalk is caused by image compression formats (e.g. MPEG, JPEG) mixing information between the three RGB color channels.
• Image encoding and transmission – crosstalk is caused by analog consumer video formats (NTSC, PAL) mixing RGB colors channels during encoding.

Crosstalk is also present in other technologies. For example Lipton’s 1987 paper names two crosstalk factors for time-multiplexed stereoscopic systems, which are phosphor decay and the dynamic range of the shutters (Lipton 1987). Phosphor decay is an effect of phosphor after-image in liquid crystal based shutter glasses, this is common with many CRT based displays, where the image generation results in still decaying phosphor projection to leak into the other eye’s view. Another crosstalk factor, according to Lipton is the dynamic range of the glasses, meaning the ratio of the transmission of the glasses’ shutters in their opened state to their closed state. Problems with a dynamic range of shutters lead to wrong image being displayed for the wrong eye (Seuntiëns 2005).

In addition to the presented technologies, there are also other 3D technologies, where crosstalk exist. Similarly to anaglyphic and polarized 3D technologies, there are different factors between the technologies that have an effect on the amount of crosstalk. As a conclusion, it could be said that when designing a 3D technology-enabled experiences a decent amount of research should be dedicated to understanding the factors affecting the amount of crosstalk on that current approach. This statement is further strengthened by a statement found in 3D literature of that crosstalk is intrinsic to most of the technologies (Seuntiëns 2005).

Crosstalk’s Effect on Viewer Experience and Perception

The presence of crosstalk can lead to several problems such as general annoyance, visual discomfort, hindrance of fusing the images together, and breakdown of stereoscopic depth (Daly 2011, Woods 2004). Crosstalk is even considered to be one of the most annoying distortions in the visualization stage of stereoscopic imaging systems (Xing 2012, Seuntiëns 2005). At best, crosstalk is perceivable as a faint halo surrounding the edges of objects (Daly 2011) and at worst it contains all of the previously mentioned problems.

The amount of crosstalk is dependant on disparity and amplitude, with high levels resulting in ghosting (Daly 2011). According to Daly et al with small disparities and low amplitudes, such as in textures, crosstalk is perceivable only as a blur. With moderate amplitudes and disparities, crosstalk appears as tolerable double edges, while higher amplitudes can lead it to be displayed as an annoying ghost image. With even higher levels the double image disturbs stereoscopic fusion and prevents depth effect. Daly et al also point out other viewer experience such as general annoyance and discomfort, which can exist along with ghosting.

Another description of the effect on viewer experience can be found from a paper by Xing et al (Xing 2011). They also claim that comparatively few research efforts have been dedicated to this subject. Their paper does indeed describe an extensive study on the subjective experience of crosstalk. The described study investigated how much crosstalk can be perceived when it is visible. Additionally, this investigation focused on more realistic scenarios where natural scenes varying in crosstalk levels affect the perceptual attributes of crosstalk. This study led to finding three perceptual attributes of crosstalk, which can be categorized to 2D perceptual attributes that exist in a single eye view, and 3D perceptual attributes that exist once the view has been fused. Two of the attributes shadow degree of crosstalk and separation distance of crosstalk belong to 2D perceptual attributes while 3D attributes consist of spatial position.

Xing et al define Shadows degree of crosstalk as the distinctness of crosstalk when compared to the original view. The way it affects crosstalk is that when the level of shadow degree of crosstalk rises, the amount of crosstalk is experienced as more annoying. Xing et al. point out that the contrast of the scene content relates to the shadow degree of crosstalk. Another 2D perceptual attribute that they define is the separation distance of crosstalk, meaning the distance of crosstalk from the original view. According to the paper, crosstalk is experienced as being more annoying with increased separation distance. In addition to the 2D perceptual attributes, which also interact mutually, Xing et al list also one 3D perceptual attribute, spatial position. The spatial position is defined as the impact of crosstalk position in the 3D space on perception when the left and right views are fused and 3D perception is generated (Xing 2011). It is also heavily related to the two earlier mentioned 2D perceptual attributes, having an impact only on the visible crosstalk satisfying requirements of shadow degree and separation distance.

Crosstalk also affects the perceived depth in thin structures and in natural scenes (Tsirlin 2010, Tsirlin 2012). In a paper by Tsirlin et al published in 2010, they demonstrate that as the level of crosstalk increases the magnitude of perceived depth decreases. They also define a maximum level of crosstalk at 4%, at which the perceived depth and visual comfort are at suitable levels. These findings are backed supported by their 2012 paper, in which they assign the 4% level to synthetic images and a lower 2% level for natural images, resulting from crosstalk having a more disruptive effect on natural scenes.

As a conclusion to the subject of crosstalk’s effect on viewer experience, it can be argued that the effects are multiple and that there is also a connection between many of them, as demonstrated by Xing et al (Xing et al 2011). What comes to the level of crosstalk in the 3D system, 4 percentage seems to be the optimal according to Tsirlin et al, but there are also different views as Woods et al make a note of (Woods 2010).

Studying and Measuring Crosstalk

In order or to measure and conduct studies on crosstalk, a crosstalk-free technology has to be used. Earlier mentioned Wheatstone and Helmholtz approach is capable of reaching zero percent level of crosstalk and is therefore often used in crosstalk studies. Often the crosstalk effect is created digitally in this case, which allows the amount of crosstalk to be adjusted by the experimenter quite easily.

Crosstalk can be measured with optical sensors and with the use of visual measurement charts (Woods 2010). In the case of optical sensors, consideration has to be given to how well the sensor’s spectral sensitivity matches that of an eye. Traditionally the measurements are made by measuring the leakage between opposing channels when full-white is projected to the other one and full-black to the other one. This particular metric can be called black-and-white crosstalk and is often used, as it works with the crosstalk formulas described earlier. A variation of this metric is called grey-to-grey crosstalk, which is directed towards crosstalk measurement in time-sequential 3D systems, as crosstalk occurs differently in them. The basic method of this metric consists of measuring multiple grey level combinations and analyzing them.

While the optical sensor method is not necessarily a slow measuring method, a quicker way is to do the measuring with visual measurement charts. However, as this method is based on subjective evaluation there is a greater chance of error than when using sensors (Woods 2010). In addition to this, this measurement has also other limitations, for example, a requirement for calibration with correct gamma sensor, potential differentiation in crosstalk levels in the different parts of the screen, and chart not accounting the non-zero black level of some monitors.

Counteracting Crosstalk

The complete elimination of crosstalk is difficult, and methods that are close to succeeding in this are rarely compact (see Wheatstone & Helmholtz method) (Daly 2011). The methods for counteracting crosstalk are many, starting from enhancing the quality and build of 3D viewing hardware and ending in software-based compensation algorithms. This is a consequence of crosstalk being a sum of many factors. However, it must also be taken into consideration every cost and benefit trade-offs have to be done in order to reduce crosstalk with this method (Woods 2010).

Various signal-processing techniques are being developed, and have proven particularly valuable in hardware approaches using synchronized, alternating viewpoints (Daly 2011). Methods using liquid crystal displays, for example, can be improved with overdrive algorithms. Another algorithm method is known as L-R matrix compensation, which aims to anticipate and remove the ghost images from the images sent to the screen. This way the unwanted crosstalk signal, which is a result of the display process, is pre-subtracted from the digital image. Former method does not, however, work well when crosstalk is caused by high enough contrast. This will cause the subtraction to go negative, which will be impossible for the physical display to achieve, resulting in incomplete crosstalk correction.

Additionally to the algorithmic approach, one could also decrease the level of crosstalk by reducing the contrast ratio of the image, or even the display. Reducing the brightness of the display used for showing the 3D images would also be beneficial (Woods 2010). However would also result in reduced image quality, and for example, in the case of polarized glasses, the end quality could be questionable. This highlights the problem of multiple different technologies – a universal solution to counteracting crosstalk possibly impossible.

Conclusion

This essay has reviewed some of the scientific literature found on the crosstalk effect. The main foci of the paper have been on defining the concept of crosstalk, its relation to different stereoscopic technologies, its relation to the viewer experience, and the ways of counteracting it. In addition to the former, the essay has also briefly highlighted the technological aspects related to crosstalk. This paper cannot be described as a thorough inspection of the crosstalk phenomena but mainly an introduction to it. In order to achieve a more thorough look at the crosstalk phenomena, the essay should be narrowed down t a single stereoscopic imaging technology. This can be also said to be one of the essay’s shortcomings, as there exists a slight change of some of the technologies related to crosstalk getting confused due to the relatively light introduction to stereoscopic technologies.

This essay’s structure has been more akin to a scientific paper than one of an essay. Therefore there has been a relatively little reflection on the subject, and the focus has been mainly on presenting the knowledge found in the literature. However, I personally feel that traditional reflective essay, would not have worked in this case, as many of the subject’s properties are more a matter of fact that a subject of discussion. Another remark I want to make is that the amount of background material is quite small, and there was a noticeable problem of finding related literature that fit the scope of the essay. This can be due to having quite limited knowledge about the context, as the subject itself is relatively well researched.

Exactly what counts as a touchpoint depends on the literature you read. Definitions vary across service design, marketing, branding, and CRM. This article reviews those definitions, highlights where they overlap, and explores how touchpoints are used in service design practice today.

Introduction

A common definition is that touchpoints are the moments of contact between a customer and a service provider—specific places and times where a customer’s need is addressed ¹. Another interpretation is that touchpoints are the elements that make a service experienceable and help build the service’s brand ².

Both definitions highlight very different aspects of touchpoints, and this variety reflects a broader issue: the term has no universally accepted meaning. This creates problems for both research and practice. When designers reference “touchpoints” without a clear shared definition, misunderstandings are easy, and design approaches may become too narrow or inconsistent.

Touchpoints are considered one of the central aspects of service design because they highlight key differences between products and services ^{3 1 4}. Yet despite their centrality, the concept remains abstract. This article examines how touchpoints are defined in different literatures, then focuses on how service design tools use the concept in practice.

Origin of the Word

The term touchpoint appears in several disciplines, and its exact origin in service design is unclear. Early uses can be found in branding and trade publications in the early 1990s, where it referred to moments of contact between a customer and a company (Howard 2007). These early definitions resemble the ones used in service design today, though they weren’t identical.

Before “touchpoint” entered service design, similar concepts already existed:

• Service evidence — the physical elements of a service ⁵
• Service encounter — the interactions between customer and provider ⁶

Other related terms include moment of truth, contact point, point of contact, and customer contact ^{3 7}.

Touchpoints vs. channels

In CRM literature, “touchpoints” and “touch-points” appear frequently, but the field often talks more about multi-channel delivery ^{3 8}. The important distinction is:

• A channel is broad (e.g., “Twitter”, “in-store”, “email”).
• A touchpoint is the specific expression of that channel (e.g., a company’s Twitter account, a store kiosk).

Chris Risdon explains this clearly:

“A single touchpoint — a customer getting their rental car — but a concert of channels: physical retail space, video with remote agent, touchscreen kiosk interface.” ¹

Other uses

Clatworthy notes that the term “emotional touchpoint” is also used in medical research, where it serves as a tool for gathering patient experience data ³. Although the domain differs, the idea—highlighting emotionally significant moments in a journey—aligns closely with service design.

Across all these fields, the term is used in slightly different ways, which helps explain why no unified definition exists.

Touchpoints in Service Design Literature

Instead of trying to create a cross-disciplinary definition, a more useful approach is to focus on how service design research itself treats touchpoints. This helps reveal the practical and conceptual challenges caused by inconsistent definitions.

AT-ONE and Cross-disciplinary Process

The AT-ONE project is a service design research initiative aimed at supporting cross-functional teams in the early stages of service development ³. Touchpoints are so central to the project that the “T” in AT-ONE stands for them.

The project includes touchpoint workshops and a card-based tool with three main functions:

A. Team building

1. Build shared understanding of touchpoints
2. Strengthen cross-disciplinary collaboration

B. Analysis and mapping

1. Identify all touchpoints in a customer journey
2. Highlight critical touchpoints
3. Understand each touchpoint’s constraints and possibilities
4. Identify ownership and responsibilities

C. Idea generation

1. Explore new touchpoint ideas or redesign existing ones

A challenge noted in the research is that touchpoints are often referenced through examples rather than definitions. For instance, an iPad is listed as a touchpoint in the card set. But an iPad alone does not constitute a touchpoint unless it’s tied to a service interaction. This ambiguity illustrates how difficult it is to define touchpoints without context.

Sequencing and Mapping Through Touchpoints

Stickdorn and Schneider’s This Is Service Design Thinking distinguishes between touchpoints and interactions, which together form “service moments” ⁹. Touchpoints can occur between:

• human and human
• human and machine
• machine and machine

The last category is not intuitive from a customer perspective, but machine-to-machine interaction can shape the service experience. For example, a health app may send data to a medical provider behind the scenes. The customer might not realize this is a touchpoint, but it still influences the service.

Stickdorn argues that touchpoints are essential for:

Sequencing

Touchpoints structure the phases of a customer journey. They provide the backbone for tools such as service blueprints, journey maps, and service experience blueprints (SEBs) ^{10 11}.

Evidencing

Touchpoints make invisible service processes tangible. This helps customers understand what’s happening behind the scenes and strengthens the perceived value of the service.

These ideas align with the work of Bitner, Clatworthy, Patricio, Risdon, Shostack, and others, who all highlight the role of touchpoints in making services concrete and comprehensible.

Conclusion

There is no single, definitive definition of “touchpoint” in service design. Given the field’s multidisciplinary origins, this isn’t surprising. As service design matures, the terminology will likely settle into more widely shared meanings.

Even without a universal definition, certain characteristics repeatedly appear across the literature:

• Materiality and tangibility — Touchpoints often involve physical or digital artifacts that make the service real.
• Interactivity — Touchpoints involve actions or exchanges.
• Context-dependence — Their meaning depends on the situation and channel.
• Sequencing — They structure the customer journey.
• Evidencing — They reveal otherwise invisible aspects of the service.

Touchpoints may never have a perfectly clean definition, and perhaps they don’t need one. What matters is understanding how they function in service experiences and using them deliberately to create coherent, meaningful journeys.

References

Hackathons have changed over the past years, and they are no longer pure 24h+ coding sprints. Of course, coding still plays a large role in hackathons, and nicely coded things are still highly regarded. But nowadays, the service concept behind the hackathon project, the design of the service, and the business model also play key roles. Service-designed solutions in hackathons are now more common than ever. But what is service design, and how do you design a service in a hackathon?

I decided to put together a small guide on how to do successful service design in a hackathon and create a good concept (service idea). My method focuses heavily on the problem-solving aspect of it all because all good services and products always solve a customer’s problem. The following process is based on how I've done things in hackathons, and it has proven to be very successful in a variety of hackathons.

Choose Whose Problems You Are Solving

“We want to make things easier for elderly people.”

Before rushing into the problem, it is best to choose whose problems your service is going to solve—the targeted customer group of the service. This helps in narrowing down the problem and makes it easier to develop the service concept for the problem. It’s best to settle on a target group even if you have already come up with a problem you are going to solve.

There are multiple ways of finding a suitable target group, and they could easily warrant a separate article. One easy way to pick a target group is to pick one you yourself are part of, e.g., student, elderly person, etc., and develop that into a persona. Using yourself as a model of a potential customer is heavily biased and can lead to false assumptions, for example, about the customer’s capabilities. In the context of hackathons, this is, however, not that critical. If you want to avoid this and do things in a bit harder way, you can focus on a group of people you are not familiar with and do research on them. Pick, for example, city planners and interview them in order to understand their problems (this is what we did in one hackathon).

Find a Problem to Solve

“We plan to make commuting easier for elderly people.”

After you have settled on the target group, it’s time to find out their biggest problem by either observing their behavior in context or interviewing them. If you’re using yourself, think about the problems you’re facing daily. What problems do you face daily? Is there perhaps something that takes a considerably large amount of your time, money, or other resources? In what context does this usually happen? The context in this case could be, for example, commuting.

The best option is to pick one concrete and recognizable problem that is solvable within the hackathon’s time frame. If your target group is, for example, the aforementioned elderly people, and their context is commuting, the problem you’re trying to solve could be, for example, how commuting could be made easier for elderly people. When formatted as a problem statement: “How to make commuting easier for elderly people.”

How Does Your Service Solve the Problem?

“We plan to make a crowdsourced helpline for elderly people that makes their commuting easier.”

After finding and understanding the problem, it’s time to come up with a solution to it. Now, I can’t give any specific tools for coming up with solutions, but I’ve personally found that brainstorming is a good method to start with. The most important thing in coming up with the solution is to make it simple and doable in a hackathon. The solution should also be quick and easy to comprehend. In hackathons, you have to pitch your idea, usually in under three minutes. During this time, you have to describe the problem, who it affects, how you have solved the problem, and how your solution works. Therefore, a simple service solution is often better than a complicated one in a hackathon.

You should try to fit your service solution into one sentence, which should describe the problem, your target group, and your solution to it. To give an example, we can use the elderly people again. One way to solve their problems in commuting could be, for example, a crowdsourced helpline where the elderly can call and receive instructions on commuting. When put in one sentence: “We plan to make a crowdsourced mobile helpline for elderly people that makes their commuting easier.”

How Does Your Solution Work?

Customers, customers’ problem, solution to the problem → the service built around these that works like this.

Service is always a combination of multiple different pieces, where the problem and the solution are forces tying everything together. In hackathons, you rarely have time to think about the whole service structure, but you do have enough time to make a light customer journey. The customer journey, in this case, means a description of how the customer finds the service, how the service solves the problem the customer is facing, what is the role of the service after this, and how the service is different from others, for example.

Creating a customer journey is a rather broad task that brings out the benefits of a multidisciplinary team. Creating a simple but easily understandable customer journey is a lot easier with a versatile team.

In addition, it might also be beneficial to come up with a business plan for the hackathon concept, as that is also usually used as a way to evaluate the team’s idea.

Conclusion

With these instructions, it is possible to create a winning hackathon service concept. It should, however, be noted that a concept by itself is rarely enough and should be accompanied by a demo that demonstrates key elements of the service. Creating the service concept and a technical demo of it has to be done in parallel, which makes hackathon concepts with both a good service concept and a cool demo a rare sight. These are, however, often the solutions that end up winning.

If you want to check whether another iOS app is installed from your SwiftUI app, use UIApplication.shared.canOpenURL() with the target app's URL scheme. You must declare the schemes you want to query in your Info.plist under LSApplicationQueriesSchemes. This article shows you exactly how to set it up.

I'm building a companion app for Flighty in SwiftUI, and I wanted to detect whether Flighty app was already installed on the user’s device, in order to ask them to open it and export their flight data. I have written instructions how to do this in the app's onboarding, but providing a direct link to the app provides a way smoother UX. Since Flighty itself isn’t my app, I need to

If Flighty is installed, I can show a shortcut that opens it directly. If it isn’t, that option stays hidden.

The basic idea

iOS allows apps to check whether another app is installed by asking the system if it can open a specific URL scheme.

There are some important constraints:

• You must declare the URL schemes you want to query in Info.plist
• Apple expects you to have a legitimate reason for checking
• Querying lots of unrelated apps can lead to App Review questions

Used carefully, this is a supported and documented approach.

Step 1: Identify the app’s URL scheme

Many apps expose a custom URL scheme, either publicly documented or discoverable through testing. Flighty exposes the flighty:// scheme, which makes this possible. If you write that in your browser and press enter, it should prompt to open Flighty. On iOS you can then call the scheme with canOpenURL to see if the app is installed – as long as you've registered the scheme in your app first.

Step 2: Register the scheme in Info.plist

You must explicitly add this scheme to your apps' Info.plist file, using Queried URL Schemes (key is LSApplicationQueriesSchemes). You can do this either through Xcode or by editing the Info.plist directly.

In Xcode navigate to Targets → You app name → Info tab → Custom iOS Target Properties:

Alternatively, editing Info.plist directly, add this:

<key>LSApplicationQueriesSchemes</key>
<array>
    <string>flighty</string>
</array>

This flags tells iOS that your app is allowed to ask whether flighty:// can be opened. Without this, canOpenURL will always return false.

Step 3: Check if the app is installed

With the scheme registered, the runtime check is simple. Here’s the property I use in my SwiftUI app:

private var isFlightyInstalled: Bool {
    guard let url = URL(string: "flighty://") else { return false }
    return UIApplication.shared.canOpenURL(url)
}

If this returns true, the app is installed on the device. I use this in my app to conditionally render UI, showing a button that opens Flighty only when it’s actually available.

Opening the other app

Once you know the app is installed, opening it is straightforward:

private func openFlighty() {
    if let url = URL(string: "flighty://") {
        UIApplication.shared.open(url)
    }
}

A note on privacy and App Review

You should be careful when checking for other apps, there used to be no limitations on this but some ad SDK apparently abused this method. But if you're doing it for a legitimate purpose, Apple is generally fine with this pattern when:

• The integration is clear and user-facing
• You only query the specific app you integrate with
• You’re transparent about what you’re doing

Be explicit in your App Review notes and privacy policy about why you check for the other app. The goal here is user convenience, not tracking.

Final thoughts

This is a small feature, but it can make a big difference in the user experience. I like these kinds of UX "hacks", that you most likely won't even pay that much attention to, but which just make the life of the user a tiny bit easier when interacting with your app.

Related articles

• React Native in-app purchases guide - Monetize your iOS and Android apps
• App release checklist - Don't forget these before shipping

If you're seeing flickering, layout shifts, or scroll position resets when using React Query with FlatList in React Native, it's usually caused by conditionally replacing the entire screen based on loading state. The fix is to always render the FlatList and use ListEmptyComponent for loading and empty states.

This article explains why it happens and how to fix it properly.

React query pairs incredibly well with FlatList (and FlashList, and LegendList, if you prefer to use those). You get fast, predictable data fetching combined with efficient virtualized rendering. The challenge is keeping the UI stable while handling loading, empty states, refetches, skeletons, and safe area adjustments. Unfortunately LLMs seems to be always giving worst possible options for handling all of these.

Avoid conditionally replacing the entire screen

A common bad patterns is to conditionally replace the entire screen based on the query state. For example, rendering a loading spinner during the initial fetch, then rendering an empty state if no data exists, and only rendering the list once real items arrive. This creates three separate component trees for the same screen and forces React to constantly mount and unmount the scroll container. The result is flickering, layout shifts, and scroll position resets.

A better approach is to always render the list component and use ListEmptyComponent to show whatever should appear when the list has no rows. This keeps the list mounted from the moment the screen appears and makes transitions between states much smoother.

Here's an example of what to avoid:

if (isLoading) {
  return <LoadingSpinner />;
}

if (!data?.length) {
  return <EmptyState />;
}

return (
  <FlatList
    data={data}
    renderItem={renderItem}
  />
);

And here's the correct approach:

const { data, isLoading, isError } = useQuery({
  queryKey: ["items"],
  queryFn: fetchItems,
});

return (
  <FlatList
    data={data ?? []}
    renderItem={renderItem}
    ListEmptyComponent={
      <EmptyState
        isLoading={isLoading}
        isError={isError}
      />
    }
  />
);

This is better because if data is undefined, the list will render the EmptyState component, but the actual list element won't be unmounted when data is gone. This pattern works for FlatList, FlashList, and LegendList because all three support an equivalent empty state component. You can use the the same EmptyState component to display both loading data, error states, and the actual empty state. This component is also a prime place to put a retry button.

List should be the single scroll container for the screen

Another important rule is that the list should be the single scroll container for the screen. That means header content, filters, and summary sections should live inside ListHeaderComponent, not above the list in a parent view. When they're above they don't scroll so don't do it (unless that's the behavior you want). Don't nest a FlatList inside a ScrollView either.

Example of the broken pattern:

return (
  <View style={{ flex: 1 }}>
    <Header />
    <Filters />
    <FlatList data={items} renderItem={renderItem} />
  </View>
);

Instead make use of the ListHeaderComponent to render everything you want to show above the scroll container, but that still needs to scroll. Similarly use the ListFooterComponent for everything that should go under the list elements. Keep in mind that these elements will be rendered always, even if the data array is empty, so make use that your ListEmptyComponent

Correct version:

const ListHeader = () => (
  <>
    <Header />
    <Filters />
    <Summary />
  </>
);

<FlashList
  data={items}
  renderItem={renderItem}
  ListHeaderComponent={<ListHeader />}
/>;

FlatList should be the top level component of the screen

FlatList should also be the top level component of the screen. I've seen a lot of people wrap this list in a parent container such as a View with flex set to one. Same goes for AI assisted coding with LLMS pushing the same element. ScrollViews have props for styling the containers so you don't need any other views around the list component itself.

Problematic example:

<View style={{ flex: 1 }}>
  <FlatList data={items} renderItem={renderItem} />
</View>

Correct approach:

<FlatList
  data={items}
  renderItem={renderItem}
  contentInsetAdjustmentBehavior="automatic"
/>

By setting contentInsetAdjustmentBehavior to automatic when the list is the root component, the system applies correct safe area spacing at the top and bottom. This ensures consistent behavior across devices and navigation setups without extra layout hacks.

React query has different states such as isLoading, isRefetching, isError, and success. None of these should cause you to remove or replace the list. Instead, integrate them into the list itself. isLoading and empty states should be represented through ListEmptyComponent. isRefetching should trigger a subtle inline indicator, such as a pull to refresh spinner or a small header badge, rather than replacing the visible content.

Skeleton placeholders make the loading experience feel even more immediate. Instead of a blank screen or large spinner, create a small set of placeholder rows and pass them to the list whenever the initial load has not completed. The list will render items instantly and the user will see the structure of the content even if the actual data is not available to use yet.

Skeleton placeholder array:

const SKELETON_ITEMS = Array.from({ length: 10 }).map((_, index) => ({
  id: `skeleton-${index}`,
  isSkeleton: true,
}));

Using skeletons during initial load:

const items = isLoading && !data
  ? SKELETON_ITEMS
  : data ?? [];

Then in renderItem:

const renderItem = ({ item }) => {
  if (item.isSkeleton) {
    return <MySkeletonItem />;
  }

  return <MyItem item={item} />;
};

Co-locate component and skeleton component

The final key practice is to co-locate skeleton item components with their real counterparts. The skeleton layout should mirror the real layout exactly, including containers, spacing, and alignment. Only the content should differ. If the two components drift apart in your codebase, layout inconsistencies will appear.

Example of paired components that share structure:

const MyItemLayout = ({ left, title, subtitle }) => (
  <View style={styles.container}>
    {left}
    <View style={styles.textContainer}>
      {title}
      {subtitle}
    </View>
  </View>
);

const MyItem = ({ item }) => (
  <MyItemLayout
    left={<Avatar uri={item.avatarUrl} />}
    title={<Text style={styles.title}>{item.title}</Text>}
    subtitle={<Text style={styles.subtitle}>{item.subtitle}</Text>}
  />
);

const MySkeletonItem = () => (
  <MyItemLayout
    left={<SkeletonCircle size={40} />}
    title={<SkeletonLine width="60%" />}
    subtitle={<SkeletonLine width="40%" />}
  />
);

I find it easier to reason over skeleton layouts when they are located in the same component as the component they are "skeletoning".

Here's a complete example of everything put together using FlatList, although the same structure works for FlashList and LegendList.

const SKELETON_ITEMS = Array.from({ length: 8 }).map((_, index) => ({
  id: `skeleton-${index}`,
  isSkeleton: true,
}));

export const ItemsScreen = () => {
  const { data, isLoading, isError, isFetching, refetch } = useQuery({
    queryKey: ["items"],
    queryFn: fetchItems,
  });

  const items = isLoading && !data
    ? SKELETON_ITEMS
    : data ?? [];

  const renderItem = ({ item }) =>
    item.isSkeleton ? (
      <MySkeletonItem />
    ) : (
      <MyItem item={item} />
    );

  return (
    <FlashList
      data={items}
      renderItem={renderItem}
      keyExtractor={item => item.id}
      estimatedItemSize={80}
      contentInsetAdjustmentBehavior="automatic"
      ListHeaderComponent={
        <ListHeader
          isFetching={isFetching}
          onRefresh={refetch}
        />
      }
      ListEmptyComponent={
        <EmptyState
          isLoading={isLoading}
          isError={isError}
          onRetry={refetch}
        />
      }
      onRefresh={refetch}
      refreshing={isFetching && !isLoading}
    />
  );
};

Recap

Recapping:

• Always keep the list mounted and show empty or loading states inside ListEmptyComponent.
• Put all header related UI inside ListHeaderComponent so everything scrolls together.
• Make FlatList or FlashList the top level component on the screen.
• Always set contentInsetAdjustmentBehavior to automatic on the list when it is the root.
• Use skeleton placeholder items when data has not arrived yet.
• Co-locate skeleton and real list item layouts so they always stay aligned.

Following these gives you consistent behavior, when using FlatList, FlashList, or LegendList.

Related articles

• Fix "VirtualizedList should never be nested" in React Native - Another common FlatList issue and how to solve it
• React Native in-app purchases guide - Learn how to monetize your React Native app
• All React Native guides - More tutorials and best practices

The year in flights

2025 started slow. January through March were mostly grounded — a deliberate choice after a hectic end to 2024. The first flights of the year were to Krakow for a quick work trip, followed by a longer stay in Germany.

Spring brought the conference season. App.js in Krakow was the highlight — a chance to catch up with the React Native community and see what's new in the ecosystem. From there it was straight to the US: first to Salt Lake City, then San Francisco, then Las Vegas for various events.

The summer was split between Finland and Japan. Two weeks in Tokyo and Osaka in June were the longest vacation of the year. The rest of the summer was quieter — mostly working from Helsinki with a few hops to Amsterdam.

Fall picked up again with more US travel. The East Coast this time: New York and Dallas for work, then back to Europe. The year wound down with a quiet December in Finland, punctuated by one last trip to Munich.

Patterns

Looking at the monthly breakdown, the busiest months were May and October — both conference-heavy periods. The quietest were January, February, and December. That tracks with my energy levels: I tend to hibernate in winter and travel more when the days are longer.

The "Airplane" category in the location chart represents actual time in the air. At around 145 hours, that's roughly six full days of my year spent at 35,000 feet. Add in airport time, security, and transit, and the real number is probably closer to 15-20 days of travel logistics.

Looking ahead

For 2026, I'm aiming to travel more intentionally. Fewer short trips, more longer stays. The environmental cost of flying is hard to ignore, and the productivity hit from constant timezone changes is real. But conferences remain valuable — there's no substitute for in-person conversations with people building things you care about.

The data comes from Flighty's export feature, processed with some custom code to calculate time spent in each country. If you're curious about the implementation, the source is available in this site's GitHub repository.

Every day we make decisions guided by our aesthetic preferences (Palmer, 2013). For example, we may end up buying artworks for our homes based on the aesthetic experiences they evoke, not because they provide us with utility in some other way. The influence of aesthetics on our information processing and decision-making is strong and multifaceted, as illustrated well by the design of many consumer products. Aesthetically pleasing products sell better than comparable products with better features (Tractinsky, 1997; Creusen, 2005). We also evaluate other attributes through the lens of aesthetics. For instance, we perceive user interfaces as more usable when they are visually pleasing (Sonderegger, 2010; Tractinsky, 1997). Examining this aesthetic experience and the factors behind visual aesthetics is the focus of this thesis. The topic is narrowed by focusing on the best-known model of visual aesthetics: the golden ratio, and its use in designing digital user interfaces.

User interfaces belong strongly to research in human–computer interaction. Often, the focus is on factors responsible for interface efficiency, such as errors, comprehensibility, learning, and performance over time (Michailidou, 2008; Tractinsky, 2003). However, interface research focused solely on usability and efficiency has over the years made room for the study of aesthetic properties as well. Still, the focus has often been on how aesthetics influences other evaluation metrics of the interface. The study of the factors that define interface aesthetics has remained limited (Tractinsky, 2003). Studies such as how visually pleasing interfaces provide subjectively better usability strongly exemplify this prevailing approach (Michailidou, 2008). Although such research argues strongly for the importance of aesthetic experience in human information processing, research into the determinants of aesthetics has not, at least so far, attracted great interest among researchers (Palmer, 2013). One reason is the difficulty of operationalizing aesthetics and its strong subjectivity—defining clear measures of aesthetics has so far not succeeded, and the generalizability of results has been low. In addition, in studies evaluating the aesthetics of user interfaces, the methods assumed to be responsible for aesthetics are often defined ad hoc, often only loosely grounded in earlier theories of aesthetics (Karvonen, 2000).

This thesis reviews research that engages with the study of aesthetic experience, touching on the challenges of studying aesthetics and applying findings in practice. First, it examines aesthetics and the definition of aesthetic experience, topics studied especially in philosophy. Next, the thesis presents the model of the golden ratio and research concerning it. The thesis considers aesthetics only from the perspective of visual aesthetics, narrowing the scope to the effect of composition (i.e., arrangement). The simplicity of the golden ratio and its applicability to assessing the relationships and placement of interface elements make it a relevant topic. Its long history—for example in art—and early research also make the golden ratio a worthwhile model of aesthetic experience to examine. Finally, the thesis discusses the golden ratio through models of aesthetic experience in user interfaces.

2. Aesthetics as a science and the definition of aesthetic experience

Research on aesthetic preference is one of the oldest topics in psychology, with Gustav Fechner often seen as its pioneer (Philips, 2010). Fechner's aesthetic experiments conducted in the late 19th century are also considered among the first in experimental psychology. After Fechner, however, research on aesthetic experience and aesthetics in psychology decreased significantly (Palmer, 2013). Before Fechner's experimental work, aesthetics had been studied in philosophy, where it is defined as "the study of the relationship between the human mind and emotions and the perception of beauty" (Liu, 2003; Palmer 2013). Although aesthetics is generally defined as a branch of philosophy that studies values of beauty, the study of experienced beauty has been strongly linked to art and the relationship between humans and art (Palmer, 2012). Such a boundary creates problems when examining aesthetic experience in contexts where the sources of aesthetic experience are not unambiguously stimuli defined as art. Another problem is defining beauty. Palmer notes that definitions of aesthetics rely on an abstract understanding of the concept "perceiving beauty." Aesthetics then becomes based on immeasurable qualia and is therefore difficult to operationalize.

Partly due to this vague definition, there are significant differences in aesthetics research across disciplines. Recently, due both to this cross-disciplinary tension and to the partial exclusion of experimental methods, there has been an effort to redefine aesthetics in psychological research. This has taken place as part of the emergence of a new "interdisciplinary aesthetic science" (Shimamura, 2012; Palmer, 2013). Shimamura and Palmer's foundations for aesthetic science are set out in a 2013 work that brings together practitioners of aesthetics, neuroscience, and psychology, aiming to integrate findings across these fields about aesthetics. The aim is especially to build a deeper understanding of aesthetics than before.

A newer, more comprehensive definition of aesthetics and aesthetic experience is thus offered through aesthetic science. According to Shimamura, the term should be broadened to include all "hedonic reactions" to sensory experiences while severing ties to art (Shimamura, 2012). In this definition, a hedonic reaction refers to an individual's preference-based judgment of aesthetics: one likes or does not like an object. Such a broad definition makes it possible to expand the research questions of aesthetics to a wider set of methods than before. In this thesis, aesthetics and aesthetic experience are therefore treated in line with Shimamura and Palmer's definitions within aesthetic science. Aesthetic science makes it possible to extend aesthetics to more targets than before, such as user interfaces (Shimamura, 2012; Weed, 2013).

3. Theories of visual aesthetics

Visual perception can be examined—both from neural and cognitive perspectives—as a combination of top-down and bottom-up information-processing processes (Shimamura, 2012; Liu, 2003). In bottom-up processes, lower-level processing proceeds from brain areas responsible for low-level perception toward higher-level brain areas responsible for processing sensory information. In aesthetics research specifically, Fechner's experiments on preferences for basic shapes and colors can be seen as emphasizing bottom-up processes. Fechner's aim was to form an understanding of the relationship between the visual properties of form and aesthetic experience (Philips, 2010; Shimamura, 2012; Liu, 2003).

A criticism of bottom-up processing in aesthetics is that an aesthetic response to a complex object, such as a work of art, is not merely the sum of its parts (Liu, 2003). In the opposing view—top-down processing—higher-level processes, such as memory, influence lower-level processing. An example is recognizing objects based on prior knowledge. While Fechner can be viewed as an example of a supporter of bottom-up processes, early 20th-century Gestalt psychology can be seen as an alternative supporting a top-down view (Shimamura, 2012). According to three German psychologists representing this tradition—Max Wertheimer, Kurt Koffka, and Wolfgang Köhler—visual perception could not be understood through a purely atomistic approach; rather, a holistic understanding of the organization of elements was necessary to construct visual perception.

Aesthetic experience cannot be said to be primarily composed of any single factor, nor is it possible to clearly limit its processing to purely bottom-up or purely top-down mechanisms (Liu, 2003). The list of theories describing the emergence of aesthetic experience is extensive, covering, for example, evolutionary psychological perspectives as well as ecological and sociological accounts (Liu, 2003). Within the framework of this thesis, however, the emergence of aesthetic experience is considered primarily as a bottom-up process.

4. The golden ratio

The golden ratio (also the golden section) is one of the oldest mathematical models (Konechi, 2003). Historically it has appeared across many disciplines and is still considered one of the most aesthetically pleasing ratios for composing arrangements—for example in photography (Konechi, 2003; Svobodova, 2014; Boselie, 1992). The model has also been applied as a model of an aesthetic ideal in interface design (Lee, 2015).

The golden ratio is a simple equation used to define the relationship between two numbers. In the case of a line segment, the golden ratio is obtained when a segment is divided into two parts such that the ratio of the shorter part to the longer part is the same as the ratio of the longer part to the whole segment. The model can be illustrated with the following formula.

When the length of the segment is 1 and the longer part is x, then the shorter part is 1 − x and x must satisfy the equation:

1/x = (1 − x)/x

Then:

x² + x − 1 = 0

The positive solution to this quadratic equation is:

x = ½(1 + √5)

In condensed form, the equation can be presented as:

1/x = ½(1 + √5) ≈ 1.618

The golden ratio thus approaches 1:1.618. Notably, this ratio is very close to 1:1.5, which is also commonly used, for example, in photographic composition (Svobodova, 2014; Boselie, 1984; Boselie, 1992). According to Boselie's research, this ratio is preferred just as much as the golden ratio (Boselie, 1992).

The golden ratio can be extended beyond line segments to other shapes as well. The side lengths of the so-called golden rectangle are in the golden ratio. Like the golden ratio itself, the golden rectangle has also been believed to have strong connections to aesthetics (McManus, 1997). Practically speaking, the golden ratio has been claimed to be found—or can be found—almost anywhere in the context of art and construction (Green, 1995). For example, Leonardo da Vinci's Mona Lisa has been claimed to follow the golden ratio, as has the Parthenon built by the ancient Greeks (Boselie, 1992). However, it is questionable how accurate these claims are (Boselie, 1992; Di Dio 2007; Green, 1995; Konechi, 2003).

4.1 How the golden ratio has been studied

Its frequent appearance in many contexts is one reason the golden ratio has been widely studied (Boselie, 1992). The studies can roughly be divided into two categories: preference studies based on evaluating geometric figures, and studies in which the golden ratio is evaluated in images or artworks (Green, 1995). Most studies have primarily examined geometric shapes with different ratios—triangles, rectangles, and line segments. In these cases, validity is higher and the aesthetic experience can be more strongly argued to stem from proportions. However, whether these lower-level shape preferences can be generalized to higher-level representations, such as artworks, is questionable (Stieger, 2015). Methodologically, studies have been limited to choosing the most pleasing figure (which is more pleasing) or producing a figure (divide a line "beautifully").

Research on the golden ratio has proceeded in a rhythm where for every study that refutes an aesthetic effect of the golden ratio, a handful of new studies emerge that challenge methods or criticize how results are presented in favor of refutation (Green, 1995). The same phenomenon has occurred in the other direction as well, and the history of the golden ratio includes many "proclamatory" studies attempting to overturn all previous research (Boselie, 1992). Over time, many studies have also been undermined simply due to poor documentation and fairly imprecise methods. For example, Fechner's results have nearly as many different interpretations as they have citations (Green, 1995). Criticism of the golden ratio has thus largely been built on personal interpretations of results and methods rather than genuine comparisons of outcomes (Green, 1995).

The most comprehensive review of psychological research on the golden ratio was conducted by Green, who examined studies from 1865–1995 (Green, 1995). Green concludes that the results presented in the reviewed studies are so sensitive that they could not establish the existence of a potentially meaningful psychological factor. Green continues:

"On the other hand, one might argue that there has been something of a concerted effort among some psychologists to show that there is nothing to the alleged effects of the golden section; that the unreliability of the effects is due to research practices geared to show it to be a fraud, rather than to an inherent weakness in the effect."

According to Green, many of the reviewed studies show a clear desire to disprove this "numerological fantasy" and exhibit obvious carelessness. The goal has not been to objectively demonstrate the nonexistence of the phenomenon. However, this also does not prove the golden ratio either.

In studies where a preference for the golden ratio is found, the result is most often an average effect: the group's preference converges toward the golden ratio, and the variance in preferences can be quite large (Green, 1995). Clear individual preference for the golden ratio is found only in a few experiments. Comparing results is complicated by the fact that in experiments where the golden ratio is highest on average, the mode or frequency is often not reported. Green concludes that the golden ratio is potentially a real phenomenon but on very shaky ground. It is difficult to say whether preference for the golden ratio is learned or innate. Although the golden ratio appears primarily in Western culture, there is evidence of the phenomenon in other cultures as well (Konecni, 2005; Green, 1995). Finally, Green states that the methods used to study the relationship between the golden ratio and aesthetic experience are too crude to refute the claims of skeptics or believers, and that the phenomenon cannot be disproven or proven solely by observing outward behavior.

4.1.1 Konecni's studies with artists

Among contemporary empirical studies of the golden ratio, the largest experimental setup appears in Konecni's 1997 research (Konecni, 1997). Across three separate experimental designs, the study uses methods of aesthetics earlier developed by Fechner. The first study applied methods previously used in studying the golden ratio (such as producing rectangles, dividing a line in two) as well as new methods (such as evaluating vases made with and without the golden ratio). The sample size was 260 students. In studies based on earlier methods, no evidence was found connecting the golden ratio to beauty. Nor did evaluation of the vases reveal a clear preference for those based on the golden ratio. In a second study conducted by Konecni in 2003, the presence of the golden ratio was tested in illustrations produced by professional artists (Konecni, 2003). The artists were tasked with producing illustrations of presented objects and paintings in which the golden ratio was clearly present. The results support the golden ratio: the relative accuracy of produced illustrations in copying the criterion proportions was high, and the golden ratio appeared in most of them very precisely. Criticism of the design is that it does not demonstrate that the golden ratio is more pleasing.

Konecni's results must be treated with caution, and Konecni also notes that the existence of the golden ratio is subtle but elusive. Importantly, none of the studies produced significant evidence of a relationship between the golden ratio and aesthetic experience (Konecni, 1997; Konecni, 2003). The results of experiments that did produce positive findings thus suggest more the presence of the golden ratio in art than that the golden ratio is exceptionally pleasing. Green's earlier conclusion about the crudeness of methods applies here as well: the possible existence of the golden ratio is likely impossible to verify solely by examining outward behavior.

4.1.2 Association studies

The golden ratio has continued to be studied even after Konecni's 2006 work (Stieger, 2015). In Stieger's 2015 study, no greater preference was found for the golden ratio than for other ratios (Stieger, 2015). Stieger's studies used the IAT method (Implicit Association Test), which can be used to examine implicit evaluation (Stiegler, 2015; Fiedler, 2006). In IAT studies, participants are shown a series of stimuli that they must categorize into the correct category from their perspective. The time allotted for categorizing a stimulus is so short that under time pressure, participants' decision-making is strongly shaped by familiarity, symmetry, and simplicity, reducing the role of conscious information processing in categorization. According to Stieger, the IAT method can bypass Green's criticism of methods based on observing external behavior. Stieger argues that IAT can better reveal decision-making based on low-level processing.

Stieger's research consisted of three separate sub-studies. In each, participants were shown artworks whose central element was placed either according to the golden ratio (first and second designs) or at a 3/4 ratio. The studies observed both explicit and implicit preferences for the artworks. The results were unfavorable for the golden ratio. None of the studies found evidence of preference for the golden ratio either implicitly or explicitly. The golden ratio also did not differ significantly from the 3/4 ratio, and often artworks with centrally (symmetrically) placed elements were rated as more pleasing. Stieger suggests that implicit preference may lean more toward symmetry, while appreciation for the golden ratio is learned, for example through art. Stieger notes that even the IAT method may not be suitable for detecting the golden ratio's effect because the stimulus (in this case the artwork) is shown briefly. According to Stiegler, the short presentation time—central to IAT—may prevent the golden ratio from "opening up" to participants. In that case, the golden ratio might only be detectable through conscious perception. However, Stieger's study did not find evidence that the golden ratio is preferred even with longer exposure times. The IAT method has also been criticized, and its reliability and validity have been questioned in several studies (Fiedler, 2006; Blanton, 2007; Rezaei, 2011).

4.2 The neural basis of the golden ratio

Based on the studies presented earlier, it is possible that the golden ratio is a bottom-up process, making its effects difficult to verify solely by observing outward behavior. It is possible that the phenomenon is so small that its effects do not straightforwardly appear in behavior (Stiegler, 2015; Green, 1995; Konecni, 2005). Studying the phenomenon should begin by examining the lowest-level information processing. In practice, this means locating neural responses to the golden ratio using brain-imaging methods.

Neural correlates of aesthetic experience have been a major recent addition to the study of aesthetic experience (Chatterjee, 2011; Zeki, 1999; Palmer, 2013; Ramachandran, 1999; Di Dio, 2007). The roots of the field known as neuroaesthetics can be seen in the neurological models of Ramachandran and Zeki, which argue for the critical role of a neural basis in understanding aesthetic experience (Zeki, 1999; Ramachandran, 1999;). Zeki in particular argues strongly for the importance of neural mechanisms for theories of aesthetics, stating that theories remain incomplete without a position on the neural foundation (Zeki, 1999). As a product of human information processing, aesthetic experience must be built on the rules of the system producing it—the brain. Palmer, however, questions the usefulness of searching for neural correlates. According to Palmer, locating the activation responsible for aesthetic experience requires first identifying the manifestation of that activity in behavior, and then demonstrating the dependency between the two. If behavioral measures of aesthetic experience cannot be found, then correlation cannot be demonstrated either.

The golden ratio has been examined in at least one neuroaesthetics study. Di Dio used fMRI to study the effects of art on brain activation (Di Dio, 2007). In the setup, participants were shown sculptures from ancient Greece and the Renaissance whose original proportions had been altered to conform to the golden ratio. The experiment evaluated participants' (n = 14) subjective and objective aesthetic experience. The study found evidence for objective aesthetics, meaning certain features could be said to specifically activate brain regions responsible for experiencing aesthetics. Conversely, the golden ratio was not found to cause activation in these regions (Di Dio, 2007).

5. The golden ratio in user interface design

Due to its simplicity, the golden ratio can be applied to many different shapes and targets. Its presence in architecture, art, products, and—depending on perspective—also in nature supports this claim. Notably, its presence in these cases has often been artificial: most artists have consciously included the golden ratio in their works, often in pursuit of maximal aesthetic experience, and evidence for naturally occurring outputs that follow the golden ratio cannot yet be confirmed (Green, 1995; Stieger, 2015). Because preference for the golden ratio may also be learned, the problem becomes even more complex (Green, 1995).

Although findings on the golden ratio's aesthetic value are contradictory, it can arguably be used at least as an early-stage design model in industrial design (Bloch, 1995). Design patterns have long been used to communicate established knowledge in interface design and to assist designers (Van Welie, 2001). With patterns, designers can avoid recurring problems and make better decisions about interfaces. The requirement of evidence is a weakness for the golden ratio, creating challenges in adopting it as a design pattern (Van Welie, 2001). Clear evidence for the golden ratio's effect as a measure of aesthetics is lacking and requires further investigation. To determine the golden ratio's suitability for user interfaces, experimental studies would be needed where the golden ratio is applied specifically in this context.

5.1 Background factors of user-interface aesthetics

User-interface aesthetics affect how users interact with an interface (Miniukovich, 2015). Interface designers aim to build a visually aesthetic whole that implicitly helps the user navigate to the desired part of the interface and understand the available actions. Aesthetics is also an important factor for approachability, and an unpleasant interface raises the user's threshold for interaction (Faraday 2009). In addition, cultural factors significantly affect interface aesthetics, and in Eastern cultures a Nordic minimalist interface may be seen as cheap and ugly (Karvonen 2000, Reinecke 2013).

Several measures have been proposed for user-interface aesthetics, such as: visual clutter, color scale, number of primary colors, figure/ground contrast, symmetry, balance, order, cohesion, proportion, and simplicity (Miniukovich, 2015). In many cases, these measures originate from research in human–computer interaction or psychology examining complexity and unpleasantness. In addition, interface aesthetics can also be examined temporally (Miniukovich, 2015). Tractinsky et al. found research on the relationship between first impressions of interface aesthetics and perceived overall aesthetics (Tractinsky, 2006). According to their results, a half-second first impression of aesthetics correlates strongly with a first impression formed over ten seconds as well.

Designing user interfaces is a complex, expensive, and time-consuming process (Sears, 1995; Cross, 2004). During design, multiple problems may be encountered, and multiple solutions may be derived. For frequently encountered problems, ready-made solution patterns can often be found, though using them requires a considerable amount of knowledge. Manually traversing the wide problem space and its solutions is neither feasible nor sensible (Poltrock, 1994). A possible solution is computational optimization, which applies models derived from research to solve design problems. One way to solve the design problem is therefore to convert it into a list of parameters that an optimizer based on a mathematical model explores, generating different interface proposals from the results.

5.2 Ngo et al.'s model of visual aesthetics for user interfaces

One of the most significant models for assessing the aesthetics of interface element placement is the one developed by Ngo et al., whose aesthetic measures are the same as those used in art (Ngo, 2003). The model consists of fourteen measures that can take values between zero (bad) and one (good). One measure is proportion, which evaluates how far the assessed element is from an aesthetically valued form, such as a square or a golden rectangle. Ngo et al.'s model is the only computational model of aesthetics in which the golden ratio appears as an aesthetic measure, though only in a single way of applying it. It should be noted that in Ngo et al.'s model, the golden ratio is one of five proportions toward which the model seeks to optimize, and the reasons for including it are not presented in the model.

Ngo et al.'s model was tested in an experiment with 79 students. The students had no prior experience with concepts of designing interface aesthetics. In the experiment, participants were shown five different interfaces for 20 seconds each. Participants rated the aesthetic quality of the interface on a low–medium–high scale. The setup produced weak evidence of a positive effect of aesthetics on perceived usability. The role of the golden ratio is not separately mentioned in the results, but in the experiment proportions were not found to have significant effects on aesthetics.

7. Discussion

This thesis has presented a cross-section of research on the golden ratio and aimed to form a holistic picture of the quality and methods of research over time concerning the golden ratio and the aesthetic experience it is claimed to produce. Based on the studies presented in this thesis, the golden ratio cannot be said to be a reliable measure of aesthetic experience. As a phenomenon, the golden ratio has been studied repeatedly throughout history and with many methods. The strongest evidence appears in older studies, many of which use methods from perceptual psychology. With contemporary methods—such as brain imaging—the aesthetic value of the golden ratio has not, however, been demonstrated.

Despite limited research evidence—or perhaps partly because of it—the golden ratio still seems to receive considerable attention today. In light of the earlier discussion, studying the neural basis of aesthetics will likely be the only way to either verify or refute the golden ratio as a phenomenon.

In view of the presented research, it is questionable whether using the golden ratio as a model of aesthetics—for example in user-interface design—is appropriate. Because the golden ratio does not differ significantly from other proportions, its influence on interface aesthetics is likely not significant either. There are also relatively few studies and models addressing the golden ratio in interface design.

8. References

• Blanton, H., Jaccard, J., Christie, C., & Gonzales, P. M. (2007). Plausible assumptions, questionable assumptions and post hoc rationalizations: Will the real IAT, please stand up?. Journal of Experimental Social Psychology, 43(3), 399-409.

• Boselie, F. (1984). The aesthetic attractivity of the golden section. Psychological Research, 45(4), 367-375.

• Boselie, F. (1992). The golden section has no special aesthetic attractivity!. Empirical Studies of the Arts, 10(1), 1-18.

• Bloch, P. H. (1995). Seeking the ideal form: Product design and consumer response. The Journal of Marketing, 16-29.

• Chatterjee, A. (2011). Neuroaesthetics: a coming of age story. Journal of Cognitive Neuroscience, 23(1), 53-62.

• Creusen, M. E., & Schoormans, J. P. (2005). The different roles of product appearance in consumer choice. Journal of product innovation management, 22(1), 63-81.

• Cross, N. (2004). Expertise in design: an overview. Design studies, 25(5), 427-441.

• Di Dio, C., Macaluso, E., & Rizzolatti, G. (2007). The golden beauty: brain response to classical and renaissance sculptures. PloS one, 2(11), e1201.

• Faraday, P., & Sutcliffe, A. (1998, September). Making contact points between text and images. In Proceedings of the sixth ACM international conference on Multimedia (pp. 29-37). ACM.

• Fiedler, K., Messner, C., & Bluemke, M. (2006). Unresolved problems with the "I", the "A", and the "T": A logical and psychometric critique of the Implicit Association Test (IAT). European Review of Social Psychology, 17(1), 74-147.

• Green, C. D. (1995). All that glitters: A review of psychological research on the aesthetics of the golden section. PERCEPTION-LONDON-, 24, 937-937.

• Karvonen, K. (2000, November). The beauty of simplicity. In Proceedings on the 2000 conference on Universal Usability (pp. 85-90). ACM.

• Konecni, V. J. (2003). The golden section: Elusive, but detectable. Creativity Research Journal, 15(2-3), 267-275.

• Konecni, V. J. (2005). On the "Golden Section". Visual Arts Research, 76-87.

• Lee, C. B., & Lee, K. (2015). LG's G3 GUI. interactions, 22(1), 12-15.

• Liu, Yili. "Engineering aesthetics and aesthetic ergonomics: theoretical foundations and a dual-process research methodology." Ergonomics 46.13-14 (2003): 1273-1292.

• McManus, I. C., & Weatherby, P. (1997). The golden section and the aesthetics of form and composition: a cognitive model. Empirical Studies of the Arts, 15(2), 209-232.

• Michailidou, E., Harper, S., & Bechhofer, S. (2008, September). Visual complexity and aesthetic perception of web pages. In Proceedings of the 26th annual ACM international conference on Design of communication (pp. 215-224). ACM.

• Miniukovich, A., & De Angeli, A. (2015, April). Computation of Interface Aesthetics. In Proceedings of the 33rd Annual ACM Conference on Human Factors in Computing Systems (pp. 1163-1172). ACM.

• Ngo, D. C. L., Teo, L. S., & Byrne, J. G. (2003). Modelling interface aesthetics. Information Sciences, 152, 25-46.

• Palmer, S. E., Schloss, K. B., & Sammartino, J. (2013). Visual aesthetics and human preference. Annual review of psychology, 64, 77-107.

• Phillips, F., Norman, J. F., & Beers, A. M. (2010). Fechner's aesthetics revisited. Seeing and perceiving, 23(3), 263-271.

• Poltrock, S. E., & Grudin, J. (1994). Organizational obstacles to interface design and development: two participant-observer studies. ACM Transactions on Computer-Human Interaction (TOCHI), 1(1), 52-80.

• Ramachandran, V. S., & Hirstein, W. (1999). The science of art: A neurological theory of aesthetic experience. Journal of consciousness Studies, 6(6-7), 15-51.

• Reinecke, K., & Bernstein, A. (2013). Knowing what a user likes: A design science approach to interfaces that automatically adapt to culture. Mis Quarterly, 37(2), 427-453.

• Rezaei, A. R. (2011). Validity and reliability of the IAT: Measuring gender and ethnic stereotypes. Computers in human behavior, 27(5), 1937-1941.

• Sears, A. (1995, December). AIDE: A step toward metric-based interface development tools. In Proceedings of the 8th annual ACM symposium on User interface and software technology (pp. 101-110). ACM.

• Shimamura, A. P., & Palmer, S. E. (Eds.). (2012). Aesthetic science: Connecting minds, brains, and experience. Oxford University Press.

• Sonderegger, A., & Sauer, J. (2010). The influence of design aesthetics in usability testing: Effects on user performance and perceived usability. Applied ergonomics, 41(3), 403-410.

• Stieger, S., & Swami, V. (2015). Time to let go? No automatic aesthetic preference for the golden ratio in art pictures. Psychology of Aesthetics, Creativity, and the Arts, 9(1), 91.

• Svobodova, K., Sklenicka, P., Molnarova, K., & Vojar, J. (2014). Does the composition of landscape photographs affect visual preferences? The rule of the golden section and the position of the horizon. Journal of Environmental Psychology, 38, 143-152.

• Tractinsky, N., Cokhavi, A., Kirschenbaum, M., & Sharfi, T. (2006). Evaluating the consistency of immediate aesthetic perceptions of web pages. International journal of human-computer studies, 64(11), 1071-1083.

• Tractinsky, N. (1997, March). Aesthetics and apparent usability: empirically assessing cultural and methodological issues. In Proceedings of the ACM SIGCHI Conference on Human factors in computing systems (pp. 115-122). ACM.

• Van Welie, M., Van Der Veer, G. C., & Eliëns, A. (2001). Patterns as tools for user interface design. In Tools for Working with Guidelines (pp. 313-324). Springer London.

• Weed, E. (2013). Stephen E. Palmer and Arthur P. Shimamura, eds. Aesthetic Science (review). Estetika: The Central European Journal of Aesthetics, (1), 128-133.

• Zeki, S., & Nash, J. (1999). Inner vision: An exploration of art and the brain (Vol. 415). Oxford: Oxford University Press.

⚡️ Premise

Sometime around early January I came around one rather odd looking website. I’m not sure what made me stay on the website (maybe the weird lobsterman?) but eventually I deciphered that there was going to be a energy efficiency themed hackathon. I quickly applied to it, and started looking flights to Berlin.

I had no idea of all the peculiar things waiting for me there.

✋ Sunday

15:00 After a short flight I arrived in Berlin and made by way to the venue. The hackathon would take place at **BetaHaus**, a co-working space eerily familiar. I walked in and received my swag: t-shirt, back bag, and notepad. I tried to argue against XL-sized t-shirt, but the helper convinced me that it would be right size. It wasn’t.

The program started with a short introduction to theme of the hackathon, and continued with a quick design thinking / get to know each other activity. We then moved to the rooms dedicated for the different challenges and had hour and half for forming the teams and asking questions from the challenge partners.

In total there were three challenges: Danfoss, Schüco, and Evonik, from which we’re asked to pick when signing up. I had picked Danfoss, as hacking grocery store efficiency sounded fun.

Danfoss engineers going through the challenge

20:00 Now usually at this point you would start hacking. However, this wasn’t that type of a hackathon. Instead we opened a couple of cold ones and started socializing, eventually ending the night in our hotel bar. I guess this is a one way to start a hackathon.

💯 Monday

11:30 Arriving at the venue surprised me. There seemed to be even more people than yesterday.

After the day’s opening speeches we got back into the challenge spaces and started the ideation process. Our task was to come up with the initial idea that we would pitch in a one minute pitch for the other teams. For this we had two hours.

We settled on a idea of smart tags that would start out opaque and slowly change color as the expiry date of product got nearer. Different colors would indicate different discounts. This would mean that less products would go to waste, bringing the cooling cost down because you don’t spend energy to cool down products that never get sold. Although a good idea, I was quite skeptical if it would fly with Danfoss. After all they are a company that manufactures fridges and other cooling appliances.

We settled on a idea about smart tags that would start out opaque and slowly change color as the expiry date of product got nearer. Different colors would indicate different discounts.

We then moved back to the auditorium to do our one minute pitch with all the other teams. This turned out be a little disappointing in our case. Not because we got negative feedback, but because we didn’t get any. The jury had been asked to give feedback after all the pitches were done, and had simply forgotten most of the teams at that point.

We conducted pretty quick and definitely dirty user testing to test if our hypothesis could actually work.

13:00 We got back the working space and discussed whether we should continue with this idea or pivot. We decided to continue and started working on the actual concept. One part of the team started working on building a quick and dirty user testing session by using the fridges around the building. Other started working on the presentation materials (there were no powerpoints allowed in the final pitching) and I started writing our submission. The 7 hours we had for hacking went super fast.

Now before you start complaining that we didn’t actually code or build anything I’m going to stop you right there! We did. It was awesome, and took most of the time we had for hacking. We also had never done anything similar so it was a learning experience as well. So what did we build? This:

Yeah, we 3D printed a fish. Why? I’ll have to get back to you on that.

21:00 The final started with words from Germany’s minister for economic affairs and energy, and continued with pitching that ended almost as soon as it had started. Large teams and 2 minute maximum pitch made everything lighting fast. The pitches were also positively different from the startup pitches I’m used to seeing, having a lot of acting and humor in them.

Then it came to announce the winners. Total of six prizes would be given, one for each of the three tracks, and for best design, best business case, and best overall concept.

To my, and to my teams surprise we ended up receiving the main prize for our track and also the prize for best design. Taking up on a rather different idea had paid of, and Danfoss seemed quite impressed with the concept. Our quick and dirty user testing had also been a good idea, as it had been the reason for receiving the best in design award.

You see kids, this is how you should look when accepting a prize.

The evening continued with us celebrating the double win at Betahaus until they ran out of beer, after which we ventured back to the good old hotel bar. Would like to see more hackathons like this, that take place during the day and end in good afterparty.

❤️ What I loved

I have to be honest, I was quite skeptical that this type of a hackathon would work at all. It just seemed so wacky and inefficient. Take for example the massive teams. I’ve had bad experiences on teams with more than 5 members being vert ineffective, especially when they are all strangers to each other. However, in our case the huge team worked pretty well!

I also loved the prizes, which in our case meant a little bit of Bitcoin and a trip to Danfoss’ headquarters to present the concept again. These type of prizes are in my opinion better than just giving out gizmos for example.

🔨 Things to fix

Smaller teams, please.

This makes it easier for participants to form their teams, settle on an idea, and start working. I also believe it would more valuable for the companies participating to get as many new ideas as possible.

Last weekend we participated in one of the most exciting hackathons in a long time, Kuohu Creative hackathon by Luova Aalto. As a manifestation of the core idea behind Luova Aalto, multi-disciplinary and creativeness combined, this hackathon was all about creative problem-solving. So, during the weekend we did not write even a line of code, nor did we open Sketch or other UI tools either. Instead, we talked, questioned, and formed solutions such as pricing models for companies and brands you rarely see in hackathons.

Seeing as Kuohu was first of its kind, we were slightly skeptic if it could live up to its promises and whether we could provide any meaningful solutions in our challenge by Fazer.

Pssst. If you are organizing a hackathon, this was something you might want to benchmark.

Friday

Friday was all about getting to understand the challenge. At Demos Helsinki’s premises, we heard short introductions from all participating companies, after which all of us hacking for Fazer moved to another room for confidentiality reasons. All the doubts we had had about the challenge objectives quickly faded away, once Fazer revealed what we were going to be working on in this hackathon. Our task revealed to be the creation of a new, innovative business model for Fazer to support their new digital service.

After the brief was done, we started going through the background material again and discussing with the mentors (we’re sorry if it felt like a police interrogation, it’s easy to get carried away with questioning when you’re super excited). In the end, we had a pretty good grasp on what kind of a solution Fazer was looking for; now we just needed to make it solid and believable.

Since we ended Friday quite early, there was plenty of time to contemplate our future, discuss our dreams, and build up the team spirit with Luova Aalto’s gift to us, Rami. The best way to do that was, of course, navigating to the nearest bar and grabbing a couple of cold ones from the tap. Now, we had not met Rami previously, but oh boy, did we quickly realize how incredibly talented he was, and how excellent an addition he was to our team! Once we parted ways for the evening, Olli and I both had the same thing in our minds, working with Rami would be awesome!

Saturday

Amidst rain and overcast skies, we jumped on a ferry to Suomenlinna, a place well fit for hacking, in the morning. After getting out the post-its and pens, we started working straight away, as there was no time to waste. Pitches would start at half-past four, and we were seven hours away apart from that.

“And who doesn’t want a free lunch?”

Unfortunately, we can not go into detail on what our proposal ended up being, as the service is not yet public. Let’s just say it involved free lunches. Here’s a couple of good pictures on how we worked on the solution!

Getting feedback for our business plan from D11's Tuomas Ylä-Kauttu. On the table, you can spot the best hackathon beverage ever, the Ginger Pepsi Max.

When it was time to pitch, Olli climbed on stage and started going through our holistic approach that tied in the business model and the future of the service. Earlier on we had made some bold choices on the pricing, and our numbers raised some serious doubts in us and in the jury.

“Umm… does this look right?”

At the end of just one intensive day, Fazer had 5 different but viable revenue models in their hands. All the solutions were excellent and it was definitely not an easy task for the jury to pick only one winner. Our solution, however, ended up being the winning one, despite the hard questions it got from the jury. The jury actually thought that our solution was so simple that it irritated them greatly that they had not thought about it themselves.

Conclusion

We had a blast in this hack and based on our conversation with Luova Aalto, so did everybody else. Unfortunately, we weren’t able to witness what the teams had created in other challenges, for Jenkki and Happy Joe, but based on the atmosphere of the finals teams had a lot of fun working on those solutions.

At first, we were doubtful whether such a short hackathon could work in innovating a completely new business model for an existing service. But, this hackathon proved to be wildly successful in doing exactly that. This event serves as further proof for our view that a multidisciplinary team, design thinking, and constant questioning can solve basically any problem.

I will conclude this Hack Report by saying that Kuohu Creative was one of the friendliest yet one of the most effective hackathons we have seen in a long time. Not to mention the level of production and attention to detail in the participant experience, which were truly stellar. I’ve personally witnessed only one hackathon having this high level of production before, and they had a god damn film crew on the venue.

How to hack with 5G networks in mind? How do you manage three teams and ten hackers in an efficient manner? Is Oulu one of the best places to hold a hackathon?

The role of technology

When 3G networks came, they brought us our first real chance in mobile internet and mobile video calls, among other things. Now it’s time to add another odd number in front of the letter G and, like before, supercharge the speed of the network. But what kind of world-changing solutions will this new 5G network bring? It seems that no one knows yet, but there’s a lot of potential!

Network technologies aren’t really my jam, but I see 5G networks — like any other cutting-edge technology — as an enabler. This hackathon provided a new kind of challenge that we were eager to take on. A well-defined problem and a polished solution wouldn’t cut it this time — we would also need to take into consideration what role this specific technology plays in all three solutions.

How did we do? Short answer: 1 win and 2 honorary mentions.

The challenges we took up

In total, there were three challenges, two from industry leaders Nokia and Telia, and one from the Oulu University Hospital. Here is a quick rundown of those challenges.

Oulu University Hospital (OYS) challenged teams to improve their customers’ journey. With 42 kilometers of corridors, the hospital is a massive complex, and navigating through different departments takes ages. Additionally, all patients are given the same information in the same format, which is confusing to some patients. Since OYS is a special health care hospital, patients have no say when it comes to scheduling, leading to late or missed appointments, which is very inefficient.

Nokia wanted participants to develop new ways of optimizing their already state-of-the-art telecom network equipment. To succeed, the hackers would need to make the current process even more digital than it currently is by utilizing machine learning, computer vision, wearable technology, augmented and virtual reality, and robotics. Nokia’s industrial environment challenges allowed our team to try building with novel technologies.

Telia presented a challenge with the largest scope — mobile apps for the 5G age. Unlike Nokia’s and OYS’s challenges, there was no apparent real-world problem. This meant that to create a truly useful solution, our team would need to find a target group whose needs are not yet met by any other solution. We eventually selected students and educators as our target group and included a teacher student as one of our hackers to gain valuable insights.

How we worked

Perfektio set out to solve all three challenges with three separate teams. Our participant size was ten hackers, eight of whom were Perfektio employees and two guest additions (one a teacher!). Even with the guest additions, our established hackathon workflow proved effective, enabling us to leverage collective expertise into amazing concepts.

We don’t make strict rules on which hacker works in which team but instead opt to keep the teams and their members in a constantly fluctuating state and keep everyone updated on what is happening in each team. This allows us to allocate hackers based on every team’s need at the moment. In Oulu, this worked fantastically. For example, in the case of OYS, our primary team consisted of only two hackers but leveraged the collective input.

Before the hackathon, we keep the concepts fairly undefined because we don’t want to go into hackathons with ideas we can’t part ways with. This has been our approach for a long time. For the same reason, we start the first day of the hackathon by bombarding company representatives with questions. We then combine this with the knowledge of potential users we have gathered before or during the hackathon. Why? Because you can only solve problems if you understand them.

The teams and their solutions

Perfekt Patient set out to create the best customer journey ever seen in a hospital. A week before the hackathon, we reached out to doctors and people who had spent long times in hospitals. From these interviews and conversations with OYS representatives, we defined our problem space, focusing on guiding patients to the right place at the right time. Our solution was a mobile application coded with React Native. OYS appreciated our solution and awarded us an honorable mention.

Industry Perfekt made an impressive demo and development plan for Nokia to optimize their component tracking process. With wearable technology and always-on optical reading, the tracking process would become much less prone to errors. Although we didn’t win the main prize, we received an honorary mention, which is always nice.

Team Classroom created a dashboard for teachers that provided insights into students' engagement and included a VR demo of a heart for students. This solution enabled students to immerse more in teaching while giving teachers valuable insights into student learning. Telia loved our demo and awarded us the 10K main prize for it!

Oulu 5G hackathon was a truly positive experience. The venue and event were masterfully organized, and just look at how much fun we had! Big thanks to Nokia, Telia, and OYS for the challenging projects, which were some of the toughest in our hackathon history — and that’s a good thing!

What is the difference between a hackathon in Finland and one in UK? I wanted to find out how hackathons around the world differ and decided that this year I’m going to travel to different hackathons around the world. About a week ago I did my first little research trip. to Royal Hackaway, Royal Holloway‘s first student hackathon. Here’s what I found out.

Saturday

Early Saturday morning I stuffed one day’s worth of clothes and a borrowed sleeping bag into my trolley bag, and headed to the Helsinki airport. The flight went fine, although I did get a nosebleed the moment the wheels touched the landing strip, and dirtied the only hoodie I had with me (having bloodstains on your hoodie in hackathon shows character). After I had landed and stuffed a sizable amount of paper cloth in my nose, I made my way to the bus. There I played a round of “spot the tourist” with the bus driver before jumping on board. At this point I had spent about five hours traveling to this hackathon.

Once I reached the campus of Royal Holloway (”The most beautiful university in UK”), I snapped a quick picture of the premises and composed a Facebook post (I got like 20 likes, baller yeah). After that I made my way to the building where the hackathon would take place, received my badge and lunch vouchers, and walked into the auditorium where the show was about to start.

Theme of the hackathon turned out to be open data, a relatively original theme⸮ Once the welcoming speeches ended, we moved to another room and started hacking. No team formation, no nothing. This is a thing I found a little stupid because it felt that organizers did not consider that there could be people running solo (like me for example). I was able to force myself into one team after bragging how many hackathons I’ve won (14, not that I’m counting or anything).

Our team spent around two hours getting to know each other and coming up with an idea to build. We finally decided to build a tool that would put all the hackathons around you on a map, show the prizes, and provide fare estimates for flights (hey, Major League Hacking, the map part would be good addition to your site as well). After this it was time to decide who would work on what and what kind of stack we would use — we chose Vue.js, which was positive surprise.

“…no offense but I thought you were shit!”

What was my part in team? I started by reading a little Vue.js documentation in order to start building the frontend. After a rough start I was asked to build a HTML mockup instead. This I did for maybe 20 minutes, before I once again asked to do something else, this a photoshop mockup. Reason for constant pivots was my team’s distrust in achieving in these tasks; or at least achieving them in a way that would helps us win this thing.

Once I was done with the mockup I showed it to my team mates, half expecting to get disappointed looks. To my surprise, I got a heart warming “dude this is really cool; no offense but I though you were shit!” compliment on my mockup. After that our work together went really smoothly and we managed to build most of the app during Saturday. Sunday we spent fixing and rewriting everything we had written the day before.

Sunday

I got a pretty solid 4 hour sleep during the hackathon which you might consider to be a lot, but you are wrong. Well, first because little sleep can do wonders to your cognitive functions. In hackathon context you should aim around 50% of the sleep you get on an average night, to continue functioning at about average performance. Second reason is, because I’m old and weary I need my sleep (26, which was about 6 years over the average age of this hackathon).

Submission deadline was at 12, after which it was time for presentations. Judging by the presentations most teams seemed to consists of first timers, which is always cool. Hackathons need fresh blood.

When it was our time present, we got to stage and presented our project. We had actually created a two solutions: an API that gave us hackathons and webservice to used that API. We had to remove the fare estimates for flights because it turned out Google’s API and Skyscanner’s API aren’t open anymore. You can find a more detailed explanation of the project here.

Then came time for the prizes. I’m quite sure that the judges decided to give prices to other teams instead of giving all of them to us, to keep up the morale. After all, our hackathon submission was a masterpiece. The first place went to a solution that converts video and audio files to text summaries, with the help of ML, making it easier to study. I’m a bit sad that my personal favorite, a web site which tells you if Trump thinks your country is a shithole, did not win. It had all the potential to be a disruptive tool in international politics.

Conclusion

I want to say special thanks to the organizers of Royal Hackaway. I enjoyed the event a lot, especially the atmosphere. But I do also have small suggestions that could make the event event better. First, some kind of a team formation activity would make it easier to get started. Second, a more defined theme, or a challenge to solve that you advertise before the hackathon, could also make the hackathon more marketable.

I want to also thank my teammates, working with you during the weekend was a blast! I was also really impressed with your skills. I hope to see you in Start Hacks in Switzerland.

Premise

“Has anyone ever done any gardening?”

The question echoed in our office for a short time, but was soon met by a snarky counter question wondering whether signing up for a university’s campus farming would suffice as gardening. Our office, a tiny 30 sqm room with a turquoise floor mat, located in a buzzing co-working space, was packed with eight people. The clock was already half past eight in the evening, and we were no closer to coming up with ideas that would make gardening more interesting and get us into this hackathon.

Room full of people and no one had ever even tried gardening. How were we ever going to get through the selection process of this hackathon, that had everything to do with gardening? What kind of a record breaking concept could a bunch of never-even-held-a-trowel-people create that would both bring gardening to the 21st century and guarantee a pilot project to develop further? You could say that the odds were not in our favor.

Did I mention that this Fiskars hackathon was organized by Industryhack, one of the best hackathon organizers, which also has the toughest application process? But why is it so tough? First of all this is the big league and there’s no hand holding. Most of the teams come from existing companies, some even from quite big companies such as Tieto and Kone. You cannot apply as an individual but instead you form a team of 2–3 people. Such a small team leaves no room for freeloaders or newbies.

Second of all, the submission, in which you first introduce yourself, your team members, your motivation and your idea is the only thing that affects whether you’re selected or not. We often spend more time polishing our submission to perfection than coming up with the idea. After all only 6–8 teams are selected to the hackathon from possibly dozens of teams. Getting selected into the hackathon is a already prize by itself — your idea and team sounded more promising than so many others.

We had to get into this hackathon. It had everything a young company needs, a potential for a pilot project and a big client. So we decided to submit two hackathon project proposals. Double the changes right? Quantity over over quality? Or perhaps a sure way to double the depression that you get from not getting selected at all.

The problem

”What makes gardening cool?!”

So was any of our proposals selected for the hackathon? Drumroll please…. and the selected projects are…. project 1,project 2….project 7 and Shed (that’s us)! So one, out of the two ideas. Now let me describe both of the ideas and you try to guess which one got selected:

“ Idea 1. We want to help gardeners to use the correct tools and get the correct information needed in order to succeed based on their gardening goal. With our mobile app you are taken from novice gardener to a pro”

“Idea 2. Our idea is a completely new business model for Fiskars where a combination of physical tool shed and mobile companion app allows people to rent Fiskars tools. With our service people can always find the correct tools from a place closest to them.“

Now, which one would likely be the one to get selected? If you think that number two sounds lot more interesting, I don’t blame you. Why number one sounds quite dull, is partly because although it solves some real problems, there is not really an original thought behind it and no original problem.

What is “an original problem”? Isn’t the main thing in hackathons to provide solutions? It is true that quite often hackathons exist in vacuum where problems are made to fit the solutions the teams have already come up with before the hackathon. There is a word for this, as defined by Cooper: solutionizing. The only way to steer away from solutionizing is to solve original problems, which are problems that you did not invent. Our first idea is classical case of an invented problem — knowing what tools to use is not that severe case. Number two is quite vague, but goes in the right direction. Getting the right tools when needed is problem you might face several times a day in many different domains. How do you find these original problems? You do your research on the subject of course!

The team

“Who the hell do these guys think they are?”

Sugar. Spice. And everything nice. Accidentally add some Chemical X and you have the Powerpuff girls. But what do you have to mix to get the perfect hackathon team — I kept wondering while sitting in an airplane somewhere over the English channel. I was making my way back to Helsinki from UX Scotland conference where I had had a chance to witness Jared Spool talk about about integration of UX design into the whole organization. Many of the things mentioned there resonated with my thoughts on the perfect hackathon team. What does our Fiskars hack team have in common with Spool ideas?

So our Shed-team, consisted of three experts. Me a UX designer, Jyri a full-stack developer with expertise in developing 3D stuff, and Tuomas our very own business analyst (We also had Jonne, a designer/developer as my substitute on the first day). This is quite a typical hackathon team composition based on our experience. It also seems to work pretty well, both in our case and in cases where we have witnessed other teams winning.

We see that what matters the most is the overall experience of the whole team. Besides this it is also about how your team can work together despite lacking expertise and resources in some of the areas that are central for your hackathon concept. Designing for experiences is founded on unified expertise, both on hackathon level as well as on organisational level.

How do you achieve this? First no silos of experience and no pecking order. Jyri’s opinion about bad use flow, isn’t in anyway less worthy than mine and our team doesn’t cease working if I’m unable to participate on the first day of the hackathon (which actually happened, because of me being in Scotland). Hackathon team has no leaders. It is single organism that lives only to solve problems.

Solution

“That ain’t gonna win”, said one coder to another

On Friday, around two o’clock Tuomas was getting ready to pitch the idea to Fiskars representatives. This pitch, however was a little different from what we’ve done before. It was done in a small room instead of a large stage. Instead of having three minutes to the sell the idea, we had 10. This gave us all the changes to sell an idea that would often be considered too large for hackathon concept.

Ideas ain’t worth a dime however. So instead of simply selling big ideas you also have to sell your expertise and the factors that make you better than all the other teams. We ended doing pretty well in this, as we were one of the three teams Fiskars decided continue the discussion with.

I can’t really tell you about the solution itself, as the discussion concerning it still ongoing. I can tell you that we did a mobile prototype and that there was a circular economy aspect to it. Our concept was very well received by Fiskars, but did not do so well when other teams we asked to vote for their favorite concepts. Mostly this was because our concept wasn’t so technically inspiring. Oh well, you cant’ have everything.

Conclusion

So did we get the pilot project? That is yet to be decided. In the last meeting we had with Fiskars things were looking quite good. Hopefully in the future you will see our service in use, as we think it is pretty frickin cool’. However, once the discussion concludes we will tell you more about the service itself.

If you use Netlify even a little, I'd love your help trying the beta. In case you’re inpatient, here’s the link to the TestFlight.

Didn’t you build this app already once before?

Yes, I did. You can find the original announcement here. I eventually had to pull the app from the app stores because updating it was eating up my time (the app was mostly free and I had to focus on my actual job). During the years it’s been out of the app stores, some users have been emailing me with bug reports and feature requests, so I decided to finally answer all of those users and bring the app back.

What Netli.fyi does

Netli.fyi's goal is simple: take the parts of Netlify you check often and make them fast and comfortable on iOS.

Manage sites

You can browse all your sites at a glance with deployment status, frameworks, and thumbnails. There's a full editor for environment variables, plus access to build settings like build command and publish directory.

Build and deploy tools

You can trigger builds right from your phone and watch deploy logs update almost in real time. Deploy history is there too, so you can spot failures quickly.

Domain and DNS access

You can view your DNS zones, inspect individual records, and copy name servers or domain info with one tap.

Account support

The app supports multiple teams and profiles. You can switch between them easily, check your stats, and pick light or dark mode based on your system settings.

Under the Hood

For anyone curious about the tech, the app is built with a modern React Native stack: Expo with the new architecture, Expo Router for navigation, Jotai for state, TanStack Query for data, and NativeWind for styling.

In short, it aims to feel fast.

Want to Join the Beta?

Here’s a TestFlight link, I’ll try to add the Android version soon as well.

Before launching the first public version, I want to be sure the app feels right in actual day to day use. I'm mainly looking for feedback on:

• Performance. Does the app feel quick on your phone?
• Navigation. Are the screens and flows clear?
• Bugs. Crashes, odd UI behavior, broken states.
• Missing features. What would you expect from a mobile Netlify client?

Thanks for taking the time to read this and for helping me shape the app.

Changing your habits from unhealthy to healthy ones is hard.

Fortunately changing behavior has become easier with technology. We don’t necessarily need that expensive coach to push towards our goal anymore, and a cheap mobile app might even suffice. The question is, how can we build services that help users to change their behavior?

Change in behavior cannot be forced, but we can persuade the user to change his behavior through Persuasive Design.

Why do you need to understand Persuasive Design?

Apps that enable users to order food are kindergarten level in terms of design complexity to apps that try to change the user’s eating habits. Designing products that change behaviors and attitudes is complicated because it forces us to think beyond what the user wants to do, and instead focus on how to get them to do things they should do.

You don’t need to be designing a product for healthier living to benefit from understanding the principles of persuasive design. The basic thesis behind persuasive design, changing user’s behavior to targeted one, is relevant in any domain.

Four approaches to Persuasive design

There are four design approaches for persuading the user to change his behavior: primary task support, dialogue support, social support, and creditability support. Using the different methods and principles in combination maximizes persuasiveness of the service we are designing. A higher level of persuasion means the user is more probable to change his behavior.

Primary task support – making everything easier

The main function of a user interface is to support the user in carrying out the primary task they have at the moment. For a user that aims to exercise regularly, this means, for example, turning the more significant job of exercising into smaller ones, such a picking a suggested training program. This is called the reducing principle.

Seven principles make up the primary task support approach:

1. Reducing: chunking complex task into smaller ones, e.g. reducing the effort of going for a run by suggesting a running route.
2. Tunneling: guiding the user through a process, e.g. providing a step by step on how to produce a healthy meal.
3. Tailoring: providing context-specific information, e.g. showing different information for beginners and professionals.
4. Personalizing: providing personalized information.
5. Self-monitoring: tracking the user's performance in the task, e.g. providing step count in an activity app.
6. Simulating: simulating the link between cause and effect, e.g. showing before-and-after pictures of people with the same weight.
7. Rehearsal: practicing targeted behavior, e.g. using an app to train meditation for example.

Dialogue support – providing good feedback

Users expect some form of feedback when using an app or a service to achieve a goal or change in behavior. In persuasive design, this should be seen as dialogue, in which users actions are reflected in the system that allows for a continuation of the interaction. For example, when the user accomplished something they set out to do, the service acknowledges this and provides next steps for after it. To provide meaningful feedback, your service should incorporate the following principles:

1. Praising: offering positive feedback, e.g. congratulating the users for achieving her goals.
2. Targeting: rewarding the user for targeted behavior, e.g. giving out trophies.
3. Reminding: reminding the user of their targeted behavior, e.g. notifications about today’s running goal.
4. Suggesting: suggesting fitting ways to achieve targeted behavior, e.g. food app suggesting healthier alternatives.
5. Similarity: proving the service in a way that is familiar for the user, e.g. using users language, slang, etc.
6. Liking: providing a look and feel that appeals to the user, e.g. cartoony graphics for an app that is meant to teach children to brush their teeth.
7. Social role: offering a social connection for the user, e.g. connecting users to professional coaches.

Social support – using human’s social behavior

We are social beings. Doing things in a group and competing against each other can, in many cases, lead to better results. Services that aim to change behavior have the added benefit of social pressure if done right. Being social of the things we are changing in ourselves pushes us to follow through. Ways of building social support in your service are the following:

1. Social learning: a person is more prone to change her own behavior if given a chance to observe others, e.g. allowing users to share their completed workouts.
2. Social comparison: allowing people to compare their performance to others, e.g. people can compare their pace for running 10k.
3. Normative influence: using peer pressure, e.g. allowing a group of people to set a shared goal that everyone must work to achieve.
4. Social facilitation: people are more likely to perform target behavior if they feel other people are doing it as well.
5. Cooperation: using the natural drive to co-operate as leverage, e.g. allowing a group to set for example a shared weight loss goal.
6. Competition: using people’s drive to compete, e.g. win a prize if you run more miles than your peers.
7. Recognition: offering public recognition, e.g. interviews of the people who achieved their goal with the service or showing a global leaderboard for most runs.

Credibility support — be trustworthy

Besides providing the means, the feedback, and the social elements for changing behavior, your service should also be credible. More credibility converts to more persuasiveness. There are seven aspects that increase the creditability of your service:

1. Trustworthiness: users are more likely to follow instructions of a trustworthy app.
2. Expertise: services that are perceived to be based on expertise and researched knowledge are more persuasive.
3. Surface creditability: people make a quick judgment of the system's creditability based on several factors. Using a cartoony font, for example, might reduce the professional aspect of the service.
4. Real-world feel: providing information on the people behind the service builds creditability.
5. Authority: using authority to build more creditability and increase persuasiveness.
6. Third-party endorsements: well-known and respected sources as endorsers work wonders in building creditability.
7. Verifiability: allowing the user to verify services claims, for example, by linking to outside sources.

Conclusion

The presented approaches and principles are some of the most fundamental ideas behind the persuasive design. However, despite multiple the ways that we can increase the persuasiveness of the services and products that we design, changing user’s behavior is a rather difficult task. We can also see this in the surprisingly few products that are in the market today, which are good at changing their user’s behavior. This, of course, should not be seen as discouragement, but rather as an incentive to work even harder at building these products that change our behaviors for the better. There is a huge market for the products which help us realize our potential and live a healthier and happier life.

Thankfully, there is a way to revert to the old UI, as discovered by the Reddit user u/guitwo. Their original instructions are for the browser client, but I much prefer the desktop client. Following these instructions, you should be able to get the old UI back on the Mac desktop client of Slack:

Enabling the developer menu

We first need to enable the developer menu in order to run a small piece of JavaScript code. Start by first closing your Slack client. After that, run the following command to enable the developer menu for the client:

export SLACK_DEVELOPER_MENU=true

Because the Slack desktop client is just an Electron app, i.e., a web app pretending to be a real application, "the developer menu" is actually just Chrome's Developer Tools.

After running the command, reopen Slack by running the command:

open /Applications/Slack.app

2. Switching the configuration to use the old UI

Next, we need to run a small bit of JavaScript in Slack's developer menu. Use the hotkey Cmd ⌘ + Option ⎇ + I.

If nothing shows up, repeat the steps from before. Once you have the developer menu open, run the following commands:

// get the current local configuration object
const localConfig = localStorage.getItem('localConfig_v2')
// toggle off the is_unified_user_client_enabled
const updatedConfig = localConfig.replace(
  /\"is_unified_user_client_enabled\":true/g,
  '"is_unified_user_client_enabled":false',
)
// set the item to local storage
localStorage.setItem('localConfig_v2', updatedConfig)

Now close Slack one more time and reopen it. You should see the old Slack UI again!

There are certain caveats with this approach. One, the app will revert back to the new UI once you fully close the Slack app. Second, there are no guarantees how long this will work.

Building a great Android app takes time, creativity, and persistence. But once your app is live, there’s one question every developer eventually faces: how do I actually make money from this?

Android developers often struggle with monetization more than iOS developers. Not only are Android users statistically less likely to pay for apps, but implementing in-app purchases or subscriptions comes with technical and operational hurdles that can overwhelm solo devs or small teams.

This guide breaks down every major Android monetization model that brings in recurring revenue, explains why some apps succeed while others fail, and walks through practical implementation strategies using RevenueCat.

I'm too lazy to read, show me the video

I got ya, here is the video version of this article from Droidcon London 2025 and Droidcon Berlin 2025:

Why monetizing an app is hard, especially when it’s on android

There are three main challenges developers face when trying to earn money from Android apps.

1. Users expect free apps

Unlike iOS users, Android users have been conditioned to expect free experiences. Many come from markets where disposable income is lower, and a large portion of the Android ecosystem runs on ad-supported or open-source apps.

Looking at top selling Android phones, which are usually priced in a few hundreds dollars, it’s no wonder most users expect apps in their phones for free. When compared, a 50 dollar yearly subscription feels way more expensive on a Samsung A16 costing 150 dollars, than on the cheapest iPhone (16E) priced at 600 dollars.

Possibly for this reason developers on Android often see one-star reviews the moment they move previously free features behind a paywall. It’s more than likely that these reviews come from users who genuinely like the app, but resent being asked to pay. Winning over these users requires convincing users your app is worth supporting.

2. Implementation complexity

Monetizing users is hard, but adding monetization to your app isn’t easy either. Even adding in-app purchases or subscriptions isn’t a plug-and-play process, often requiring:

• A backend service for validating receipts.
• Logic for managing active and expired subscriptions.
• Handling user authentication and cross-device restoration.
• Keeping up with Google Play Billing API changes.
• Navigating regulatory requirements like EU subscription rules.

It is not uncommon to come across large teams in big companies, whose sole purpose is to develop and maintain the in-app purchase infrastructure of the company’s Android app. Google Play Billing provides a lot of functionality out of the box, but you still need to build a lot around that API to provide a great purchasing experience.

Even if you build it perfectly once, you’ll need to maintain it as well, which will likely be an even bigger time sink. Every API change or edge case can break your monetization flow and cost you real money. For indie developers, this kills a lot of momentum from delivering features, not to mention the way it eats up motivation, when you’re forced to build “boring stuff” (you have to be a real sicko to enjoy working with Google Play Billing API’s).

3. Android apps earn less on average

Combing through the data of RevenueCat’s State of Subscription Apps highlights the difficulties of monetizing Android apps through subscriptions. Even with similar user bases, Android apps tend to earn less than their iOS counterparts:

Fewer people start trials on Google Play than on the App Store. Even at the high end, only about 14% of users start a trial on Google Play, compared to roughly 23% on the App Store. Revenue per install is also significantly lower on Android apps than iOS in general. However top performers on Android do see comparable revenue to iOS.

So even though monetizing Android apps is certainly possible, it is way way harder than on iOS. Boringly, the playbook for making money is the same on both platforms: building high quality apps, addressing a real need, and having the right monetization strategy. Let’s look at the last point in the next section.

Options for monetizing on Android

Right off the bat: there is no single perfect monetization method. What works, when and how, depends on a variety of things. Successful apps often combine several different strategies. Here’s how to think about each approach.

1. Advertising: simple but scale-dependent

Everyone on Android knows ads. As an iOS person it feels like every Android app has ads in it. When I’ve done roundtables in Android conferences, it seems that more devs have ads in their apps than in-app purchases. Ads are the easiest way to start earning money. Integrate AdMob, AppLovin, or another ad network, and you’ll begin to see small amounts of revenue per user.

However, the problem with ads is the scale they require to turn any meaningful revenue. If you take the 1,000 true fans hypothesis and make those fans pay in the form of ad clicks, you’re making only between $1 and $10 every month.

If your app has a viral or casual audience — games, wallpapers, entertainment — ads can work well. For productivity or paid tools, they tend to feel intrusive.

Pros:

• Easy to implement.
• Works for completely free apps.
• Passive, recurring income.

Cons:

• You need massive user volume to make meaningful money.
• Ads can hurt the UX and damage your brand.
• Doesn’t scale well for niche or professional apps.

2. One-time purchases: simple value exchange

Google Play Store supports two types of One-time products, consumables and non-consumables; former you can use for recurring revenue, latter for one time unlocks .

• Consumables: Can be purchased multiple times (e.g., extra lives, credits, tokens, tips).
• Non-consumables: Unlock permanent features (e.g., dark mode, ad removal). \

Non-consumable purchases don’t generate recurring income, and they cap your revenue at the number of users willing to pay once. The mental model of it is similar to that of the old boxed software, where you would release a new version of the app one a year, and people who needed the new features would upgrade. In the time of monthly server costs (few apps can do without a backend), this model just doesn’t work anymore.

Consumables can bring you the much needed recurring revenue, but work very poorly for unlocking features. The repeated buying of consumables makes them great for games, where purchasing allows users to continue playing, for example, by buying additional lives.

3. Subscriptions: the gold standard

Subscriptions power the most profitable apps in the world. They give you predictable, recurring income and create a healthy incentive loop: the more value you provide over time, the longer users stay. They do also come with downsides:

• Since everything is now a subscription, “subscription fatigue” can make customers lose interest
• Dark patterns in getting users to subscribe to for example weekly subscriptions, can deter users from making a purchase if your app doesn’t have a good reason for paying for usage that often.

It’s important to select the right type of subscription periods for your app. One way to think of these:

• Weekly: Low commitment, popular in certain lifestyle categories.
• Monthly: Common baseline for SaaS-like apps.
• Yearly: Encourages long-term commitment, often with a discount.

Health, fitness, productivity, and education apps do especially well here. Users perceive them as ongoing journeys — and are more willing to commit for a full year.

The key is delivering consistent value. A subscription app that stops improving or engaging users will quickly see churn.

4. Virtual Currencies: build your own economy

This one has nothing to do with cryptos, virtual currencies are a flexible custom in-app economy. Instead of selling specific features, you sell credits that users can spend inside your app. There are other names for this as well such as credits, tokens, minutes.

Virtual currencies are easiest to explain through an example: if you build an AI-powered photo enhancer, you might sell 100 credits for $5, where each image generation costs 1 credit. You can even combine this with subscriptions: subscribers get monthly credits and can top up via consumable purchases.

This approach works beautifully for:

• AI/ML apps.
• Games.
• Creative tools with usage-based costs.

I feel that there’s a huge unexplored potential with virtual currencies.

Hybrid monetization strategies

The best way to go with monetizing is still to combine multiple strategies. Should be careful though, people can smell when you’re trying to just squeeze money out of them in multiple ways. Monetization should always make sense; people pay you because they feel they are getting the amount of value that they are paying for you or more. The more they end up paying, the more they expect to receive value in return. So make sure all your monetization has a purpose.

1. Ads + Subscription

Show ads to free users. When someone subscribes, remove the ads. If they cancel, ads return automatically once their entitlement expires. People subscribe for two reasons, at least technically:

1. Get rid of the annoying ads
2. Because they actually like the product

2. Subscription + credits

Give subscribers a monthly credit allowance (e.g., 100 exports). Heavy users can top up with one-time purchases. You capture value from both subscriptions, as well power users using your app more.

Building your subscriptions infrastructure

One word: don’t

Buying your subscription infrastructure

Ok, maybe this counts as a bit of an ad, but you should go with RevenueCat , and I’m certainly biased since I work there so take whatever I say with a modicum of salt.

There are very few rare cases where you should build your own subscription infrastructure, or even go with anything else. For starters Google Play Store APIs are generally not fun to work with: they are constantly changing, at times poorly documented, and well… built by Google 🤷‍♂️. Receipt validation, subscription status, and billing errors are just some of the things you will end up having to figure out. From personal experience I can say that there are way more fun things to do in app development.

There are other reasons for not building your subscription infrastructure yourself. The laws, rulings, and regulations around in-app purchases change constantly and you would have to keep up with all the markets your app is available in. Your development time is also limited, and I personally think developers should focus on bringing value to their users – not on the mechanics of extracting value from their users. \

Now all those horrible things I’ve told you about, RevenueCat takes care of them all. So give it a try, it’s free until you make $2,500/month, then pay 1% of tracked revenue. If you have any questions, just reach out to me.

Adding RevenueCat to your Android project

This article is already rather long and I still have a few points to consider, so I’m not going to add a tutorial here about adding RevenueCat to your Android app, but instead I’m going to link a few sources.

1. The best source for getting started with RevenueCat is their docs. Specifically this RevenueCat Android SDK setup.
2. RevenueCat Codelab gives you much of the same stuff but slightly more interactively.

Keep more revenue by purchasing on web

So far we’ve only talked about in-app purchases, where Google handles the underlying payment infrastructure. Google requires that all digital purchases made apps have to make use of their in-app infrastructure. For that honor they take a **15–30% **cut of all in-app purchase transactions. That’s fine early on, but when your app starts to grow, that cut will start to feel quite big.

However, it’s just a matter of time before purchasing through alternative payment providers becomes available for the Play Store. At least in the way it is for the App Store already in the US and soon in Japan.

So build your own web payment solution or use RevenueCat Web billing to do that. Let users pay via Stripe or Paddle, where commissions are 3–4%, and then just synchronize the purchase with your app. To stay compliant with store rules:

• Don’t link directly to external payments in your app (unless allowed by law).
• Use email or in-app messaging to direct users to your web checkout.
• When they complete the purchase, deep-link back to your app and associate the transaction. \

Easiest way is to use the web purchases for win-back campaigns. When a user cancels, automatically send them a discount link via email — e.g., “Come back and save 30%.” Since the transaction happens on the web, you don’t lose 30% to Google. If you’re interested in learning more, I’ve written a tutorial about web-based win-back campaigns with RevenueCat.

Final thoughts

Making money on Android isn’t easy, but it’s absolutely possible. Users are more comfortable with paying for apps they love to use nowadays, and in tricky cases you can always rely on the power of hybrid monetization models e.g. ads + subscriptions.

To emphasize the point I made earlier in this blog post: the best strategy for making money with your Android app is to build something people want and need. That means features and bug fixes, not wrestling in-app purchases infrastructure. After you've built something that people want, and monetized it in a way that makes sense, you can start looking into tweaking your monetization with web purchases for example.

Related articles

• How to Monetize Your Mobile App in 2026 - Complete guide covering iOS & Android monetization strategies
• React Native In-App Purchases with RevenueCat - Step-by-step implementation guide
• Building a Subscription Paywall in React Native - Pre-built paywalls with RevenueCat Purchases UI
• React Native in-app purchases: iOS & Android guide - Comprehensive in-app purchases overview

That's where ASC CLI steps in. It's an unofficial, open-source command-line tool for App Store Connect APIs, that lets you manage your entire App Store workflow from the terminal. Builds, submissions, metadata, localizations, TestFlight — all of it. And when you pair it with AI agent skills, things get really interesting. But we'll get to that in a bit.

Let's set it up first.

Step 1: Install ASC

One line, thanks to Homebrew:

brew install asc

ASC is in very active development and doesn't auto-update, so get in the habit of running this every now and then:

brew upgrade asc

Step 2: Connect to App Store Connect

You'll need an App Store Connect API key — the same kind you use for RevenueCat, Fastlane, or any other service that talks to the App Store Connect API.

2.1 Create an API key

Head to Users and Access → Integrations → App Store Connect API in App Store Connect and create a new key:

It'll ask you about access level. Admin gives you full access to everything. App Manager is enough if you're only managing app metadata and builds.

Once created, download the .p8 key file immediately. Apple only lets you download it once — if you lose it, you'll need to generate a new one. I'd recommend dropping it straight into 1Password or your preferred secret manager.

You'll also need two values from this page:

1. Issuer ID
2. Key ID

Here's where to find them:

2.2 Authenticate the CLI

Now wire it all together. ASC can store credentials in a few ways — the simplest is a local config file:

asc auth login \
  --bypass-keychain \
  --name "YourAppsName" \
  --key-id "ABC123" \
  --issuer-id "DEF456" \
  --private-key /path/to/AuthKey.p8

That's it. You're connected. But let's still break down what each part does. asc auth login tells the CLI you want to save a new set of credentials. --bypass-keychain stores them in a simple local file instead of the macOS Keychain — less hassle. --name is just a label so you can tell your credentials apart if you have multiple keys. --key-id and --issuer-id are the two values you copied from the App Store Connect API page. And --private-key points to the .p8 file you downloaded. Once you run this, every future ASC command is automatically authenticated. you don't need to pass these values again.

What can you do with it?

Let's run through a few everyday workflows to give you a feel for how ASC works before we get to the really powerful stuff. In reality you would not probably even use these in the command line yourself, since they are pretty difficult to remember, but let's still go through them so when we get to the skills section, we know what is actually happening under the hood.

Upload a build

Archive your app from the command line and upload it straight to App Store Connect. The first command here is not related ASC CLI directly, but it's needed so we can upload a build without Xcode.

xcodebuild clean archive \
  -scheme "YourScheme" \
  -configuration Release \
  -archivePath /tmp/YourApp.xcarchive \
  -destination "generic/platform=iOS"

xcodebuild -exportArchive \
  -archivePath /tmp/YourApp.xcarchive \
  -exportPath /tmp/YourAppExport \
  -exportOptionsPlist ExportOptions.plist

Then hand the IPA to ASC:

asc builds upload --app "APP_ID" --file "/tmp/YourAppExport/YourApp.ipa"

Submit for review

Once your build has finished processing, one command sends it off:

asc submit create --app "APP_ID" --version "1.2.0" --build "BUILD_ID" --confirm

Localize your store listing

Pull down your existing localizations, translate them however you like, and push them back up:

asc localizations download --version "VERSION_ID" --path "./localizations"
# ... translate the files ...
asc localizations upload --version "VERSION_ID" --path "./localizations"

These are just the basics. ASC has commands for TestFlight groups, encryption declarations, pricing, certificates, and a lot more. But here's where it gets fun.

ASC CLI + AI Agents = Magic

This is the part I'm most excited about. Rudrank didn't just build a CLI — he also built 19 skills that teach AI agents how to use it. Install them and your AI agent suddenly knows how to manage your App Store presence.

Get started with one command:

npx skills add rudrankriyam/app-store-connect-cli-skills

Pick which AI tool you want the skills installed for (I went with Claude), and you're good to go. Instead of memorizing flags and looking up build IDs, you just talk to your agent in plain language.

The real power is that these skills compose. In a single conversation, you could say: "Build and upload my app, check it's ready for review, localize into Japanese, Korean, French, and German, and show me what's crashing in the latest TestFlight build." That one prompt kicks off four different skills — build, preflight, localize, crash triage — and walks you through an entire release cycle without leaving your editor.

asc-xcode-build

Handles the entire build → archive → export pipeline. No fiddling with xcodebuild flags or hand-crafting ExportOptions.plist files. Just tell your agent "build my app and upload it" and it handles the rest.

asc-release-flow

An end-to-end release skill for both TestFlight and App Store, covering iOS, macOS, visionOS, and tvOS. It knows the right order of operations — create a version, attach a build, fill in metadata, submit.

asc-localize-metadata

This one is a game-changer. It uses LLM-powered translation to localize your App Store descriptions, keywords, what's new text, and subtitles across multiple locales. It knows the character limits (30 for subtitles, 100 for keywords, 4,000 for descriptions) and enforces them automatically.

asc-crash-triage

This skill pulls your TestFlight crash reports, groups them by signature, device, and build, and gives you a plain-language summary of what's breaking and why.

asc-subscription-localization

If you're using RevenueCat (or just have a lot of in-app purchases), this one bulk-updates subscription and IAP display names across every App Store language at once.

Wrapping up

I recently one shotted a small command line app with Claude and ASC CLI, and the only time I had to jump into App Store Connect was to create the app submission. This step you seem to be able to already automate as well, at least what I've been following the ASC CLI skills repo. Funny thing was that Claude even ended up creating a screenshot of the app itself and uploading it, which to be honest was a pretty bad screenshot, but still a screenshot.

ASC CLI is one of those tools that makes you wonder why you put up with the web UI for so long. The CLI on its own is already a huge time-saver, but the AI skills are what really set it apart. Being able to say "localize my app into Japanese, Korean, and French" and have it just happen — with character limits enforced and a review step built in — is a massive time saver. You can then use that time to obsess over the UX of your app instead, which is what you should be doing.

Give it a try: brew install asc. Your future self will thank you.

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 are 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 post 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.

Links

• Publish
• Netlify
• Swift
• My example repo

If you want to add in-app purchases to your React Native app, you need to understand the different types (consumables, non-consumables, subscriptions), set up products in App Store Connect and Google Play Console, and use a library like RevenueCat to handle the purchase flow across platforms. This article walks you through the entire process with working code examples.

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 consume 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 paid 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 want 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 payments 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 access 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 interested 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 earlier. 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 implemented 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 cached 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.

Related articles

• React Native In-App Purchases with RevenueCat: Complete Guide (2026) - Updated step-by-step RevenueCat setup guide
• Building a Subscription Paywall in React Native with RevenueCat Purchases UI - Pre-built paywalls, A/B testing, and remote configuration
• How to Monetize Your Mobile App in 2026 - Complete guide to app monetization strategies for iOS & Android
• How to make money with your Android app - Android-specific monetization strategies
• React Query + FlatList best practices - Build smooth list UIs for your app

Girl: "What's your idea of a perfect date?"

Engineer: "DD/MM/YYYY. I find other formats a bit confusing."

Dates can be structured in a multitude of ways:

• DD/MM/YYYY (most of Europe, Australia)
• MM/DD/YYYY (United States)
• YYYY/MM/DD (ISO 8601, East Asia)
• DD.MM.YYYY (Germany, Finland, Russia)
• YYYY.MM.DD (Hungary, Lithuania)
• DD-MM-YYYY (Netherlands, South Africa)
• YYYY-MM-DD (ISO 8601, Sweden, Canada)

What varies is both the separator between the numbers and the order of day, month, and year. In the US, the most common format is MM/DD/YYYY. In most of Europe, it's DD/MM/YYYY or DD.MM.YYYY.

I've built enough UIs over the years to know that eventually you'll need to localize your dates. I remember particularly well a case where we tried to push the European date format to US users. We received a lot of user feedback—zero positive. Turns out Americans don't appreciate you pushing your "superior" date format on them.

Now that we've established the problem, let's look at the solution.

The Challenge with React Native

Date localization in React Native is an interesting topic. If you navigate to Settings on iOS, you'll find a section in General → Language & Region that shows the user's preferred date and time formats. These settings are based on the language and region configured on the device.

The challenge is that React Native doesn't directly expose these system preferences. You can't simply ask the OS "what date format does this user prefer?" Instead, we need to combine a few tools to achieve proper localization.

The Solution: Intl.DateTimeFormat + react-native-localize

The approach combines two things:

1. Intl.DateTimeFormat — A native JavaScript API for locale-aware date formatting
2. react-native-localize — A library that exposes the device's locale information

Step 1: Install react-native-localize

First, install the library:

npm install react-native-localize
# or
yarn add react-native-localize

For iOS, run pod install:

cd ios && pod install && cd ..

Step 2: Understanding Intl.DateTimeFormat

Intl.DateTimeFormat is part of the ECMAScript Internationalization API (ECMA-402). It's supported in modern JavaScript engines, including Hermes (React Native's default engine since 0.70).

Here's a basic example:

const date = new Date('2023-10-15')

// US English format
new Intl.DateTimeFormat('en-US').format(date) // "10/15/2023"

// Finnish format
new Intl.DateTimeFormat('fi-FI').format(date) // "15.10.2023"

// German format
new Intl.DateTimeFormat('de-DE').format(date) // "15.10.2023"

// Japanese format
new Intl.DateTimeFormat('ja-JP').format(date) // "2023/10/15"

The beauty of Intl.DateTimeFormat is that it handles all the complexity of different locales for you. You just need to provide the correct locale code.

Step 3: Getting the Device Locale

This is where react-native-localize comes in. It provides the getLocales() function that returns an array of the user's preferred locales:

import { getLocales } from 'react-native-localize'

const locales = getLocales()
console.log(locales)
// [
//   { countryCode: "FI", languageTag: "fi-FI", languageCode: "fi", isRTL: false },
//   { countryCode: "US", languageTag: "en-US", languageCode: "en", isRTL: false }
// ]

The first item in the array is the user's primary locale. We can use the languageTag (e.g., "fi-FI") directly with Intl.DateTimeFormat.

Step 4: Putting It Together

Here's a simple utility function to format dates according to the user's locale:

import { getLocales } from 'react-native-localize'

export const formatLocalizedDate = (date: Date): string => {
  const [{ languageTag }] = getLocales()

  return new Intl.DateTimeFormat(languageTag, {
    day: 'numeric',
    month: 'numeric',
    year: 'numeric',
  }).format(date)
}

// Usage
const date = new Date('2023-10-15')
formatLocalizedDate(date) // "15.10.2023" for Finnish users, "10/15/2023" for US users

Advanced: Getting the Format Pattern String

Sometimes you need the format pattern itself (like "DD.MM.YYYY") rather than a formatted date. This is useful when you're working with date picker libraries or displaying placeholder text.

The trick is to use formatToParts(), which breaks down the formatted date into its components:

import { getLocales } from 'react-native-localize'

export const getDateFormatString = (): string => {
  const [{ languageTag }] = getLocales()

  return new Intl.DateTimeFormat(languageTag, {
    day: 'numeric',
    month: 'numeric',
    year: 'numeric',
  })
    .formatToParts(new Date())
    .map((part) => {
      switch (part.type) {
        case 'day':
          return 'DD'
        case 'month':
          return 'MM'
        case 'year':
          return 'YYYY'
        default:
          return part.value // This preserves separators like ".", "/", "-"
      }
    })
    .join('')
}

// Returns "DD.MM.YYYY" for Finnish, "MM/DD/YYYY" for US

Working with date-fns

If you're using date-fns for date manipulation (and you probably should be), you can combine the format string with its format function:

import { format } from 'date-fns'
import { getLocales } from 'react-native-localize'

const getDateFormatString = (): string => {
  const [{ languageTag }] = getLocales()

  return new Intl.DateTimeFormat(languageTag, {
    day: 'numeric',
    month: 'numeric',
    year: 'numeric',
  })
    .formatToParts(new Date())
    .map((part) => {
      switch (part.type) {
        case 'day':
          return 'dd'
        case 'month':
          return 'MM'
        case 'year':
          return 'yyyy'
        default:
          return part.value
      }
    })
    .join('')
}

export const formatLocalizedDate = (date: Date): string => {
  return format(date, getDateFormatString())
}

Note that date-fns uses lowercase dd for day and yyyy for year, which differs from the common uppercase notation.

Handling Time Formats

The same approach works for time formatting. Users have strong preferences about 12-hour vs 24-hour time formats:

export const formatLocalizedTime = (date: Date): string => {
  const [{ languageTag }] = getLocales()

  return new Intl.DateTimeFormat(languageTag, {
    hour: 'numeric',
    minute: 'numeric',
  }).format(date)
}

// "2:30 PM" for US users, "14:30" for most European users

Complete Utility Module

Here's a complete utility module you can drop into your project:

// utils/dateLocalization.ts
import { getLocales } from 'react-native-localize'

const getLocale = (): string => {
  const [{ languageTag }] = getLocales()
  return languageTag
}

export const formatLocalizedDate = (date: Date): string => {
  return new Intl.DateTimeFormat(getLocale(), {
    day: 'numeric',
    month: 'numeric',
    year: 'numeric',
  }).format(date)
}

export const formatLocalizedDateTime = (date: Date): string => {
  return new Intl.DateTimeFormat(getLocale(), {
    day: 'numeric',
    month: 'numeric',
    year: 'numeric',
    hour: 'numeric',
    minute: 'numeric',
  }).format(date)
}

export const formatLocalizedTime = (date: Date): string => {
  return new Intl.DateTimeFormat(getLocale(), {
    hour: 'numeric',
    minute: 'numeric',
  }).format(date)
}

export const formatRelativeDate = (date: Date): string => {
  return new Intl.DateTimeFormat(getLocale(), {
    month: 'short',
    day: 'numeric',
  }).format(date)
}

export const getDateFormatPattern = (): string => {
  return new Intl.DateTimeFormat(getLocale(), {
    day: 'numeric',
    month: 'numeric',
    year: 'numeric',
  })
    .formatToParts(new Date())
    .map((part) => {
      switch (part.type) {
        case 'day':
          return 'DD'
        case 'month':
          return 'MM'
        case 'year':
          return 'YYYY'
        default:
          return part.value
      }
    })
    .join('')
}

Gotchas and Tips

Hermes and Intl Support

If you're using Hermes (the default since React Native 0.70), Intl is fully supported. For older versions or if Hermes is disabled, you might need to polyfill it with packages like intl or @formatjs/intl-datetimeformat.

Caching the Locale

The locale doesn't change during app usage (unless the user changes their device settings and restarts the app). Consider caching the locale value:

let cachedLocale: string | null = null

const getLocale = (): string => {
  if (!cachedLocale) {
    const [{ languageTag }] = getLocales()
    cachedLocale = languageTag
  }
  return cachedLocale
}

Testing Different Locales

During development, you can test different locales by changing the language and region settings on your simulator or device. On iOS Simulator: Settings → General → Language & Region.

Conclusion

Proper date localization isn't just a nice-to-have—it's essential for any app with international users. The combination of Intl.DateTimeFormat and react-native-localize gives you everything you need to display dates in a format your users expect.

The key takeaways:

1. Never hardcode date formats—use Intl.DateTimeFormat with the user's locale
2. Use react-native-localize to get the device's locale settings
3. The formatToParts() method is your friend when you need the format pattern string
4. The same approach works for time formatting

Your American users will thank you for showing them 10/15/2023 instead of 15.10.2023.

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

Why nesting VirtualizedList inside a plain ScrollView is bad?

Virtualized lists, such as <SectionList> and <FlatList>, are performance-optimized, meaning they massively improve memory consumption and performance when rendering large lists of content. The way this optimization works is by rendering only the content currently visible in the window, usually the container/screen of your device. It also replaces all other list items with same-sized blank spaces 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, of course, it will 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 the 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, of course, give you the warning mentioned before, and you will also not be able to use the performance features FlatList offers. 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
      ListHeaderComponent={() => (
        <>
          <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.

Why WebRTC on Mobile?

Real-time communication isn’t just a feature for companies anymore; it’s something customers expect. People want to video call doctors, live stream content, or chat with friends—functionality that’s increasingly common across various apps. With mobile phones being the primary device for many people to stay connected, building for mobile becomes a natural first step for real-time communication applications.

Why React Native?

WebRTC on the web has proven to be fairly straightforward, and thankfully, the complexity doesn’t have to increase significantly on mobile—thanks to React Native. In case you’re unfamiliar, React Native is essentially JavaScript-based technology that enables cross-platform app development for iOS, Android, TVs, and even cars. What makes it effective is its ability to leverage web knowledge in a mobile environment and stay close to native APIs.

React Native provides a relatively quick way to get apps up and running in the app stores, and in my experience, the cross-platform aspect is highly efficient.

How to Get Started

To start a new React Native project, I recommend using Expo, a framework that simplifies access to native APIs, deployment, and rapid prototyping. To create a new Expo app:

npx create-expo-app@latest

Run the project with:

npx expo start

Now we have one small thing we need to take in to consideration, we need to run npx expo prebuild so that we can start using the native code parts as well.

npx expo prebuild

Next we need to think about how to integrate WebRTC to our project. We thankfully don’t have to look far since in react-native it is usually enough to just write “react native” and the technology you’re interested in, so let’s do react-native-webrtc and lo and behold, we have react native webrtc package!

React Native WebRTC

Most of the functionality that react-native-webrtc provides is identical to that of web. So for example these are most likely familiar to you if you’ve worked on WebRTC before. If not, worry not, let’s look at some basic things:

import {
	ScreenCapturePickerView,
	RTCPeerConnection,
	RTCIceCandidate,
	RTCSessionDescription,
	RTCView,
	MediaStream,
	MediaStreamTrack,
	mediaDevices,
	registerGlobals
} from 'react-native-webrtc';

Getting local stream

WebRTC provides standard APIs for accessing cameras and microphones on computers and smartphones, same goes for React Native WebRTC. We can access these devices through the get mediaDevices API:

const mediaStream = await mediaDevices.getUserMedia();

By default react-native-webrtc expects us to send both audio and video. To limit this we can define media constraints:

let mediaConstraints = {
	audio: true,
	video: {
		frameRate: 30,
		facingMode: 'user'
	}
};

If we want to share our screen we can use

const mediaStream = await mediaDevices.getDisplayMedia();

To actually display anything we can make use of the <RTCView /> component to render both local and remote streams:

And there we have it, a very quick, but working implementation of WebRTC on React Native.

Additional Packages for a Full Video Calling App

For a complete calling experience, consider adding:

• react-native-incall-manager: Manages events like headset plug-ins. • react-native-callkeep: Integrates your app with native call screens.

WebRTC Across Platforms

The beauty of React Native WebRTC is that it works seamlessly on iOS and Android, requiring minimal platform-specific code—only permissions differ between platforms. Performance holds up well, though lower-end Android devices may struggle slightly.

Beyond mobile, React Native WebRTC opens possibilities for platforms like tvOS and even web through React Native Web. The react-native-webrtc-web-shim allows you to extend your React Native app to the web, making it possible to build a mobile-first, cross-platform app supporting WebRTC.

Limitations of React Native WebRTC

While react-native-webrtc offers a solid foundation, it’s primarily geared toward voice and video calls. For example, if you’re using it solely for streaming, the package still requires microphone permissions, which can be a roadblock. In our project, we customized our instance of react-native-webrtc to avoid this.

Another limitation is the lack of picture-in-picture (PIP) support on mobile. PIP currently only functions within the app, not when users switch to other apps. However, recent developments suggest iOS PIP support might be on the way.

Conclusion

React Native WebRTC makes implementing real-time communication feasible on mobile, with extensive cross-platform support. While there are limitations, its flexibility allows it to serve various real-time media needs. Whether you’re building a video-calling app or incorporating streaming features, React Native WebRTC is a powerful choice that could simplify your development process.

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 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 🙂

If you're quickly asked to name three of your favorite books and their authors, you probably won't have to think about it too long. However, asking anyone to name their three favorite movies and then asking to name the people who wrote the screenplays for them is definitely harder. Even the biggest movie buffs have a hard time doing that. For most of us, movies are formed by the directors and actors. Who came up with the story seems less important. With novels we have almost the exact opposite: authors are celebrated, and sometimes who wrote the book weighs more than the story being told. But why? Aren't screenwriting and novel writing just different ways of telling stories?

At first glance: Similar story structures

On the surface, screenwriting and novel writing seem very similar: you take interesting characters, create a story that makes them go through events that conflict with their beliefs, and eventually reach the end of the story with changed characters. Or that's how it goes if you're writing a monomyth.

The fundamental differences: Scope, character depth & time

How much you can develop the characters and how many life-changing events you can throw in your character's journey differ a lot between screenwriting and novels; a book you read for 6 hours has too much content to fit into a blockbuster movie, and script for a feature-length movie can easily be read through in under an hour.

Underneath the surface of screenwriting, the differences between novels become evident. While many novels are treated as exemplary students who proudly carry the author's name, screenplays are disowned offspring, monospaced bastards. As the script goes through the adoption process of becoming a movie, it sheds its familial connections to the original screenwriter. It becomes a product of the tribe of actors and directors.

Perhaps because it's easier to strip the story to its central themes than it is to build a compelling book from a simple story premise, it seems to be more common for novelists to end up writing scripts or modifying their original stories into screenplays. Take for example Gillian Flynn, author of books such as Gone Girl, Sharp Things, and Dark Places, all of these have been turned into movies or television productions, Flynn being a screenwriter on Gone Girl and co-writer of Sharp Things.

Why screenwriters are often invisible

Screenwriting is also a rather weird and disrespected profession. You churn out scripts and submit them; if you’re really good, someone might pick up your script for further development. Eventually, even a movie might come out that vaguely resembles your original screenplay. Or if you wrote the script for the 2003 Daredevil, you get a version that got run over by a movie exec in a Humvee and reanimated with Evanescence. That’s just the nature of movies. After all, they are “productions,” communal art projects rather than singular visions.

It's no wonder that screenwriting does not get the attention that it (in rare cases) deserves. Hollywood seems to treat screenwriters akin to sperm donors: you give out the goods, we raise your kid, and in turn, you get to enjoy reverse child support. Alternatively, you might get paid only once when handing in the script for the first time, just like the good old times when selling little jack to the mines could net you enough food to survive the winter.

Case study: The making of Se7en

The 1995 movie Se7en is the aptest example of the nature of screenwriting. Our story starts in the early nineties, with an aspiring screenwriter Andrew Kevin Walker (other notable works: The Killer, 8mm, Sleep Hollow) landing in New York City and getting so depressed about the bleak city and its crime problems that they decide to write a thriller about police officers on the hunt for a serial killer with a biblical thirst for committing murders in the style of the Se7en deadly sins. If that does not sound like the simplest but, at the same time, the raddest plot line, read the premise again while listening to Nine Nine-Inch Nails Closer.

Now, a good script isn’t enough by itself. You also need someone to produce it into a movie. In the case of Se7en, the script went through a few studios before eventually landing at Newline Cinema, which was finally ready to adopt this child. However, as it often is with foster kids who get bounced from one home to another, Se7en was considered too dark. The infamous ending was considered so bleak that Walker had to do multiple rewrites. You can find one of these rewritten scripts on the internet, and the ending part is definitely a choice with the story ending in a shootout in a church. I can just picture movie execs going “a movie about Se7en deadly sins ending in a church, get it? Eh? Eeeh?”

As mentioned, the movie we know has a different ending, which can only be attributed to someone accidentally sending the original script to David Fincher, who would become the movie's director, instead of the alleyway doctored version. Fincher mixed in some of his signature style (if you ever find your life having desaturated colors and corruption in seemingly prosperous settings, you're either depressed or in David Fincher movie), baptizing the script into the violent neo-noir classic we know as the Se7en.

From script to novel: The Se7en novelization

At some point, before Se7en came to theaters in September 1995, someone decided that the movie needed a book tie-in. I’m not sure how common this was at the time or how common it is even nowadays, so one can only guess who thought the movie needed this and why. Perhaps someone at Newline was worried that the movie would bomb and hoped that a novelization would regain some of the dollars that went into production. Whatever the reason, Anthony Bruno was commissioned to write the novelization (with Walker getting credit for the original screenplay in the books).

There is not much information concerning Bruno or his thoughts on writing the novelization. Based on a quick Goodreads skim, it seems Bruno has made his career writing non-fiction and fiction crime books, with the latest published in 2014. Perhaps a bit surprisingly, the Se7en novelization appears to be his highest-rated work, with 4.23 stars on Goodreads (although this is based on only a bit over 4000 reviews).

With around 250 pages, Se7en is a very short book, something an average reader would go through in 7-8 hours. Now, considering that the book revolves around Se7en deadly sins-themed murders, we can quickly calculate that on average, the murder discussed in the book would get only 35 pages to introduce the murder victim, murder scene, and characters related to the murder. This is very little page estate to use, making Se7en feel like sprinting through cliff notes.

Comparing the script, the film & the novelization

Although the book feels like it was written very quickly, with both redundancy and continuity errors, the novelization does develop the characters of Somerset and Mills a bit further. Somerset’s nihilistic worldview, for example, becomes more fleshed out, turning Somerset’s “Ernest Hemingway once wrote, ‘The world is a fine place and worth fighting for.’ I agree with the second part.” quote into something that reflects more on the character inner turmoil rather than being a cliche of forced positivity it is in the movie.

But does reading the novelization bring additional value over watching the movie? Well, it’s certainly more difficult to get through if you’re glancing at your Instagram at the same time, so it must feel like there’s more depth to it. But I think the real question is whether the novelization beats reading the original script. For that, the answer is more multifaceted. Reading scripts requires you to picture the scene to bring depth to the story actively:

In the above scene, for example, very little is explained about how the characters talk to each other: the focus is on what is being said. This is deliberate, allowing actors to bring personality and depth to the characters. If you're capable of putting yourself into the shoes of an imaginary director and reading the script as if you were getting ready to shoot it, then go with reading the script instead of the novelization (also it's available for free on the internet).

Personal reflection: Why this story resonates

Despite its shortcomings, the novelization of Se7en has had a special place in my heart ever since I accidentally stumbled on it in my father's collections when I was ten. It is one of the only two books I’ve ever read more than once, the second time being after I had seen the movie more than 5 times already. I enjoy both the book and the movie for different reasons. The movie’s acting, characters, cinematography, and camera work are something I find myself coming back to because similar combinations seem to be much rarer in this age of comic book movies. For me, the movie is a video essay on how to tell a great story on a screen.

The book has none of those qualities. It's a clumsily written movie tie-in from an unknown author, and for most people, that's all it is.

Conclusion: Medium matters — but story transcends

But for me, it's a love letter to how a good story transcends its medium.

const Tooltip = ({ content }: { content: string }) => (
    <div className="bg-white">
        <div className="[&>p]:text-zinc-800"
            dangerouslySetInnerHTML={{ __html: content }}
        />
    </div>
)

Essentially you can target any element using the [&>element] syntax. Tailwind itself for example has an example of [&:nth-child(3)], and in case you need to style for example all the p elements in the dangerouslySetInnerHTML, not just the direct descendants as in the example above, you can use underscore: &_p as replacement for space in your selector.

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 <TouchableWithoutFeedback/> 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
  • Expo
  • CodePush
  • Remote Config
• Measure everything.
  • AWS Amplify
  • App Center
  • Firebase

Design is the process of making sense of things, as well as solving the problems that are found through sense-making. Human-centered design is an approach that aims to incorporate the perspective of the user into this process so that the needs of the users are addressed better, which in turn leads to better solutions. In human-centered design, the role of the designer is to formulate the solutions by understanding the user, not by acting on the insights by the designer himself. This article evaluates the previous statement through aspects found in the literature. I start by proposing that human-centered design is always affected by the designers’ perception of the surrounding world and users. I call this collection of emotions, beliefs, and other human properties, the “designers ’ flavor,’ and continue by proposing that it plays a central role in innovation. The claims surrounding incremental and radical innovation are evaluated against the proposition of designers having an important role in igniting innovation.

Introduction

To design is to create a plan or convention that will lead to a construction of an object, service system, or possibly even an experience. It is a direct result of human decisions and happens whether you do it while aware of it or not. As such, there are no human-made things that didn’t have a design, and the question lies in whether the item is a product of good design or bad design or something residing in between these two opposites. This leads to another way of concretizing the term design by calling it a property of an object that communicates the function of the object through it’s designed to form.

For example, if we imagine a person that is like us in every manner except that said person had never encountered a bucket. Now let us imagine a situation where this person encounters a bucket for the first time in his life. For a short time, this person would not have the slightest idea of the use of the bucket, but in good time this person would learn to use the bucket, for example, to transport water from well. This is a scenario of understanding the bucket’s function as a vessel is only possible because of the form of the bucket.

Additionally, to merely being the property that communicates function, the design is also the process that leads to solving of a problem by making sense of things [4]. The design of the bucket and the bucket itself was not born from a void; it was the result of both encountering a problem of transporting water from a well, and solving that problem. The solution was born from noticing a hindrance in life and solving it by understanding that the solution is constrained by the ones affected by the design. Such is the essence of human-centered design. But understanding human-centered design is not possible by merely reducing it to two components. If we want to inspect the way designers solve these problems through human-centered methods, we have to examine the process from the ground up.

As design is always the result of human decision, the same issues also affect it as other actions based on the human decision [10]. In some cases, these human characteristics of designers such as beliefs, biases, interpretations, and experiences might provide innovative solutions, while in others for example in the case of novice designer’s the solutions might turn undesired [19]. Take, for example the previously mentioned bucket. One designer that has interpreted the main goal as carrying as much as water as possible might design a bigger bucket. While another designer might focus on improving the ergonomics of the buckets handle. As such, it is hard to say which one of the designers have provided a better solution. However, this demonstrates how the design process and its outcomes change drastically based on the actor.

In this article, the design process, according to the human-centered design approach is inspected more closely and the methods employed in it are evaluated against the outcomes. The focus of this article is on the inspection of how the designers themselves play a central role in HCD. We look at a body of literature consisting of articles that critique the effectiveness of HCD and especially its role in the development of innovation. I propose based on the reviewed research that the UCD process is capable of producing even radical innovation, but not without first developing methods to address the human characteristics of designers.

Human-centered design — the basis for incremental innovation

Human-centered design (HCD) is an approach concerned with incorporating the user’s perspective into the process [1,2,14]. According to the ISO-9241–210 standard it aims to make systems usable and useful through focusing on users, their need and requirements, as well as the properties of the users. End products and services that are produced through the HCD process quite often also employ interactiveness, meaning that product is designed, evaluated and redesigned until the product is deemed ready [3,14].

As previously stated one of the key components in HCD is the understanding the humans who are affected by the product or service, also know as the users. [5] The HCD process emphasizes conducting qualitative and contextual research for better understanding of the stakeholders at hand [5,12]. From this understanding, we can produce requirements for the product. A central method in gathering qualitative data is ethnographic field research, which is the process of studying groups and people through immersing the designer into the social setting [6,7]. Immersion is especially essential, as no deep understanding of the subject at can come from only observing the daily life of the subject from the outside. Actual knowledge comes from action and experience in the context [13]. As crucial as immersion, is the production of field notes, transformation of knowledge into written records observation and participation [6]. However, this also points in the design process where individual differences between designers create different interpretations of both the problems that people come across, as well as ways they interact [19]. This, in turn, leads to differences in what type of solutions are devised by the designers.

Where ethnographic research provides sparks for ideas and directions in which to take the product, are many of the HCD methods defining, correcting, and adjusting in their approach [11]. Methodologies such as rapid prototyping, testing, use observations, and interviews are just some of the several methods for finding out how the on-going design process can be elevated to better reflect the requirements of the users. Especially central, this is deemed in the areas of usability and accessibility, where the implicit image that the designer has of these properties is by itself insufficient [8]. This type of “poking” the design in the right direction through iterative changes in usability, functionality, and accessibility could also be seen as a method of hill-climbing that aims to reach the designs local optimum, however, for this work there has to already be a starting point [4]. The important thing to notice from all of this is the fact the there is significant difference in how much designers’ interpretations affect the design solution generation versus how much they affect the development of already devised solutions. In the latter, the interpretations of the designers have a less significant role, as the methods are more structured [8].

Donald Norman and Roberto Verganti have stated that HCD can provide incremental innovation in products, a statement that was based on the observations of the types of innovation in different cases [4]. Before diving into the meaning of incremental innovation, the concept of innovation will need to be concretized. Robert Reimann explains that innovation is often misunderstood and narrowly applied to advances in technology and production methods, but should also be extended to include a human-centered perspective of on empowering people to do more and do things easily [5].

How Norman and Verganti define incremental innovation is similar to Reimann’s narrower definition. According to Norman and Verganti, incremental innovation refers to all the small changes that end up improving its cost-effectiveness, performance, desirability, or result in a new release of the product [4]. Norman and Verganti also note that most successful product undergoes continual incremental innovation, a matter that can be addressed to businesses often trying to beat their competition through better products. Good examples of products that undergo incremental innovation are computers, which often go through periods in which no radical change happens in them but properties such as performance, size, and energy consumption are enhanced with every iteration.

Figure 1. The diffusion of ideas, according to Everett Rogers. The blue line illustrates the successive groups of consumers adopting new technology. Yellow line illustrates the market share and its eventual saturation. Image CC-BY-AND Wikipedia.org

In addition to the earlier argument of incremental innovation being a driving force behind companies’ product differentiation process, it could also be argued that it is also behind the product adoption rate. Evidence to this can be formulated from the diffusion of innovations theory first introduced by Everett Rogers [9], which seeks to explain how and why new ideas and technology spread through cultures. The central concept of Rogers theory is that the potential users of a product can be categorized into 5 groups, whose sizes follow a normal distribution. Illustration of this can be found in figure one.

Rogers theory can be used to argue that HCD plays a central role in grounding innovation. The earlier mentioned viewpoint of HCD as a hill-climbing strategy is in line with this, as ideally, innovations’ should transition towards the goal of being more accepted by users [4]. HCD provides means for this through elevation of such properties as usability, accessibility, aesthetics, and experience. However, this notation has led some people to state that HCD is not capable of giving birth to radical innovation, as it focuses on incremental change in products. The next chapter will inspect this statement more closely as well as provide a counter-argument.

Radical innovation — where designer's flavor comes in to play

Today the concept of HCD is entirely accepted by practitioners [5.] However, not without critique [4,5,12]. There have been doubts that if HCD process really helps in understanding users, is it possible that it’s obscuring designers’ view of possible solutions and if the emergence of radical innovation is possible through HCD as stated earlier [4,12].

At this point, it’s time to refine the concept of designers’ interpretations or “designer flavor” to reflect on the arguments of radical and incremental innovation development. Although novel by name, designer flavor, or the more familiar individuality is an old subject and topic of research in many research fields such as philosophy, psychology, economics, etc. When I talk about designer flavor, I’m are talking about the central properties of the human that create the basis for individuality, such as beliefs and emotions that in general can be seen as different mental representations. Our interaction with the surrounding world is based on our representations [11,14,16]. Therefore an argument that design process always is always a reflection of the designer can be made.

Bardzell provides an additional view of the previously stated and argues that the traditional approach of using the truth in the world is insufficient in some areas of HCD [14]. For example, user experience design (UXD) although extensively used and almost a buzzword, has a different definition and scope depending on whom the question is asked [14, 16]. According to Bardzell UX is one the areas of HCD that cannot be addressed by representationalist approach, which means that the correct knowledge is the product of representation (e.g., an idea or understanding) and given external reality. So, for example, the knowledge of how experiences are designed is “not out there” or there doesn’t exist a way to connect the reality and our mental representations [14]. Hassenzahl, who argues that the end products of design do not necessarily reflect upon the underlying needs, provides a similar argument. Experiences have to be designed from the point of understanding why people engage with such experiences, and as we are unable to understand fully how other people experience things [17], we have to someway incorporate our own experience into the process. As such, the designer plays a central role in the HCD process in incorporating these properties to the design, through his understanding of them.

As stated earlier Norman and Verganti argue that HCD in insufficient in producing radical innovation. According to them, radical innovation is born from either change in the meaning of the object or from the development of new enabling technology [4]. They continue that no evidence of radical innovation was found from the products that resulted from the HCD process and concluding that design research and formal analysis of needs is unnecessary for giving birth to radical innovation. The statement can be seen to hold the truth in the case of technological advances. The example used by Norman and Verganti comes from the world of video games. They provide convincing evidence of how the advancement of technology-enabled radical innovation that was sufficiently powerful in enabling the production of an entirely new collection of video games.

Norman and Verganti’s example of a change in meaning reviews how Nintendo changed the video game industry by changing the meaning of video games from a product targeted to niche segments to a product that meant meaningful experiences for everyone [4]. However, it could be suspected that this change in meaning ignited from the efforts of the designers at Nintendo to make video games more accessible by different types of people. This, in turn, can be simplified to consist of two parts:

1. Understanding who are the users that cannot be reached by merely producing games with better graphics but also understanding why these users cannot be achieved through this method.
2. Innovating a solution to bridge this cap between video games and a broader audience.

The first part is a direct consequence of understanding the people, which is the product of design research, and Norman and Verganti note that in this way HCD can provide a base for sparking innovation but it insufficient to do so by itself.

I now argue that although Norman and Verganti’s evidence holds in case that HCD is insufficient to produce radical innovation by itself, it is with the addition of designer's own interpretations fundamental to sparking radical innovation. It is the combination of these two that leads to employing a different design space that allows the development of radical innovation. Norman and Verganti’s idea of modifying the HCD process to require simultaneous development of multiple ideas and prototypes is not enough to spark radical innovation. The design purpose must be selected by the designer, not by the beneficiaries and be integrated continuously [12]. According to Sas, Cockton and Reimann and the problem with HCD is not that is doesn’t create radical innovation, as it was never meant do that. The problem with HCD is that it's not efficiently used to spark this innovation and cultivate it after the ignition [5,12,18].

As a final point I want to bring in the aspect of co-design to focus on the second part of the presented development of video games. As stated earlier, there are parts of the design where the truth in the world is not sufficient, such as experience design [14]. In these cases, empathy is central to the design process [18]. In co-design, this level of empathy can be elevated. And while I have argued that radical innovation can be sparked from the combination understanding the user and the designers’ interpretations of the world, there is still a possibility that no innovation is born and even some cases we end up with products that do not truly reflect the user's needs. Co-design could be seen as a solution to this as it has the potential for to provide better understanding of the users, help in making sense of things, and provide starting points radical innovation [18].

Conclusion

This article has reflected on the role of the designer in the HCD and reflected on what is the role of the designer’s interpretation to the process. The focus has been narrowed down to inspection of innovation, making use of the concepts of incremental and radical innovation. I have proposed that designers’ interpretations of the world combined with human-centered design, plays a role in sparking radical innovation. Due to the scope of this article, the subject has been only vaguely introduced and weight has been shifted to inspecting the concept in relation to theories of innovation development in HCD. However, the subject of designers’ interpretations role in HCD is interesting and should be examined on its own, in relation to several other factors of design.

As a conclusion, human-centered design is both a process and approach to how that should incorporate the user throughout the whole design process. However, simply involving user as a mean of incrementally improving the design is not enough. For establishing radical innovation in design, there has to be a way of incorporating knowledge of the user that cannot be found by purely objective methods. How designers interpret the surrounding world provides a starting point for this, but actual user involving interpretation can only be found by co-designing approaches.

I recently published @perttu/app-store-scraper, a TypeScript rebuild of the app-store-scraper by facundolaano (it's a really good package by the way). I wanted to keep all the same features, just add TypeScript support improve some of the scraping after Apple updated their App Store website.

The package gives you the following features:

• app() - Get app details
• search() - Search for apps
• list() - Get curated lists
• developer() - Get developer apps
• reviews() - Get user reviews
• ratings() - Get rating histogram
• similar() - Get similar apps
• suggest() - Get search suggestions
• privacy() - Get privacy details
• versionHistory() - Get version history

Play around with the package

To test them out I built this little website where you can test all the APIs. All the data it returns comes from the scraping API.

One of the things you will run into when using this package is that the App Store API is rate limited

The Search API is limited to approximately 20 calls per minute (subject to change). If you require heavier usage, we suggest you consider using our Enterprise Partner Feed (EPF). For more information, visit the EPF documentation page.

Simplest fix to this this is using both memoization and throttling. I didn't want to add these features to the package itself, because I wanted to keep it as minimal as possible. Show here's instead a guide on how to implement them yourself.

Throttling and memoizing app-store-scraper

The easiest way to implement throttling and memoization is to use the p-memoize and p-throttle packages. Start by installing them:

bun install p-memoize p-throttle

Memoization

Then when using the package, you can wrap the functions with the memoize:

import { app, search } from '@perttu/app-store-scraper';
import { memoize } from 'p-memoize';

const cachedApp = memoize(app, { maxAge: 600000 });
const cachedSearch = memoize(search, { maxAge: 600000 });

Now when you use the package, you can use the cached functions instead of the original ones:

const appData = await cachedApp({ id: 553834731 });
const results = await cachedSearch({ term: 'minecraft' });

First time calling the function will be slower, because it will fetch the data from the API. But subsequent calls will be much faster, because the data will be cached. You can also specify the max age of the cache, so that the data will be refreshed after a certain time.

Throttling

With throttling you can limit the number of calls to the API within a certain time window. You're forced to do this because Apple's rate limits. Throttling only really comes to action when you're scraping over 20 apps, so use if for example when scraping a list of apps. This is what I did for Shipaton Apps Showcase. Here's how to throttle the app function for with list of 100 apps:

import { throttle } from 'p-throttle';
import { app } from '@perttu/app-store-scraper';

const throttledApp = throttle(app, { limit: 20, interval: 60000 });

const apps = await Promise.all(Array.from({ length: 100 }, async (_, index) => {
  return await throttledApp({ id: index + 1 });
}));

This will call the app function 100 times, but only 20 at a time, because of the throttling. You can also specify the interval, so that the calls are spaced out over a certain time.

That is pretty much it. If you have any questions, shoot me a message on Twitter or LinkedIn.

1. Styled-components with VS Code and types for styled-components
2. Theme variable suggestions using declaration merging
3. Type checking for component props

Styled-components With VS Code

As a prerequisite, it is crucial to mention the vscode-styled-components plugin for VS Code. This plugin vastly improves the writing of styled-components with syntax highlighting, error reporting, and IntelliSense. When combined with TypeScript and styled-components, the developer experience is truly enhanced.

Styled Components doesn’t come with types so we need to install them either running:

npm i --save-dev @types/styled-components

or alternatively

yarn add @types/styled-components --dev

Theme variable suggestions using declaration merging

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:

// The commonly seen way of accessing them
const TextOne = styled.Text`
  color: ${(props) => props.theme.primaryColor};
`

// Or by using object desctructuring for cleaner code
const TextSecond = 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 IDE 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 on how declaration merging works can be found here, and here). Here’s how to achieve that:

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

2. Then we create the theme file, import the original styled-components module declaration and extend it using declaration merging. We add our own theme variables like primaryColor to the DefaultTheme and tell our theme objects to use that interface.

// 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>
  )
  authors: [{ name: article.author }],
}

export default App

We could do this in a separate styled-components.d.ts declaration file, but placing it inside the themes.ts file allows us to tweak the theme definition at the same when we add new variables.

With the declaration merging done using the theme variables suggestions in VS Code should look like this now:

No more guessing whether it was accentColor or colorAccent.

Type-checking for custom Props

Another typical case with styled-components is using the props of the styled component to alter the styling, e.g. creating a button container that has the prop “disabled” and then using it as the conditional for reducing opacity like this:

import React from 'react'
import styled from 'styled-components/native'

type Props = {
  disabled: boolean
}

const StartButton = ({ disabled }: Props) => {
  return (
    <Button disabled={disabled}>
      <ButtonText>Start counter</ButtonText>
    </Button>
  )
}

const Button = styled.TouchableOpacity`
  opacity: ${(props) => (props.disabled ? 0.5 : 1)};
`

const ButtonText = styled.Text`
  font-size: 17px;
`

export default StartButton

This works pretty well and when we type props.something VS Code should even show us an IntelliSense suggestion for the disabled prop, as long as we’ve installed the styled-components type definition. This is because those type definitions contain the type definition for TouchableOpacity with definition for the disabled prop. However, if were to define our own prop, something such as primary which would be of boolean value we would get a type error like the below:

To fix this we need to add a new type for our button which contains the primary prop and then tell styled-components to use it:

type ButtonProps = {
  primary: boolean
}

const Button = styled.TouchableOpacity<ButtonProps>`
  opacity: ${(props) => (props.primary ? 0.5 : 1)};
`