Solipsism Gradient

I was the first developer in Brazil to sign up for Apple’s official developer program. I think this was at one of the first WWDC‘s in San Jose around 1989, so long ago that I couldn’t find an artifact or email to remind me of the exact date. Since then I faithfully renewed my membership every year, sometimes with difficulties caused by constantly changing payment details and evolving technology. I had to keep an old FAX machine around for years just because of that!

But 2025 marks the end of that era. This past November 11th I did not renew my membership and now I’m officially a common user of Apple products. Not that I plan to change platforms at my age (0x4A as I write this), but several factors have made it both necessary and convenient to cancel.

Special membership privileges have continually eroded and now are essentially reduced to “able to publish in the various Apple app stores”. WWDC attendance is virtual and the cool parts are open to anyone; special hardware are gone, as far as I know; public software betas have gone up in quality and are widely available.

On September 30th, 2018 I sunsetted all my available applications and my hopes of writing anything new have been sidelined by my eye issues. I’m glad to report that my eye seems to have stabilized, courtesy of regular injections, but it won’t get any better — reading huge screens of small text (or even medium text) — is over. I can still read a lot, drive a car under good conditions and play regular table tennis championships; that covers my current requirements.

I have been following the evolution of the Swift language with some trepidation. The idea of providing memory safety, clean concurrency and correcting other programming issues of the C/ObjC era is excellent, but, at the same time, exploring programming syntax and overlaying these concerns on current hardware architecture seems doomed to failure IMHO. I think I’m becoming that old man shouting at clouds that the old Burroughs mainframe architecture solved all that! But things like the recent ARMv8.5 Memory Tagging Extension show that Bob Barton was right.

At the start of the COVID pandemic (is it over yet?) I finally decided that my computer science-fu had become insufficient to follow all the theoretical talk about Swift programming and that the language/compiler features were changing to fast to adopt my usual program-by-exploring tactics. Furthermore, macOS was constantly curtailing my ability to hack around in the OS for beneficial purposes and the App Store rules were becoming more and more restrictive and confused, so my favorite type of utility was becoming very difficult to write. Finally I gave up altogether.

If you need up-to-date utilities that delve into macOS internals, Howard Oakley’s Eclectic Light Company site is an excellent resource which I can’t recommend enough. Frankly, I don’t know how he does it.

So, wishing you-all a better 2026. I look forward to write more here about computer history and table tennis. Let’s see how that works out.

In case you’re wondering, I’m still here and — after 4 years of balancing acts — now consider my situation stable. Here’s a brief update on my previous post.

The eye needed a second triamcinolone injection but can now, several months after that, be considered stable. I’ve worked out a regime of eyedrops that seems to keep the macular edema mostly at bay and holds dryness etc. to tolerable levels. My eyesight has stabilized at 20/50 and I can drive cautiously.

The development hiatus can now be labeled retirement, unfortunately. I can’t see (hehe) going back to writing Mac apps and the pace in Swift(UI) development is still such that I’m adopting a wait-and-see approach to iOS/iPadOS development.

The health reports are good, my weight is almost down to my optimum level of 72-73kg and my level of exercise keeps improving; not up to pre-pandemic levels yet, but good.

Hopefully I’ll have time to write more about table tennis soon. It’s a fascinating subject.

Two years have passed since my last post on the subject, and the few readers left may want to know what happened since then with my eye troubles.

There have some relatively minor complaints. The Diamox pills I was using to keep eye pressure down turned out to have noxious long-term side-effects and I had to discontinue them gradually. Some side-effects (dizziness, weakened voice and reduced coordination) I had attributed to lack of physical exercise and old age ? but they’re gone now, it’s a relief.

Fiddling around with eyedrops to find the least irritating ones is an ongoing process, complicated by two bouts with small corneal injuries — probably caused by forgetting to blink while using the computer.

