Something I noticed about the new Apple Mac Mini

I’ve always had a soft-spot for the Mac Mini. I’ve always liked the diminutive form factor, and in fact, if it were up to me, the updated Mac Pro would basically be a slightly larger Mac Mini with space for a couple of internal drives and perhaps a way for end-users to change processors, memory and video cards.

But here’s an interesting thing about the Mac Mini.

The base price of a 4-core Mac Mini is around $800. Throw in about $200 for a good monitor and keyboard and for $1k you have a very nice little computer with a 3.6ghz quad-core computer with 8gb memory and a 128gb of (SSD) storage.

But unlike previous models of the Mac Mini, there are a number of ways you can upgrade the processor, memory and storage. Toss in a 3.2GHz 6-core i7 processor, 64gb of memory, and a 2Tb SSD drive with an upgraded Ethernet connector, and now you’re rounding the corner of $4,200.

I understand why Apple doesn’t want to report numbers anymore. Because the number of Mac Minis Apple sells doesn’t really tell the story of how much money is making.

Further, the numbers tells us where Apple may be going when they finally upgrade the Mac Pro.

My guess: Apple will have an upgrade path for a Mac Pro that nearly crosses the $10k line, but will be quite a powerful little box.

I think the iPad Pro is it’s own category of laptop computer.

It has been a common accusation since time immemorial that Apple computers are just too expensive. Even when the original iPad came out much cheaper than the market predicted, it wasn’t long before people concluded the iPad was too expensive.

With the introduction of the new iPads and iPhones, we’re seeing the press double-down on this assertion–one which is only confirmed (to the minds of some) that Apple will no longer give unit sales numbers. Apple has been accused of squeezing out customers, of Apple’s losing profitability, of Apple now trying to lock in customers and engaging in “rent seeking” (despite not understanding what that term means).

And Exhibit One of this assertion is the new iPad Pro:

Apple’s higher iPhone, iPad Pro prices are the new normal

Here’s the thing, though. A couple of years ago developers started to wonder if Apple would make the iPad UI framework available for writing applications on MacOS X.

