It happened again. I made another thing.
Logzi started life in that region of time when work was slow enough for me to contemplate using my spare time for more. When I considered what I wanted to build, I landed on something fairly simple, how about a log viewer? Basically something that could improve the experience of viewing logs in the AWS console.
To get there I first started in Electron. I was able to get a prototype of up and running fairly quickly, but something was bothering me. I based my design for the application on some native macOS applications, and in my first prototype, I tried to follow very closely all of the macOS conventions I was used to. At some point I stopped to ask myself, why am I recreating something I could get for free if I just built a native application? So that’s what I decided to do.
I went to a Swift development website and paid for a course to learn both Swift and SwiftUI. Once I had the basics, I started hacking at the app again, but this time all in Xcode. The nice part about building it native is that I got a lot of things for free. Niceties like toolbars, dark/light mode, menu commands, were all well supported and easy to implement. I made progress fast and was really loving the fact that I was also learning something new.
After several months, I had a prototype that was working, but I had some issues still. By far the biggest hurdle for me was the log detail view. At its core it’s just text, and displaying text natively isn’t hard, but the whole point of this application was to improve on the standard experience of viewing logs. To do this, I wanted to add things like syntax highlighting and code folding. I was able to find many existing samples for syntax highlighting. It’s pretty basic right now, a few regular expressions, but they get the job done. Code folding on the other hand, was much harder to figure out.
To support code folding at all, you can approach it one of two ways. If you parse the log as if it were code in a specific language like JSON, the parsing libraries will have an understanding of where and how the code can fold. The other option is to fold based on indentation, meaning if the output of the file is already printed out nicely, you can traverse the lines and track the levels of indentation to determine folding.
Both options were quite a bit over my head in the native world. In macOS, all of the existing efforts I’ve come across rely on the first option, a semantic parsing of the code. To support this, it would require that I know what language the log is in, and even in my limited use cases that can vary quite a bit. Logs can come from a Node project, a Python backend, or a database query log. One such project that does a very good job at handling a wide variety of code that supports folding is Monaco, which is the editor portion of the VSCode project.
I embedded a web view with Monaco into my native application and it worked quite well. I styled some of the custom ui components to fit in with the overall application, and for a long time this was going to be what I launched. I had a preference pane in the application that let users choose a native text view that didn’t do any folding, and an “enhanced” viewer that did folding, the aforementioned Monaco editor.
Other projects I came across landed on similar solutions for rich code handling, and a survey of the native macOS editor ecosystem shows only a handful support code folding. It’s not an easy thing to develop for, because it involves diving into some lower level structures within a text view, looking at the bounding boxes for lines and then keeping track of folded zones and line wrappings. I wanted my web view to the solution, but it nagged me quite a bit that I didn’t have this built out natively.
Enter the LLM. One evening I wanted to just see how far it could get with them. I knew it wasn’t a simple ask, but I also knew the limits of my own ability to deeply understand the inner workings of macOS’s text layout internals. I justified this to myself with the understanding that my goal wasn’t to build a text editor, just a log viewer. Eventually, with a lot prompting, re-prompting, and focused problem fixing, I was able to get it working.
Once the folding was working like I wanted it to, I removed the web view, and felt much better. At this point I was beta testing the app within my normal daily workflow, making sure it worked for somebody like me. This led to a lot of bug fixes and constant ui tweaking.
We’re probably over a year in at this point of me off and on working on this app. I would get burnt out with the workflow. I found setting up previews in Xcode tedious, and not close enough to the final product to give me a sense of how things would look and feel. Coming from the web I was used to things like hot module reloading, or constant refreshing to view my changes, but with native ui work I typically code a module, run the app, make some tweaks, run the app, over and over. It was time consuming, and definitely very inefficient on my part.
As my development time grew, I eventually had to contend with new versions of macOS, and even a new visual language for the whole operating system. Most recently, AWS launched a new way to authenticate users outside of key/secret combinations, so I had to build in support for that as well.
Over the past couple of days I decided to throw in an in app purchase setup. I thought it was quite bold of me to charge for something before a user could even experience the app, so I set up a system to generate demo content and allowed the app to be free, and only after an unlock could you add your own credentials.
All in all, I guess we’ll see how it goes! I’ve built a couple of other personal apps that are no longer in development, and I’m expecting the audience for this one to be minuscule, but I’m still enjoying hacking on it. Current status is pending approval in the macOS App Store.
Update 2025-12-31
Rejected! Probably user error. I need to have my in-app purchase approved before it will show, but I need to submit it with a binary to get it approved, but the app got rejected because the in-app purchase will only show if it’s approved. Seeking further clarification.
Update 2026-01-08
Still rejected. It took me some time to figure out how to get in-app purchasing to work in the sandbox. Once I verified that, I got dinged for not showing the price in the purchase window. I just submitted a new version with the price showing.
Update 2026-01-13