The remaining problem is a macular edema that appeared over a year ago, causing blurred vision. After it proved resistant to eyedrops, a subtenonian triamcinolone injection relieved the condition for several months, but it seems to be coming back. It’s still undecided whether repeating the injection will be worthwhile.

In the meantime, the eye is still drier than usual, painful towards the end of the day, and the dilated pupil makes me avoid the sunlight; I’m still getting used to these — apparently permanent — conditions.

On the development front, I’ve decided to start writing software again in the near future; maybe not for publication, but purely as brain exercise. None of my old apps seem to be doable for the recent macOS versions; Apple has tightened restrictions on what can be done by third-party apps.

Also, I see that most of my Objective-C experience is now obsolete and Swift has progressed beyond my feeble CS skills. But it still might be fun to try to catch up! To that end, I’ve purchased a reasonably configured M1 Mac mini running macOS Monterey and have slowly been migrating my normal apps to that; tricky as I was still depending on some 32-bit utilities, so my trusty “Late 2014” iMac will still be in use in parallel for several months.

Things are more positive on the general health front. We’re both fully vaccinated with a booster shot, and have been able to start regular gym sessions again, with encouraging results. This has also been producing excellent results in our table tennis training, and we have even been twice to special training sessions in nearby Varginha. This weekend I’ll play the 10th TMB Challenge Plus tournament and have good chances to add a medal to my collection.

WWDC 2020 opens next June 22nd and all indications are that the highest-impact announcement will be the Mac’s migration from Intel to the ARM architecture.

While CPU architecture migrations are infrequent — they happen every decade or so — Apple has a good track record of pulling them off successfully.

The first major migration was the move from Motorola 68K to PowerPC chips around 1994, followed by moving from the Classic Mac System 9 to Mac OS X around 2000. Relevant here was that for some time Mac OS X ran older applications in the “Classic Environment”: a compatibility sandbox that emulated the APIs of System 9 and the instruction set of the 68K.

This worked reasonably well as PowerPC CPUs were several times faster than the old 68K ones. It also introduced the concept of “fat binaries“; the same application file contained code for both old and new environments.

A better historical precedent is the move from PowerPC to Intel processors in 2006. This was more traumatic for developers, as PowerPCs were “big-endian” and Intel CPUs were “little-endian”. This meant that, except for strings, values stored in memory, files or transmitted over networks had a different byte sequence ordering. To have the same program source code work on both systems you could no longer assume it would just work, but had to bracket your instructions with macros or function calls that would do nothing on one platform but swap bytes around on the other.

If you’re not an oldtimer like myself you probably never had to think about this — every Mac, iPhone, iPad, Apple Watch or Apple TV use little-endian values, and I even had to dig into documentation to make sure of it. ARM CPUs can be run in big-endian mode by setting a special bit at boot time but this is not the default, and no Apple device uses that mode.

Now, this meant that in 2006 developers could not just migrate their apps to Intel by recompiling; we had to look through every line to either check that it was endian-neutral, and if it wasn’t, those special macros had to be used. For people who had very CPU-specifically optimized code — perhaps even in (shudder) assembly language — separate code sections were necessary.

Having done all this, you recompiled your app twice; once for PowerPC, once for Intel; and the magic of fat binaries allowed you to ship it all in one app. Later on, some apps even needed 3 or 4 different code sections, depending not only on endianness but also on whether they would run on a 32- or 64-bit CPU!

Another — today mostly forgotten — aspect was that Apple prepared for the Intel migration by gradually modernizing and building their developer toolchain in-house. LLVM, Clang, LLDB etc. allowed Apple to ensure that, for whatever CPU they wanted to support, compilers were ready beforehand and could be optimized continuously later on, without depending on outsiders.

Still, in 2006 Apple had to ship special hardware, “Developer Transition Kits”, to select developers for testing. For software that couldn’t be converted to the new architecture, Apple introduced a limited compatibility box: Rosetta. If I recall correctly, it did on-the-fly translation of PowerPC code into Intel code, which was then cached. Because of its limitations it didn’t work for many larger applications and was soon phased out.

