Recently, I’ve been experimenting a lot more with Swift as a language for web applications. I’ve primarily been focusing my efforts on the web framework Vapor which is the most complete and popular web framework for Swift and is used by the likes of some very large projects such as the Swift Package Index.

The framework is based on SwiftNIO which is Apple’s open-source “cross-platform asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients.” I also recently read somewhere that Apple itself uses SwiftNIO to power its newer web services as it is low-level and low-latency — both critical aspects considering the sheer enormity of the number of requests that Apple’s web services have to process. Whether or not that is true is something I can’t confirm, but it sounds plausible considering it is an Apple-developed framework that does exactly what a high-performance web service would need.

So, naturally, I asked myself what it would take to make my own basic web app using SwiftNIO without any other dependencies beyond the three others that SwiftNIO itself relies on. As it turns out, it doesn’t actually take as much as I thought. Since I wanted to keep this experiment simple, I focused on basic functionality rather than implementing a fully featured web framework. If I wanted that, I would just go with Vapor.

Before we start, I want to mention that I pushed the entire experiment to GitHub with thoroughly commented code so that you can see what I did and/or play around with it yourself. There will be several links to various parts of the code on GitHub through the post.

Setting Up the Server

The first, and arguably most critical, feature any web application needs is a server. In this case, one that uses SwiftNIO for network communication. In order to accomplish that, I created two classes: HTTPServer and HTTPHandler. As the names might suggest, the first sets up the server and network infrastructure while the latter handles each individual connection.

The HTTPServer class includes a method called start() which uses SwiftNIO’s ServerBootstrap to bind a TCP port and configure how connections are handled:

public func start() async throws {
    let router = self.router

    let bootstrap = ServerBootstrap(group: group)
        // How many pending connections the OS kernel should queue before the
        // application has a chance to accept them.
        .serverChannelOption(ChannelOptions.backlog, value: 256)
        // Allow the port to be reused immediately after the process restarts,
        // without waiting for the OS TIME_WAIT period to expire.
        .serverChannelOption(ChannelOptions.socketOption(.so_reuseaddr), value: 1)
        // For each accepted connection, configure the NIO pipeline:
        //   1. Built-in HTTP/1.1 encoder + decoder
        //   2. Our custom HTTPHandler for routing
        .childChannelInitializer { channel in
            channel.pipeline.configureHTTPServerPipeline().flatMap {
                channel.pipeline.addHandler(HTTPHandler(router: router))
            }
        }

    let channel = try await bootstrap.bind(host: host, port: port).get()
    print("Server running on http://\(host):\(port)")

    // Suspend here until the channel is closed. In normal operation this never
    // returns — the server runs until the process is killed.
    try await channel.closeFuture.get()
}

That’s all that the HTTPServer class actually does. The rest happens in the HTTPHandler class which, as you may have noticed is added as a handler to the channel pipeline.

For each incoming request, a new HTTPHandler instance is created and is responsible for four different tasks:

1. Receiving request parts
2. Bridging to Swift concurrency via Task
3. Writing the response
4. Closing the connection

This is the lifecycle of a single request:

Client connects
        ↓
ServerBootstrap accepts → creates HTTPHandler
        ↓
SwiftNIO fires channelRead(.head)  → store head
SwiftNIO fires channelRead(.body)  → accumulate bytes  (0 or more times)
SwiftNIO fires channelRead(.end)   → dispatch to router via Task
        ↓
Router matches route → calls handler → returns HTTPResponse
        ↓
eventLoop.execute → write response head + body + end
        ↓
Connection closed

Receiving Request Parts

The HTTPHandler class implements SwiftNIO’s ChannelInboundHandler protocol which expects, among other things, the function channelRead(). This function is called multiple times per request and a value identifying which part of the request is currently being handled is passed via one of three different enums: .head, .body and .end. With these, we can determine our course of action and how to handle the data being sent.

One gotcha, however, is that SwiftNIO breaks down large bodies into chunks which means there is the potential for multiple .body parts. I go into more detail about that in the section below where I describe how I implemented the RESTful methods.

