From Swift Publish to Next.js

Swift Publish was a natural first home for this site. It let me keep the writing workflow close to the Apple-platform tools I use every day, and it made the site feel like an extension of the same Swift ecosystem I enjoy building in.

But the site has a new job now. I still care deeply about Swift, iOS, and native mobile craft, but I also want this space to reflect more frontend work: interface systems, responsive layouts, static rendering, web performance, and the small product details that make a site feel considered.

Next.js is a better fit for that direction.

What changed

The migration keeps the site simple: Markdown posts, static generation, tags, RSS, resume, and an about page. The important shift is that the UI now lives in the same language as the surface it renders. Instead of treating the web layer as an output target, I can work directly with React components, CSS, routing, metadata, and the frontend concerns that make a web experience feel polished.

That matters because the site is no longer just a place to publish notes. It is also a small workshop for practicing modern frontend development outside of Swift and mobile.

Why Next.js

The biggest reason is range. Next.js gives me room to keep the boring parts boring while still leaving space for more ambitious frontend work later.

• Static pages can stay fast and easy to deploy.
• Markdown content remains lightweight and portable.
• React components make design iteration more direct.
• App Router conventions provide a clear path for metadata, feeds, and page structure.
• The project can grow into richer frontend experiments without changing foundations again.

This is the same kind of tradeoff I like in native apps: choose a stack that handles the repetitive parts cleanly, then spend the saved attention on product feel.

What I want to explore next

On iOS, polish often comes from the details: animation timing, accessibility, navigation rhythm, data loading, state restoration, and how the interface behaves under pressure. The web has its own version of that craft.

I want to use this site to explore more of it:

• Cleaner writing and portfolio layouts.
• Component systems that feel maintainable instead of ornamental.
• Responsive pages that hold up on real devices.
• Frontend performance and static deployment tradeoffs.
• Small interactive demos that complement native-app work.

The throughline is still the same: build software that feels intentional.

Keeping the Swift mindset

Moving the site to Next.js does not mean moving away from Swift. If anything, it makes the contrast more useful. Swift has trained me to care about clear types, smooth interaction, and system-native detail. Working more directly on the web is a way to bring those instincts into a different environment and sharpen a broader frontend toolkit.

That is the direction I want this site to point: native craft, web craft, and the engineering judgment that connects them.