The Changing Face of Apple

Yesterday’s Apple Event featured a golden MacBook and a $10,000+ watch. Time to reflect on how on how we got there.

Jony Ive has designed some beautiful things. People kid about his “white world” in which his disembodied voice chirps on about facets of the design that most people will never even have thought about before. The revelation that he is chauffeured to work in a Bentley every day sits well with a man who designs $10,000+ watches.

Jony Ive also has a penchant for form over function and aesthetics over functionality. His Luxor Jr. iMac was his only true excursion into the realms of ergonomically correct design and it was soon replaced with the now iconic “it’s-just-a-screen! where-is-the-computer” iMac design that has changed little since.

Jony subsequently discovered “aluminum” (yes, he even knows how to pronounce it) and glass; then few years later he re-invented “gold” and “space gray”; yesterday he invented Fluoroelastomer and all-new-never-seen-before versions of stainless steel and gold.

All the while, Apple’s product owners have continued to live with ergonomic, practicality, and performance problems.

Clearly, Jony’s focus on desirability has paid off handsomely for Apple and is not about to change. As a professional Mac user, however, I find it hard to put up with iteration upon iteration of beautiful but impractical designs.

Take the iMac. The Retina iMac has a great screen, but even thought it’s the n-th iteration of the glassy front pane, the glare and reflection are still bothersome and keep me from ever wanting to use one as my main work machine. The new laminated screen technology and the new coating are a big improvement over the initial iteration, but still much worse than simply not putting glass in front of the display at all.

Take the Mac Pro. I bought a new late-2013 trash-can Mac Pro for a couple of a thousand euros to replace my previous “cheese grater” Mac Pro. It is amazingly quiet, but.. it’s not much faster than my 2010 Mac Pro because it lacks a second CPU. Instead it has a second high performance GPU.. which can’t drive 5K displays. I can purchase a 5K-compatible GPU for my old Mac Pro, but not for my new improved Mac Pro. The new Mac Pro is so small, it can (and in reality must) sit on my desk rather than under it. So now I have a mass of cables running all over my desk..

In summary, all current Macs make often inappropriate compromises in the search for aesthetics.

Enters the “MacBook”. It is gorgeous and I want to have one (in gold.. please kill me!) because it’s so desirable. It is also an incredibly hobbled piece of technology. It has a Retina screen, but at a resolution of 2304-by-1440 corresponding to a non-retina resolution of 1,152-by-720, it has the tiniest resolution on a Mac for a long time. As an application developer this means that I’ll have to seriously look into how well my UIs work on such a tiny screen.

It also has only one USB-C port, which doubles as a charger. Fewer ugly holes in the unibody enclosure yes, but what a nightmare of adapters and cables it will be to attach an external keyboard, mouse and display while charging..

Then there’s the great new keyboard with almost no travel and metal keycaps. The jury is still out, but even Wired’s two minute hands-on confirms what seems obvious: it’s likely to be awful.. even though the keys are now individually lit by their own LED.

Laptops and notebooks are ergonomic nightmares in any event, because of the crammed keyboards and fixed displays and Apple’s offerings with their mini-cursor keys and mirror-effect displays start out with a severe handicap that needs superior engineering to compensate for.

The elephant in the room is of course performance. A gaming notebook this certainly won’t be. Graphics performance is likely to be appalling given the fan-less design and the choice of CPU will prevent anything but “light” work to be performed on this gem.

Still..l I want one and I’m already trying to talk myself into getting one.. surely I could use it as a replacement for the iPad when I travel (I don’t travel) or I could use it in a coffee shop for writing code (I don’t go to coffee shops). I could get one for the kids (but it couldn’t run Minecraft).. darn I’ll just have to go and look at it in the shop and lust after it there until they shoo me away.

This was the theme from yesterday’s event: They showed a lot of gorgeous stuff but I don’t need any of it.. and it’s too expensive to buy on a whim.

The Apple Watch is the answer to a question I never asked and Apple has not done much to crystalize what that question should have been. They haven’t been able to come up with a rationale for why you would want to have a smart watch.. what it’s going to be good for.

In that way it is quite similar to the iPad. Steve Jobs clearly had no idea what you’d want to use it for beyond “surfing the internet on the couch” when he presented it.. but it has found its place.

I’m sure that the MacBook and the Apple Watch will also find their place in our lives.. and for much the same reason. We want these devices because they are desirable not because we necessarily need them, so we are actively looking for reasons to want them.

I’m not yet convinced that I will enjoy wearing an Apple Watch. In all honesty, I wouldn’t get one at all if it weren’t for the fact that my customers will expect some sort integration between my Mac and iPhone apps and their new Apple Watch.

All this is a far cry from the Apple that I fell in love with all the way back in the 1980s. The Apple IIe was my first computer (my father briefly thought of it as of his first computer). Shortly thereafter I saw the first Macintosh and it took many years of going through Atari XLs and STs and some pretty awful PCs before I could finally afford my first Mac in the early 90s.