Bridging to Swift Concurrency via Task

SwiftNIO operates with event loops which, like when working with Node.js, should never be blocked. As such, we need to ensure that route handlers are executed asynchronously. I implemented that by stuffing them inside a Swift Task when SwiftNIO passes .end:

Task { [head = head] in
    let response = await router.handle(head: head, body: body)
    // ↑ runs on Swift's cooperative thread pool, not the NIO thread
    
    eventLoop.execute {
        self.write(response: response, context: context)
        // ↑ hop back onto the NIO event loop to write the response
    }
}

Writing The Response

The HTTPHandler class is also responsible for serializing the HTTPResponse object returned by the routes (more on that below) into SwiftNIO’s three-part format which includes:

• HTTPResponseHead (status & headers)
• ByteBuffer (body bytes)
• End marker (signals that the response is complete)

This logic takes place in the write() function (see on GitHub):

private func write(response: HTTPResponse, context: ChannelHandlerContext) {
    // Allocate a NIO `ByteBuffer` sized to the response body and copy the bytes in.
    var buffer = context.channel.allocator.buffer(capacity: response.bodyData.count)
    buffer.writeBytes(response.bodyData)

    var headers = HTTPHeaders()
    headers.add(name: "Content-Type", value: response.contentType)
    // Telling the client the exact byte count avoids chunked transfer encoding
    // and lets browsers display progress correctly.
    headers.add(name: "Content-Length", value: "\(buffer.readableBytes)")
    headers.add(name: "Connection", value: "close")

    let responseHead = HTTPResponseHead(version: .http1_1, status: response.status, headers: headers)

    // Write all three parts. The first two use `write` (buffered); the last uses
    // `writeAndFlush` to push everything to the network in one syscall.
    context.write(wrapOutboundOut(.head(responseHead)), promise: nil)
    context.write(wrapOutboundOut(.body(.byteBuffer(buffer))), promise: nil)

    let channel = context.channel
    context.writeAndFlush(wrapOutboundOut(.end(nil))).whenComplete { _ in
        // Close the TCP connection once all bytes have been sent.
        channel.close(promise: nil)
    }
}

HTTPResponse is a Sendable struct I created that contains the response HTTP status, the content type and the body data as a Swift Data object. You can view it on GitHub.

Closing The Connection

The write() function above also contains the code that closes the connection after every response. This is the bit of code responsible for doing that:

let channel = context.channel
context.writeAndFlush(wrapOutboundOut(.end(nil))).whenComplete { _ in
    // Close the TCP connection once all bytes have been sent.
    channel.close(promise: nil)
}

Starting the Server

Now that we have everything in place, all that is left is to instantiate the HTTPServer class and call the start() function at the end of the main.swift file to start the server:

let server = HTTPServer(host: "127.0.0.1", port: 8080, router: router)
try await server.start()

Now that we’ve looked at how the custom server works, let’s see what else the application can do using the server.

What This Basic Web App Can Do

I’ve mentioned several times already that the web app I made is basic and simple. It does, however, contain everything necessary for a basic API application or even a web application with light templating needs. Here is an overview:

• RESTful methods
• Routing
• Basic templating with XSS safety
• Static content
• HTTP/1.1 support

RESTful Methods

First off, the application includes support for routes with all RESTful methods (GET, POST, PUT, PATCH, DELETE) including body and header parsing. Initially, I wasn’t going to include support for anything but GET, but SwiftNIO made it surprisingly trivial to include all of them.

Supporting body parsing was a bit trickier, but also wasn’t all that difficult once I figured out how SwiftNIO actually handles requests. It doesn’t actually ever give you a complete HTTP request in one go. Instead, it streams it piece by piece. These can be identified via enums like this: .head  →  .body  →  .body  →  ...  →  .end. As you can see though, the .body case can arrive multiple times for large payloads since SwiftNIO breaks it down into chunks. That made it a bit trickier to solve, but also not terrible. I just had to accumulate the chunks and then put them together at the end of the request:

