Phillip Caudell @phill@mastodon.notsobig.co

Hello!

I still need to post an introduction, so here it goes.

I'm Phill, one of those designer/developer types. I quit my VC job a couple of years back to bootstrap my own business, The Not So Big Company (@updates).

I'm working on a fast and modern new mail client called Big Mail. The whole thing is written in Swift and SwiftUI, which has been an experience. 🤓

Launching very soon. In the meantime, enjoy some screenshots!

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:

https://github.com/notsobigcompany/BigUIPaging/blob/master/Sources/BigUIPaging/Examples/ExampleGridToPageView.swift

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.

This will likely be a sentiment shared by many of you already, but I still feel compelled to say it each time I see fresh nonsense:

Leave 👏 trans 👏 people 👏 alone 👏

This is the first of many packages from Big Mail and Big News that I’ll be open sourcing over the coming weeks.

It’s also my first time open sourcing anything this big, so feedback whilst I get the hang of things is appreciated!

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:

https://opensource.notsobig.company/documentation/bigswiftui/pageviewstyle/

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.

https://github.com/notsobigcompany/BigUIPaging

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!

technology has peeked

And look, Apple's frameworks have always had bugs. Many of us lived through UISearchDisplayController 💀

But there are two differences:

1. UIKit/AppKit's API surface is much larger. There are just more knobs and dials to turn when things aren't working. Abstracting complexity comes with a cost.

2. The frequency and severity of issues. It would be unimaginable if UINavigationController was left broken for several cycles, but that's exactly what's happened: https://mastodon.notsobig.co/@phill/110939609793823190

Airbnb's recent article highlighted something I think about a lot:

"While Swift and its surrounding foundation have been open sourced, SwiftUI’s implementation remains a black box. If SwiftUI were open sourced, we could better understand the framework and debug more effectively.”

I don't think Apple will ever do it, but boy that would go a long way in fixing many of the issues SwiftUI has today.

(The whole article is great read, btw)

https://medium.com/airbnb-engineering/unlocking-swiftui-at-airbnb-ea58f50cde49

No doubt you can ship amazing things with SwiftUI. I see many great examples of it.

But I also see many examples of developers pulling their hair out trying to understand why their app isn't behaving as expected.

Things that once worked now don't because of an OS update. Or some modifier begins interacting with something in an unexpected way. Or something isn't clearly documented.

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.

https://gist.github.com/phillipcaudell/269e1d9abe1dea1709327fc95560760f

Ooo DocC now includes extensions in Xcode 15!

👏 👏 👏

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)

https://gist.github.com/phillipcaudell/8509aba4f3fc064b3d7bfbb1fefbe9a9

back in my day you could swizzle the whole runtime using a fork whilst hot swapping a UIViewController from space and no one ever got hurt

“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!

https://gist.github.com/phillipcaudell/99d1fe52873d0c5115bc281272003784

This is definitely the best looking rectangle they’ve made yet

The only brushed metal I’m interested in

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.

https://gist.github.com/phillipcaudell/df04ebf01e9579a308e3534ac829a540

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