The Tech Stack Behind Svift Studios (And Why I Keep It Boring)

Simple tech stack diagram showing SwiftUI and CloudKit
TL;DR
  • Apps: SwiftUI + SwiftData. No third-party UI frameworks.
  • Backend: CloudKit for sync, no custom servers. $0/month infrastructure cost.
  • Website: Static HTML/CSS. No React, no build step, hosted free on Vercel.
  • Boring tech means less maintenance, faster shipping, and more time for what matters.

People sometimes ask what tech stack powers Svift Studios. I think they expect something interesting. Microservices. Kubernetes. A custom design system.

The real answer is almost embarrassingly simple.

The Apps

Convert is built with:

  • SwiftUI — Apple's declarative UI framework. No UIKit unless absolutely necessary.
  • SwiftData — For local persistence. Replaced Core Data when iOS 17 came out.
  • Combine — For reactive data flow, though honestly just the basics.
  • WidgetKit — For home screen and lock screen widgets.

That's it. No Realm. No Firebase. No third-party analytics SDK. No custom animation libraries.

The currency rates come from a free API with a paid tier I'll probably upgrade to eventually. Exchange rate data gets cached locally so the app works offline.

The Backend (Or Lack Thereof)

Convert's "backend" is CloudKit. Apple's iCloud-based database that syncs across devices.

Monthly cost: $0.

Seriously. CloudKit is free up to pretty generous limits. For an app like Convert, I'd need millions of users before hitting any caps. Even then, Apple's pricing is reasonable.

What CloudKit handles:

  • Favorites sync — Your saved unit pairs sync across iPhone, iPad, Mac.
  • Settings sync — Theme preferences, default currencies, display options.
  • Currency alerts — Alert configurations stored in the cloud, checked server-side.

Could I build something fancier with a custom backend? Sure. Supabase or PlanetScale or whatever's trendy this month. But then I'd be maintaining servers. Monitoring uptime. Handling security patches. Managing database migrations.

All of that is time not spent building features or fixing bugs.

The Website

sviftstudios.com is static HTML, CSS, and vanilla JavaScript.

No React. No Next.js. No build step. No npm install with 847 dependencies.

I write HTML in VS Code. I save. It works. The site loads in under a second because there's almost nothing to load.

Hosting is Vercel's free tier. Which is overkill for a static site, honestly. I could host it on GitHub Pages or Netlify or a $5 VPS.

The only JavaScript is some fade-in animations and a contact form. Maybe 40 lines total.

Why Boring?

There's a temptation, especially early on, to use new technology. It's more interesting. It looks better on a resume. You can tweet about your cutting-edge stack.

But every technology choice is a maintenance burden. Every dependency is a future security patch. Every framework is something that might break in the next OS update.

For a solo developer, time is the scarcest resource. Every hour spent fighting tooling is an hour not spent on product.

SwiftUI has bugs. Sometimes frustrating ones. But when I file a radar, Apple eventually fixes it. I don't have to fix the framework myself. I don't have to wait for an open-source maintainer to review my PR.

CloudKit isn't as flexible as a custom backend. But it's one less thing to monitor at 2am.

Static HTML isn't impressive. But it's never going to break because a package got yanked from npm.

What About Scaling?

"What if you get millions of users?"

Then I'll have a very good problem and the resources to solve it.

Right now, Convert has maybe 15,000 monthly active users. CloudKit handles that without thinking about it. SwiftUI handles that without thinking about it. The static website could handle 10x the traffic with zero changes.

If I hit a million users, I'll have revenue to hire someone who knows how to scale. Until then, I'm not going to prematurely optimize for problems I don't have.

Most apps never need to scale. They need to ship.

The Exceptions

I'm not religious about this. Sometimes new tech is genuinely better.

SwiftUI was risky when it launched in 2019. By the time I started Convert in 2024, it was mature enough. I made a judgment call that the productivity gains outweighed the remaining rough edges.

SwiftData was newer but solved a real pain point with Core Data. The API is so much cleaner that it was worth adopting early.

For Anchor (coming later this year), I'm experimenting with Swift Charts and the new iOS 18 animation APIs. They're new but stable enough.

The question isn't "is this new?" It's "does this help me ship faster and maintain less?"

The Unsexy Truth

Users don't care about your tech stack.

They care if the app is fast. They care if it crashes. They care if it does what they need.

Convert could be built with React Native or Flutter or a custom game engine. Users would never know the difference if it worked well.

But I would know. I'd be spending nights debugging cross-platform weirdness instead of adding features. I'd be managing bridge dependencies instead of answering user emails.

Boring tech is a competitive advantage. It lets a solo developer punch above their weight by not fighting their tools.

I'll take boring every time.

Shaun
Shaun

Founder of Svift Studios. Building thoughtful apps for iOS.