private var bodyBuffer: ByteBuffer?

// ...

case .body(var buffer):
    // Accumulate body chunks. For small bodies this will be a single call;
    // for larger bodies NIO may deliver multiple chunks.
    if bodyBuffer == nil {
        bodyBuffer = buffer
    } else {
        // Append the new chunk to the existing buffer.
        bodyBuffer!.writeBuffer(&buffer)
    }

case .end:
    if var buf = bodyBuffer, let bytes = buf.readBytes(length: buf.readableBytes) {
        body = Data(bytes)   // ByteBuffer → [UInt8] → Data
    } else {
        body = Data()        // no body (GET, HEAD, etc.)
    }

The code above is heavily cherry-picked. You can see the whole context on GitHub.

Routing

Of course, no web application would be worth anything if there wasn’t some form of routing. To accomplish this, I created a Router class that is responsible for registering all routes with their respective methods and handler functions, parsing the incoming URLs and calling said handler functions. The latter always return an HTTPResponse object as described above. I figured the best way to do this would be the regex-route (pun intended) which can be seen in the add() function of the Router class:

public func add(_ method: HTTPMethod, _ path: String, _ handler: @escaping Handler) {
    var paramNames: [String] = []

    // Replace each `:paramName` segment with a regex capture group `([^/]+)`,
    // and record the parameter name so we can map captures back to names later.
    let regexString = path.replacing(/:([a-zA-Z0-9_]+)/) { match in
        paramNames.append(String(match.output.1))
        return "([^/]+)"
    }

    guard let regex = try? Regex("^" + regexString + "$") else { return }
    lock.withLock { routes.append(Route(method: method, regex: regex, paramNames: paramNames, handler: handler)) }
} 

Then all you have to do is add your routes and handlers in the main.swift file:

router.add(.GET, "/") { head, _, _, _ in
    let pageHtml = layoutView(title: "Homepage", content: homeView())
    return HTTPResponse(status: .ok, contentType: "text/html", body: pageHtml.description)
}

router.add(.GET, "/hello/:name") { head, params, urlComponents, _ in
    let name = params["name"] ?? "unknown"

    // Extract the optional `?german=true` query parameter.
    let germanParam = urlComponents.queryItems?.first(where: { $0.name == "german" })?.value
    let isGerman = germanParam == "true"

    let title = isGerman ? "Hallo \(name)!" : "Hello \(name)!"
    let pageHtml = layoutView(title: title, content: helloView(name: name, isGerman: isGerman), name: name)

    return HTTPResponse(status: .ok, contentType: "text/html", body: pageHtml.description)
}

You might have noticed in the example that parameterization of URLs is also supported. This includes both inline parameters (i.e. /hello/:name) as well as query parameters (i.e. /hello/:name?german=true). Inline parameters are parsed using the regex above and query parameters are extracted from the urlComponents variable injected into the handler function.

You can find the entire Router class on GitHub.

Basic Templating with XSS Safety

There were a number of approaches I considered when it came to adding templating to the project. My first instinct was, of course, to reach for one of the off-the-shelf solutions such as Vapor’s Leaf, but I wanted to avoid extra dependencies and keep it as simple as possible. As such, I just decided on simple string interpolation where each template is a standard Swift function that returns a string of HTML. That may not be the best approach for a large web application with a complex frontend, but works perfectly well for this experiment.

Fortunately, that also means it’s fairly straightforward. There is a layout view that provides the structure for the site as well as a specific view for each route that should return HTML.

The layout view:

func layoutView(title: String, content: HTML, name: String = "") -> HTML {
    return """
    <!DOCTYPE html>
    <html>
        <head><title>\(title)</title></head>
        <link rel="stylesheet" href="/css/main.css">
        <script src="/js/scripts.js"></script>
        <body>
            <nav>
                <a href="/">Home</a>
            </nav>
            <main>\(content)</main>
            <p>Input your name: <input type="text" id="name" value="\(name)"></p>
            <div class="buttons">
                <button type="button" id="sayHelloButton">Say Hello!</button>
                <button type="button" id="sayHelloGermanButton">Say Hello in German!</button>
            </div>
        </body>
    </html>
    """
}

