: Stop using AppStorage directly. It’s prone to typos, value mismatches and more.

Instead give yourself strongly typed keys and associated defaults, à la EnvironmentValues.

I’ve published my implementation as a package, but you can just as easily wrap AppStorage yourself with a few dozen lines.


Had a few people ask how you might go from a scrolling grid to a PageView, à la Photos app.

Using matchedGeometry will get you most of the way there, then it’s just a few little extras to keep both views in sync.

I’ve added some new sample code in the project to show how:


Show thread

There is something incredibly cathartic about running your own Mastodon instance and being able to block an entire instance in a single click.

A thousand ‘free-speech extremists’ screaming into the void.

Show thread

Certain styles such as .scroll and .historyStack bridge directly to UIPageViewController and NSViewController respectively, so you get all those great native behaviours.

But you can also adopt PageViewStyle to create completely custom transitions, like the 3D deck of cards in Messages.

Checkout the docs to see how:


Show thread

New SwiftUI package drop!

📦📖 BigUIPaging

PageView is a flexible container for creating paged interfaces.

Unlike TabView:
- Pages can be decided 'in flight’, ideal for large datasets
- Works across iOS and macOS
- Handles complicated view hierarchies more consistently
- Allows for totally custom styles and interactions

Also included is PageIndicator with support for the new iOS 17 progress timer.


The Creator was excellent and easily one of the most exciting sci-fi movies I’ve seen in a long time.

It felt like James Cameron and Spielberg made a film together. I can’t stop thinking about it.

Go see it in the cinema if you can!

Here's a prime example of what developers mean when they question "is SwiftUI ready for production?”

A simple menu. Left iOS 16.4. Right iOS 17.0.

One works. One fails. Same code.

I love SwiftUI, but it's this kind of thing that make me lose confidence in it.


Why is deinit not called here?

If a StateObject's lifetime is that of the containing view, popping from the stack should deallocate it. But it doesn't.

Weirdly removing the List's selection binding results in a dealloc as expected.

Is this a memory leak with List or am I missing something? (iOS 17/latest Xcode)


“Your engineers were so preoccupied with type-safety that they didn't stop to think if they should”

– Ian Malcolm, 1993

I need an ”AnyCodable" type for serialising some generic stuff.

Is something like this the best approach now that we have existentials on protocols?

AnyThoughts appreciated!


I'm a little embarrassed to admit, but I had been blissfully unaware that View extensions are type erasing.

That means if you have an extension for using your ViewModifier in a more ergonomic way, it'll be erased to AnyView unless you explicitly mark it as @inlinable.


Edit: Perhaps this is just a quirk of Xcode Previews: mastodon.notsobig.co/@phill/11

NavigationStack loses its navigation bar on iPad when returning from the background, making it impossible to go back or do anything. iOS 16 and 17.



Something that tripped me up recently was not understanding how .onAppear { } behaves on iPad.

It gets called multiple times, even though the view is not visible.

Why? Logging reveals the size class is also changing, so presumably iOS is taking snapshots for the app switcher.

If like me you rely onAppear to denote a user has seen something (say, Mark as Read), you'll need to check the scenePhase first.

Here's a gist: gist.github.com/phillipcaudell

Here’s one weird trick Apple DON'T want you to know:

If you present a confirmation dialogue from a swipeAction or contextMenu nothing will happen as the view is removed before the dialogue is presented. Annoying, but it makes sense.

Instead, delegate the confirmation to the environment. Now the Button isn't responsible for the presentation and you're left with a nice clean call site.

Here's my implementation with an example: gist.github.com/phillipcaudell

Show older
The Not So Big Company

The home of The Not So Big Company on Mastodon.