Back then Macs were both beautiful and offered much greater practicality than PCs and Windows. Apple’s huge success since those days goes down to a large extend to the failure of Microsoft and the rest of the industry to take usability seriously until it was much too late. Even today the likes of Microsoft and the Linux “community” manage to screw up even elementary usability concepts and even though Macs have made no major advances in usability over the past decades, they remain the benchmark against which all other contenders are measured.

I’m not arguing against Apple’s search for desirability over functionality. It is clearly working for them. I’m more bemoaning the fact that today’s Apple has little in common with the multi-coloured Apple that I grew up admiring.

Some of this goes down to the absence of Steve Jobs. Steve ruled Apple with an iron fist and often successfully played the user advocate. He reigned in Jony Ive’s minimalist tendencies and despite never really living up to his own grand and egalitarian ideals, those ideals nonetheless shaped many of his sensibilities and decisions.

A $10,000+ product that is functionally the same as the $350 model but provides infinitely higher bragging rights would probably not have sat comfortably with Steve’s ideals. It does not sit comfortably with many people who were inspired by the iconic “Think Different” campaign to give the company another chance at greatness rather than turning their backs on them like the rest of the world did.

Is this the same company that could conjure the spirits of Gandhi, Martin Luther King and Einstein without raising any eyebrows? No.

Today’s Apple gets its inspiration more from following the good deeds of marathon running ex-models than from the humble civil disobedience of a Mahatma Gandhi. It is more likely to feature full-page ads of David Beckham wearing an “Edition” watch than celebrating the quiet genius of Albert Einstein.

For Old-Timers like me, it’s more than a little sad.

MacBreakZ 5 web site redux

MacBreakZ is one of my earliest software projects and started in 1996, when I developed tendonitis in my forearms.

I heeded this as a wake up call and learned everything I could about RSI recovery and prevention and I have been RSI free for close on twenty years now.

As a software developer, of course, I needed to write a program that would embody all of that know how.

MacBreakZ has since gone through 5 major revisions and development is still ongoing.

Last month, I published the first Yosemite-only version and today the new website is ready.

In doing this I also had to review my book list on RSI, only to find that little has changed in the past decade. Either RSI is no longer a problem (definitively not true) or there’s no much money in writing about it :-)


How not to become an indie developer

The write-an-app-and-get-rich-quick meme has been circulating ever since the iPhone SDK was first announced.

As a long-term Mac developer, I took it all with a pinch of salt. Success certainly hadn’t come that easily for me: I started developing “shareware” for the Mac in 1994 and only went full-time indie in 2006; so after 12 years of part-time indie-doom.

Yet, the get-rich-quick meme was endemic for many years and it sure looked as if every high-school kid who wrote an app became a zillionaire overnight. Nobody (and I mean nobody), ever said “I’ve got a great app, but it’s not making that much money”.

The economics of the iOS app store were always a mystery to me: How can you make a steady income from 70% of $0.99, even forgetting about sales tax in much of the world? Can you really sell thousands of apps every day.. forever? In a marketplace that full? With such a huge bias for novelty and the “next big thing”? all the while competing with all the VC-backed “free” offerings?

It did not seem likely to me that there were a lot of people out there making the kind of money that allows you to pay back your mortgage and bring up your kids.

Intrigued nonetheless, I decided to make a small experiment  in the early days of the App Store: I used some of the existing stretching routines from my MacBreakZ product to create a small iPhone app, just to see what would happen. StretchZ sold a few copies here and there, but it was much as I had thought: you need a really good app to make “decent” money.. and even then the effort-to-revenue ratio is prohibitive.

About half a year ago, Brent Simmons finally dared to ask the question: “Where are all the successful Indie iOS App Store developers”?

This unleashed a flurry of opinion pieces resulting in some of the developers with more or less respectable success to post their sales figures online. Respect! I won’t publish my figures any time soon :-)

The recent revelation that even indie rock star Marco Arment of, amongst other things, ATP podcasting fame, does not make much more than an average developer in industry, was sobering for many.

The discussion seems to have bifurcated into roughly two camps since:

  1. the Doom-and-Gloom camp
  2. the Forced-Optimism camp

The difference between both camps is largely down to what their expectations were.

The Doom-and-Gloom-ers are coming to realize that it is very though to make a living on the App Store even if you make top-notch apps.

The Forced-Optimism crowd tend to be excited hobbyists, who are delighted when they see that some day, they might actually be able to make a living from doing what they love!

On the one hand, I find some of Forced-Optimism crowd quite irritating because they bend over backwards to keep any blame for what is going on from Apple. On the other, the Doom-and-Gloom crowd often seems to blame only Apple and seem unwilling to take much responsibility for their perceived lack of success themselves.