The /hello/:name route’s view:

func helloView(name: String, isGerman: Bool = false) -> HTML {
    let greeting = isGerman ? "Hallo \(name)!" : "Hello \(name)!"
    return "<h1>\(greeting)</h1>"
}

The layout and route-specific views get put together in each route’s handler. If you look back at the previous examples of adding routes, you’ll see the layoutView() function takes a content parameter. This is where the route-specific view is injected into the layout.

You might have also noticed the mysterious HTML type. This doesn’t come from SwiftNIO, but instead is a custom interpolation struct that provides XSS (cross-site scripting) safety. While a little excessive for this particular basic project, I happened to find out while making it that Swift supports such a thing and decided to give it a shot. I won’t go into detail about it here, but you can view the commented struct on GitHub.

Static Content

If you have templates, you have to have static content as well. What modern website doesn’t have CSS and JavaScript? Even my basic example does, but more as a proof of concept than anything else.

Static files are located in the Public folder at the root of the project. The application will automatically figure out the path to it relative to the executable and then return the requested file via a wildcard GET route added to the router after all of the user-defined routes have been added. If no file is found, a 404 “not found” error is returned.

This was surprisingly one of the trickier parts of the whole experiment to figure out, but once I had it, it wasn’t terrible to implement. Essentially, I had to read the static file as a Swift Data object and pass it along with the mimeType to the HTTPResponse to be handled in the same way it handles a standard string response:

guard let data = try? Data(contentsOf: URL(fileURLWithPath: fullPath)) else {
    return HTTPResponse(status: .notFound, body: "Not Found")
}

let ext = (fullPath as NSString).pathExtension
return HTTPResponse(status: .ok, contentType: mimeType(for: ext), data: data)

There is a little bit of magic that also happens in there in the form of path sanitization so that a user can’t use standard Unix/Linux paths like “/..” to reach other files in the OS:

let sanitized = filePath
    .components(separatedBy: "/")
    .filter { !$0.isEmpty && $0 != ".." }
    .joined(separator: "/")

guard !sanitized.isEmpty else {
    return HTTPResponse(status: .notFound, body: "Not Found")
}

You can see the wildcard route and how the files are read on GitHub.

Only HTTP/1.1 is Supported

One notable limitation of the web application in its current form is that it only supports HTTP/1.1. SwiftNIO also has additional Apple-developed libraries that extend it to support HTTP/2 (swift-nio-http2) and even an experimental library to allow it to support HTTP/3 (swift-nio-http3), but I figured sticking with HTTP/1.1 would be good enough for this small experiment.

What Else It Could Have Done

I enjoyed creating this project enough that it was hard to keep it simple. I could have just kept tacking on feature after feature until it did everything a standard web application can do, but I was (fairly) disciplined and kept it basic. These are some of the ways I thought it might be nice to expand it and, perhaps, I will fire up a new repo one day to do so.

As mentioned above, the server currently only supports HTTP/1.1. It would probably be fairly trivial to add at least support for HTTP/2 with swift-nio-http2, but I haven’t attempted that yet.

Also, a proper templating engine might be useful for a real application. I’ve worked with Vapor’s Leaf, but have also dabbled with Stencil which is another template language for Swift. Either one would be a good choice.

Then, of course, rare is the web app that doesn’t have a database behind it. The easiest solution would be to statically link to the operating system’s C SQLite library and call it using raw queries directly in your Swift code. For other databases such as MySQL and PostgreSQL, the makers of Vapor also provide NIO-libraries: MySQLNIO and PostgresNIO. If you would prefer a full-fledged ORM, then Vapor’s Fluent is probably the way to go.

However, if you’ve already got Leaf and Fluent, then you might as well save yourself the trouble of everything else and just use Vapor itself which, as mentioned above, is also based on SwiftNIO.

Conclusion

