I'm having a re-rendering issue in SwiftUI. - I have two windows open with the same Space in each. - I then change the name of the space in `LaunchView`. Now, only the frontmost window will be automatically updated to display the new name of the Space. However, the window behind does **NOT** update unless I hover above the button displaying the name. I have tried the `.id()` approach, but that didn't work. It's a minor problem, but it's still driving me crazy. Using `@Observable` in the ViewModel should take care of re-rendering the necessary parts in the UI. I just don't understand why it only works in the frontmost window...

It's funny how sometimes when asking a complex question to Claude, it will go in an infinite loop. It's like: - "Wait, that won't work" - "Actual Fix:" - "Actually, that's not the right approach either." - "Actually, let me check the actual update flow more carefully:" - "The ACTUAL problem:" And then it ends with: "Let me try a different approach - add logging:" Please Claude, just tell me to add print statements before you start rambling off... It's wasting my weekly limit 😭

I have now finished implementing support for adding and removing note documents as bookmarks. The user can simply right-click a note and then select the option called 'Bookmark'. Bookmarks are saved locally on the user's device in a file called `bookmarks.json` located in the hidden folder `.space/`. Also, I have worked on making a small preview overlay that appears when hovering notes. It's not quite done yet. Still need to work on the UI of it, but I think it's pretty nice. #dev #AppKit #SwiftUI #macOS

I’m starting to get a pretty good understanding of the limitations and quirks/bugs in SwiftUI and AppKit, and of ways to workaround these issues. It makes developing native apps with SwiftUI and AppKit a lot more fun.

I don't understand why liquid glass buttons are so boring on macOS 26 compared to iOS. They are just static without any cool effect when clicking them... :( Been thinking about integrating them into my notes app, but I don't even see why I would want to. This is probably not an easy task, but I wonder if it's possible to modify the `.glass` effect on SwiftUI buttons. Otherwise, maybe I could go completely custom and use the `.glassEffect()` modifier on my own buttons. But the animation will not be easy to accomplish - it's what makes the buttons so engaging to click on iOS.

I have now implemented functionality to save and remove bookmarks. Simply right-click on a note document, and the context menu will show a ‘Bookmark’ button. Bookmarks are stored in a local file called `bookmarks.json` located in the hidden folder `.space/`. **Next task:** Display list of bookmarks in the UI.

I was wrong… It had nothing to do with switching to `NSWindowController` from `WindowGroup`. I just didn’t realize my SwiftUI `CommandGroup` was messing up my close shortcut for the AppKit window. I thought they wouldn’t work with the AppKit approach, but apparently they still do. Now `Cmd+W` will close the selected tab while using `Cmd+Shift+W` will close the focused window. View quoted note →

Well, turns out I also needed to replace my `LaunchView` from being initialized with SwiftUI's `WindowGroup` to an AppKit approach using `NSWindowController`. Now I have full control with AppKit and can easily choose when to open and close the window 😌 #dev View quoted note →

I'm happy that I made the switch to AppKit for the window management. Even though it's not as fun to work with, it's just so much more reliable than SwiftUI if you want to do something more complex. View quoted note →

I tried using `UserDefaults` to save the IDs of open windows, so that when terminating the app and then re-launching, the app would open the same windows again. But apparently, this is not as easy as I thought - at least not when using #SwiftUI. I'm moving to an #AppKit approach instead to handle my window management... #dev

LLMs like Claude are cheap. Especially considering the value they bring me and many other developers. But I do wonder how long the prices are going to stay like that… 😬

By window management I mean supporting multiple independent windows to be open at the same time. I want to enable a different Space to be open in each window, or the same Space… Currently, all windows are linked, so if you switch Space in one window, the same change will happen in all the others. It’s not intentional though, I think it must be some default behavior in AppKit. #dev View quoted note →

Attempted to implement advanced window management for my notes app this afternoon, but gotta admit, I’m just too tired to think clearly. I’ve done a lot of work to get the functionality working to create and switch Spaces. Made a little menu to view all Spaces and switch between them. Seems to work really well. Tomorrow will be about implementing window management. #dev GN Nostr 💤

I hope to get the `app_state.db` completely up and running today, but it’s going to require a bit of work. I need to implement the following: - Create and update Spaces - Switch between current Space - Pull recently opened Spaces in chronological order to make a list in UI - Reopen the latest Space when launching app Most of the tasks also require building the UI. Maybe I can even start working on `cache.db` today as well, but it’s more important to get a really solid solution implemented for `app_state.db`. I did the database queries yesterday using the Swift package called `GRDB`:

GitHub

GitHub - groue/GRDB.swift: A toolkit for SQLite databases, with a focus on application development

A toolkit for SQLite databases, with a focus on application development - groue/GRDB.swift

View quoted note →

After having used a bunch of LLM models, this is my conclusion: - Gemini 3 Thinking for brainstorming - Claude Sonnet 4.5 for programming View quoted note →

I think perhaps having two databases would be preferable: - `app_state.db`: It stores data such as which Spaces are currently added to the app and where they are located on the disk. Will also include a table of recently opened Spaces - this will be used to show a list in the UI. - `cache.db`: This database is disposable and is just used for mirroring. The app will scan the Space folder to rebuild the database. The local files are always the source of truth, but having the `cache.db` database allows for very efficient indexing. #dev View quoted note →

The easy route would be to just store everything in the SQLite database, but I really do prefer the approach of having local files. I think the right choice is going to be a hybrid approach where the app uses both local files and a database, but I need to find the right balance... There should be an app database storing 'Spaces' with their names and icons/images. This database will be stored inside the app directory, and it will therefore be device-specific. This means, each device will have its own local database. This creates a bit of a problem in terms of continuity because of no global database that's hosted in the cloud. Imagine the following scenario: - The user bookmarks a note on their Mac. - Now the user opens the iOS app, but the bookmark is not to be found. The bookmark will not appear automatically, because as already mentioned, each device has its own local database. Luckily, there is another way to do it that solves the problem of continuity. I could simply use hidden folders inside the space folder. Then the local database will just mirror the information found in the files located in the hidden `.space/` folder. The folder structure could be something like: ``` /Documents/My_Project_Space/ ├── .space/ │ ├── settings.json (spaceName, icon/image, bookmarks, recentNotes, ...) │ └── history/ │ └── F0B35EEF/ (Folder named by note ID) │ ├── 20260112_1000.json │ └── 20260112_1045.json ├── assets/ │ └── some_image.png ├── Work_Notes/ │ └── meeting_jan_12.json └── some_other_note.json ``` The local files should always be the source of truth, while the database is there mirroring for performance. If the user types a character in a note, the local DB should be updated and immediately refresh the UI, this should take <1ms, so the user sees the change instantly. Then after, the app triggers a background task to write the updated JSON to the disk. I'm still in the process of figuring out the best architecture before beginning implementation, but I think I'm starting to have a pretty good idea of how to best do this. #dev #app View quoted note →

Gemini 3 Thinking is really good at brainstorming implementation architectures for my notes app. I'm trying to decide how I want to store notes. Currently, I have an approach of using a local JSON-file for each note document, but I _need_ a local SQLite database for version control and other features. Technically, I don't really need the database for version control, as I could have a `/.history/[note-id]` folder and then store each version of the note, but this is not efficient at all. It increases disk usage like crazy compared to the database-approach. #dev

Interesting blog post, but Nostr should have been mentioned in "Connecting with friends on the Web"

A Website To End All Websites | Henry From Online

How to win the war for the soul of the internet, and build the Web We Want.

Can confirm 👍 View quoted note →