These are of course sweeping generalizations and there’s not a single individual who fits in only one of those camps and many developers have a more much subtle and nuanced view. I’m overstating their positions to make a point: reality is more subtle.

I think that it is naive to believe that you can just go out there, develop an app that you would like to use yourself, put it on the app store and wait for the millions to come rolling in. Yet, that seems to be a fair description of the general approach taken by many developers and “idea people”.

Engaging in ridiculous oversimplifications such as “apps need to be beautiful”, “apps need to do one thing really well”, etc. is not enough to be successful in a competitive market.

Similarly, keeping any blame for the current situation from Apple is just as ridiculous.

Apple did not blunder into this situation by chance. Apple took a very deliberate choice to create a walled-garden App Store for iOS. You cannot install an app on your Apple devices without Apple’s consent and Apple has enforced its the role as gatekeeper. It is thus more than fair to hold Apple accountable for what happens in its store.

The aforementioned naive belief of many developers that just writing an app will make you rich does not come from nowhere. Apple has been at pains to present the App Store as an Eldorado for app developers. They never cease to announce the billions that they “share with app developers”, so perhaps app developers can be excused for having high expectations.. and Apple can be blamed for creating them.

Apple also creates the shape of the App Store through its own policies. Early on Apple seemed to simply have repurposed the iTunes music store implementation to now sell apps. In fact this is still the case.

Top 10 lists, featured sections, $0.99 price tags, no communication between content providers and content consumers, no trials, difficult returns, etc.. all this is the stuff of the Music industry and not that of the software industry.

Free trials, discounted upgrades, direct contact with customers, FAQs, Wikis. That is the stuff of software development.

You can call this “old fashioned”, but Apple has hardly “reinvented” the software industry. What it has done is turn software into a consumable piece of entertainment.

Is it it any wonder that professional grade software isn’t doing great on the App Store?

Why then is Apple so unwilling to change anything?

The answer is quite simply that it seems to be working very well for them. Change is always dangerous, especially if you don’t understand why you are successful in the first place. It is easy to talk yourself (and others) into believing that you are successful because you are doing things the way that you are. The more successful you are, the easier it is to convince yourself that you are doing everything right.

I’m fairly certain that Tim Cook isn’t losing any sleep worrying about how much money Indie developers are making.

What does all this mean for aspiring Indie developers?

Go in expecting nothing. Don’t give up your day job.

Don’t be naive and expect that you’ll be an overnight success. That, as they say takes 10 years.

Don’t rely on money you may never see. Write your first killer app for fun and a bit of pocket money.

Once you’ve got your app in the App Store, try to learn from what happens. What did you do right? What did you do wrong? How far are you from being able to go part-time? What is  your back-up plan?

Also avoid spending your own money on your killer app in anticipation of a large pay-off that may never come. Paying a designer tens of thousands of dollars makes the designer happy, but it is more likely to make you poorer than richer. Once you’ve established that there’s a market for your app, you can still invest in more professional help.

Indie software development can be an enormously satisfying experience. You can create something yourself and share it with the world.

It is also a very hard thing. It takes a lot of effort and energy. It is full of ups and downs. Having people use your stuff can be very rewarding, but you’ll also have plenty of negative feedback. If you have thin skin, now is the time to grow a thicker skin (still working on it personally).

Keep your expectations in check.. Don’t take crazy risks, and above everything else: Enjoy the experience.



Some thoughts about Optionals in Swift

Like many Mac and iOS developers, I haven’t yet made the jump from Objective-C to Swift, nor will I make it in the near term.

Just like most other developers, I am slowly putting a little bit of Swift code into new projects to get a feel for the language and I’m experimenting with its new features to be ready when it becomes a more practical proposition.

At the moment, I’m trying to come to grips with “optionals“, a construct that I have never seen in any language I’ve used before.

Essentially, “optionals” are shoeboxes that may or may not contain a value. You can find out whether they contain a value and if so, you can get the value out by “unwrapping it” and if it contains a mutable type, you can change it.

This replaces the C-style pointers that may either point to the data belonging to an object (in the largest sense of the word) or have a “nil” or “NULL” value that signifies “no object”.

Optionals are a clear improvement on null pointers or nil types in at least two significant ways:

  1. Optionals eliminate a whole class of common bugs by forcing developers to think about “what happens if this method does not return a valid object/ value”
  2. Optionals help make Swift code faster by making it easier and safer to optimize code; optimizers do not have to worry about edge cases where the value may be empty.

The price for those two advantages seems very steep, however.

First, not dealing with potentially invalid objects being returned prevents the code from being compiled in the first place. You cannot not deal with the problem.

Secondly, optionals require developers to learn a host of new concepts. This may be a good thing in the long term, but it will slow adoption as you can’t just dive into the language without understanding optionals and you have little hope of ever having come across them before (unless you are beta testing Rust that is).

