This is easily achieved using SwiftUI’s safeAreaInset:

List(0..<100) { i in
  Text("Row \(i)")
}
.safeAreaInset(edge: .bottom) {
  VStack {
    Text("Some summary content")
    Button(action: {}) {
        Spacer()
        Text("Save")
        Spacer()
    }
    .buttonStyle(.borderedProminent)
  }
  .frame(maxWidth: .infinity)
  .padding()
  .background(.background)
}

Recently I’ve been evolving PB’s design and one way I’m doing that is by adding a slight inset to these cards, so they float above the content. I feel like it fits in more with iOS 26’s look and feel.

Insetting the card

Insetting the card is easily done by adding some extra styles like padding and corner radius:

// same code as the prior example, plus the below modifiers
.cornerRadius(20)
.overlay(RoundedRectangle(cornerRadius: 20).stroke(.gray.opacity(0.25), lineWidth: 1))
.shadow(color: .black.opacity(0.1), radius: 5)
.padding()

It doesn’t look quite right though. Even with the border and shadow, it’s hard to tell it apart from the content below.

Fortunately there’s a simple fix: safeAreaBar. A safe area bar is functionally the same as a safe area inset except it applies iOS 26’s scroll edge effect where the content blurs, fixing the readability issue.

iOS 18 fallback

Unfortunately there’s an issue with this: safeAreaBar requires iOS 26. At the time of writing PB supports iOS 18, so I needed a workaround.

So, I built a fallback that works on iOS 18 combining an ultraThinMaterial and a gradient to give the content behind the card a soft fade effect.

.safeAreaInset(edge: .bottom) {
  myContent
    .background {
      Rectangle()
        .fill(.ultraThinMaterial)
        .mask(
          VStack(spacing: 0) {
            LinearGradient(
              colors: [.clear, .black],
              startPoint: .top,
              endPoint: .bottom
            )
            .frame(height: 30)
            Color.black
          }
        )
        .ignoresSafeArea()
    }
}

The VStack inside the mask is the key bit. The top 30 points are a gradient from clear to black, which means the material gradually becomes visible as you scroll down. Below that, the mask is solid black, so the material is fully opaque behind the bar itself.

.ignoresSafeArea() on the background lets the material extend all the way to the bottom edge of the screen, under the home indicator.

Making it reusable

The final step was to abstract this out into a something reusable that would use a safeAreaBar on iOS 26 and fall back to my custom version on iOS 18. The code for that is below:

import SwiftUI

extension View {
  func floatingSafeAreaBar<InsetContent: View>(
    @ViewBuilder insetContent: @escaping () -> InsetContent
  ) -> some View {
    modifier(FloatingSafeAreaBar(insetContent: insetContent))
  }
}

struct FloatingSafeAreaBar<InsetContent: View>: ViewModifier {
  @ViewBuilder let insetContent: () -> InsetContent

  @ViewBuilder
  func body(content: Content) -> some View {
    if #available(iOS 26, *) {
      content.safeAreaBar(edge: .bottom) {
        insetContent()
          .modifier(CardStyle())
      }
    } else {
      content.safeAreaInset(edge: .bottom) {
        insetContent()
          .modifier(CardStyle())
          .background {
            Rectangle()
              .fill(.ultraThinMaterial)
              .mask(
                VStack(spacing: 0) {
                  LinearGradient(
                    colors: [.clear, .black],
                    startPoint: .top,
                    endPoint: .bottom
                  )
                  .frame(height: 30)
                  Color.black
                }
              )
              .ignoresSafeArea()
          }
      }
    }
  }
}

private struct CardStyle: ViewModifier {
  func body(content: Content) -> some View {
    content
      .padding()
      .frame(maxWidth: .infinity)
      .background(.background)
      .cornerRadius(20)
      .overlay(RoundedRectangle(cornerRadius: 20).stroke(.gray.opacity(0.25), lineWidth: 1))
      .shadow(color: .black.opacity(0.1), radius: 5)
      .padding()
  }
}

The CardStyle modifier wraps the inset content in a card with all my styles applied: full width, padding, rounded corners, a background colour, shadow and border.

Using it

Now I have a convenient view extension I can use anywhere to get a pre-styled card.

ScrollView {
  // ... your scrolling content
}
.floatingSafeAreaBar {
  VStack {
    Text("Some summary content")
    Button(action: {}) {
        Spacer()
        Text("Save")
        Spacer()
    }
    .buttonStyle(.borderedProminent)
  }
}

Here’s a few screenshots of how it looks in practice in my app:

The future

Even when iOS 26 becomes my app’s minimum supported version this view extension will remain useful for applying consistent styles to these cards throughout the app. I’ll simply remove the fallback code and make it use a safeAreaBar all the time.

For this I was using OneSignal which is fine but felt like overkill for my use case. Also I really didn’t like having to add their SDK to my project. It’s over 23,000 lines of code, requires its own notification service extension target, and phones home on every app launch. I try to keep my dependencies very minimal, so I was never happy about having to include this.

So, I replaced it with a Cloudflare Worker that’s about 200 lines of TypeScript plus a few of lines of Swift in the app. The whole thing costs nothing on the free tier.

What I actually need

My requirements are simple:

• Store device tokens so I can send notifications later
• Know whether each user has Personal Best Pro or not, so I can target messages
• A basic admin UI to send messages

I’ve deliberately kept it very lightweight for now. I might want to add things like media attachments later, but I’m not worrying about that right now.

The service: Pushy

I built a Cloudflare Worker called Pushy. It has three endpoints:

• POST /tokens – register a device token. Accepts a JSON body with the token and whether the user has Pro.
• DELETE /tokens – deregister a device token. Used when someone opts out of notifications.
• GET /admin – a simple HTML page where I can compose and send a notification.

Tokens are stored in Cloudflare KV, which is a key-value store. Each token is a key, and the value is some metadata (pro status, registration date). When I send a notification, the worker reads all tokens from KV and sends each one to APNs directly.

Sending to APNs

This was the part I expected to be hard, but actually it was super easy, barely an inconvenience. Apple’s Push Notification service has an HTTP/2 API. You POST a JSON payload to https://api.push.apple.com/3/device/{token} with a signed JWT in the header. Cloudflare Workers support the crypto APIs needed to sign the JWT, so no external dependencies are required.

If APNs returns a 410, the token is stale (the user uninstalled, or their token rotated). Pushy deletes these automatically, so the token list stays clean over time.

The app side

On the iOS side, all I needed was to:

1. Get the APNs device token when the system provides it
2. POST it to Pushy on registration
3. DELETE it from Pushy on opt-out
4. Skip redundant calls if nothing has changed

The networking code is minimal:

private static func sendPushyRequest(method: String, body: [String: Any]) async -> Bool {
  guard let url = URL(string: "\(baseURL)/tokens") else { return false }
  var request = URLRequest(url: url)
  request.httpMethod = method
  request.setValue(appKey, forHTTPHeaderField: "X-App-Key")
  request.setValue("application/json", forHTTPHeaderField: "Content-Type")
  request.httpBody = try? JSONSerialization.data(withJSONObject: body)
  guard let (_, response) = try? await URLSession.shared.data(for: request) else { return false }
  return (response as? HTTPURLResponse)?.statusCode == 200
}

Both register and deregister use this same method, just with different HTTP methods and bodies. On success, a local flag in UserDefaults is updated so we don’t make the same call again next launch. This matters because Cloudflare KV has a write limit on the free tier, and there’s no point burning a write when nothing has changed.

Capturing the device token

To get the APNs token, you implement didRegisterForRemoteNotificationsWithDeviceToken in your app delegate:

func application(
  _ application: UIApplication,
  didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data
) {
  let token = deviceToken.map { String(format: "%02x", $0) }.joined()
  UserDefaults.standard.set(token, forKey: "deviceToken")
  Task { await PushNotificationsManager.register(token: token, pro: hasProAccess) }
}

The token is stored locally so it’s available for deregistration later, without needing another system call.

Gotchas

Sandbox vs production APNs

APNs has two environments: sandbox (for debug builds from Xcode) and production (for TestFlight and App Store builds). They use different endpoints and a token from one won’t work on the other. If you’re testing with a debug build and sending to api.push.apple.com, you’ll get a 410 and your token will be deleted.

I added an environment picker to the admin UI so I can switch between sandbox and production without redeploying.

KV write limits

Cloudflare KV’s free tier allows 1,000 writes per day. With the deduplication logic in the app (only register if the token or pro status actually changed), steady-state writes are minimal. The spike to watch for is the initial rollout when every user registers for the first time. The $5/month paid plan gives you 1 million writes per month, which is more than enough headroom.

What I removed

Thanks to this I was able to remove:

• The OneSignal SPM package (154 files, 23K+ lines)
• The OneSignalNotificationServiceExtension target and its files

Was it worth it?

For my use case, absolutely. The Cloudflare Worker is simple enough that I can understand every line of it, it costs nothing, and I have complete control over the data.

If you’re sending millions of notifications, doing rich media, running notification A/B tests, or need delivery analytics, you probably want something more full featured like OneSignal or Firebase. But if your needs are minimal (like me), something like this is very doable.

Every decision is a trade off. TWhen I used OneSignal they were responsible for ensuring the service remained online, and now I’m in a position where I’m responsible if Cloudflare goes down or there’s a bug in my code, For me the trade off of getting rid of a massive dependency and having more control over things is worth the downsides.

Apple should offer this natively (pls Apple 🫶)

Apple already has a push notifications console, but it only allows sending either broadcast notifications for updating Live Activities, or sending to a single individual user.

It’d be amazing if there was a nice first-party SDK that could take care of storing device tokens for users, and then if the push notifications console allowed us to target those stored users. I’ll keep my fingers crossed for next WWDC.

I wanted structured logs I could retrieve later, without adding a third-party dependency or paying for a service. Here’s what I did.

Choosing a solution

Apple’s OSLog system is built into their platforms but I didn’t even know it existed until now.

It has lots of benefits like automatic log rotation so logs never grow too large, and it doesn’t persist debug and info logs by default, so you can log liberally during development without worrying about bloat in production. It also supports categorising your logs, which makes filtering through hundreds of entries much easier.

I built a lightweight wrapper over it called LogManager.

LogManager

import Foundation
import OSLog

struct LogManager {

  enum LogCategory {
    case networking
    case sync
    // Add more categories here as needed
    case custom(String)

    var stringValue: String {
      switch self {
      case .networking: return "networking"
      case .sync: return "sync"
      case .custom(let value): return value
      }
    }
  }

  private static let subsystem = Bundle.main.bundleIdentifier ?? "com.example.myapp"

  private static func logger(for category: LogCategory) -> Logger {
    Logger(subsystem: subsystem, category: category.stringValue)
  }

  static func debug(_ message: String, in category: LogCategory) {
    logger(for: category).debug("\(message, privacy: .public)")
  }

  static func info(_ message: String, in category: LogCategory) {
    logger(for: category).info("\(message, privacy: .public)")
  }

  static func notice(_ message: String, in category: LogCategory) {
    logger(for: category).notice("\(message, privacy: .public)")
  }

  static func error(_ message: String, in category: LogCategory) {
    logger(for: category).error("\(message, privacy: .public)")
  }

  static func error(_ error: Error, in category: LogCategory, context: String? = nil) {
    let message = if let context = context {
      "\(context): \(error.localizedDescription)"
    } else {
      error.localizedDescription
    }
    logger(for: category).error("\(message, privacy: .public)")
  }

  static func fault(_ message: String, in category: LogCategory) {
    logger(for: category).fault("\(message, privacy: .public)")
  }
}

Usage is straightforward:

LogManager.notice("Starting sync", in: .sync)

do {
  try await performSync()
  LogManager.notice("Sync completed successfully", in: .sync)
} catch {
  LogManager.error(error, in: .sync, context: "Sync failed")
}

And because we’re using a thin wrapper around OSLog, if I ever want to integrate with a third-party service in future, it’ll require very minimal code changes:

static func error(_ message: String, in category: LogCategory) {
  logger(for: category).error("\(message, privacy: .public)")
  SomeRemoteLoggingService.send(message, level: .error, category: category.stringValue)
}

Be aware that by default OSLog redacts dynamic strings in production, so you’d just see <private>. I’m only logging operational stuff (no user data), so .public is fine for me, but it might not be for you.

Exporting logs

I also needed a way to get logs off the device — both for me when I’m not connected to the debugger, and for users reporting issues.

OSLog entries live in an OSLogStore that you can query directly:

import Foundation
import OSLog

func exportLogs(lastHours: Int = 24) throws -> URL {
  let store = try OSLogStore(scope: .currentProcessIdentifier)
  let date = Date.now.addingTimeInterval(-Double(lastHours) * 3600)
  let position = store.position(date: date)
  let bundleIdentifier = Bundle.main.bundleIdentifier ?? "com.example.myapp"

  let entries = try store
    .getEntries(at: position)
    .compactMap { $0 as? OSLogEntryLog }
    .filter { $0.subsystem == bundleIdentifier }

  var logLines: [String] = []
  logLines.append("App Logs")
  logLines.append("Generated: \(Date.now.formatted(date: .complete, time: .complete))")
  logLines.append("Period: Last \(lastHours) hours")
  logLines.append(String(repeating: "=", count: 80))
  logLines.append("")

  for entry in entries {
    let timestamp = entry.date.formatted(date: .omitted, time: .standard)
    let level = levelString(for: entry.level)
    let category = entry.category.padding(toLength: 20, withPad: " ", startingAt: 0)
    logLines.append("[\(timestamp)] [\(level)] [\(category)] \(entry.composedMessage)")
  }

  let logsString = logLines.joined(separator: "\n")

  let tempDirectory = FileManager.default.temporaryDirectory
  let fileURL = tempDirectory.appendingPathComponent("app-logs-\(Int(Date().timeIntervalSince1970)).txt")
  try logsString.write(to: fileURL, atomically: true, encoding: .utf8)

  return fileURL
}

This grabs the last 24 hours of your app’s logs, formats them into a text file, and gives you a URL you can hand to a share sheet. The output looks like:

App Logs
Generated: Saturday, 22 February 2026 at 14:30:00 GMT
Period: Last 24 hours
================================================================================

[09:15:23] [NOTIC] [sync               ] Starting sync
[09:15:24] [NOTIC] [sync               ] Sync completed successfully
[09:22:01] [ERROR] [networking          ] Request failed: The operation timed out
[10:45:12] [NOTIC] [notifications       ] Scheduled notification: Reminder

The categories from LogManager carry through here, so you can quickly scan for the area you care about. I have an ‘Export logs’ button in my app which brings up the share sheet with the file, which I can either send to myself or have a user send to me.

That’s it

I can now debug issues that happen away from Xcode, and get better user reports.

An example invoice made with Pages

I could have just spent ten minutes making a nicer Pages template, but like all good programmers I decided to instead invest a significant amount of time into building a bespoke solution.

So – meet Tally – a simple invoicing app.

I didn’t want to distract myself from focusing on Personal Best too much, so v1 of Tally has a modest feature set:

• Save your business and payment details
• Add your customers
• Make ‘one off’ and ‘day rate’ invoices
• Export invoices as PDFs

Everything automatically syncs over iCloud, and it supports iOS, iPadOS, macOS, and visionOS.

What’s next

I’m going to leave Tally alone now for a few months while I focus on Personal Best, but when I come back to it I’ll start evolving it into a fully-fledged billing platform for freelancers. It’s easy to imagine places this could go, like:

• Other types of invoice, like hourly rates
• Purchases orders, quote, and credit notes
• Marking invoices as paid, late, etc
• Emailing out invoices automatically, including reminders and late notifications based on your payment terms
• Static links for invoices, so you can send a link to your client for them to pay online
• Web and Android support
• Monetisation – v1 of Tally is free, but if I pursue this properly I’ll gate some features behind a paywall

Download Tally

Get Tally on the App Store

If you’d like to catch up on previous years first, check out 2024, 2023, 2022, 2021, and 2020.

Overall

It’s been a good, albeit unexpected year. When the year started I was working full time and spending evenings and weekends on Personal Best (PB). Unfortunately in March the startup I was working at closed down unexpectedly. So, I decided to take some time to focus on PB exclusively, working on it full time for around six months.

In September I started contracting part time, so I now contract three days a week and spend the rest of my time focusing on PB. I’ve been wanting to get into contracting for some time and I’m really happy that I now have the opportunity to do so.

My goals

In 2024 I set myself three loose goals for 2025:

Focus on Personal Best

Status: Achieved ✅

I wanted to make PB my main focus this year and I pretty much succeeded. I was tempted to build some other apps – I have a few ideas knocking about in my head – but I managed to resist the urge to build them.

Continue refactoring

Status: Achieved ✅

I addressed a bunch of tech debt in PB (more on that later). I was really glad to have finally spent some time improving PB’s foundations.

Build goal tracking

Status: In progress ⏳

I’m about 75% of the way through building this, but it isn’t quite ready yet. I plan to release it in early 2026.

What I shipped

I did a lot of work on PB this year and shipped a bunch of stuff, some user facing, others behind the scenes.

Pricing and paywall tweaks

I shipped a new paywall and ran several experiments to tweak it further, testing things like layout, trial length, pricing, and button text. I used RevenueCat and TelemetryDeck to run my experiments and I’m a very happy customer of both. I’m pretty much now always running an experiment of some kind on the paywall.

I also switched to region-specific pricing for Personal Best Pro. I used the excellent Pricetag app to do this with the Apple Music Index as the basis for my pricing. In practice this means that PB’s subscription price now reflects relative purchasing power in different regions – for example in India the price dropped by 90%. As a result my revenue in India in 2025 was 128% higher than in 2024. This means that the price cut is easily offset by how many more people purchased the app with a more accessible price.

Another pricing tweak I made was adding discounts. If new users don’t choose to start a trial during onboarding, they’ll be offered a year at 50% off at a later date. Similarly, users who had a subscription but then churned will be offered 50% off another year.

Revamped notifications

PB has had post-workout notifications for a while, but they were behind the paywall. I decided to make them available to all users – not just subscribers – so that they could act as a growth driver. I also integrated them into onboarding with an ‘a-ha moment’ to demonstrate their value to users as early as possible.

Users see an example notification during onboarding to give them an idea of what they'll get

Post-workout notifications got a lot richer in 2025 too. I learned about a little-used API on iOS – Notification Content App Extensions, which allows apps to display any UI when a notification is expanded. You’ve probably seen this before in the Messages app which opens a small version of the conversation when expanded. Thanks to this, post-workout notifications now display a rich view of your workout when expanded.

An expanded notification displaying rich content

I also added server-driven notifications powered by OneSignal, so I can notify users about things like when their Year in Review is available. I plan to use this sparingly – nobody likes an app that spams you with annoying notifications.

Workout planning

My vision for PB is for it to eventually do everything you need to work out at your best. To take another step towards that I added workout planning.

Users can plan a workout and PB will make suggestions based on their recent history. Once they’ve saved the plan it’ll be pinned to their app (and the new Today widget) for the rest of the day, and PB will motivate them to complete it, including sending notifications when it’s close to the end of the day (think Duolingo).

