Archive for September 5, 2025

Friday, September 5, 2025

reMarkable Paper Pro Move

Hartley Charlton (Hacker News):

reMarkable today unveiled the Paper Pro Move, a compact color E Ink tablet that brings its minimalist writing experience to a more portable form factor aimed at those seeking a focused alternative to full-featured tablets like the iPad mini.

The Paper Pro Move features a 7.3-inch Canvas Color display based on E Ink Gallery 3 technology, offering improved color reproduction and a paper-like texture optimized for handwriting. The tablet measures 7.7 inches tall, 4.24 inches wide, and 6.5 millimeters thick, weighing 235 grams, making it significantly smaller and lighter than the 11.8-inch Paper Pro introduced in 2024. The iPad mini, on the other hand, measures 7.69 inches tall, 5.3 inches wide, and 7.2 millimeters thick, weighing 293 grams.

[…]

The Paper Pro Move supports PDFs and ePub documents but does not provide access to digital bookstores or third-party apps.

[…]

Pricing begins at $449 with the standard Marker stylus, while a $499 configuration includes the Marker Plus with an integrated eraser.

Previously:

One Size Does Not Fit All

Craig Hockenberry (Mastodon):

If you’re someone who’s only using email, a web browser, and some messaging apps to get stuff done, changes to your desktop appearance aren’t going to be disruptive. It’s also likely that you’ll appreciate changes that make it look like your phone.

If you’re doing anything more complex than that, your response to change will be much different.

[…]

Professionals on the Mac are like truck drivers. Drivers have a cockpit filled with specialized dials, knobs, switches, microwave ovens, refrigerators, and pillows that are absolutely necessary for hauling goods across country. Those of us who are making movies, producing hit songs, building apps, or doing scientific research have our own highly specialized cockpits.

And along comes Alan Dye with his standard cockpit, that is beautiful to look at and fun to use on curvy roads. But also completely wrong for the jobs we’re doing. There’s no air ride seat, microwave oven, or air brake release. His response will be to hide these things that we use all the time behind a hidden menu.

John Gruber (2010):

It’s the heaviness of the Mac that allows iOS to remain light.

After mocking the Toaster-Fridge, it turns out that’s kind of where Apple’s taking us. I think they’ve done OK at keeping iOS and iPadOS light, but a lot of the Mac changes seem aimed at achieving a foolish consistency.

Jason Snell:

The iPhone has utterly changed Apple’s priorities as a company. It generates, directly or indirectly, most of Apple’s revenue and profit. But it’s also had knock-on effects: The popularity of the iPhone has driven more people to the Mac. The proportion of Mac users who are “using email, a web browser, and some messaging apps” has risen, probably markedly.

[…]

In many ways, it makes good financial sense for Apple to steer the Mac in a direction that feels familiar to iPhone users and pleases those casual Mac users. They’re probably the majority of Mac users! But what about the Mac as a platform for professional users, who use the Mac as a truck, not a car?

Marco Arment:

Dye’s “consistency” poorly attempts to solve a problem no Mac users had, by radically redesigning the Mac to be utterly unlike itself, carelessly discarding decades of thoughtful design, function, and delight without bothering to understand any of it, and lacking adequate resources to replace it with anywhere near the quality and consideration that it once had.

It’s the sad conclusion of macOS’ takeover, under Tim Cook, by people who seem to kinda hate the Mac.

Brent Simmons (Mastodon):

I seriously dislike the experience of using a Mac with Liquid Glass. The UI has become the star, but the drunken star, blurry, illegible, and physically unstable. It makes making things way more of a struggle than it used to be.

We had pretty good Mac UI, but Apple took the bad parts of it — the translucency and blurriness already there — and dialed it way up and called it content-centric. But it seems to me the opposite. Liquid Glass is Liquid-Glass-centric.

Norbert Heger:

Why menu icons are a terrible idea on macOS?

Here’s a photo showing them side by side on an iPhone and on a MacBook Pro screen.

On iOS, menu icons can work quite well to communicate the meaning of menu items. They’re reasonably sized, displayed on screens with very high pixel density (around 460 ppi), and typically viewed from a fairly close distance.

But this doesn’t translate to macOS at all. On macOS 26 Tahoe, the icons are ridiculously small (about one-quarter of the physical area), displayed on screens with much lower pixel density (e.g. 254 ppi on the latest MacBook Pro), and usually viewed from about twice as far away.

Steve Troughton-Smith:

If you already think Liquid Glass looks bad on macOS, try running apps fullscreen and take a look at the botch job they’ve done to shoehorn it in and get it over the line. You get a mostly-opaque toolbar that intersects the sidebar that no app is designed for, bleed-through of shadows and other chunks of off-white areas, and a miserable bleached sidebar that removes any sense of Liquid Glass and just looks pale and awful.

Michael Flarup (Hacker News):

With iOS, iPadOS, macOS, and watchOS 26, icons are now, for the first time, shared between platforms. Liquid Glass is attempting a unification of the design language across all of these platforms (but curiously not VisionOS).

This also means that the Macintosh now shares the constraints of these other platforms.

[…]

With Liquid Glass, iOS gains personality and macOS loses some of its soul.

While I mourn the loss of transparency and unique app icon shapes on the desktop, I also fear that applying a single visual effect consistently across a big system is problematic.

Steve Troughton-Smith:

My two theses of the summer beta period remain:

  1. iPadOS 26 has crossed the rubicon on the way to becoming a ‘real’ desktop OS
  2. Classic/traditional Mac apps no longer feel fully native on macOS

Pierre Igot:

It’s actually macOS itself that no longer feels fully native on the Mac.