Using optionals is also really, really cumbersome. Unwrapping each and every optional makes even trivial programs balloon to many times their normal size. This is why Apple has thoughtfully added a lot of syntactic sugar to make the medicine go down that much more easily.

This syntactic sugar (chaining, etc.) makes your code smaller and cleaner and you can almost forget that it is there at all when you read it. Unfortunately that isn’t the case when you write the code and it does also add a whole layer of complexity making Swift harder to learn and understand.

Optionals also do not map onto anything in Objective-C and as there are no native libraries yet, “implicitly unwrapped optionals” abound and feel very much like a backwards-compatibility hack and a solution to a problem you wouldn’t have without optionals.

So there is a price to be paid for beauty, performance and safety.

That needn’t be a show stopper. You get nothing for free in life and the result may be worth the effort.

Unfortunately, when I’m actually using Swift, I find that I don’t seem to be getting much value out of optionals.

Firstly, there’s the fact that now instead of trying to express what I want to do, I find myself wondering about whether I need to unwrap my optionals? and what might be the best syntax for expressing the unwrapping? where should it be done? now or later? Why does this code not compile?

Admittedly with a little bit of practice, this will probably largely go away. There will always be a  cognitive overhead associated with it, but it will that overhead is likely to get smaller with time. I certainly won’t miss having to check the location member of the return value of rangeOfString: for NSNotFound.

The real killer for me is, however, that I now find all those places in my code where I need to think about what to do when the optional is empty .. and I find that there’s not much to be done.

What can you do when you are loading an image from your app bundle and it is not there? There only seem to be two options:

  1. raise an exception, crash or display an alert that the user can’t do anything about
  2. do nothing

Crashing is great, because now there’s a crash report being generated and I know that something has gone wrong in the production version and I can work out what the cause is and correct it. Crashing early is best practice. It certainly beats crashing later.

Doing nothing might be okay in many situations, because it might not be so bad. It is in fact what Objective-C does most of the time in this situation. It just ignores the problem, the application keeps running (but not necessarily working) or it simply crashes somewhere down the line.

Herein lies the problem with optionals. They force you to deal with potential problems that you can’t do anything intelligent about. Worse, because of the absence of an exception mechanism you need to deal with exceptions in situ, polluting your beautiful code with non-sensical error handling code.

So, what I’m wondering is: “Is there any value in explicitly dealing with problems that you can’t do anything about?”



Image Capture Workflow Updated for A Better Finder Rename 9

Back in 2009, we published a couple of blog posts describing how to
use OS X’s Image with A Better Finder Rename 8:

The second post linked to an Automator workflow to use with this process, but the release of A Better Finder Rename 9 “broke” this workflow; it works only with A Better Finder Rename 8.

We have updated this workflow for A Better Finder Rename 9, so you no longer have to settle for the default import location. Instead, you may choose your import destination at run-time. Grab a copy of the workflow here:

MacBook Pro Retina external display problems & resolution

I’ve just spent an entire afternoon messing around with my MacBook Pro Retina trying to get it to work with multiple high resolution monitors and I thought I’d share my misadventures here so that other people may benefit from what I’ve found out..

I run my 2013 MacBook Pro 15″ retina in two different offices both with two external Dell 2711/2713 displays.. I love all that extra space…

Today, I tried to connect up a third 24″ display also from Dell using a new cable and all hell broke lose.. suddenly ALL my monitors were stuck in HDMI modes making it impossible to select their native 2560×1440 resolution. It took me three hours to figure out how to change things back.. so this is what I’ve found.

The 2560×1440 resolutions were gone from the Display Preference Pane and I was stuck on 1080p and the screen mirroring kept coming on.

Things to try:

1. Zap PRAM

There’s actually no longer any PRAM in Macs, but the newer NVRAM works the same. The NVRAM stores some basic system settings including the screen resolutions of attached monitors.

So just shut down your Mac, press the Power button, hold the Command, Option, “P” and “R” keys (before the gray screen comes up) and keep them pressed until you hear the chime once.

No luck, the screen resolutions weren’t back.

2. Zap the System Management Controller (SMC)

In theory, this shouldn’t be necessary, but it’s another standard step in rectifying “weird” behaviors, so I went ahead anyway.

Shut down your Mac and start it up by holding down the Shift, Control, Option (all on the left side) and Power keys.

Still no change. So I spent an hour playing around with SwitchRes X, which is the step that I should have skipped.

3. In the Display Preferences Pane, Option-Click the “Scaled” radio button..

Suddenly all resolutions appear and you can choose whichever you want, not just the ones deemed “safe”. Hurray!

Except there still isn’t the the 2560×1440 resolution I’m after..

4. Finally, switch off the monitors while connected to the MacBook and pull their power supply cables, wait a few seconds, then reconnect the cables, switch the monitors back on and do the option-click trick.. hurray!