Once they’ve completed their workout, PB’s post-workout notifications and the app shows them how they did compared to what they planned. If they don’t complete their workout they can roll it over to the next day and try again.

The workout planning flow

New design and iOS 26 support

I’ve started to slowly evolve PB to be more ‘branded’ and look less like the Settings app. I’m still a long way from where I want it to be (it’s a slow evolution), but I took the first steps this year with some new gradients I’m using in parts of the app.

Example of the new gradients. It uses a mesh gradient combined with a noise effect.

I also made sure that PB was ready for iOS 26 on day one. I was very fortunate to get to work with Apple over the summer on adapting PB to the new design and to use the Foundation Models framework, which was a great experience.

Thanks to this I was lucky to be featured by the App Store editors for the iOS 26 launch, and PB was also included in some of Apple’s internal slides shown to developer workshops as an example of best practice.

Being shown by Apple as an example to other developers 🤯

Other things I shipped

Things that don’t merit their own section

• Users can now find their past workouts with powerful filters on the Workouts tab.
• The Dashboard tab became the Today tab, and users can now customise it by choosing which sections appear.
• PB now works great at all dynamic type sizes. See my previous post for more on this.
• I updated PB’s Year In Review feature (think Spotify Wrapped but for workouts) for 2025.
• The Dashboard tab now displays a rotating list of facts about your latest workouts.
• The leaderboards widget gained support for custom leaderboards.
• I spent some time improving PB’s ASO by experimenting with different keywords and screenshots on the App Store.
• Users can now manually add (and delete) workouts.
• I completed the database migration started in 2024. PB now uses Swift Data for everything; Core Data is no more.
• PB now identifies and ignores duplicate workouts. Previously PB would show all workouts, so when a misbehaving app added multiple entries (e.g. Strava) to HealthKit users would see multiple of the same workout. This no longer happens.
• I made a bunch of new app icons featuring photos from around the world that I took during workouts.
• I replaced the old contact form which opened the user’s mail app with a slicker one which sends me feedback directly. I also added a Home Screen Quick Action to open the feedback form when users are thinking of deleting the app.
• I posted a lot more on PB’s Instagram and TikTok accounts.
• The iPad version of PB gained support for keyboard shortcuts.

Metrics

TL;DR: Downloads have decreased, revenue is up, users are stable.

Downloads

PB’s downloads in 2025 were down compared to 2024. It went from 180,000 downloads in 2024 to 137,000 in 2025.

While this is slightly disappointing, I’m not overly concerned as revenue has increased year on year (see next section).

My other four apps are pretty much a rounding error compared to PB at this point. I’m fine with this, as I’ve put zero work into them this year and they’re quite niche.

Downloads from 2020-2025

Revenue

Sales are up in 2025, from $35,000 in 2024 to $45,000 in 2025, an increase of 29%. I’m particularly happy about this, particularly when factoring in the lower downloads in 2025, as it indicates that my efforts to drive revenue are working.

Sales from 2020-2025

RevenueCat breaks my income into monthly recurring revenue (MRR). On December 31st 2025 my MRR was $3,630, a 31% increase over the $2,769 I had on the same date in 2024.

MRR from 2022-2025. It starts in 2022 because PB didn’t have a subscription until then.

Users

My monthly active users for 2025 were pretty much identical to 2024; around 42,000.

Monthly active users from 2021-2025

Goals for 2026

I’m setting some loose goals for the year ahead.

‘Finish’ PB

PB will never be fully finished, but I want to get to the stage where it’s a cohesive, well-made app that offers a clear value proposition. If you work out, then PB should have an obvious benefit for you.

I realise this is quite a subjective goal, but I think there’s value in setting it so I can make sure it’s something I keep in mind and build towards in 2026.

Reach $5K MRR

This is a tough goal – I’d need to increase MRR by 38% this year to meet it – but it would be an amazing milestone to hit.

I’m still working on adding better VoiceOver support, but I’m happy to say that Personal Best now works great at all dynamic type sizes. This means that no matter what text size people use the app will be fully usable.

Dynamic type primer

Dynamic type is an Apple feature for customising your text size. As of May 2025 there are twelve possible values: xSmall, small, medium, large (default value), xLarge, xxLarge, xxxLarge, AX1, AX2, AX3, AX4, and AX5. The AX in the latter five sizes stands for accessibility.

In terms of dynamic type support, apps fall into one of three categories:

1. Unsupported

Some apps don’t support dynamic type at all. The font is always the same size regardless of your dynamic type setting.

Below is the Skyscanner app with my font size at the AX5 (highest) setting. You can see it’s stuck showing text at the default size because they’ve opted out of dynamic type entirely.

2. Supported but broken

Some apps support dynamic type but haven’t been fully optimised, so some elements look broken or cut off. An example of this is the weightlifting app Hevy where a lot of text gets cut off.

3. Fully supported

Finally, we have apps that work perfectly at all dynamic type sizes. The text grows and shrinks according to the user’s text size, and everything still looks and works great. An example of this is Foodnoms, my food tracking app of choice.

The state of Personal Best

Before starting this work Personal Best was in category #2. There were parts that looked ok, but a bunch of issues in almost every screen with text getting cut off or otherwise looking bad.

I want Personal Best to be a best-in-class iOS app, which means making it work great for everyone. Not only is this the right thing to do, it’s also a business opportunity. My TelemetryDeck analytics indicates that very few of my users are using the AX text sizes, which could be an indication that I was leaving the needs of a significant section of the market unaddressed.

To fix the issues, I went through every screen and checked it at the AX5 size, and every time something looked broken, I’d adapt the layout to fix it. Then I’d put the text back to the default size, and check I hadn’t inadvertently broken anything in the process.

Fixing it

I found that every issue fell into one of three categories:

• Non-scrollable content
• Insufficient horizontal space
• Custom approach required

Here’s how I approached each of these issues.

Non-scrollable content

Often we’ll have some content that fits fine at smaller sizes, but at very large ones it goes off the screen. Unlike on the web, SwiftUI views don’t scroll by default when they overflow.

In the screenshot above, the text gets cut off and there’s no way for users to see the end of the text.

A simple fix is to wrap it all in a ScrollView. This solves the problem but replaces it with a different problem. We’ve broken the layout at non-AX type sizes – our content was bottom aligned but that’s no longer the case.

To fix this, we can make the ScrollView only display when needed. For this I turned to Daniel Klöck’s ScrollViewIfNeeded package. This is a great utility which only adds a ScrollView if the content is large enough to need it. Here’s how the code looks:

ScrollViewIfNeeded {
  VStack {
    Spacer()
    Image(systemName: "heart.fill")
    Text("Here is some long text content. At small text sizes it's not an issue, but at larger dynamic type sizes we may begin to run into some issues. Especially on smaller phones like iPhone SE. I'm running out of things to say.")
  }
}

And here’s how it looks in practice:

Insufficient horizontal space

I use HStack extensively to lay content out side by side. At large sizes the available space is reduced because more of it is taken up by text, and the content can become difficult to parse. Here’s a typical example of this issue:

While it’s still pretty readable, it could be better. The icon on the trailing edge has a lot of empty space above and below it. If we give that space to the text, it won’t need to wrap as much. To do this, we change the layout at larger sizes to use a VStack instead of a HStack.

SwiftUI has a couple of ways to achieve this: ViewThatFits and dynamicType.isAccessibilitySize. These allow us to detect if we’re running out of space or if the user is using an AX type size and show a different layout. Here’s how that looks:

Using ViewThatFits

ViewThatFits {

  // Original HStack-based layout
  HStack {
    VStack(alignment: .leading) {
      Text("Welcome to the app!").font(.title)
      Text("Some extra text about onboarding.")
        .font(.headline)
        .foregroundStyle(.secondary)
    }
    Spacer()
    Image(systemName: "globe")
      .imageScale(.large)
      .foregroundStyle(.tint)
  }

  // Alternative VStack-based layout
  VStack {
    VStack(alignment: .leading) {
      Text("Welcome to the app!").font(.title)
      Text("Some extra text about onboarding.")
        .font(.headline)
        .foregroundStyle(.secondary)
    }
    Image(systemName: "globe")
      .imageScale(.large)
      .foregroundStyle(.tint)
  }
}
.padding()
.background(.regularMaterial)

This works quite well. Our original HStack layout is used initially, but at larger sizes we get a VStack-based layout.

This is a big improvement. Instead of eight lines the text now only occupies five lines, and ‘onboarding’ doesn’t need to be hyphenated; it fits on one line.

There is a potential issue however. The VStack-based layout kicks in at the xLarge size, when it probably didn’t need to. I’m not knowledgeable enough about SwiftUI’s layout system to know why this happens. In your case this might not be a problem, but for me I wanted to maintain the HStack-based layout until it didn’t make sense anymore. For this, I turned to dynamicType.isAccessibilitySize.

Using dynamicType.isAccessibilitySize

We can use SwiftUI’s environment to detect the current type size, which comes with a convenient property to check whether it’s one of the AX sizes. We can use this to only change to the VStack-based layout when the user is using an AX size:

@Environment(\.dynamicTypeSize) private var dynamicTypeSize

...

Group {
  if dynamicTypeSize.isAccessibilitySize {

    // VStack-based layout
    VStack {
      VStack(alignment: .leading) {
        Text("Welcome to the app!").font(.title)
        Text("Some extra text about onboarding.")
          .font(.headline)
          .foregroundStyle(.secondary)
      }
      Image(systemName: "globe")
        .imageScale(.large)
        .foregroundStyle(.tint)
    }
  }

  else {

    // HStack-based layout
    HStack {
      VStack(alignment: .leading) {
        Text("Welcome to the app!").font(.title)
        Text("Some extra text about onboarding.")
          .font(.headline)
          .foregroundStyle(.secondary)
      }
      Spacer()
      Image(systemName: "globe")
        .imageScale(.large)
        .foregroundStyle(.tint)
    }
  }
}
.padding()
.background(.regularMaterial)

This approach isn’t necessarily better than using ViewThatFits, it’s just different. You should choose whichever approach makes the most sense for the screen you’re adapting.

Going the extra mile

This works well, but we can enhance it a bit more by making the VStack-based layout look a bit more at home. It’s nice when the screen works fine at large type sizes, but we can go the extra mile by making it look great. Let’s now tweak the layout to look a bit nicer:

if dynamicTypeSize.isAccessibilitySize {
  VStack(alignment: .center) {
    Image(systemName: "globe")
      .imageScale(.large)
      .foregroundStyle(.tint)
      Text("Welcome to the app!")
      .font(.title)
      .multilineTextAlignment(.center)
      Text("Some extra text about onboarding.")
        .font(.headline)
        .foregroundStyle(.secondary)
        .multilineTextAlignment(.center)
  }
}

Here I’ve removed a redundant second VStack, centre-aligned everything, and moved the image to the top of the view.

Cleaning it up

There’s a lot of duplication in this code because we’re defining two completely different layouts. We can clean this up by making a new reusable view that abstracts away much of the logic for, named HOrVStack:

struct HOrVStack<Content: View>: View {
  @Environment(\.dynamicTypeSize) private var dynamicTypeSize
  let content: Content
  let flipAt: DynamicTypeSize
  let horizontalAlignment: HorizontalAlignment
  let verticalAlignment: VerticalAlignment

  init(
    flipAt: DynamicTypeSize = .accessibility1,
    horizontalAlignment: HorizontalAlignment = .center,
    verticalAlignment: VerticalAlignment = .center,
    @ViewBuilder content: () -> Content
  ) {
    self.content = content()
    self.flipAt = flipAt
    self.horizontalAlignment = horizontalAlignment
    self.verticalAlignment = verticalAlignment
  }

  var layout: AnyLayout {
    if dynamicTypeSize < flipAt {
      AnyLayout(HStackLayout(alignment: verticalAlignment))
    } else {
      AnyLayout(VStackLayout(alignment: horizontalAlignment))
    }
  }

  var body: some View {
    layout { content }
  }
}

Usage

...

var imageView: some View {
  Image(systemName: "globe")
    .imageScale(.large)
    .foregroundStyle(.tint)
}

var textAlignment: TextAlignment {
  return dynamicTypeSize.isAccessibilitySize ? .center : .leading
}

@ViewBuilder
var hStackView: some View {
  HOrVStack(horizontalAlignment: .center) {
    if dynamicTypeSize.isAccessibilitySize { imageView }
    VStack(alignment: .leading) {
      Text("Welcome to the app!")
        .font(.title)
        .multilineTextAlignment(textAlignment)
      Text("Some extra text about onboarding.")
        .font(.headline)
        .foregroundStyle(.secondary)
        .multilineTextAlignment(textAlignment)
    }
    if !dynamicTypeSize.isAccessibilitySize {
      Spacer()
      imageView
    }
  }
  .padding()
  .background(.regularMaterial)
}

Now we have both HStack and VStack-based layouts looking great with a minimal amount of duplication.

I used this pattern extensively to adapt Personal Best, and having a reusable view was a huge time saver.

Custom approaches

Adapting Personal Best for dynamic type fell solidly into the 80/20 rule: 80% of issues were fixable in 20% of the time by applying the quick fixes detailed above. The remaining 80% of the time was spent fixing the 20% of screens that needed a more custom approach.

For these there’s often no ‘one size fits all’ solution; you need to carefully assess what doesn’t look right at large type sizes, then apply fixes on a case-by-case basis. Here are some examples from Personal Best.

Charts

I had a chart that struggled at larger sizes because of a lack of horizontal space for the text labels. I improved it by changing the chart to use a vertical layout at larger type sizes.

Tables

My paywall features a comparison of which features are available in the free and paid versions. At larger sizes there simply wasn’t enough horizontal space for this to look good, so I switched it to a simpler list of paid features at larger type sizes.

Background contrast

The onboarding screen has a graphic at the top of the screen, where various workout types move in concentric circles. At smaller type sizes this looks fine, but when the text is very large the text clashes with the background, making it difficult to read.

To fix this I added a background to the lower part of the screen which is only visible at AX text sizes. It’s a simple fix, but it goes a long way to make the screen more readable.

Takeaways

Here’s some tips from my own journey into making Personal Best more accessible.

1. Do it from the start

I could have avoided all this work by just making these screens properly support dynamic type from the beginning. It takes about 10% more work to do this from the start, compared to the large effort it took for me to fix the whole app at a later date.

2. Keep it simple

If you fill your codebase with if...else statements for dynamic type support, you’re creating a lot of technical debt and making the codebase less maintainable in the future. Not only will this make work for future you, it’ll also increase the likelihood of you making a mistake and inadvertently breaking your app’s dynamic type support in the future.

Keep things simple by using reusable views as much as you can (like my HOrVStack view), and avoid duplicating your code.

3. ‘Done’ is better than perfect

We all want our apps to be the best they can be, but if you’re struggling to make something look absolutely perfect at large type sizes, just settle for making it usable. It’ll deliver value immediately for your users who use large type sizes, and you can improve it further at a later date.

Further reading

If you’d like to learn more about dynamic type, here are some great resources that I found helpful.

• Apple: Get Started With Dynamic Type (WWDC 2024)
• Bang Tran: Designing for scalable Dynamic Type in iOS for accessibility
• Deque: Guide to Supporting Dynamic Type

Fortunately I learned that TelemetryDeck supports A/B testing. I’ve been a happy customer of TelemetryDeck for years. I use it to record analytics in my apps in a privacy-first way, so I can see things like daily active users, what OS people are using, and things like that.

So, I built a simple integration into my app to allow it to support A/B testing. It’s something manual and hard coded, but it suits my needs for running a basic experiment. Here’s how to do it.

Getting started

Assuming you already have TelemetryDeck set up in your app, you’ll need something in to represent each cohort. For this I made an enum.

import Foundation

enum ABTestCohort: String {
  case control
  case experiment

  private static func getRandomCohort() -> ABTestCohort {
    return Bool.random() ? .control : .experiment
  }

  static func getCohort(forKey key: String) -> ABTestCohort {

    if let savedCohort = UserDefaults.standard.string(forKey: key),
       let cohort = ABTestCohort(rawValue: savedCohort) {
      print("🧪 Retrieved saved cohort '\(cohort.rawValue)' for experiment \(key)")
      return cohort
    }

    // If no cohort is saved, generate a random one and save it
    let newCohort = getRandomCohort()
    setCohort(newCohort, forKey: key)
    print("🧪 Assigned cohort '\(newCohort.rawValue)' for experiment \(key)")
    return newCohort
  }

  private static func setCohort(_ cohort: ABTestCohort, forKey key: String) {
    UserDefaults.standard.set(cohort.rawValue, forKey: key)
  }
}

The code here is very straightforward. There’s only one public method: getCohort(forKey:). It takes a key which corresponds to an experiment, then returns either .control or .experiment to denote which user the cohort is in. It makes use of UserDefaults to store the value locally, so that we’ll always get the same value each time.

Hooking it up to a view

Next we need to make use of it in a view. For this, let’s assume we have two SwiftUI views defined ahead of time: Paywall_Control and Paywall_Experiment. Now, we make a wrapper component that makes use of our new ABTestCohort enum and shows either the control or experiment to the user based on what it returns:

import SwiftUI

struct Paywall {
  private let cohort: ABTestCohort

  init() {
   self.cohort = ABTestCohort.getCohort(forKey: "PaywallExperiment")
  }

  #if DEBUG
  init(cohort: ABTestCohort) {
    self.cohort = cohort
  }
  #endif

  var body: some View {
    switch cohort {
      case .control: Paywall_Control()
      case .experiment: Paywall_Experiment()
    }
  }
}

#Preview("Control") {
  Paywall(cohort: .control)
}

#Preview("Experiment") {
  Paywall(cohort: .experiment)
}

Just like before the code here is very simple. When the view initialises, we determine which cohort the user is in, and set a local variable accordingly. Then we display one of the views based on what we get back.

By doing this on init instead of asynchronously using some state, we ensure that a value is set before the view appears. It’s ok to do this here as the way the value gets set – being read from UserDefaults – is very fast, but if we were doing a more complex lookup (for example, getting a value from the internet), we’d do something more fault tolerant.

The #if DEBUG part gives us an extra initialiser that’s only available in debug mode, allowing us to manually test this in previews. It’ll be stripped out in release builds.

Sending it to TelemetryDeck

Now we need to let TelemetryDeck know when each variant is displayed. All we need to do for this is add an onAppear modifier to our view’s body:

...

var body: some View {
  Group {
    switch cohort {
      case .control: Paywall_Control()
      case .experiment: Paywall_Experiment()
    }
  }
  .onAppear {
    TelemetryDeck.signal("PaywallShown", parameters: ["variant": cohort.rawValue])
  }
}

Here we’re simply sending a PaywallShown event to TelemetryDeck when the view loads, with some metadata to tell it which variant we displayed.

Creating an A/B test in TelemetryDeck

The last step is to set up an A/B test on TelemetryDeck. Create a new insight, and when asked for the type, choose A/B Testing Experiment.