So, would I ever use this on an actual production system? Honestly, probably not. For the vast majority of projects, a complete web framework like Vapor makes a lot more sense because it makes development so much faster and easier with much less code to maintain yourself. The performance penalty is so negligible that you probably wouldn’t be able to measure the difference in anything but nanoseconds.

However, if you are serving requests at the same scale as Apple, then every nanosecond counts and you might want to consider going with raw SwiftNIO. The margin for error is wide, but the ability to finely tweak performance is vast. Since no project I have ever worked on — professionally or personally — has ever even come close to receiving the amount of requests an Apple service does, I honestly would always go with a framework like Vapor.

That said, I did enjoy the experiment and it was interesting to piece together how it works behind the scenes. I could have easily just kept bolting on more features until I had my own mini framework, but I decided to just keep it simple and focus on the core of the application. After all, the point of the experiment was to figure out how it worked and if I could even make it work at all. Fortunately, I was successful in both endeavors.

And just as a small aside: The README file in the GitHub repository has a few more technical details than I’ve included here. There are also instructions on how to get it to run and build on Mac (with and without Xcode) as well as Linux. It will only work on Windows with WSL since SwiftNIO relies on POSIX calls for its thread-pooling.

Links

• GitHub repository with my experiment
• SwiftNIO
• Vapor

Changes include:

• Added a new menu item to reset the selected text’s or an entire note’s formatting. You can find it under Format -> Reset Formatting
• Fixed a bug where using cmd+option+shift+v didn’t paste anything

You can download ScratchBook for free on the Mac App Store.

Two days ago, I relaunched a website that I first set up in 2021 called The Old West. It not only features a new design, but also a lot of new content. The purpose of the website is to consolidate Wikipedia articles about the old American west into one spot, making it easy to browse them. I import the articles into my database using Wikipedia’s API and display them under their Creative Commons Attribution-ShareAlike License. The articles are defined in config files and I wrote a script that imports and updates them. The script is run via a cronjob once a week to keep the articles up to date with the latest changes from Wikipedia.

A complete rewrite was long overdue as I could no longer build the old website. At the time, I was heavily into React and Next.js which is the technology I chose to power the website. Unfortunately, I also used the Material UI component library which became the main liability. Material UI released a major new update at some point and I really didn’t like their new approach to CSS handling. Not only did I dislike it, it would have basically required a major rewrite of the website and all of its CSS. Therefore, I decided not to update. Of course, as time went on, the old version became incompatible with newer versions of React and Next.js and I got stuck with Next.js 12 which is several versions behind.

That by itself isn’t as much of an issue, however, Node itself also continued to move on and eventually, Next.js 12 no longer supported the version of Node I had installed locally. I’m aware I could have used nvm combined with a specific Node version defined in a .nvmrc file at the root of the project, but that is more than I was willing to do to support the old, increasingly fragile technology powering the project. At that point, I had also become very disillusioned by React, Next.js and the general highly volatile Node ecosystem with its well-known dependency churn and increasing number of supply chain attacks.

So, when I decided to finally completely rewrite The Old West, I chose to go in a fully different direction with the technology. I chose vanilla PHP.

With so many shiny new programming languages and web frameworks on offer, why did I choose PHP? Well, I didn’t want dependencies. I wanted to write the code once, deploy it and be able to forget about it for years at a time even if it meant a little bit more work up front. My other requirement was that I still wanted to be able to update it at anytime without having to first spend hours trying to sort out dependency or runtime version incompatibilities just to get it to build again.

Vanilla PHP is not only perfect for that, but really the only feasible way to do it. Combined with Apache, Linux and MariaDB (the truly classic LAMP stack), it is practically bulletproof. No supply chain attacks, no version incompatibilities, no dependency update hell — nothing but stability and peace of mind.

PHP is incredibly backwards-compatible which means I can safely update the version on my server using my package manager and don’t have to worry about too many, if any updates to my code. The only “dependencies” I rely on are official PHP extensions such as PDO for database connectivity which I’m not concerned about because they are maintained and updated with PHP itself.

I wrote my own autoloader for namespaces, a tiny, fully custom router module, as well as a very lightweight ORM layer with an inheritable Model class, a QueryBuilder class, and a migration class that processes raw .sql files for migrations. Templating is handled with pure PHP. There is hardly any JavaScript on the website and I use pure CSS without anything like SCSS or Less. I do use the Bootstrap CSS classes for responsiveness, but I copied the CSS files into my project by hand which means they will work forever unless I feel like updating them.

That’s really all there is to it. The website is lightweight, lightning-fast, and entirely customized to my specific needs. It will run stably for as long as the server runs and even if the server craps out at some point, moving the project to another server requires minimal effort.

Vanilla PHP may not be glamorous, but it has been the stablest way to create a website for decades and, since it still powers the majority of the web, I think we can safely say it will remain that way for decades to come.

If you’d like to see the new design, you can find The Old West here: www.the-old-west.com.

But once I found out that cyberport.de had MacBooks on sale (I’m not sponsored), I decided that I couldn’t wait anymore and bought one. The basic specs are:

• M5 chip
• 32 GB of RAM
• 2 TB SSD
• 14″ display

I got that for €2500 which is about €500 less than directly from Apple and essentially made the 2 TB SSD upgrade free. I also could have gone with a 16″ instead, but I decided I’d prefer a larger SSD. Most of the time I use it plugged into an external monitor anyway and when I’m traveling with it, I like the smaller, lighter form factor.

I did play around with the idea of getting a 15″ MacBook Air instead since the specs I care most about are the same, but in the end I decided the fans might be nice to have even though I’ll probably only rarely, if ever, need them.

Here are a few pictures:

Changes include:

• Added support for macOS 14 (Sonoma) and macOS 15 (Sequoia)
• Fixed an issue with truncated text on the import sheet

You can download ScratchBook for free on the Mac App Store.

Ever since I experimented with the Swift server-side framework Vapor last year, I’ve been interested in actually seeing it in operation in the wild. I know there have been a number of companies, including Apple itself, that have started using it for their server-side applications, but it’s nice to see some concrete examples of it.

I’ve been following the official Swift blog for a while now, but I just recently discovered two posts about companies that are using Swift and Vapor at large scale to run their server-side applications.

The first of which is the syncing service for the very popular Mac/iOS productivity application, Things. I’ve played around with Things before in the past, but it’s too expensive for my basic needs, so I don’t use it. Nonetheless, it is still a very popular application and the fact that Swift and Vapor power its syncing backend is great news for those who are questioning the framework’s reliability or scalability.

You can read more about Things using Swift and Vapor here. The post also includes more information about their infrastructure in general.

The second usage I found recently was for the TelemetryDeck analytics service. Unlike Things, I had never heard of them, so I can’t say a whole lot about them, but they apparently have a massive amount of traffic that Swift and Vapor handle flawlessly.

You can read about it here.

Of course, something to keep in mind is that both of these posts are on the official Swift blog which is unlikely to report on any negative experiences that companies have had with server-side Swift. However, I still find it great that companies are having success with using Swift and Vapor in production environments with large traffic loads.

If you know of any other examples of server-side Swift in the wild, let me know. I’d love to read about it — good or bad!

A couple of months ago, I took my 11″ iPad Air M2 with me to the city of Regensburg to try working with it as a laptop replacement. Unfortunately, the tiny 11″ screen and the non-standard, smaller keyboard made it less than a stellar experience. However, I thought I could mitigate those problems while taking advantage of iPadOS 26’s new windowing feature by using a normal keyboard, mouse and a large external screen — essentially, turning it into a desktop replacement.

Equipment

My equipment list for this experiment isn’t as exciting as it was for the laptop replacement experiment because I just used my usual desktop accessories:

• Logitech MX Keys keyboard
• Apple mouse
• LG widescreen monitor that supports USB-C