Moving in parallel to the PowerPC to Intel migration was a slower-motion shift in operating system APIs. Most notably, this involves Carbon and Cocoa.

Carbon was a C-based API introduced in 2000 to ease migration from Classic System 9 to Mac OS X. Cocoa, introduced around the same time, was an Objective-C based API for modern object-oriented programming, itself an evolution of NeXT’s OpenStep system. Underneath both APIs, in the now well-known layer model, was Core Foundation, which could be used from both types of apps; and some apps (like my own) could mix calls to both APIs with some care.

Not too long after the Intel migration, Apple announced that 64-bit was the future, and that Carbon would not be migrated to that environment. This process was stretched over several years and involved redefining what APIs were really considered “Carbon”; some, like the File Manager, were “de-carbonized” and lived on until macOS 10.5 (Catalina) came out.

Cocoa, on the other hand, continues to be used everywhere in macOS. The Finder, the Dock, Xcode, and Safari are all Cocoa apps. Even when Swift came out a few years ago most of it was built on top of Cocoa and Objective-C objects; the notable exception is the Swift toolchain itself.

So, after all this, here we’re looking at Yet Another Hardware Migration for Macs. Let’s look at the implications.

Economically, it makes sense for Apple, as many others have already commented. They’ll no longer be bound to a foreign evolution roadmap on which they have little influence. They have extensive experience in producing high-performance, low-power CPUs for their mobile devices, and the latest versions already outperform Intel in some situations.

Technically, it’s a huge win. Switching to ARM64 — and not just the standard ARMv8.x architecture licensed from ARM, but with their own, extensive modifications — will allow them to have unified GPUs, Neural Engines, memory controllers and so forth on all their line, with more uniform device drivers and low-level programming.

For 99% of developers, I think nothing will change. The new chips are little-endian also, so a simple recompile will have Xcode produce a fat binary for the new Macs which should run outright. Of course, if you have assembly language sections in your program and/or write kernel extensions/device drivers, time to learn a new architecture…

Snags will come for people who dislike, or can’t use, Xcode. Some have to use Intel’s compilers, for instance; I know too little about such cases to have an informed opinion, sorry.

Some pundits seem to expect a sudden concurrent change in macOS; something like Objective-C and/or Cocoa being obsoleted in favor of Swift and SwiftUI. Or even the Mac going away entirely, some sort of huge desktop iPad taking its place. In my view this won’t happen. For one, what would developers or even most Apple engineers use for development?

A big question is: will Apple be able to provide an Intel compatibility box on the ARM Macs? Certainly Boot Camp will not be available. Running a virtualizer like VMware Fusion or Parallels seems almost as difficult, unless the new CPUs have some sort of hardware assist to decode x86-64 instructions. This may not be as outlandish as it sounds; current Intel/AMD processors already break x86 CISC instructions into RISC micro-operations which are then cached and executed by the “inner” CPU. This is a gross oversimplification but in theory nothing — except silicon space — bars Apple from breaking x86 instructions into ARM instructions.

A Rosetta-like box seems more feasible for running individual Intel applications, but who needs that? Game users? Performance will be limited. Most virtualizer app users want the complete OS running and with native speed. Linux/BSD might be available soon; perhaps Windows for ARM.

But what about Catalyst, some of you may ask? Here I can only shrug. In its present form it certainly is not an important future technology for macOS. While simple apps can be done with it — perhaps purely for the benefit of developers unfamiliar with AppKit — can you envision a Catalyst Finder? SwiftUI is still very new and primitive, and will continue to be layered on top of AppKit/UIKit for some time. They may merge in the future, or be renamed gradually like Carbon was, but that’s a long time out.

Finally, hardware. I don’t think the existing A13 SoCs would be applicable to any Mac, though. Some version of the Mac mini would be the obvious candidate to be the first to get the all-new CPU. It would then percolate up through the laptop line and the iMac. In these cases, reduced power usage would be a bonus — even for the iMac, it would mean a smaller power supply, less heat and a thinner enclosure.

The Mac Pro should be the last Intel redoubt. Multiple CPUs, OEM graphic cards, generic PCIe cards — Apple will have to address a huge range of problems there and this will take years.

Enough handwaving for now; the usual disclaimers apply and I’m really looking forward to the keynotes next week.

Update:
— corrected date for the 68K->PowerPC migration. Thanks to Chris Adamson for catching the error.
— fixed some awkward language about virtualization. Thanks to Maurício Sadicoff.

I know you’ve all been waiting for an update on my eye surgery…
…not really? Well, here’s one anyway.

Fast recap: here’s how things looked from my right eye —  it’s just slightly exaggerated. It’s called a macular pucker, and reading Spalding Gray‘s monologue about it wasn’t very comforting. The darkened, twisty part was unfortunately almost right in the middle, so reading with that eye was impossible, and the whole 3D experience was unreliable.

So, 3 weeks ago I had that somewhat scary vitrectomy operation and I’m happy to report that the surgeon said that, technically, everything went well — no infection, no visible scarring on the retina, no harm to other parts of the eye. Whew. In the meantime, I still have two weeks of antibiotic and steroid eyedrops every few hours; a small price to pay, of course!

Subjectively, the darkened blob is almost gone and the twisty parts are very gradually spreading apart and getting smaller; there remain two gray curved marks around the center, only noticeable when looking at a uniform background. Everything should stabilise in about a year and, with some luck, my eyeglasses should need no changing.

In another week I should be ready to resume my (relatively) new favorite activity: serious table tennis. I’ve started training regularly again two years ago, after about 40 years off the tables, and will write regularly about the topic here.

Warning: long, technical post; no TL;DR.

As I’ve said a few days ago, and then explained why:

My software development activities are (now, officially and indefinitely) on hiatus.

Most of my software projects already were marked as “legacy”, and RB App Quarantine had insignificant download counts, but RB App Checker Lite continued to be reasonably popular despite the lack of updates and an increasing number of crashes after macOS 10.12 came out.

In the past years, as I was beginning to consider the possibility of making this official, I replied to a few dozen bug/crash report emails mentioning that I might have to do so. (Of course, it never crashes here on my own machines… ?) Almost everybody replied with polite wishes but also mentioned that I should publish it as open source. Unfortunately, that is impossible; see below.

My idea with the RB Utilities (including several that never were published, one of which was the first one!) was to have a common foundation for all sorts of apps that examined, or did things to, files, folders and the file system in general. Some of you old-timers may remember my very well-reviewed XRay utility, which was not only my first Cocoa app, but also brought reasonable financial returns.

I wrote the core of XRay for MacOS 10.1 during an all-nighter session at MacHack 2001, so unsurprisingly XRay proved to contain serious design flaws and did not update well as file system APIs evolved. For some time I worked on a rewrite to be called XRay II, which made heavy use of plugins for most of its functions. But I was distracted by other work and in the end decided to shelve it.

Still, the idea of plugins proved too tempting, especially as Objective-C offered so many neat facilities for it, and in early 2011 I began writing a generic RB Utility app that would be specialised into a specific utility app by incorporating a single plugin, built right into the executable (rather than being a separate code/resources bundle elsewhere). The generic app would have both a Developer ID version and a Mac App Store version. It would do the heavy lifting, such as startup, integrity/signature/receipt checking, copy protection (for the devID version), show the About Box and generally do all the common work of showing windows, scanning folders and whatnot.

My usual work style is to write the basic stuff, run/debug it, then do increasing detail in sort of a fractal way. While writing the app framework I also wrote a very simple plugin that would be the basis of my first utility, RB File Counter. It would just scan a given folder at great speed and report the number of files and subfolders inside that.