I support all the Mac developers out there who are resisting this bulldozing of decades of carefully built software environments, by buying their products and software subscriptions. And I refuse to support “Mac” developers who drink Apple’s tasteless Kool-Aid and keep embracing this relentless destruction of real Mac software, version after version. Nothing makes up for it.

Michael Flarup:

Into the squircle jail it goes.

Jeff Johnson:

The Tahoe squircle jail is in the crApp Store too!

Previously:

OmniFocus 4.7

Ainsley Bourque Olson:

OmniFocus 4.7 introduces three powerful enhancements: a new “Planned” date type (for specifying the date an item is scheduled for work), the ability to create mutually exclusive tags (handy in a variety of workflows, like prioritization and energy level assignment), and improved repeat functionality (including new support for setting a repeat to end after a specific date or set number of repetitions).

[…]

We’ve also tested and polished the database migration flow, substantially updated our Help content (and integrated it directly into the app), localized the app more thoroughly for non-English speakers, and implemented additional features which do not require a database migration (new Forecast functionality, Time Sensitive Notification support, improved shortcut actions, and more!).

I’ve been running mostly on Defer Dates for so long, often putting the date when I intend to start working on an action directly into its text. Obviously, that’s a design smell. Planned Dates seem like a better way to handle this, though I haven’t yet had a chance to get a feel for how they work in practice. I think a key will be learning how to leverage the Forecast view, which I’ve mostly ignored thus far.

With OmniFocus 3, I was a bit concerned that we were losing something with the switch from contexts to tags. An action can have multiple tags, which has proved to be very handy. But sometimes I want to treat tags more like folders, where assigning one tag automatically unassigns another. Mutually exclusive tags are a way to have the best of both styles. I can still assign multiple tags, e.g. for different locations where I might work on an action, but at the same time OmniFocus can enforce that certain groups of tags are treated like contexts:

I’ve added my “Today/Radar/Back Burner” tags to a mutually exclusive “Priority” tag group, and I can bump something up or down a priority list by simply assigning a single tag.

Task prioritization is just one example of a workflow streamlined by the introduction of mutually exclusive tags: we think this feature will also be a great fit for folks who use tags to assign energy level (high/low/medium), time of day (morning/afternoon/evening), or even appropriate weather (rain/sun) to their tasks.

The Omni Group:

To avoid breaking compatibility with earlier versions of the app, OmniFocus will only prompt you to migrate your database format once it detects that all active OmniFocus sync clients are capable of supporting the new database format.

Version 4.7 can still use the old database format, but some of the new features require migrating.

OmniFocus’s syncing has been rock solid almost the entire time I’ve been using the app. However, after finally updating to iOS 18 last month, version 4.6.1, which had never given me any trouble, suddenly kept getting out of sync with my Mac. Changes on the phone would sync to the Mac, but not vice-versa. The phone would say that it has synced yet still show itself as being many changes behind, as if the changes were stored locally but not yet integrated into the database. This continued with 4.7 and the old database format as well as after migration. Omni is looking into it. For now, I’ve found that force quitting seems to unblock whatever is preventing the app from integrating the changes.

Ken Case:

My OmniFocus tip is to use the parts of the app that actually help you, and ignore or even hide the parts that you don’t yet need.

We designed the app with a lot of depth so that people could reach for that depth when they need it. But we’ve tried to design the app with progressive disclosure, so you can start simple, ignoring those deep features until such a time as you might actually need them.

PoorBC:

I am edging toward the conclusion that OmniFocus with Planned date, Today view, and Forecast view could be the simplest task manager available if you just want to see what’s on your plate today without seeing tasks that are not available. That’s assuming you ignore the advanced features, which is certainly doable. You don’t have to have projects or tags if you choose not to.

Previously:

SQLite on macOS Not ACID

Jonathan Johnson (2022):

From my investigation, Apple’s version of SQLite instead replaces PRAGMA fullfsync = on’s implementation to use F_BARRIERFSYNC.

SQLite users who are expecting PRAGMA fullfsync to provide durability guarantees in the event of power failures or kernel panics can override xSync via a custom VFS or build SQLite from source.

[…]

Apple’s documentation clearly states that for any guarantees about data loss due to power loss or kernel panic, you must use the fcntl() API with the F_FULLFSYNC command.

[…]

For most consumer applications, F_BARRIERFSYNC will be enough to provide reasonable durability with the benefit of performing much more quickly. However, there are some situations where true ACID compliance is desired.

[…]

It’s very confusing when a feature that’s documented to be specific to macOS doesn’t behave as documented on macOS.

Although, SQLite itself is open-source, as are many parts of macOS and iOS, he says that the source for Apple’s SQLite is not available.

Andrew Ayer (Hacker News):

Unfortunately, SQLite’s documentation about its durability properties is far from clear. I cannot tell whether SQLite is durable by default, and if not, what are the minimal settings you need to use to ensure durability.

[…]

A Hacker News commenter who agrees with my reading of the documentation asked Hipp how his comment is consistent with the documentation, but received no reply.

Hipp also says that WAL mode used to be durable by default, but it was changed after people complained about poor performance. This surprised me, since I had the impression that SQLite cared deeply about backwards compatibility, and weakening the default durability setting is a nasty breaking change for any application which needs durability.

[…]

My takeaway is that if you need durability, you’d better set the synchronous option explicitly because who knows what the default is, or what it will be in the future. With WAL mode, FULL seems to suffice. As for DELETE mode, who knows if FULL is enough, so you’d better go with EXTRA to be safe. And if your application might be used on macOS, enable fullfsync.

Previously: