I think I’ve managed to achieve the behavior I want using pure SwiftUI, which makes me weirdly happy. I might have made a compromise or two on the visuals in order to do it with pure SwiftUI, but that’s a trade-off I’m OK with for now.
Having so much fun with this project! I spent last night and most of today optimizing the main UI for iPad and I think it’s turned out very slick. Might be the best iPad optimization I’ve ever done.
Spending a tremendous amount of time optimizing my app this week in order to avoid hitches during navigation. This is really tricky with a somewhat advanced SwiftUI app. I enjoyed it in the beginning, but I’m really struggling to pinpoint where I can do the remaining optimizations, so it’s starting to feel daunting.
Every of these hitches happen on some common and key navigation in my app and I'm fightning so hard to get rid of them, but… This SwiftUI code is getting the best of me 😢
I'm starting to think that SwiftUI's TextField is a bit expensive on macOS. It seems that once I load ~10 text fields into a view, I'm noticing small hitches.
About to build a “mosaic” layout in SwiftUI where the size of the views will depend on the properties of the model they represent. Some views will fill the entire screen, and some will be sized to show two-by-two.
If this turns out well, this will be the first thing people see when they open my new app 😀🤞
Seems like the tricky part is figuring out how I can introduce a concept of sections when using SwiftUI’s Layout protocol to place views on the screen 🤔
I know how to do this with a UICollectionViewFlowLayout but I’d like to do it in SwiftUI.
This project allows me to build UI that I've had on my mind for 5 - 6 years. It feels so good to see it come to life and play around with it on my own devices.
For the first time since starting this project, it’s in a state where I can actually use it myself. There are still sooo many features I want to add, but it feels amazing to finally have the core flow working 😃
Getting here has taken longer than usual. Normally, I rush to get the core flow working end-to-end so I can verify everything, and then polish later.
But this project was different. From early prototypes, I knew the technical side would work. The real challenge was designing an interface that felt good enough that I’d actually want to use it. It slowed things down, but I’m glad I did it.
Moved the category filter to the bottom of the screen so it’s within reach and tweaked the appearance slightly. It’s starting to feel the way I want it to.
Spending a few hours these Christmas days combining Swift macros, property wrappers, and result builders to build a powerful API that lets me generate large parts of the UI for my upcoming side project. Feels good to get this nerdy again 😄
Spent a couple of hours today writing some of the weirdest SwiftUI I’ve ever written. In a small part of this side project, I need to use Mirror to traverse the children of a SwiftUI view hierarchy. Looking forward to show you why 😄
As much as I dislike large parts of Liquid Glass and would go back to the iOS 18 UI in a heartbeat, I have to admit that Liquid Glass fits quite well with the app I’ve been working on intermittently since early June.
I’m so close to being able to show you the project I’ve been working on since early June (with breaks, for example, to build Festivitas). It has been eight months underway. I’m now using it daily. I hope some of you will too.
Still a few somewhat big features left before I can release this project. Payments is one of them.
I think this will be my first subscription app. My guess is it’ll require a non-negligible amount of changes and testing with every major iOS release, and to make that sustainable, subscriptions feel like the right model.
Looking forward to diving into the subscription APIs in StoreKit… though I’ve heard they can be a bit daunting 😅
Part of me really doesn’t want any kind of account in the app, even if it’s optional or delayed. But I also want something that’s secure and maintainable… which is exactly what Sign in with Apple promises to be.
Trade-offs everywhere. Curious how others have approached this.
How to Use iCloud While Only Kinda Using iCloud
iCloud is the gift that keeps on giving - both good and bad. Let’s see how to leverage one of its best aspects today.
@simonbs users will have devices not signed in to iCloud. For those that are signed in, then writing device push tokens to a public table on iCloud (that only the creator and you can read) suffices. The issue is with not signed in devices.
@pfandrade My main concern is that I need to do a mapping in my service between CloudKit user record IDs and push tokens. Unless I properly secure this, anyone with access to the user record ID can register their own devices, making them receive private push notifications.
Therefore, I need to add some layer of security on top of this so a CloudKit user record ID isn't sufficient. Proving that's actually safe is tricky.
@simonbs let the app create the device token records on a public database, protect this table so only the creator and you have read access. Look at each row’s creator user id to know who it belongs to. Add another column with the user id itself if you need to search.
Seems secure enough for me.
Add logic to remove stale device tokens when APNS tells you so.
@pfandrade How can my backend service access this? It seems that something like CloudKit JS requires to authenticate as a user, or am I missing something?
With an API key generated in the CloudKit dashboard. The user generating the API key is the one you must ensure has read permission to that push tokens table.
CloudKit Web Services Reference: About CloudKit Web Services
Simon B. Støvring
Paulo Andrade