Rixstep
 About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Home » Learning Curve » Developers Workshop

Notes Crashed

We told you so.


Get It

Try It

Notes crashed. Apple's own software. It crashed. Right out of the box.

We told you so.



We've never run Notes.app before. Why should we? But we were curious how the great minds at Apple addressed a design issue we here are currently working on.

We shouldn't have bothered. We shouldn't have wasted our time. No matter how minuscule that time frame was.

You needn't worry about the internal issues. You don't want to bother anyway. And they'd mostly be over your head. Suffice it to say that Apple 'encountered an error'.

They do a lot of that these days, Apple. Encounter errors. They do this because they've artificially implanted fake 'stops' in their code all over the place. (This began with OS version 10.14.)

What they're really after is to stop all process threads save the first from having anything to do with on-screen updates. The reason for this is unknown. This hasn't been an issue for twenty years at Apple, or for an additional fifteen years at NeXT before that. Nor has it ever been an issue with Windows, Gnome, KDE, you name it.

Only Apple.

This necessitated a lot of code being rewritten both inside and outside Apple. Screen updates which of necessity must be controlled from background threads have to suddenly avail themselves of a system API to transfer temporary control to the first thread. The reason for this isn't fully known. Things are always destructively secret at Apple. What is known is that failure to do as outlined above will result in a crash if the code is built for version 10.14 or later.

(Yes, do note: the system still has fully functional, fully durable, APIs for earlier versions of the OS. They work jim-dandy.)

The problem is it's hard to know, at a glance or even several repeated glances, what's going to end up in a code that affects the screen. In even a remote obscure way. That's where Apple's own code fails. Time and again.

Not quite even out the starting blocks. Application's on screen. About box summoned. Perusal of the menus, signifying nothing.

Then crash.

Apple's exit from IT will not be with a bang.

About Rixstep

Stockholm/London-based Rixstep are a constellation of programmers and support staff from Radsoft Laboratories who tired of Windows vulnerabilities, Linux driver issues, and cursing x86 hardware all day long. Rixstep have many years of experience behind their efforts, with teaching and consulting credentials from the likes of British Aerospace, General Electric, Lockheed Martin, Lloyds TSB, SAAB Defence Systems, British Broadcasting Corporation, Barclays Bank, IBM, Microsoft, and Sony/Ericsson.

Rixstep and Radsoft products are or have been in use by Sweden's Royal Mail, Sony/Ericsson, the US Department of Defense, the offices of the US Supreme Court, the Government of Western Australia, the German Federal Police, Verizon Wireless, Los Alamos National Laboratory, Microsoft Corporation, the New York Times, Apple Inc, Oxford University, and hundreds of research institutes around the globe. See here.

All Content and Software Copyright © Rixstep. All Rights Reserved.

CONTACT INFO:
John Cattelin
Media Contact
contact@rixstep.com
PURCHASE INFO:
ACP/Xfile licences
User/Family/Business
http://rixstep.com/buy
About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.