As things progressed I was not very pleased with the complex (but interesting!) details of certificates, codesigning, requirements for the Mac App Store, and so forth; and I realised also that many developer buddies were having even more problems than I had. The logical thing was to halt work on replicating the old XRay functions like counting files, changing permissions etc., and first do an app that would help me (and others) to make sure our work was in shape. This became RB App Checker, with the “Lite” added on because I wanted to either do a “Pro” version or a general consumer version; both were to be paid-for, and there had to be some infrastructure built for that.

RB App Checker Lite came out in early 2012 after over a year of work and was well received; many developers sent in suggestions and bug reports, and I was also busy keeping things updated and making sure the app was both small and fast. When I went back to testing the other utilities, some infrastructure changes proved to be not generic enough and I had to review my initial design, of course.

In retrospect my main (and usual) mistake was to heavily over-engineer parts of the code in a matter that wasn’t future-proof. The “interesting” parts were heavily optimised, obfuscated, compressed and otherwise squeezed into hyperspace, while also trying to use all available CPU cores; and some extremely paranoid parts of the code were checking other parts of the code. In fact, I showed some of the source to a very senior Apple engineer at my last WWDC; he blinked and gabbled something like “ahem, well, this is most unexpected and I’ll be interested to know if it passes the App Store code review” while backing away slowly.

So, to come back to my original point, this means that the code as such isn’t fit to be published as open source. I may disinfect and publish a few of the saner parts later in a very controlled manner. If all goes well for my eyes this year,and now that Swift is nearing ABI stability, I’ll restart the app entirely in Swift — a good opportunity to relearn how to use GitHub and (ahem) unit testing.

Stay tuned for more news…

As I’ve said yesterday:

My software development activities are (now, officially and indefinitely) on hiatus.

The dictionary says:
hiatus | h???d?s | noun (plural hiatuses) [usually in singular] a pause or gap in a sequence, series, or process…

Let me tell you about the “why” first. Thanks to all of you who immediately asked if I’m OK, by the way.

Short answer: yes, I’m OK, though not as OK as in the past — but then, that’s to be expected, with all these anniversaries streaking by. Not helped at all by miscellaneous stresses originating in Real Life™. But: see below. ?

Longer answer: in the past several years, my eyes have been getting progressively worse, to the point that reading on paper now works only with excellent illumination. OK, paper is not something I have to do on a daily basis nowadays, but reading on a screen also no longer works at the — admittedly, very small — font sizes I was used to. Jacking up the font size worked up to a point but my coding habits call for a huge amount of text visible at the same time. Stopping work altogether to wait for an improvement has, retrospectively, killed all my momentum. (I’m still waiting for that improvement, unfortunately.) Also: see below…

Medical answer: during a trip to Bhutan (highly recommended!) in 2014 I suffered a posterior vitreous detachment in my right eye; no doubt due to day-long van trips over their highways-in-progress. A couple of months later, a beginning retinal detachment was fixed by laser surgery, and everything seemed OK for a time. However, visual contrast worsened until, in 2016, I had to have cataract surgery on both eyes; this was when I stopped working altogether, waiting for my eyeglass prescriptions to stabilise. While that took longer than expected, I also found that there seemed to be no combination of monitor brightness/contrast that made working longer periods tolerable. To make things worse, the vitreous detachment seems to have left a scar on the right retina, causing a macular pucker; surgery on that (a vitrectomy, yikes!) is now scheduled to happen before the end of this year. My eye surgeon assures me that should take care of everything… digits crossed!

Needless to say, all this has been somewhat disheartening, and — as far as coding and blogging are concerned — I seem to have joined the Procrastination Monks for a few more years.

In the meantime, other things have happened, some quite positive! Stand by for more news…

Today I have removed my remaining apps from the Mac App Store and posted official “Legacy” status notices on the product pages. My software development activities are (now, officially and indefinitely) on hiatus.

I know this notice has been long overdue, as I’ve been unable to update anything for more than 2 years. My apologies; I’ll try to post more about this here in the following weeks.