Cam Hunt

april 1st is the best day to go offline and ignore the entire internet for one day

Swift allows including trailing commas in collection literals to make it easy to append, remove, reorder, or comment out the last element as any other element. Swift 6.1 extends trailing comma support to tuples, parameter and argument lists, generic parameter lists, closure capture lists, and string interpolations.

most exciting feature of Swift 6.1

Ooooo what’s the enum trick?

Code showing a bunch of Swift typealiases assigning codable corollaries of SwiftUI views to their corresponding SwiftUI namespace. Text = TextCodable, Image = ImageCodable, and so on and so forth. Below is a declaration of a view that perfectly resembles a SwiftUI declaration.

A full imitation of a SwiftUI view on a Vapor server, fully Codable and ready to be sent via JSON.

This iOS app displays CodableUI from a Vapor server. Then it listens for actions from the CodableViews. If it gets an action with a path, it displays a new screen that loads that path and displays the returned CodableView.

A screenshot of an iOS Simulator in the foreground and Xcode in the background. The simulator is displaying a list of breweries and Xcode is displaying a Vapor route for a list of breweries and a debug console printing requests as they are requested.

Can you use CodableUI to display entire screens in an iOS app from, say, a Vapor server? Yup!

it’s rough out there. even WWDC didn’t have enough money for another V

GitHub - camh/CodableUI: A proof-of-concept to represent native SwiftUI views in a Codable structure. A proof-of-concept to represent native SwiftUI views in a Codable structure. - camh/CodableUI

Fun weekend project. One day I woke up and thought "wait, SwiftUI views are just structs, right? Can it be Codable? Could you create a native SwiftUI view with JSON?"

The answer is yes.

github.com/camh/CodableUI

A screenshot from Xcode showing a JSON string that defines a SwiftUI body.

A preview of the resulting SwiftUI body rendered from JSON.

Getting even more cursed …

A block of code declaring a JSON string and a Swift UI preview to render that JSON as SwiftUI views.

A SwiftUI preview showing the result of rendering a SwiftUI view using JSON.

Doing something extremely cursed

Bluesky’s implementation of a federated protocol is a lot more complex than Mastodon/ActivityPub. I’d check out Mastodon’s API if you’re interested in a simpler federated API because it doesn’t employ some of the more complex concepts of atproto

Federation Architecture | Bluesky The AT Protocol is made up of a bunch of pieces that stack together. Federation means that anyone can run the parts that make up the AT Protocol themselves, such as their own server.

I’ve found the Bluesky documentation to be much more approachable than the documentation on atproto.com. This page (and the page before) are pretty good overviews of the concepts: docs.bsky.app/docs/advance...

Yup aside from complex OAuth, the API is just really complex because it’s a decentralized protocol. But it’s also polymorphic so consuming it with a statically-typed language like Kotlin is gonna be pretty advanced

Showing a new draft on launch (with the ability to go back to the draft list) is much different than, for example, making an entirely separate UX where the compose screen is the root and the list of drafts is shown on top of that. That I will not do. Because I do not want to make two apps.

I'll almost certainly add the ability to open my app to the compose screen. But unlike a lot of the apps you mentioned, I'm just one developer with limited resources.

I'm not saying allowing people to choose preferences is bad. But all software is opinionated and behaves the way the developer decides. Even your example of Obsidian doesn't have a way to create a new note on launch. (Although it does have a LOT of options)

I think if people want the inverted flow of Compose>Drafts then good news: every draft app or feature already works like that. I'm making an alternative that centers drafting.

I honestly can't think of an app that provides a feature set and allows a user to configure the flow.

I see the feature set and the UX as intrinsically linked. Either drafts are important enough to be the main screen of your app or … well, it's not really a drafting app, is it? Croissant is a composing app with a cache, it's not a drafting app IMO

Many note taking apps have the option to display a compose screen on open. But if they do, there's a back button to see the list of notes. Have you used Croissant? Draft list opens in a modal, no search, ordering, etc. Nothing that would allow you to navigate or organize more than a couple drafts

Imagine if your Notes app opened to an empty note and to see a list of your notes you had to tap a button. Would you call that a subtle difference?

Thank you for figuring it out! I think I can get OAuth working … now I'm just weighing my options for how to structure multiple persistant accounts. I was hoping to have one Bluesky client that applies auth via a parameter for any given request, but now I'm not so sure

Croissant is a well-made app, but I fundamentally dislike the inverted hierarchy of Compose > List of drafts. It should be List of drafts > Compose. Ever since Twitter implemented drafts this way, every platform copied that inverted UX for their drafting features and I extremely dislike it.

Drafting app with cross-posting app to Mastodon and Bluesky

Oh, I have no doubt it works! I'm still working on the architecture for my app. It supports any number of accounts, so OAuthenticator basically being a replacement URLSession is different than what I was originally going for

Yup! I've seen most of those (well, the Swift ones). Most are either pretty early in development or not exactly what I'm looking for. I will probably end up taking some ideas from OAuthenticator to roll my own

I'm writing in Swift, so I was gonna use the OAuthenticator package, but even that bails on the actual implementation of DPoP signing. I'd prefer to roll my own, though

Specifically authentication. I guess mostly in relation to Mastodon's API. I was able to pretty easily write my own OAuth flow for Mastodon, but atproto's OAuth implementation is very complex and strict

Holy moly Bluesky's AT protocol is complicated.

A screenshot of the web app Trello, which features columns of cards over a stylized background photo of a city

get ready for ios 19

Recently played around with a glass-like UI prototype and I can’t tell you how bad it looks on a solid color background. visionOS was made to exist in an environment and I don’t know how you do that on iOS without each app having its own Wallpapers