The 2560×1440 resolution appears and everything is fine again.

Obviously as always with this type of problem, who knows which bits are optional and which are necessary? It’s possible that if I had known about the Option-click trick and having to switch the monitors off, it would have worked straight away without a single reboot.

I’d recommend pulling the power supply cables of the monitors and trying the Option-click trick first before restarting anything. It does appear like the problem was that the monitors defaulted into some kind of “safe” mode where they don’t show any non-HDMI modes.. but as always: who knows?

I hope that somebody will benefit from this mini-report.

Best regards,


All our software is Mac OS X Mavericks ready

As you may know Apple have released Mac OS X 10.9 Mavericks during their keynote last night.

It is available for free on the Mac App Store as of now.

Apple has given us developers early access to the new release to give us time to test compatibility and take advantage of new features. We have over the past months quietly released a few minor updates to address compatibility issues and at the time of writing this all our current software titles are Mavericks-compatible.

As always, however, problems that are not apparent “in the lab” can start popping up when a new version is released into the “wild”, so if you encounter any problem, please let us know at and do not rely on other people to do so.. most people wait for “somebody else” to report the problem and then months later frustrated users post a “I can’t believe they still haven’t fixed this!” review.. while all the while developers are blissfully unaware of anything being amiss.. please just drop us a line.

There is one known problem for Vitamin-R on Mavericks that affects only multiple display setups.

Mavericks is the first Mac OS release ever to feature “multiple menu bars”; this is to make it easier to select items in the menu bar without having to mouse back to the main screen all the time. Unfortunately, Mac OS X was never designed to work that way and while Apple’s implementation works it leaves much to be desired.

The main problem is that menu bar items, such as Vitamin-R’s (R) icon appear in multiple different places at once, but Apple hides this fact from the program. As a result, programs only get to know one location for the menu item, but it exists in two or more places. On top of that which location the program is made aware of seems pretty random and is not documented.

All this makes it hard to position popup menus such as Vitamin-R’s or indeed Fantastical’s or Dropbox’s accurately.

We’ve done our best, but with only a single beta tester, we are not entirely certain that it works for everyone. We thought we’d have a little more time to test this before releasing it, but with yesterday’s surprise announcement, we’ll be releasing an updated version of Vitamin-R today.

Let us know if you run into problems!

Why the Mac Pro is perfect for Mac and iOS developers.

I love my Mac Pro. There I said it.

I’ve been a user of Apple’s pro desktop line since the PowerMac G3 (blue & white stripes) came out in 1999. It was the first Mac that I bought with money that I had “made” from Mac shareware sales.

Back in the late 90s, I had grown accustomed to working on Sun and Silicon Graphics Unix “workstations” at the Computer Science department at Lancaster University and the PowerMac to me felt like my “personal workstation”. There was something great about having “the best”; it made me feel all grown up.

Now the PowerMac G3 by today’s standards looks plain awful, but so does the transparent plastic iMac from which it borrowed much of its design. You could legitimately feel good about “thinking differently”, especially since Apple back then was part of the IT counter-culture.

The PowerMac G3 was quickly replaced by the G4 and G5 of which I owned quite a few due the more powerful PowerPC’s tendency to auto-combust at the drop of a hat. Back then there was a lot of PowerPC versus Intel mud-slinging going on and it was kind of fun trading floating point performance figures with my brainwashed PC-adoring friends.

That all changed when Apple ditched the “superior” PowerPC processors and migrated to Intel CPUs. Funnily enough, the renamed Mac Pro was a powerful machine and the Xeon processors just refused to blow up. I’ve owned a couple over the intervening years and I have lost only a single one to a lightning strike (no joke).

Ever since the stellar success of the iPod, Apple has morphed from being the “Mac company” to being the “iPod-company-that-also-makes-Macs”. The success of the iPhone and the iPad have further removed the Mac from the limelight and for a while one could have been forgiven for forgetting that Apple made computers at all.

For me as a Mac developer since 1993 and for many people like me, Apple will always remain the Mac company. We do love our Macs because we spend all day working on them. Big screens, powerful processors and gigabit ethernet cables may sound antiquated to all you iPhone-, iPad- and MacBook Air-touting hipsters but for us, the Mac is the hub of our professional lives.

That’s why people like Marco Arment and, dare I say it, myself are so attached to our Mac Pros. They just make our lives so much better.

Ask anybody who knows me: I’m not a patient man. I hate waiting around while Xcode is double broom-ing my project and while the antiquated little spinning disks are compiling, linking and starting my executables. Instant is quick enough. Anything else just breaks my flow.

Developing software is largely about keeping an awful lot of state in your head at the same time, while acting locally and thinking strategically. It’s hard. Real hard. A big screen, or better yet, two big screens really help you keep all this stuff organized.