(For those who don’t know: Apple’s operating systems rely on three core libraries (or frameworks) on which applications are built. The “Foundation” framework provides basic support for things like math, dynamic array storage: the underlying plumbing that any application would rely upon to work. On top of this, Apple has built the “Cocoa” framework, the framework used by MacOS applications to do things like create windows, handle menus, draw to the Mac display, etc. And on iOS, Apple has the “UI” framework, which provides similar functionality as the “Cocoa” framework, but for the iPhone, iPad and Apple TV devices.

Now despite providing similar functions, Apple’s Cocoa and UI frameworks are very different. The objects you use are named differently: “NSView” verses “UIView”, for example. The way they behave are subtly different. And the types of UI objects are very different: the UI framework relies on single-screen viewports which contain the familiar iOS navigation widgets (such as the back button in the upper-left of the screen), while the MacOS framework deals with multi-window applications.

Now elements of Cocoa has been bleeding into the UI framework (such as undo), and the UI framework has been bleeding into Cocoa (such as NSViewController, which manages a group of views).

So the question arises: will they ever be consolidated? Will Apple provide One True Way to write apps?

The argument against this One True Way, however, are the fundamental differences between the sorts of things you may want to do on the Macintosh (multiple window applications that require a mouse pointer and which show everything you need in a small number of windows), and the iPhone (single-window applications that use touch for navigation, and which may rely on lots of small windows and fast flipping between screens to navigate).

All of this makes me think that ultimately the iPad Pro is being positioned as a completely new line of portable computer, one that uses the (carefully thought through) touch-driven user interface ideas first championed on the iPhone.

Yes, a fully equipped 12 inch iPad Pro, once you throw in the smart keyboard and the Apple Pencil comes to $2,230, not including sales tax.

But look at what you get with that 12 inch iPad Pro. You get performance better to the 13″ MacBook Pro, which retails around $2,600. You get 1 TB of storage–the same as the $2,600 MacBook Pro. And you get a computer that is thinner, runs without a fan, and is more portable than the 13″ MacBook Pro. In fact, you get a computer faster and more powerful than the 15″ MacBook Pro that retails around $3,400.

I really think Apple is slowly evolving the iPad Pro as a new line of computers–and I wouldn’t be surprised if we see new APIs in iOS only available to the iPad Pro. (Already we see Apple Pencil APIs only available to the iPad Pro.)

In fact, it would not surprise me–especially given the iPad Pro’s introduction of a USB-C port–a port previously only available to Mac systems–that we start seeing development tools appear on the iPad Pro. I would not be surprised if Apple has Xcode for the iPad waiting in the wings, for example. Already we have the iOS “Files” application which allows you to browse and manage files on your iPad.

In fact, the only thing that appears to be missing from the iOS API is access to the Unix ‘fork’ system call. (Remember: iOS is based on Unix, and in fact, provides access to most familiar Unix API entry points including pthreads.)

Provide that (even in a very limited, controlled way), and you have the potential of an operating system rivaling that of any other Unix-based or Linux-based environment.

The bottom line, though, is that if you look at the iPad Pro as somehow just another iPad–and start looking at pricing considerations by looking at the top of the line–you’ve missed the story.

And if your primary use of the iPad is browsing the web, reading books, and watching movies–you may want to think about the 9.7″ iPad (which tops out at $560 fully loaded) or the iPad Mini (which tops out at $529 fully loaded).

My guess is that a new 10″ iPad and a new iPad Mini will be rolled out at some point with a slightly bumped processor and more storage. Though it wouldn’t surprise me if Apple phases out the iPad entirely. (To me that would be a bit disappointing, since there is room for a lower-cost iPad with less power for those who just want to read books or surf the web.)

Centering a documentView inside an NSScrollView

This took me a while to sort out, but I finally figured it out.

Basically if you want to have the documentView of a NSScrollView be centered in the view if the content area of the NSScrollView is bigger than the size of the document view, you would override the NSClipView class with a custom class. This class would then implement the -constrainBoundsRect: method as follows:

@implementation GClipView

- (NSRect)constrainBoundsRect:(NSRect)proposed
	NSRect r = [super constrainBoundsRect:proposed];
	NSRect doc = [self.documentView frame];

	if (proposed.size.width > doc.size.width) {
		r.origin.x = floor((doc.size.width - proposed.size.width)/2);
	if (proposed.size.height > doc.size.height) {
		r.origin.y = floor((doc.size.height - proposed.size.height)/2);

	return r;


This may not be good.

When you’re building an example UI for an Arduino, you have two screens to finish, and you see something like this:


Sketch uses 31424 bytes (97%) of program storage space. Maximum is 32256 bytes.
Global variables use 692 bytes (33%) of dynamic memory, leaving 1356 bytes for local variables. Maximum is 2048 bytes.

So let’s see if I can’t write the code for two screens in 832 bytes…

The Hacking Den.

So I’ve started a new blog at The Hacking Den, and I’ve included a number of posts there.

While my comments here on Chaos In Motion have generally been technology oriented and more commentary about technological ideas, The Hacking Den is intended to be a more practical hands-on learning site.

I figure it will take a few months to find my voice, and I do have a number of plans for that site, including doing video animations a’la 3 Blue 1 Brown, an fantastic site for math visualizations. My intent, however, is to use the same sort of visualizations combined with hands-on coding and hardware construction to teach a variety of topics in Computer Science, ranging from the mundane (such as constructing a 3D rendering engine for an Arduino, or teaching computer programming or user interface design, or even constructing hardware projects) to the more abstract (such as visualizing different computer algorithms).

Right now I’m concentrating on a few topics which have been of great interest to me: building an Orrery, a mechanical model of the solar system which calculates the relative position of the planets mechanically, and illustrating the principles of user interface design by building software for an Arduino equipped with a touch-screen.

Stop by and visit the new site and let me know what you think!

Well, that’s a couple of hours I won’t get back.

So today’s mission: while working on a Mac app, I wanted the correct icon to show up for my documents.

And of course that involved a lot of hair pulling.

Here’s the answer.

(1) Create your document icon. Open the Assets.xcassets, right click on the icon list, and create a new MacOS Generic Icon. (Under “App Icons and Launch Images”.) Create your document icon in the resulting icon, renaming as appropriate. (In my case, I named it “DocIcon.”)

(2) On Xcode 9.4, if you open the project file, select “Info” and show the Document Types, the “Icon” drop down does not show the contents of the Assets catalog for your icon. Xcode lies!

Just type the Assets icon name into the drop-down. You’ll continue to see a question mark. Don’t sweat it.

XCode Document Setting

(3) There is no step 3.

Now of course if you want to allow other apps to play in your background, you can also export a UTI. Notice how I defined an “Identifier” above? Well, if you don’t export a UTI this won’t work; leave “Identifier” as blank.

However, if you want to tell the OS that your file is a type of another file–like, for example, your file can be opened as a text file, then define your UTI identifier (using the com.blahblahblah style for UTIs), and add an exported UTI:

Extern UTI

This basically says “hey, MacOS, that UTI type “com.chaosinmotion.Kythera.gearfile” I told you about? Yeah, it’s also a “public.text” text file.

And you can also import UTI types; that basically tells the system “hey, I can open public.text files!” But that’s beyond the scope of stuff I care about right now.

The things you learn along the way to trying to design your own computer language.

So here are two things I sort of uncovered on the path towards designing my own computer language.

(1) Do you have headers or not?

Meaning is your computer language one that includes headers and some sort of mechanism for loading those headers? If so, then a few things become true:

You implicitly need two ways to define something: as an include or forward declaration, and as a concrete definition.

That implies you need some way to say in your header that “Foo” is a function and “Bar” is a global variable, but don’t define “Foo” or “Bar” here. If your language is object-oriented, you then need a way to say (as Objective C does) “@interface” and “@implementation”, and (if your object-oriented language has single inheritance with interfaces or protocols) “@protocol”.

Note that in Java, you only have ‘class’ and ‘interface’; ‘class’ also doubles as a way to say “somewhere this class is defined, but I’m not defining it here.” But then, Java doesn’t have include files.

How do your include files work? That is, are they loaded by a preprocessor into a single logical file, as in C or C++? Or are they separate “definition” files which are compiled then referred to during the compilation of your source code?

This can also implicitly work with precompiled headers, but I’m thinking of a header language which is orthogonal to the source language. Meaning you could theoretically design a language where the headers can only legally include stuff like “extern int foo();”, but cannot legally contain:

int foo()
    return 5;

Now if you don’t have headers, you need to figure out how to handle precompiling enough information from all of your source files so you can refer to the signature of your objects from other files. That could be done, for example, through a two-pass compilation process: the first compiler pass only constructs the implicit header information (the names of globals, functions, classes, methods), then the second pass actually constructs the code, including other class declarations as required.

(2) Is your language strongly types or weakly typed?

One consequence of a strongly-typed language is that every expression in your language, you know the type of the inputs and the implicit type of the output. You know, for example, your variables ‘a’ and ‘b’ are integers, and thus the result of addition will be an integer. You know if you have different variables types for ‘a’ and ‘b’ (say, ‘a’ is an integer and ‘b’ is a real number), then your compiler has to implicitly handle the conversion of a to a real number prior to addition, and the result os a real number.

This puts a lot of things on your compiler. You need a type representation which can represent all the types (including compound types) of your language, so you can differentiate between int **a and int *a, and so you know the result of dereferencing a variable.

On the other hand, if you have a weakly typed language–any variable can be pretty much any value–then this makes the design of the compiler far simpler. But it makes your run-time engine do a lot more work: because a can be anything and b can be anything, the variables have to have an implicit type associated with them, and you your addition code has to know how to add any two objects together to get a reasonable result.

Of course weakly typed languages result in some weirdness; just see the various examples about addition of integers and strings in Javascript.

I’m sure I’ll learn more things along the way. But these are the two that have bitten me in the past few weeks.