iPadOS Scribble Interfering with Apple Pencil Canvas Drawing in Web Browsers

SkyJin — Sat, 12 Jul 2025 07:38:28 +0000

A debugging journey that led to an unexpected system-level solution

The Use Case

I've been working on drawing directly on web pages using Apple Pencil on iPad. This approach has several advantages over traditional screenshot annotation:

Persistent positioning: Notes stay anchored to their location even when scrolling
Dynamic interaction: Can switch between tabs to reference other content while keeping annotations
Live web content: Works with interactive elements and real-time updates
Seamless workflow: No need to manage separate screenshot files

This is particularly useful for online whiteboards, web-based drawing applications, study materials, and any scenario where you want to annotate web content while maintaining full page functionality.

The Problem

While using Orion Browser (which supports Chrome extensions on iPad) with the Page Marker extension, I encountered a consistent issue: when drawing quickly with Apple Pencil, certain stroke patterns would have missing segments. Specifically, rapid "vertical-horizontal-vertical" strokes would consistently drop the third stroke.

This made the drawing experience frustratingly unreliable, breaking the natural flow of handwriting and sketching.

Initial Investigation

I assumed this was a technical compatibility issue and investigated several potential causes:

Browser extension compatibility: Orion's Chrome extension support might have limitations
Touch event throttling: Mobile browsers might be dropping rapid touch events for performance
Apple Pencil gesture conflicts: System-level gestures might be interfering
Canvas API limitations: WebKit might have restrictions on rapid drawing operations

The issue was consistent enough that I started planning to develop a custom Safari extension to work around these perceived limitations.

The Debugging Process

I dove deep into:

Apple Pencil touch event handling in Safari
iOS Safari extension development APIs
Canvas drawing optimization techniques
Touch event debugging using Safari's Web Inspector

I even set up an Xcode project and began exploring the Safari Web Extensions framework, convinced I needed a native solution.

The Unexpected Discovery

While testing different Apple Pencil settings during development, I discovered that disabling iOS Scribble completely resolved the issue.

This was surprising because I was drawing on Canvas elements, not text fields where Scribble would typically be expected to work.

Why This Happens

Scribble operates at the iOS system level, monitoring Apple Pencil input globally across all applications and contexts. When it detects stroke patterns that might be handwriting, it intercepts the touch events for text recognition processing.

The "vertical-horizontal-vertical" pattern I was drawing was likely being interpreted as potential text input (possibly the letter "H", number "4", or editing gestures), causing Scribble to capture the third stroke before it could reach the Canvas drawing API.

The Solution

Settings → Apple Pencil → Scribble → Off

This immediately fixed the dropped stroke issue, making Canvas drawing smooth and reliable.

Rethinking Window Management: A Concept for an Infinite Canvas OS

SkyJin — Thu, 10 Jul 2025 09:53:56 +0000

Disclaimer: Hello everyone. I'm just a regular user who is very interested in productivity and the tools we use every day. This post is an attempt to document some of my personal thoughts and ideas about operating system window management. My analysis of different paradigms (like temporal vs. spatial ordering) might be flawed or imprecise. I'm mainly writing this down to capture an idea that I found interesting.

We spend a significant part of our computing lives dealing with "windows." The act of switching between them is one of our most frequent operations. From the classic Alt + Tab to macOS's Mission Control and Stage Manager, we seem to have plenty of options.

But I've always felt that each of these methods has its own trade-offs, and none of them perfectly align with our brain's intuitive way of thinking. Recently, after using whiteboard software like Heptabase and Obsidian Canvas, and design tools like Figma, a concept began to take shape in my mind:

What if all the windows on our desktop weren't a "stack of papers" we have to constantly shuffle through, but "cards" placed on an "infinite canvas"?

Part 1: A Look at the "Logic" and "Pain Points" of Our Current Tools

Before building up a new idea, I wanted to outline my understanding of our current window management methods:

Alt + Tab / Command + Tab: The Logic of Time (Temporal Order)
- Its core principle is "most recently used." The window you just left is always first in line. This makes it incredibly efficient for repeatedly switching between two apps.
- The pain point is just as clear: when you have a dozen windows open and need to find one you used five minutes ago, the process becomes a tedious memory game.
Mission Control: The Logic of a Visual Overview
- With a single gesture, all windows are laid out for you to see. This is great for batch operations, like closing multiple windows or dragging one to a different virtual desktop.
- For me, however, the problem is the lack of order. The layout can change each time you trigger it, so I can't use my spatial memory to locate things. I have to visually scan and filter everything, every single time, which creates a high cognitive load.
Stage Manager & Tabs: An Attempt at Linear Order
- I've noticed that interfaces with tabs, like in a web browser or with plugins like Groupy 2 on Windows, provide a very clear one-dimensional spatial logic. I can drag and drop to define that "Window A is to the left of Window B," and this order is fixed and user-controlled.
- macOS's Stage Manager is similar in spirit, creating a vertical list of windows on the side. This is an improvement over the chaos of Mission Control because it provides a fixed visual anchor. However, its order seems to be managed by the system based on recency, giving the user less direct control than traditional tabs.

All these methods try to strike a balance between efficiency and intuition, but something always feels slightly off.

Part 2: My Concept — The "Whiteboard OS"

The core of this idea is to fundamentally change the desktop metaphor from a "stack of papers" to an "infinite canvas."

In this "Whiteboard OS":

Everything lives on the canvas: Your application windows, widgets, sticky notes, calendars... everything is an object on the canvas.
Fixed relative positions: Unless you intentionally move them, your "VS Code window" will always be below your "Browser window," and your "Terminal" will always be to the right of "VS Code." You can use your spatial memory to navigate your workspace, just like navigating a familiar city.
Infinite zoom and pan:
- You could zoom out to get a high-level view of all your tasks and their layouts. A "zoom-to-fit" button would be essential.
- You could zoom in to focus on one or two core windows for deep work.
- You could pan across the entire canvas by holding the Spacebar and dragging the mouse, just like in Figma.
New interaction models:
- Gestural navigation: For example, a three-finger swipe could move a "selection frame" between windows on the canvas, following the direction of your swipe (up, down, left, right).
- Legacy support: Command + Tab could still be used for its original purpose: quickly toggling between the last two active windows without needing to look.
Creating relationships: You could draw "lines" to connect related windows, forming a "project group." For instance, a web development project might involve VS Code, a terminal, a browser, design mockups, and a requirements doc. Connecting them would allow you to minimize or focus the entire group with a single click.

Part 3: Is This Realistic?

I know this might sound like a daydream. Building a new OS from scratch is not feasible for an individual.

But I realized this might not require a new OS. Instead, it could be a new Desktop Shell or Window Manager running on top of an existing system, most likely Linux.

Of course, the challenges would be immense:

Performance: Rendering dozens of live windows on a smoothly zoomable canvas would be graphically intensive (though Stage Manager proves real-time previews are possible).
Interaction Design: How do you elegantly select a tiny window when zoomed out? How do you design a "tidy up" function that doesn't destroy the user's mental map?
The Ecosystem: This is perhaps the biggest hurdle. Even if someone built this shell on Linux, how many of us would be unable to use it as our primary OS because the professional software we rely on (Adobe, Office, etc.) isn't supported?

Conclusion

So, for now, this remains just a concept I wanted to document.

It's an idea born from daily frustrations and inspired by modern tools. Documenting it is simply a way to give the thought a more concrete form.

Thanks for reading.

DEV Community: SkyJin