For sample1 add the event we sent in the previous step, with the variant set to control. For sample2, do the same event, with the variant set to experiment.

Adding the successCriterion is the final step. This is how we tell TelemetryDeck the thing we’re trying to improve. In my case, that’s people purchasing Personal Best Pro. I use TelemetryDeck’s integration with RevenueCat, which means there’s already an event for this I can hook into: RevenueCat.Events.INITIAL_PURCHASE.

And with that, the A/B test is set up. TelemetryDeck will monitor the events my app sends and determine which variant is more successful.

Issues and future improvements

This is a very lightweight version of A/B testing, and it does have its limitations.

1. Only one experiment

This approach only allows us to test one experiment at a time. If we wanted to test three different paywalls to see which is best, we’d need to adapt the code to support this.

2. It affects all users

If we wanted to tweak the test to not be 50/50 (for example only showing the experiment to 10% of users), we can’t easily do that without changing the code.

3. No remote control

There’s no way for us to remotely enable or disable the test. It’s baked into the app and we can only remove it with an App Store update, which could take days to get approved.

Fixing this would complicate our simple solution somewhat. We’d probably need some sort of server-side logic that the app can check on startup which says if the experiment is enabled. A lightweight version might be a Cloudflare worker which returns some JSON, like this:

{
  "tests": {
    "paywall": true,
    "someOtherTest": false
  }
}

Then during the app’s startup you’d download this JSON and use it in the UI to determine which A/B tests should be enabled.

Finally

So that’s how to run a lightweight A/B test using TelemetryDeck. If you’d like to try it for yourself, here’s my referral link for TelemetryDeck, which will give you 100,000 extra signals each month for free.

If you’d like to catch up on previous years first, check out 2023, 2022, 2021, and 2020.

Overall

I set myself three goals for 2024:

Ship two new apps

Status: Achieved ✅

I actually ended up shipping three new apps this year.

In February I released SalaryPig, an app for tracking your salary. It’s pretty niche, but in December 2023 I started a new job and absolutely hated it from day one. I made SalaryPig as a way to distract myself from it. You’ll be pleased to read that I’ve since left that job and I now work somewhere I’m much happier at.

• Read SalaryPig’s introduction post
• Get SalaryPig on the App Store

Later in the year I followed this up with two new apps, both simple quiz apps. My app Taylor’s Version already contained a quiz, and my friend Rauno suggested I split it into a separate app. A few months after that I made a second quiz app, this time about football.

To make it easier to make more quiz apps, I created a private framework named QuizKit. The idea was that QuizKit would handle 95% of the logic, so all I’d need to do is customise the questions and some theming for each app, allowing me to quickly make lots of apps like this. If each made a small amount of revenue, they could add up to make a good income.

Unfortunately, with both quiz apps I had a lot of issues getting them through Apple’s App Review team. It was enough of a hassle to put me off from making any more, so I decided to leave it at just these two quizzes for now.

• Read Taylor Swift Quiz’s introduction post

• Get Taylor Swift Quiz on the App Store

• Read Football Quiz’s introduction post
• Get Football Quizzes on the App Store

Add goal tracking to Personal Best

Status: Missed 😭

Not much to say here, I just didn’t have time, and prioritised some other things instead. I’m hoping to get to it in 2025…

Use an Apple Vision Pro

Status: Achieved ✅

A bit of a frivolous goal, but I was fortunate to attend one of Apple’s Vision Pro developer workshops this year. It was great to get some hands on time with the headset, and I was able to ship a VisionOS version of SalaryPig as a result.

Getting featured

This year something amazing happened – Personal Best was featured as App of the Day on the App Store in over 150 regions! It was incredible to be recognised and I still can’t actually believe it happened! As always, I’m grateful to the App Store editorial team for promoting my work ❤️

Delivery

Outside of the other apps I mentioned above, I shipped a lot of improvements to Personal Best, my workout app which I consider to be my ‘main’ app. The improvements were more transitional than feature based, with a lot of behind-the-scenes work focused on improving the app’s foundations for the future.

Pace customisation

Up to now, pace was always expressed in terms of seconds per mile or kilometre, based on your distance setting. This makes sense for most workouts, but not for things like swimming where you’d typically measure pace in other ways, like seconds per 100m or seconds per 25yds. To fix this, I made how you view pace completely customisable for each type of workout.

The default options are sensible so most users won’t need to change them, but for those who want more customisation there’s now full flexibility to see pace however makes the most sense to you.

All-new leaderboards

Leaderboards are one of the most-loved features in Personal Best, but they were also one of the oldest parts of the codebase, from back in May 2020. I’d often get requests for improvements, but due to some poor decisions I made with the Core Data schema back then, I wasn’t able to easily deliver them.

So, I completely rewrote leaderboards from scratch using Swift Data, with a much more flexible schema to allow for more customisation. I was pretty nervous about shipping this, in case the migration script didn’t work, but after many, many hours of thorough testing, I released it in November and there have been zero issues so far.

Improved help

I added a new Help and FAQs section to the app, with answers to common queries. I’ve maintained an FAQs page on Personal Best’s website for a few years, but I noticed that I was receiving a lot of emails from people asking things that were already covered in the FAQs. To improve this, I built the FAQs into the app directly to make it easier for people to find answers.

Price experiments

I changed some of the plumbing inside Personal Best to allow me to make use of RevenueCat’s Experiments feature, to experiment with pricing and paywall variations.

Hiding facts

I added the ability to hide facts from your workout stats, for people who don’t want to see them for whatever reason. This was driven by a request from somebody who didn’t want to see food-based facts, but I extended it to work on all categories.

Numbers

So, how did I do for revenue this year? Last year saw an enormous increase in downloads and revenue, and going into this year I was a mixture of excited about growing it further, and nervous about maintaining it.

Downloads

Personal Best’s growth continued this year, which is amazing to see. It went from 87,000 downloads in 2023 to 180,000 this year, which is just over double.

Taylor’s Version’s downloads dropped from 13,000 in 2023 to 5,500 in 2024. This makes sense, as this app is only used for replacing Taylor Swift songs in your playlists, and no new Taylor’s Version albums came out this year.

SalaryPig did ok in its debut year, with just over 1,000 downloads. I’d have loved to see more, but given how niche it is, it’s understandable.

My Taylor Swift quiz got just under 3,000 downloads, which feels pretty good for an app I built in a weekend and did no marketing for.

Finally, my poor, unloved Football Quiz app had just 169 downloads this year.

Sales

Sales were great this year, once again driven by Personal Best. It accounted for $35,000 of revenue, roughly a 2x increase on 2023.

My other apps had very minimal sales: Taylor Swift Quiz made $330, SalaryPig $200, Taylor’s Version $179, and in last place Football Quiz made just $4.

Users

I use TelemetryDeck to get privacy-first analytics in my apps.

I only track Personal Best’s active users as it’s the app I’m mostly focused on growing, and it had a healthy increase this year, with 43,000 monthly active users, up from 28,000 in 2023.

Goals for 2025

So what’s next? I’m setting myself some loose goals for the coming year. As with last year I’m not setting any revenue-based goals.

Focus on Personal Best

If the graphs above show one thing, it’s that Personal Best deserves to be my main focus. I think it has huge growth potential to become even bigger if I put more focus into making it a best-in-class iOS app. I’m terrible for getting distracted and building other apps, but this year I intend to focus only on improving Personal Best.

I have a day job that I love, but it does mean that I’m often not able to spend as much time on my apps as I want. Next year I’m going to try and block out specific evenings in my calendar to work on Personal Best, to see if that will help me balance my time better.

Build goal tracking

I’m carrying over this goal from last year into 2025, as I really need to get to it eventually, and I think it has the potential to be a game-changing feature.

Continue refactoring

I’ve been improving a lot of Personal Best’s codebase behind the scenes, like switching from callback-based APIs to async/await ones, and I want to do that along with keep working on improving performance.

It’s doing well, so I’ve adapted it into a football quiz app.

How well is ‘doing well’

The Taylor Swift quiz has been on the App Store just shy of four months, getting just under 2,000 downloads and $220 in revenue. Compared to my main app Personal Best this is a drop in the bucket, but I think it’s enough proof that it’s a viable avenue to keep exploring.

So, this felt like the right time to expand the experiment with a second quiz. I’m a big football* fan, so a football quiz was a natural choice.

*soccer for Americans

Building it

Regular readers will know that each time I make a new app I try to learn something new (for example, with SalaryPig I learned how to make interactive 2D graphics from shapes, as well as syncing user preferences over iCloud).

For this app, I learned how to make and maintain my own Swift package. I abstracted most of the logic from my existing app into a package I named QuizKit, which then meant the new app could just be a light layer on top of that, with about 95% of functionality coming from QuizKit and only the actual questions and styling bespoke to the app.

Thanks to this, I was able to make the new app in less than a day. The most time-consuming parts were the things I couldn’t abstract away, like actually writing the quiz questions and setting up the in-app purchases.

The finished product

Football Quizzes is now live on the App Store. It supports iPhone and iPad, as well as macOS and visionOS via the iPad app compatibility mode.

What’s next

Actually getting the app released was really difficult, as the App Review team at Apple rejected it repeatedly. Firstly because it fell afoul of guideline 4.3, as they argued it was too similar to my previous app and could be construed as a spam app built from a template. I managed to convince them by explaining that I’d put a lot of care into writing the questions and pointed out the high-quality UX, and contrasted it with some other low-quality quiz apps on the App Store.

Then, I had several more rejections for using intellectual property from FIFA. This is understandable – Apple don’t want to make themselves legally liable for anything on their store – so I had to remove all references to anything trademarked. For example, the “World Cup” quiz became the “World Championships” quiz. It’s a bit like Pro Evolution Soccer on PS2 where they didn’t have the rights to use real team names, so they had “West Midlands Village” instead of “Aston Villa”, “Man Blue” instead of “Manchester City”, and so on.

However, after this experience I’m going to put the quiz apps aside for now and dedicate 100% of my app development time to Personal Best. It’s my biggest app by far, and I love building it and hearing from users who are enjoying it.

Watch this space for more updates on Personal Best and how this new quiz app performs.

Why

My app Taylor’s Version already features a small quiz that appears while it makes a slow request to an external API. Recently after talking to a friend I had the idea to split this into its own app.

There are a few apps like this already, but they often have really poor UX, huge download sizes, and just generally don’t come across great. I saw this as an opportunity for me to build a compelling experience, as well as a way for me to continue developing my design skills by tackling a type of app I haven’t really done before.

How

I’m wary of spreading myself too thin and taking focus from my main app Personal Best, so I set myself some constraints:

Ready in one weekend

I would spend exactly one weekend on the app, so that I didn’t end up sinking weeks into it.

No scope creep

I’m terrible for increasing the scope of my apps. My “it’ll just take a weekend” projects often grow into month-long sagas. To help me keep things lean, I defined the scope ahead of time and didn’t allow it to budge. The app needed to:

• Offer a range of quizzes for people to complete. Some of them would be free, with others unlockable via in-app purchase.
• Have a nice UX that would make it stand out amongst other apps. I wanted each quiz to have its own colour scheme so they’d feel distinct from each other, and I wanted to have slick animations and haptics throughout. If Apple themselves made a trivia app, it might look something like this.
• Allow people to share images of their results, as this could potentially help growth.
• Support iPhone and iPad.

Learn something new

Each time I make a new app, I try to do something I’ve never done before as a way of learning something I can then apply to other apps. For example when I built SalaryPig I learned how to make interactive, animated 2D graphics.

For this, I chose Swift Data as the new thing I’d learn. I want to use it on Personal Best in the future, so this would be a good introduction to it inside a real production app.

The finished product

The app is now live on the App Store. It supports iPhone and iPad, as well as macOS and visionOS via the iPad app compatibility mode.

Next steps

I intend to let the app breathe and see how it performs before doing more with it. My hope is that it’ll pick up some downloads over time via word of mouth and having good ASO

If it does well, it’ll be very easy for me adapt it to make more trivia apps about other topics (e.g. a football quiz, movies quiz, and so on).

There’s also some more roads I could go down if I decide to further develop this app, like:

Support more platforms

I’ve never made an Android app, and this could be a good way to get started with that. It could also translate well to tvOS, or even Apple Watch so people can play on the go.

Ads

I’ve never included ads in an app, but if this does sufficiently good numbers it’ll be worth considering.

Stats and achievements

It’d be fairly simple to add things like this too, and I could even add support for Game Centre while I’m at it.

More purchase options

Right now, each premium quiz costs 49p. I could offer more diverse pricing, like a bundle where you get 5 quizzes of your choice for a discount, or a ‘mega’ purchase to unlock everything.

Finally

I’ll be sure to post an update in the future about how it’s performing. In the meantime, one of my goals for 2024 was ship two new apps. With this and SalaryPig, mission accomplished 😎