The same goes for keyboards and other input devices. Most people are well served with a laptop keyboard or even a touch-screen keyboard. It’s fine for writing email.

Many developers, however, have taken the time to learn to touch-type. Some like myself have even learned the DVORAK layout in a quest for performance and a vain attempt at preventing RSI. The great thing about touch-typing is not that you can type quicker though, but that you can type without taking your eyes off the screen. In that way, you can keep all the stuff that you need spread out in front of you and let your thoughts just flow out of your finger tips.

Working on a laptop is pure torture once you have become used to a full workstation-style setup. The tiny screen means that all the information that you are used to surround yourself with is hidden from you. It feels like you see the world through a pin hole. The keyboard makes it hard to work comfortably because you are hunched over it all the time and the whole experience feels like you are trying to play a miniature guitar. The frets are too close together, your giant fingers keep muting the strings.. your music sucks.

The Mac Pro then is the developer’s tool of choice. It may not be mobile, but neither is the developer. Working in a busy coffee shop is great some of the time, but once you get into the zone, you don’t want to be disturbed. You probably don your sound-cancelling headphones and the only thing that the rest of the world can do for you now is to deliver an espresso once an hour (or more) and leave you alone.

The most important things for a developer’s machine then are the ability to connect multiple large displays, plug in a “regular” keyboard and mouse and provide as much raw power, storage and connectivity as it is possible to engineer at this point in time.

This is in stark contrast with the other group of people who love their Mac Pros: video professionals who need to have a lot of non-standard hardware: huge disks and the most powerful graphics cards available to mankind. While big disks are a plus for us developers too, we care more about how fast they are than on how many terabytes of storage they give us. I certainly wouldn’t trade my 512GB of SSD disk for 20 terabytes of spinning disk.

The new Mac Pro’s that Apple has teased at this year’s WWDC are a great fit for developers.

Video professionals will bemoan the lack of built-in storage bays and the inability to add bigger graphics cards may well be a deal breaker for many of them. For developers, however, those two things don’t really matter.

The new Mac Pros deliver in spades for developers where it matters:

  • Master-of-the-Universe Wow factor
  • Multiple 4K displays
  • Really fast storage
  • Superior CPU performance
  • Whisper quiet operation

Yes, the new Mac Pro looks the part. I have no doubt that setting up one of these machines in your office will give you a buzz and make you feel good about your choice of career. The aesthetics of the new Mac Pro are clearly designed to appeal to our demographic (young and not so young men who fancy a BMW M3) and even steadfastly anti-Apple developers have to admit that they just want one..

Any developer who has had the opportunity to work on one of the new Mac Book Pro Retina displays is impatiently waiting for Apple to finally bring the gorgeousness of those displays to larger screens. Right now, the price for 4K displays is so prohibitive that I can’t see this happening for a while yet and yet I think Apple has paved the way for just that.

One of the major technical challenges of making a full-size retina display is how can you manage to move that many pixels around? The new Mac Pro has double graphics cards as standard. A curious choice unless you’re planning on driving retina displays. Apple talked about “third party 4K displays” at WWDC but one would imagine that they must have such a display in the works themselves no matter how expensive it might be.

All PowerMacs and all Mac Pros so far have come in multi-processor configurations; Apple also made some single processor models but those were really more of an exception.

Yesterday, a benchmark appeared that showed a single processor Mac Pro and this caused quite a stir, because like me most people had assumed that the new Mac Pro would still have two processors.

Careful examination of the videos on Apple’s teaser website, however, seem to show room only for a single CPU and two graphic cards. A curious choice, until you start thinking a bit about it.

Xeon processors are really expensive easily costing $1000 and more per unit. If you put two in a box, you are in old Mac Pro territory before you even add anything else. Yet CPU performance for many tasks is becoming less and less important.

In typical development tasks, it is the hard disk that is the limiting factor. Apple have eschewed spinning disks altogether for the new Mac Pro. Again a strike against those poor video editors. It looked like a foregone conclusion that Apple would leverage its fusion drive technology to offer fast disk access coupled with huge storage capacity.

Again for developers, this hardly matters. What matters is that SSDs speed up build times in a way that a faster CPU just can’t manage. Still, two CPUs are faster than one. So why just one? I think there are two reasons: cost and fan noise.

Hands down the main reason why not every developer has a Mac Pro on the desk is the price. They are really expensive. Largely because the Xeon CPUs that they sport are such high margin processors. Fitting only a single processor drops the price of a Mac Pro by at least $1000. It also makes heat management so much easier..

Fan noise is another one of those things that many people don’t particularly care about. Alienware gaming PCs (and their laptops for that matter) can sound like leaf blowers and many Mac Pros in the past have had annoying fan noise. While fan noise really doesn’t matter all that much on a gaming machine where it gets drowned out by the sound of explosions, it does wear on you when you’re trying to do highly concentrated work. So developers such as myself do care.. as clearly does Jony Ive and Apple and in many ways the wind tunnel design of the new Mac Pro is its stand-out feature.