Normally, I use a Logitech MX Master 3S mouse instead of the Apple mouse, but I’ve already used up all three device connections that it supports, so I had dig out my old Apple mouse. Otherwise, the most important part was the monitor with USB-C support. With that, I could just plug my iPad in and it not only activated external display mode, but importantly, it also charged.

My Experience

I know that the iPad is limited as to what it is capable of doing primarily due to the limitations of iPadOS. Development is nearly impossible on it which already means it’s not a viable desktop replacement for me full-time. However, I also write a lot, so I thought the best way to test it was to do some writing.

On my Mac, I use Pages anyway and most of it gets saved to iCloud Drive. As such, writing in Pages on the iPad means there isn’t really much of a change of workflow. I already knew that from when I tried using my iPad as a laptop replacement, but what I didn’t count on what the severe limitations I ran into when using the mouse and keyboard.

It turns out, unsurprisingly, that iPad apps are not optimized for them. That didn’t surprise me at all, but what did surprise me was just how limited it would be. Even first party-applications like Pages were severely restricted. For example, there is no way to correct a misspelled word with the mouse and keyboard. You have to use the touch screen to tap on the word that is underlined in red and then you get the popup menu with the spelling suggestions. There is absolutely not way to replicate that functionality with the mouse and keyboard which means I had to drag Pages from my big screen down to the iPad’s touch screen to use it — not a good experience at all.

Also, for some reason, forward delete doesn’t seem to work at all on the iPad. A full-size Mac keyboard has its own forward delete key and on the smaller Mac keyboards (such as on the MacBooks), you use fn+delete. Neither of those worked on the iPad at all which made trying to edit text much more tedious.

Even worse, though, were third-party apps. For example, I tried watching a YouTube video using the YouTube app. I could click on a video, but couldn’t exit it. There was literally no way to leave the video or access buttons like “Save” or “Like”. It just didn’t work at all. Again, I had to drag the app down to my iPad’s screen and use the touch interface.

The worst issue I kept encountering, though, was that the iPad would regularly crash entirely. As in, both screens would go black and there would be a loading spinner on the iPad’s screen that lasted for several seconds before I could use it again… except all of the apps I had open were closed. That happened with startling frequency even with only three of my most-used apps open: Mail, Safari and Pages. So much for windowed multitasking.

After this happened four times in a half an hour, I gave up on the experiment and went back to my Mac.

Conclusion

Needless to say, I won’t be using my iPad as a desktop or laptop replacement anytime soon. After the experiment with trying to use the iPad as a laptop replacement, I went into this one less than optimistic. Unfortunately, my pessimism was confirmed by the experience.

I find it really disappointing that, despite the improvements Apple made to desktop mode in iPadOS 26, it still doesn’t even come close to being a viable, reliable option. Frankly, my iPad with its M2 processor is several times more powerful than my old Intel MacBook Pro, but the software cripples it to the point of irrelevance.

The idea of having a truly all-in-one, portable device is extremely appealing to me. I love using my iPad to read my RSS feeds, eBooks, articles online, magazines, etc which is what I primarily use it for. While I have an Apple Pencil, I rarely use it to take notes or draw anything. Unfortunately, unless Apple makes some major changes to iPadOS, it’s just going to remain a glorified electronic reader for me.

As some of you may have noticed, my websites keep going down and are not reachable for hours at a time. I’ve been having some stability issues with my server and, of course, it always happens over night German time which is why it takes me hours to get to it. I only see it when I get up in the morning.

Ubuntu has been killing the Apache and MariaDB services due to out-of-memory issues despite my monitoring reporting RAM usage only reaching 20% of the server’s full capacity. However, I have discovered that there is a massive spike in traffic during that time and I suspect it’s due to bots. I still need to confirm my theory though.

In the meantime, I’ve reconfigured the Apache and MariaDB services to automatically restart when they die. That should at least solve the immediate problem of my websites being unreachable for hours at a time. I could have sworn that I’d already set them to automatically restart, but apparently not. Oh well.

I’m excited to announce that ScratchBook is now available as a free download on the Mac App Store!

If you are interested in downloading it, you can visit its page on the Mac App Store.

I’m especially excited about this release because it is the first time I’ve published anything on any app store and because it’s a much needed update to the original ScratchPad whose Objective C codebase dates back to Mac OS X Tiger.

Unfortunately, ScratchBook is still waiting for review. Apparently, it’s tough to review a simple application. Most likely though, it just doesn’t have much priority. It’s a small, free application from an unknown developer that Apple isn’t going to make any money from.

I submitted it for review on Tuesday, March 3rd. According to the email I received from Apple confirming its submission, the average approval time for 50% of submitted apps is 24 hours and for 90%, it’s 48 hours:

Apparently ScratchBook falls within that 10% where it takes much longer. I have no explanation for this as I have received absolutely not communication from Apple since its submission. No change in status, no emails, no notifications, deafening silence.

In any case, I’ll post again here when it’s been approved or denied.

Recently, I’ve been posting quite a bit about my project, ScratchBook (formerly ScratchPad). Just today, I submitted it to the Mac App Store for review and I anxiously await the results. However, I haven’t been content to just stop with just releasing a single app.

Instead, I’ve been working on a small software entity I’ve dubbed “Haunted House Software.” Obviously, it’s a play on my interest in horror, ghosts and, well, haunted houses. While it is not a legal entity (yet), I do intend to use the name to release not only ScratchBook, but also a couple of other apps I’ve been working on. Maybe someday I’ll turn it into a proper company, but for now, I’m content just to use it as a collective for my apps.

I’ve spent most of my afternoon finishing up a website for it which you can find at www.hauntedhousesoftware.com. Conveniently, I just shut down my horror blog, Haunting Alex, which meant I could reuse some of the styling and images. I happened to really like the logo I made for the blog, so I reused it for the Haunted House Software:

There will be more announcements coming because I’ve got big plans. However, I do first have to actually sit down and finish up releasable versions of the other apps I’ve been working on. Unlike ScratchBook, they are not only for Mac, but also for iOS and iPadOS.

As always, I’ll post them here on my blog.

Haunted House Software Links

• Website: https://www.hauntedhousesoftware.com
• GitHub: https://github.com/Haunted-House-Software

I’m excited to announce that I just submitted my very first app for review to the Mac App Store! Hopefully, all goes well and ScratchBook will be available for free soon. Of course, I’ll post about it when it is available to download.

As you may have noticed, I did decide to rename ScratchPad to ScratchBook in order to better distinguish it from another application in the Mac App Store called Scratchpad. I wrote about it in more detail here.

In my opinion, the most tedious part was preparing the images and the text for the application description. This is the description I went with:

Take notes, keep them organized. ScratchBook is a free, simple, easy-to-use, multi-page scratchpad application for macOS.

ScratchBook is version 2.0 of a small application that used to be called ScratchPad. This version is a complete rewrite from the ground up using modern macOS technologies such as SwiftUI. It runs natively on both Intel and Apple Silicon Macs and supports modern macOS features such as Dark Mode.

Features:

• Jot things down quickly and simply: no choosing folders, adding tags or any other distractions.
• Multiple pages allow you to just add a new one when you need a new note. Your existing notes stay safe.
• ScratchBook takes advantage of macOS’s built-in rich text capabilities. You can change fonts, colors, add images, make lists, and so much more.
• Automatic saving.
• Notes are saved in TextEdit-compatible .rtfd files which can be stored anywhere on your Mac or iCloud.
• You can keep ScratchBook above all other windows for easier note-taking.
• You can make ScratchBook as transparent as you’d like to see what’s behind it while taking notes.
• Export individual notes as TextEdit-compatible .rtfd files.
• Import all your notes from ScratchPad 1.0.
• Full support for Liquid Glass, including both dark and light modes.
• Free and open source.

And, of course, here are the images:

As a little easter egg, I used a section of the default wallpaper from Mac OS X Tiger as my background for these images in a nod to ScratchPad first being released for Tiger about twenty years ago.

It will certainly be interesting to see whether the application will be accepted or not. As always, I will keep you up-to-date here on my blog.