Many people are asking the obvious question: Why does it matter so much to Apple that it’s Mac Pro is so compact?

Mac Pros have always had handles. Yet they have rarely been moved, being far too heavy to ferry about easily, so we are quick to dismiss the presence of a handle as just a nice design touch. On top of that Apple’s obsession with built-height often takes on ridiculous proportions: A really thin iMac!?. Who cares!?

Yet, this time around I think the handle might be part of the equation. The new Mac Pro is actually portable if not exactly mobile.

I’m not alone amongst Indie developers to share my time between my home office and a co-working space or a dedicated office. Like many developers I’m trying to keep parity between my home and my work setup so that I can get straight on with work, no matter where I’m currently at.

I’m mostly using my retina MacBook Pro right now, but for all the reasons outlined above rather than working on it as a laptop, I plug it right into a dual monitor setup either at home or at the office. The fact that the MacBook Pro has its own screen and keyboard only comes in handy from time to time. Mostly it’s just a portable Mac and prevents me from having to break the bank by buying two powerful machines. The new Mac Pro is small and light enough to be comfortably transported from one place to another in the back of the car and once there it can be plugged into a Thunderbolt display in just the same way that my MacBook Pro can be. On top of that you don’t have to pay for the screen and the keyboard every time you upgrade it.

In other words, the new Mac Pro is pretty much perfect for Mac and iOS developers who want a lightning fast desktop machine, but don’t want to re-buy a screen every time. It’s more portable than an iMac and its air-tunnel design allows it to house much more powerful hardware than would be feasible in an iMac or Mac mini enclosure. On top of that, it may not be quite as expensive as previous models because it houses a single CPU. Whether the dual graphics cards setup really makes sense will only become clear once Apple unveils its first 4K display.

I can’t help thinking that Jony Ive designed this machine more for the participants of WWDC and the extended developer community, than for Apple’s traditional market of creative professionals.

The Mac Pro then won’t make many video editors very happy, but is a great machine for Mac and iOS developers and I suspect that is just as it was planned.

Vitamin-R 2.0 Upgrades & Mac App Store

It’s been almost 3 years since Vitamin-R was first released into the public eye.

Those who experienced version 0.01 beta 1 (!) can testify to how much the product changed between then and the 1.0 release and of course Vitamin-R has never since stood still for more than a few weeks. In total, we have up to this point released no fewer than 109 updates and I think you would agree that it’s now nearly time for the big 2.0 release.

If you own any of our software, you will have noticed that we release features as soon as they’re ready. This helps us create better product as we get feedback earlier and it also gets new features into your hands quicker.

The price we pay for this practice is that we don’t get to do the “big reveal” when the time comes to ask you for an upgrade fee.. but rest assured that we are making an extra special effort to make 2.0 more than just another point update!

Many people hate upgrade fees and we accommodate these people by providing “forever upgrades” both with your initial purchase and at any point after.

While upgrade fees may be a little painful, they are instrumental in ensuring that a product meets the requirements of experienced users. Without them there is little economic incentive to develop a product beyond what is necessary for its immediate appeal. It is no coincidence that most iPhone apps get used only a couple of times before they are forgotten forever.

Without upgrade fees there’s no economic incentive for developers to look past the moment of the sale, leading to software that is optimized for immediate appeal but fails to live up to its promise shortly thereafter. We want none of that. With Vitamin-R we want to introduce you to a more productive and enjoyable way of working and support you at every stage of your journey. In order to do so we want to furnish you with the tools to evolve your own style. This means making Vitamin-R highly customizable and leveraging your usage information to provide you with insights into your own work patterns; neither of which does much to increase the immediate appeal of the product to prospective new clients.

Please note that none of this means that we are intend on making Vitamin-R more complicated. On the contrary, streamlined operation is even more important for experienced than for novice users.

In the past, we have always given customers very generous “grace periods”, meaning that if you bought the product shortly before a major upgrade, we would grant you a free upgrade.

Unfortunately in the changing world of Mac software development this is no longer so easily done.

As you may know the Mac App Store, through which many of copies of Vitamin-R are bought, does not offer any support for paid upgrades. Instead Apple is charging full price for major new versions of its software such as “Pages”, “Numbers”, “Keynote”, “Final Cut Pro”, “Aperture”, etc.

This makes a lot of sense for Apple who operate on the “big reveal” model more than perhaps any other company in history and who of course make money on the software sale, their 30% App Store processing fee and on hardware sales.

This puts software developers like us into an awkward position.

We are masters of our own web stores and can continue to offer discounted upgrade pricing, forever upgrades and “grace periods” and we will.

On the Mac App Store, however, it’s Apple’s rules all the way. There are no discounted upgrades, no grace periods and we do not even know the identities of the people who buy our software.

All third party software developers are facing the same problems. Some decide to go Mac App Store only. Some decide to stay off the Mac App Store altogether. Most, like us are trying to mitigate the problem as much as we can.

We realize that not everybody will be happy with our solution, but what we have decided to do is the following.

To Get A Discounted Upgrade to Vitamin-R From Our Web Site / To Take Advantage of the “Grace Period”

1. Direct and Mac App Store customers alike will be able to buy a discounted upgrade from our web store via

2. Direct customers who have purchased Vitamin-R after the 1st of January 2013 will be able to obtain a free upgrade code to version 2 from

3. Mac App Store customers who have bought Vitamin-R after the 1st of January 2013 will be able to obtain a free upgrade by mailing their iTunes Store receipt to

This is much the same retrofitted solution that OmniGroup are going to apply to OmniFocus 2 upgrades.

Vitamin-R on the Mac App Store

As many of you know, Apple has decreed that all new Mac App Store submissions must comply with their new requirement for using the Mac OS X Lion “Sandbox”.

This is a security mechanism that restricts what applications can do. By default applications can do almost nothing other than bring up a window and respond to mouse clicks; there’s no access to your files, the internet, etc. This limits the damage that a crashing or virus-infected application can do. If the application, for instance, cannot access the internet or the file system, it can’t steal your data and it can’t transfer it anywhere.

It is then up to the developer to define which “entitlements” their application requires (e.g. I need access to user files, I need to be able to open a web browser on the product homepage, etc.) and up to Apple to grant or reject such entitlements. Obviously the fewer entitlements Apple grants the higher the security.

This is how iPhone and iPad apps have always worked: can’t do much, Apple decides what they can do.

It’s also the exact opposite of how Mac or PC or any other applications have traditionally worked. Mac applications by default have access to everything on your machine and the internet. The only restrictions are based on the file system permissions, so you can’t look at or change the files of another user unless you are a system administrator.

In principle, sandboxing does increase security and that is a good thing.

Unfortunately in practice, Apple have made a dog’s breakfast of both the technical implementation and the policies around the sandboxing.

While it is possible to define “entitlements” to cover almost every aspect of what an application could possibly want to do, Apple have not allowed third party developers access to these entitlements. For many things there are no “third party accessible” entitlements and for many other things, Apple is unlikely to grant those entitlements anyway. The mechanisms that are available do not allow for all existing features of existing applications to be preserved when that application is sandboxed.

I have spent considerable time adopting the Lion sandbox for the Mac App Store versions of my products, as I want to continue to update them in order to bring you the latest (and hopefully greatest) features.

Vitamin-R is the first of these sandboxed versions that I have submitted and now after two rejections it seems that it will finally be accepted.

In order to comply with the Sandboxing rules and Apple’s rejection of my request for several entitlements, the following features had to be removed:

  • Support for the Neurosky Mindwave headset was removed
  • The ability to quit applications in the “eliminate distractions” screen was removed.
  • The ability to automatically close Finder windows in the “eliminate distractions” screen was removed
  • Growl support was removed

Other changes include:

  • If you use the Dropbox integration on Mac OS X 10.7.0, 10.7.1 and 10.7.2, you will be prompted to locate your dropbox folder every time you launch the application. (Upgrading to the latest Mac OS X Lion version will fix this).
  • The download now includes the Noise Machine soundscapes files and is therefore much larger
  • Many other minor and hopefully invisible changes

I understand that many of you will be upset to lose these features and all I can say is that “it wasn’t my idea”.

When I mentioned that these features had to be removed because of the sandbox requirement in the “What’s new” section of the Vitamin-R Mac App Store page, my “meta-data” was promptly rejected and I was asked to remove any mention of Apple policies.

In other words, I’m not allowed to use Apple’s Mac App Store to inform Mac App Store customers of what is going on, because that would make Apple look bad. Apple prefers its customers to be mad at me for complying with their rules rather than to put up their hand and say “it was us and we’re not sorry because we think we are right”.

Well, I’m gutted about the whole thing.

If accepted in its current form, Vitamin-R will have survived its migration to the sandbox relatively intact. Many of the features that had to be cut were minor and won’t be missed too much by most users.

In any event, if you have bought Vitamin-R on the Mac App Store and you are missing a feature you need, please just contact us at and we’ll issue you with an unlock code for the “full” version.

Please don’t vent on the Mac App Store because this penalizes developers for something that they have absolutely no choice about. It also does not allow developers to respond to criticism as they cannot post replies and do not have any idea of who you are and how to contact you to resolve the problem.

Unfortunately, the new Mac App Store sandbox requirement means that henceforward there will be two versions of most Mac applications: a sandboxed one that misses features and a full one that is only available directly from the developer. You can basically choose between greater convenience and greater freedom. Usually it is convenience that wins out.