Badminton Shuttlecock Spin & Aerodynamics

As well as being a Mac and iOS developer, I’m a keen Badminton player and have started playing again after a 10 year absence.

As a former academic researcher, one thing that has always intrigued me about badminton is just how the badminton shuttlecock actually behaves when in flight and especially precisely how it reacts to spin.

As in many other racquet sports, players regularly slice shots, but because of the unique shape of the shuttlecock and its sharp deceleration it behaves very differently to a ball.

The aerodynamics of Tennis or Table Tennis balls are well understood and have been studied extensively, but the same is not true of the Badminton shuttlecock, which is surprising given that it is the most popular racquet sport in the wold by far (a fact that is not easily understood in the Western World where Badminton is still fairly niche).

In 2006, I asked this question on a badminton forum and was shocked to find that even people who were directly involved in designing shuttlecocks did not seem to have a really good understanding of what is actually happening when you slice a shuttle cock. 10 years on there have been some aerodynamic wind tunnel studies and I’ll summarize what I’ve found:

Firstly, the aerodynamics of actual feather shuttle cocks and synthetic ones are very different and advanced players will use only feature shuttle cocks, so we won’t go into the details of the synthetic ones.

All feather shuttle cocks are constructed so that they have a natural counterclockwise spin as seen by the hitter when the shuttle cock is moving away from him/ her. This is due to the overlapping of the feathers, which creates an asymmetrical shape. This “natural” spin stabilizes the shuttle cock while it flies and is caused by the air passing over the feathers. This spin across the central axis of the shuttle cock gets faster as shuttle cock travels faster. When the shuttle cock slows down, so does the spinning and it becomes less stable.

So far, this “natural” spin is present simply through the shuttle cock construction and is not due to player intervention. You can observe this spin by dropping the shuttle cock from a raised platform, e.g. a balcony.

As far as understand it, until a certain speed is reached the spin of the shuttle cock has little effect on its drag coefficient but simply stabilizes the shuttle cock much like a spinning top. Once the spinning goes over a threshold, however, the centrifugal force that it exerts on the shuttle cock pushes the “skirt” outwards thus increasing drag and leading to a significantly faster deceleration of the shuttle cock. I’m not sure from the studies I’ve seen whether this is due to the feathers themselves bending or only the strings that keep them together “giving” a little.

When a right handed player slices the shuttle cock in the “normal” left to right direction (clockwise), this will add to the “natural” counterclockwise rotation of the shuttle as it inverses its path. This rotation will thus be faster than it would be at the same speed without the slicing action.

Under some circumstances, the slicing action will thus cause the shuttle to decelerate more sharply due to the skirt deformation increasing its drag and the shuttle will then fall shorter. If I understand correctly, this will only be the case if the shuttle rotates quickly enough to cause this skirt deformation. If the counterclockwise spin is increased but still remains under the skirt deformation threshold, the shuttle should simply travel in a more stable trajectory. Whether this stability increase is significant or not, I don’t know and can’t find any research on.

It is clear though that applying spin to the shuttle cock through the racquet slicing action will have a significant influence  on the trajectory of the shuttle cock when shuttle is hit at great speed. The skirt will then deform and increase drag, resulting in a shorter distance travelled.

When applied to a flat drive or to an attacking clear, the slicing action will allow the player to hit the shuttle much harder while still being able to keep it inside of the court where a straight shot leaving the racquet at the same speed would go long.

In this scenario, the shuttle will travel faster on average and thus overall until it comes to a stop and drops straight down towards the floor. The slowing effect will be the strongest initially and cut off altogether at some stage during its flight path when the natural spin rate will reimpose itself due to the construction of the shuttle cock. So the later part of the shuttle’s flight path will be identical between the sliced and straight shot. The increased deceleration effect will cut off when the rotational forces become too small to result in skirt deformation.

The difference in speed thus stems entirely from the higher initial speed of the shuttle cock.

Some people believe that the rotation of the shuttle cock itself could provide a propeller-like speed increase, but this is not true. The rotation only influences its drag coefficient but does not provide forward or backwards momentum.

In ball sports, top spin and slice work by creating pressure differentials around the ball. It looks like the “gap” between the base (cork) of the shuttle cock and the skirt (feathers) produces a pressure differential that is crucial to generating the strong deceleration of the shuttle cock, but I haven’t seen any evidence that pressure differentials are influenced by the axial rotation of the shuttle cock.

So “normally” sliced shuttles decelerate quicker than when hit “straight” and they might move somewhat more stably, but what happens when a “reverse slice” is applied through the racquet head moving right-to-left over the shuttle?

Well, I haven’t been able to find any research on this at all. In forum discussions some people claim that there is no difference, but this is obviously false because shuttle cocks are constructed with a “natural” anti-clockwise rotation and the “reverse slice” will apply a clockwise rotation.

There also certainly seems to be a difference when you actually reverse slice a shuttle cock in normal play, but everything happens so fast that it is impossible to observe exactly what is happening. I use reverse slice almost exclusively for left rear court cross court drop shots, particularly because of the deceptive element of the racquet moving in the opposite direction to the actual shot. I also feel that reverse slicing the shuttle on deep net pushes (such as when taking serves in doubles) makes it less likely to go out.

Interestingly, left handed players slice the shuttle in the opposite direction, meaning their “straight slices” are in fact “reverse slices” (imparting clockwise rotation) and their “reverse slices” are “straight slices” (imparting counterclockwise rotation). When you watch Lin Dan play for instance, his shuttles certainly seem to be taking a different trajectory from that of most other players and perhaps this is one explanation for this.

Unfortunately, there seems to be no firm evidence on this at all, so the remainder is mostly speculation, some of it inspired by forum posts.

It would seem logical that making the shuttle spin in the opposite direction to its natural spin would cause it to move less stably. At high speeds, the effect would likely be insignificant, but at lower speeds there should be more tumbling.

It would also be logical that the “natural” spin imposed by shuttle construction and air resistance would counteract the “reverse” spin and might (and probably would) cause the rotation of the shuttle to move from clockwise to counterclockwise at some stage along its trajectory.

We would thus be left with a high degree of drag as the shuttle leaves the racket, followed by a drop in drag as the centrifugal forces become too small to cause the skirt to deform, followed by a stop of the clockwise rotation and finally a re-establishment of the natural counterclockwise rotation of the shuttle. Only at the beginning of the shot could the centrifugal forces be great enough to decelerate the shuttle quicker than for a straight shots.

The big unknown in all of this is whether the amount of skirt deformation is the same for clockwise or counterclockwise rotation. If it is the same, then a straight sliced shot will decelerate for longer and thus always fall shorter. If it is greater, it depends on how much greater it is. If it is a lot greater, this would compensate for the shorter amount of time that it is effective and the shuttle would fall shorter.

As far as I can see, there have been no studies on this, but just looking at the shuttle cock construction, it certainly seems possible that the clockwise rotation against the “grain” of the features would significantly impact the airflow around them and create turbulence. This will definitely cause it to stop spinning clockwise rapidly, but whether it increases or reduces drag and by how much I wouldn’t want to hazard a guess at.

Of course, whether you want to play a shot straight, sliced or reverse sliced depends on more than just the flight characteristics that it imparts. Body mechanics make it much easier to “straight slice” than to “reverse slice” for almost all shots. “Reverse slicing” may still be justified because it can be deceptive both in terms of racquet swing and flight path.

For maximum power, slicing smashes is probably not a good idea as it will make the shot slower. For check smashes or half-smashes using “straight slicing” is probably most effective, but “reverse slicing” may have a different flight path and deceleration characteristics which might inconvenience opponents.

Attacking clears can be heavily sliced so that they can get to the back faster because more initial speed can be imparted. Reverse slicing a clear is probably not a good idea as it reduces the amount of power that can be put into the shuttle as it presents inferior body mechanics.

The situation is less clear for drop shots, where both approaches seem to make sense. The reverse slicing action is more deceptive than the straight slicing action and deception is very important for drop shots. Slicing the drop shot will allow it to be played faster than if played straight, so drop shots should generally be sliced.

The body mechanics of the forehand cross court drop shot would make it hard to use reverse slice and just hitting the shuttle with a straight swing but angled racquet head provides a great way of playing “straight” sliced cross-court drop shots and thus seems the only way to go.

Similarly, playing a left-of-the-head cross-court drop shot with a straight slice would be very hard to do and the reverse slice is much easier to execute and more deceptive and thus the obvious choice.

When it comes to straight drops, things are rather more finely balanced. As we suspect that the straight slice is more effective at slowing down the shuttle, you can probably produce a more effective shot using this technique and its advantage will increase with the speed. So the closer we are getting a half-smash the more we should prefer the straight slice. At lower velocities, however, it is not clear whether the any slice actually decelerates the shuttle at all; it might only make it more stable.

The reverse slice at lower speeds probably makes the shuttle less stable in the middle of its flight path as the “natural” spin reimposes itself and the shuttle briefly tumbles. This might be an advantage as the shuttle will travel under perfect control while it still rotates clockwise, letting you place it precisely. Then if the timing is right, it will start becoming unstable after it crosses the net and thus inconvenience your opponent.

Clearly, the reverse slice motion, while harder to perform, is also much more deceptive. So slow drop shots should probably be executed using the reverse slice.

On the forehand side, fast mid-court drives have a high risk of going long, but body mechanics make it practical to hit them with both forms of slice. On the backhand side, it is hard to see how one would be able to play a hard reverse sliced drive and few players will have enough strength to have to worry about sending the shuttle out anyway. So we only really have a choice on the forehand side, but there seems to be no advantage to trying to execute the harder reverse slice.

In summary then, sliced shots definitely decelerate faster in the beginning of their trajectory and thus fall shorter than straight shots. Reverse sliced shots definitely decelerate faster than straight shots, but probably decelerate both differently and probably less so than straight sliced shots. Even straight shots cause the shuttle to spin counterclockwise at high speeds.

Any insights or corrections would be very much welcome, as I’m keen to understand this whole area better. Any pointers to relevant research or articles would also be much appreciated.

Tools of the Trade: AppCode, a breath of fresh air from the Xcode monoculture.

If you are a Mac or iOS developer for better or for worse there is no way around Xcode.

Xcode is free and full-featured, so why would you ever want to use anything else? This is the main reason why there are practically no other Mac OS X or iOS developer tools on the market today. There just isn’t any room for third parties for it to make economic sense to develop expensive developer tools.

The only other serious IDE for Mac OS X and iOS development is JetBrain’s AppCode and I’d recommend that every serious Apple developer should own a copy. While Xcode has evolved into a powerful and mostly stable tool, Apple has a lot of blindspots and Xcode is in many areas (at least) 15 years behind the top of crop. AppCode isn’t.

JetBrains is the powerhouse of Java development tools and they represent everything that Apple does not. Where Apple is closed, secretive and has a very paternalistic approach to its developer community, JetBrains is open, transparent, friendly and as cross-platform as it is possible to be.

The advantages for an Apple developer such as myself is that you get a peak at the world beyond Apple’s strictly enforced white room monoculture. Using AppCode is as much about growing as a developer as it is about efficiently developing software.

JetBrains offers IDEs that support nearly every language that is available and the more outrageously new and niche a language is, the more likely that JetBrains has a tool for it. This means that once you get used to the basic IDE concepts, you can take that expertise and use it for developing in other languages, on other platforms (Android, Windows, Web) and with other technology stacks.

I use WebStorm for my own website development, RubyMine for web app stuff and IntelliJ IDEA for learning functional programming in Scala. If I ever wanted to learn CoffeeScript, Dart or Haskell I know I’d be covered there too. On top of this JetBrains’ plug-in technology makes adding support for the latest and greatest open source technologies a breeze and JetBrains are very good at keeping an eye open for exiting new technologies. There’s a good chance that the first you hear about a new technology is by looking at JetBrains’ product release notes.

The AppCode IDE itself is very much in the mold of other Java development environments. The IDE can do everything and more, but it is also very busy and a long way from the pared-down minimalistic Apple aesthetic. It’s a nerdy power tool more than a philosophical statement.

JetBrains is rightly famous for their language parsing and refactoring acumen, so their IDEs are chock full of “intelligent” features. Not the kind of “intelligent” that makes everything harder, but the actual intelligent kind.

Navigating in AppCode is much more powerful than in Xcode. The gutter contains a myriad of options that will take you from method implementation to declarations and vice versa. You can also click and hold from class definitions to jump to super- and sub-classes, get in-line help and auto-fixing for commons problems. The as-you-type code analyzer finds potential problems and standard fixes, the code reformatting options are powerful and easily accessible. The intelligence extends to seamlessly into finding all places a piece of code is actually used rather than having to rely on text searches.

Best of all, however, AppCode can make changes to associated files without leaving the current file. The annoying roundtrip between implementation and header files that keeps interrupting your train of thought in Xcode can be wholly avoided. You write the implementation for a method and AppCode just offers you the ability to declare said method in the header with a single click without ever taking your eyes of the code you are busy writing.

Working in AppCode you constantly find yourself wondering why Apple can’t just do this. If it seems obvious, it’s in AppCode. Unfortunately this is rarely true for Xcode.

Refactoring is part and parcel of the AppCode experience and backed so far into the IDE that it becomes a nearly invisible part of your development. If you are used to refactoring in Xcode, you are likely to be non-plussed by AppCode’s refactoring support. Where Xcode makes a huge deal out of every refactoring: taking a snapshot, making you validate a thousand changes and more likely than not failing bang in the middle of the refactoring, AppCode just makes the changes with no fuss whatsoever. The first time I used the renaming refactoring in AppCode, I was wondering what I was doing wrong. I typed the new name into the red highlighted area and nothing happened! How do you terminate the editing? In fact, AppCode had already done the project-wide refactoring. Why make a fuss about it? Why could it fail? Why beach-ball for a few seconds? Why indeed?

AppCode enables you to work in a completely different manner to Xcode. Say you are into Test-Driven Development. Write the test cases first. When you instantiate your target class in the test class, AppCode will tell you that the class does not yet exist. A single click solves the problem by creating the class for you. As you write your tests, you can one-click to add method declarations and empty implementations. When you’ve finished with your test cases, there’ll be .m and .h files with complete stub implementations all without you ever leaving the test case implementation file.

Another big differences with Xcode is that where Apple knows everything best and either offers no customization or forces you to comply with their guidelines, JetBrains puts you in charge. Almost every aspect of the IDE is fully customizable: you can define your own coding style, which will cause AppCode to use your specific style to create stubs. You can even decide to reformat your code automatically before checking it into source control. You can (obviously) choose your own source code management system, add CocoaPods support, edit and preview HTML, CSS, Compass, TypeScript, JavaScript, files or add your own selection of plug-ins. In short, JetBrains is for grown-ups that like taking their own decisions.

Similarly, if you’ve ever felt the frustration of never being able to talk to anybody at Apple about Xcode, you will find the JetBrains support team a breath of fresh air. Something not working? Something not supported? Something you’d like to see added? Just drop them a line and an actual person will reply to you; better yet that person will be an approachable, open-minded fellow developer intent on helping you out. With JetBrains you’re the customer and you know best.

Seriously, just give it a shot. If only for a breath of fresh air.

The unbearable fragility of modern Mac OS X development

There I’ve done it again: I shipped a broken A Better Finder Rename release despite doubling down on build system verification, code signing requirements validation and gatekeeper acceptance checks, automation, quality assurance measures, etc.

Only in October, I had a similar issue. Luckily that time around it only took a few minutes to become aware of the problem and a few hours to ship a fix so very few users were affected. Right now I don’t know how many users were affected by the “botched” A Better Finder Rename 10.01 release.

This didn’t use to happen. Despite the fact that I did not spend nearly as much time ensuring that everything worked properly with the release management. Nor am I alone in this situation. Lots of big as well as small developers have recently shipped similarly compromised releases.

The situation on the Mac App Store is much, much worse. Nobody other than Apple knows how many Mac App Store customers were affected by the recent MAS certificate fiasco that had the distinction of making it all the way into the pages of Fortune magazine.

The truth is that Mac OS X development has become so very fragile.

The reasons for this are manifold and diverse but boil down to: too much changetoo little communicationtoo much complexity and finally too little change management and quality control at Apple.

The recent Mac App Store (MAS) fiasco that left many (1% of Mac App Store users? 100%? Nobody knows) users unable to use their apps purchased from the Mac App Store was down to Apple’s root certificate expiring. This was a planned event: certificates are used for digitally signing applications and they are only valid for a particular period of time, after which they need to be replaced with new certificates.

When the Mac App Store certificate expired, it was replaced with a new certificate but there were two problems. First, the now expired certificate was still cached by some of Apple’s servers: when Mac OS X opens an application it checks its signature, which in the end is guaranteed by Apple’s root certificate. Since this was no longer valid, Mac OS X refused to launch them and reported them as “broken”, leaving users and developers equally baffled. After far too long, Apple investigated the problem and emptied their caches which made the problem go away.

The second problem which was not solved by updating the caches, was due to Apple also replacing the certificate with a new, higher security version; of course without telling anybody. The new certificate could not be verified with the old version of OpenSSL that was used in the receipt checking code of many shipping apps.

When Apple created the Mac App Store, it provided a “receipt” that each application should check to see whether it has been properly bought on the Mac App Store. This is just a signed file that contains details about what was bought and when. Instead of doing the obvious thing, which would have been to provide developers with an API for checking the validity of the receipt against Apple’s own rules, they just publishing snippets of sample code so that each developer could “roll their own” verification code. Supposedly this was for added security (by not providing a single point of failure), but it seems more likely that they couldn’t be bothered to ship an API just for the Mac App Store.

This decision came back to haunt them, because most developers are not crypto experts and so had to rely on developer contributed code to check their app’s receipts. Once this worked properly, most developers wouldn’t dream of touching the code again.. which is how it came to pass that many, quite possibly a majority, of Mac App Store apps shipped with the same old receipt checking code in 2015 that they originally shipped with in 2010(?). This was fixed by Apple revoking the new style certificate and downgrading it to the old standard.

For once, I had been ahead of the curve and had recently updated all the receipt code in my applications (no small feat) and I have yet to hear from any customers who had problems.

Just before the Mac App Store fiasco, however, many non-MAS had also shipped with broken auto-update functionality.

Apple does not offer any auto-update facility for applications that are not on the Mac App Store, which lead to Andy Matuschak’s “Sparkle” framework becoming the de-facto standard for adding an auto-update features to Mac applications.

Driven by abuse of some HTTP communications in iOS apps, Apple decided that in iOS 9 it would by default opt all developers into using only (more secure) HTTPS connections within their applications. What is good for iOS 9 can’t be bad for Mac OS X 10.11 El Capitan, so Mac applications also got opted into this scheme.

Unfortunately, that broke Sparkle for applications which do not point to HTTPS “app casts” such as mine. I have long resisted installing my own HTTPS certificates because I was worried about messing up the expiry periods, etc.. apparently just the way that Apple did with the Mac App Store certificates.

Most developers will have been unaware of the change since Apple never announced it, but I had happened to see the WWDC conference videos that mentioned this in passing. Unfortunately, nothing “clicked” in my head when I heard this. My applications do not communicate with a server anywhere and I thus thought that this was not something I had to worry about. I had forgotten that Sparkle might use this internally.

Fortunately, I caught this at 6AM when I released A Better Finder Rename 10 final. I was just doing a normally completely redundant check through all the features of the program when I noticed that the new version failed when trying to check for updates. By 8AM, I had identified and fixed the problem so that very few people indeed could have been caught out by it. That was luck though.

The nefarious element here was that applications were opted in automatically and silently. Before 10.11 El Capitan was installed on your Mac, my applications updated just fine. Afterwards, they no longer did. Just because they were on El Capitan. Gee thanks!

Of course, this would not have happened if I hadn’t built A Better Finder Rename 10 with the Mac OS X 10.11 SDK (Software Development Kit) at the last moment.

It is somewhat crazy for a developer to change the SDK that s/he builds a brand-new version of their software against in the middle of the beta phase. Changing the SDK always introduces errors because the entire environment in which the code executes is changed. This may bring out bugs that were already present; things that should never have worked, but worked just because the API happened not to trigger the bug. It also introduces bugs that are just part of the new SDK and that you now have to work around. Changing SDKs makes existing programs fragile.

I’m very conservative when it comes to changing SDKs because I’m well aware of the risks. That’s why I’ve been building my code against older SDKs for the past 15 years. A Better Finder Rename 10 was built against the Mac OS X 10.7 SDK which is forwards-compatible with newer versions of Mac OS X.

The main reason for doing so, is that I wanted to be certain that I didn’t accidentally break A Better Finder Rename on older systems, which brings us to the next problem with Mac OS X development.

Xcode lets you specify a “deployment target”, for instance 10.7, while building with a newer SDK. This is the recommended way of developing on Mac OS X and keeping backwards compatibility. Xcode will, however, happily let you use APIs that are not compatible with your deployment target and thereby ensure that your application will crash on anything other than the latest Mac OS X.

In fact, Xcode encourages you to use the latest features that are not backwards compatible and will rewrite your code for you if you let it, so that it will crash. It will give you “deprecation warnings” for any API usage that is not in the latest SDK and resolving those warnings is likely to break backwards compatibly as well. Of course, you won’t know this until you run it on the old Mac OS X version.

Now which developer can afford to keep testing rigs with 10.7, 10.8, 10.9 and 10.10? Never mind spend the time re-testing every change on multiple platforms for each change?

Thus I happily built with the 10.7 SDK. Apple did not make this easy by not shipping the old SDKs with Xcode, but you could manually install them and they would work just fine.

Imagine my surprise after installing Xcode 7 and finding out that this no longer worked. The only workable solution was to build against the 10.11 SDK, so jumping forwards not one but 4 SDK versions. A bunch of code wouldn’t compile any longer because the libraries were gone. Luckily the receipt checking code was amongst those, so it got modernised just in time to avoid the Mac App Store receipt fiasco.

Nonetheless, now my entire code base had become fragile and largely un-tested between the last beta release and the final shipping product. Nightmare!

On top of that was it still even 10.7 compatible? or indeed 10.10 compatible? Just quickly running it on older systems wouldn’t provide more than a little additional confidence since it’s impossible to go through every code path of a complex product.

After installing virtual machines to test on, I still couldn’t be 100% certain. The solution came in the form of deploymate, a now truly essential developer tool which does what Xcode can’t do: check that API usage is compatible with the deployment target.

I have since spent many weeks trying to ensure that I won’t run into the same problems again by adding (additional) automated verification processes to my build system. My build system now runs the built product through SDK compatibility checking courtesy of deploymate, code signing validation and gatekeeper verifications on each build. I’m still working though deprecation warnings and the like and my code base will soon be bullet proofed at least until the next forced changes arrive.

You’d think that this was a long enough list of problems for one year, but this still does not account for Apple also changing the code signing rules (once again) earlier in the year (in a point update of 10.10 no less). This time it affected how resources and frameworks are signed. So applications that were signed correctly for years, now suddenly became incorrectly signed and Mac OS X would refuse to launch them because they were “broken”.

All this points to the underlying issues with the current spade of fragility of Mac applications: Apple keeps changing the status quo and neither it, nor developers have any chance of keeping up.

Apple’s own applications are full of bugs now. None more so than Xcode, which is both the lynch pin of all Mac OS X, iOS, watchOS and tvOS development and no doubt Apple most fragile app offering. Xcode is in beta at least 6 months a year and never really stabilises in between. Each new version has new “improvements” to code signing, app store uploading, verification code, etc.. and each new version breaks existing code and introduces its very own new bugs and crashes. From one day to the next, you don’t know as a developer whether your code works or not. Existing code that had worked fine on Friday evening, no longer works on Monday morning. Worse, chances are that you are not hunting for your own bugs, but those in your development tools, the operating system or Apple supplied SDKs.

All this is driven by the one-release-a-year schedule that Apple has imposed on itself. This leaves all of Apple’s software in various stages of brokenness. When Apple’s own staff cannot deal with this constantly shifting environment, how are third party developers supposed to?

Case in point: Apple’s own apps are not all iOS 9 compatible yet. Many don’t support the iPad Pro’s new native resolution yet. Some have gained Apple Watch extensions, but most haven’t.

Reliability is a property of a system that is changed slowly and deliberately and where all constitute parts are themselves reliable. The Mac and all other Apple platforms are currently undergoing the worst dip in reliability since Mac OS X was introduced.

Apple is pushing out half-baked annual releases of all its software products, as well as apparently completely unmanaged changes to policies, external rules and cloud services at an ever more frenetic pace.

These could be written off as temporary “growing pains”, but the big question is: Do all these annual updates equate to real progress?

When I switch on my Mac today, I use it for much the same things that I used it for 10 years ago. A lot has changed. Cumulatively Mac OS X 10.11 El Capitan is somewhat better than 10.6 Snow Leopard.. and yet if you discount cosmetic changes and new hardware, nothing much has changed. Certainly nothing much has actually improved.

I can’t help thinking that if we had had 2 or possibly 3 Mac OS X updates instead of 5 over those last 5 years, we’d be in a much better shape now. Apple and developers would have time to provide user benefits and rock solid reliability rather than just endlessly chasing their own tail.

The beauty of the Mac used to be that it just worked. I want to get back to that.

A Better Finder Rename 10 beta auto-update broken on 10.11 El Capitan

We are sorry to report that the auto-update feature on beta releases of A Better Finder Rename 10 is broken on Mac OS X 10.11 El Capitan and you will need to download the update to version 10 (out yesterday) directly from our website.

We  noticed this early at 6AM yesterday while checking the A Better Finder Rename 10.00 release and shipped a fixed version at 9AM (after struggling through work traffic) both GMT+1.

We have over time evolved a build process that guarantees that we only ship high-quality product builds, but we were caught out his time by the rapid pace of change imposed by Apple’s frequent Mac OS X and Xcode updates.

In the past, Apple was quite good about letting developers upgrade their development environments at their own pace, which is important because Mac users do not expect to always have to upgrade their Macs as soon as a new Mac OS X release is dropped. More recently, Apple has transferred a lot of its iOS practises to Mac OS X and have started really pushing developers to adopt features quickly and to get rid of backwards compatibility quickly.

At first this took the form of a gentle prodding, but over time it has become much more aggressive. Essentially they are deliberatley making it hard for developers not to drop support for older OS X versions.

We were caught out in this and still are. We had to install 10.11 on our development machines in order to test on El Capitan properly (the remote debugger has been discontinued for a while now), which lead to an auto-update of Xcode 7.

We had for the past decade built our products using the latest Xcode but using the oldest compatible SDK (in this case 10.7), because this ensures that the builds do not break backwards compatibility for customers on older OS X releases.

We were caught by the fact that Xcode 7 quietly drops the ability to work with older SDKs. Unfortunately building to the 10.11 SDK opts the program into a new rule that the program can only read HTTPS streams for security reasons. This was mentioned at WWDC for iOS applications but OS X hardly gets a mention in those talks. In any event, we did not think that this would affect A Better Finder Rename as we have no server backend, but as it happens, it breaks Sparkle auto-updates, which power our product’s (and 99% of non-Mac App Store applications’) auto-update feature. Note that our auto-updates are securely signed even thought they do not use https.
As a result the auto-update feature works fine as long as you are not on 10.11, but no longer works on 10.11. We only found this out when we shipped the first update since users have started installing 10.11, resulting in a minor but real mess where A Better Finder Rename beta cannot auto-update.
Sorry for the inconvenience.

Tools of the trade: Monitor Arms

Ergotron LXSitting in front of a computer display all day long does not do wonders for your health.

Things are made considerably worse if that computer display is of the notebook kind. Laptops in general are ergonomic nightmares putting your body into all the wrong positions. First, you need to look down all day long, then to make matters worse, the keyboard is attached directly to the screen forcing you to find the least bad compromise between positioning your arms and hands correctly and getting the screen into a semi-comfortable viewing position. Unfortunately no good compromise exists and you will over time do both your upper extremities and your neck/ back/ shoulders in. If it feels a little uncomfortable now, trust me, it’ll hurt a few years down the line.

Desktop computers are much better in that regard, allowing you to independently adjust keyboard, mouse and display. Unless you are using an iMac of course. Its aesthetics-over-function design has led everybody’s favourite industrial designer, Johnny Ive, to give it a stand that is far too low to allow you to view it comfortably. Such a shame because his Luxor Junior-inspired second generation iMac featured what must surely have been the best built-in monitor arm ever.. Oh Johnny..

When it comes to ergonomic Macs then, it’s a choice between the Mac Pro (my choice), the Mac mini (also my choice) or the newish VESA-mounted (stand-less) iMac.

On this type of setup you can not only choose your own (non-glossy if you want it to be easy on your eyes) display(s), but also adjust its height, distance from your eyes and inclination to your heart’s content.

The “ideal” viewing position is usually said to be at least 30cm (circa 12 inches) from your eyes, with the top-most row of pixels level with your eyes. A very slight forward tilt to the monitor is also said to be beneficial.

I find that advice to be fairly close to what I find comfortable myself, even though it’s better still to slightly raise and lower the display every now and then.

Monitor arms allow you to reach this position very easily and make adjusting it much less painful, though even the best monitor arms are not quite as good as the one on that second generation iMac. Monitor arms also free up space under the monitor and make for a much tidier setup over all.

I personally own several Ergotron LX Desk Mount Tall Pole mounts and they are great. They can be fixed directly through a screw onto your desk and once installed are much steadier than their admittedly much cheaper counterparts. They are sturdy and easily set up correctly and can be adjusted within a very large range of distances and heights. Moreover they work great in multi-display setups.

I’m fairly tall (6 feet 4) and I find that having the display slightly higher than is usually recommended is most comfortable for me. Most monitor arms do not stretch high enough for me and the Ergotron LX’s tall pole to which the arm itself is attached allows for raising the displays as high, and indeed higher than is comfortable. Anyway it’s better to have more range of adjustment than you need than to have just that little bit too little.

I also use a sit/ stand desk in my home office and unfortunately even the tall pole version of the LX, does not go high enough to cope with the standing position.

In theory, you shouldn’t have to adjust the height of the screen at all when your desk goes into the standing position. When you are sitting at your desk, you are holding your upper body completely straight just as if you were standing! Or at least that’s what the theory says.

In practice, my merely-human body isn’t candle straight at all times but likes to move around, lean forward, then back, etc. When I stand up I find that the screen is too low for comfort and it needs adjusting upwards. The Ergotron LX Sit/Stand Monitor Arm gives you jumbo-sized adjustability and takes even heavy weight monitors. I originally got those for my twin 30″ Apple cinema displays that showed their age through their ludicrous weight. One of them now has my Dell UP3214Q 4K display monitor on it, while the other supports a Dell UP2713HM; both awesome displays in different price ranges and weight categories.

Designed to be used to easily lift a monitor from a sitting to a comfortable standing position without the desk itself moving, the sit/stand version of the Ergotron easily deals with the comparatively small task of lifting the monitors that extra bit higher. The sit/stand version is clearly overkill but in a good way. It’s much more stable and paradoxically moves much more easily with even heavy loads. Not cheap but highly recommended, even in combination with a sit/stand desk.

Monitor arms seem like an indulgence to most people, but the cost of an ergonomic setup is dwarfed by the cost of wasted productivity and the inevitable medical bills that accumulate after a decade or two of full time screen-based work. For a home-based full-time IT professional like myself there really should be no hesitation in splurging out on a proper setup.



iPad Pro: A professional tablet with a phone operating system and an everything for $1 store?

Steve Jobs never understood “business“. Don’t get me wrong: he did understood how to make money. He did understand how to run a company (kind of). Most of all he very much understood consumers.. but he never understood organisations; least of all how to sell to them. I’m not sure I cared then or now.

The iPad Pro brings us a decent stylus, something that was anathema to Jobs, but in many other ways Tim Cook’s Apple seems little different from Jobs’ Apple when it comes to understanding the “Pro” crowd.

The stylus (sorry “Apple Pencil”) is a great step in the right direction for both Apple and for the iPad.  It shows that Apple is capable of listening to reason and putting out-dated home-brew memes behind itself. It is a long due improvement for iPad users in the creative fields, as well as for people who like taking hand-written notes or just like doodling; I’ve gone through a host of really crappy slightly-better-than-meat-pencils accessories and I’ve been lusting after a Wacom Cintiq Companion for ages. I even own a Microsoft Surface Pro 3 and a Live Scribe Sky Wifi Pen, so I’m clearly desperate.

It’s a few years late because Steve carefully crafted the meme that styluses are bad at everything just to rubbish Microsoft’s earlier attempts at creating tablets. I doubt he even really believed it himself, but it did make a great one-liner and for years Apple devotees could finish every conversation about styluses with a superior “you have no taste”.. unless they themselves owned a bunch of rubbish styluses just like me..

The new iPad Pro keyboard is a pure Microsoft Surface rip-off even though they changed the hinge to make it much less practical. Quite probably this was done to make it a little different from the Surface’s and quite definitely because Johnny Ive had a stroke when somebody suggested putting a stand at the back of his iPad.

What’s a real shame is that they didn’t put 3D Touch on the iPad Pro. A standardized right-click tap would have made the iPad much more productive than the tap-and-hold right-click. Once again Apple deliberately makes a product worse than it has to be, just so that they can upgrade all the iPads to 3D Touch in its next iteration. It’s not a winning strategy unless you can afford it.

Another omission is that of a trackpad on the keyboard. You’ll probably say “just tap the screen dummy!“, but once you’ve used a Microsoft Surface you realise that having a trackpad on the keyboard is essential. It makes “mousing” around the screen much more efficient (because of the up-scaling of the motion), avoids awkward reaching motions and plain “puts you in command”.

None of this really matters though. The iPad Pro won’t take business users by storm anyway. It’s not going to be a complete dud, but it’s not going to make the iPad into a serious productivity tool either.

The reasons for this are (almost) too many to mention. The two that are going to kill it are the App Store ecosystem and the operating system, but there are plenty more besides.

iOS is a smartphone operating system designed for quick, simple, casual interactions on a small touch screen. It’s been conceived for the iPhone form factor. It has been scaled up to the iPad, but the iPad was and remains a big phone without the phone features. iOS never really embraced the larger screen. In recent years Apple has almost completely ignored the iPad in its iOS revisions. iOS 7 pretty much forgot about it altogether. On the rare occasions that Apple does bother to demo iPads at all, it’s always to showcase some game or other.

iOS is rubbish at supporting keyboards. Yet the keyboard is a crucial part of what makes people productive on a Mac or a PC for that matter. Any experienced computer user knows how to zip around the screen using a combination of the arrow, tab and escape keys and keyboard shortcuts. Command-C and Command-V sound familiar? In many respects, Windows is still much superior to even Mac OS X when it comes to keyboard navigation. You can get quickly into any menu and select any option, whereas on the Mac you can do this but it’s really just for masochists (Command-F2 is it?).

All this keyboard navigation magic requires an infrastructure in the operating system. In Windows much of it is automatic, on the Mac it’s a lot of hard work in most cases. On iOS.. well even if there was a decent infrastructure, no developer would ever paid any attention to it. Even in Apple’s own apps a simple thing like the arrow and tab keys working is by no means a sure thing. More often than not when you connect a third party keyboard to an iPad, you are enter a world of frustration. Nothing works. Half the time you need to tap around the screen at arms length to perform even the most basic editing tasks. In fact, writing on the iPad is not half as frustrating as editing on the iPad.. in that way it is very similar to dictation features.

The video with the iPad Pro sitting flat on the desk with its full-size on-screen keyboard was hilarious. Who could type like that for more than a few minutes at most? How many hours of chiropractor’s work is involved in undoing the neck strain that you’d get after a mere hour of sitting like that?

So in practice, if you’re going to be typing long articles on the iPad Pro and you don’t have the keyboard cover, you’ll have it propped up on something. It might as well be the keyboard cover. In fact is there even a non-keyboard cover for the iPad Pro?

Again the much maligned Microsoft Surface is much more practical in that respect. It has a great built-in kickstand that means you can angle it even if you don’t have the keyboard cover on it. Great idea me thinks!

So you’re there, doing your “Pro” work on your iPad Pro in landscape mode, with the device propped up on its keyboard cover, seething at the fact that keyboard don’t work properly. Now, you’re faced with the biggest question of all: where’s the productivity software?

Well, Microsoft to the rescue: they have Office on the iPad. It’s probably not anything near as good as Office on the Mac or on a PC, but it looks like they’ve put a lot of effort in. The keyboard seems to be functional for navigation as well as for plain old typing. You still don’t have a file system, so you’ll have to use some kind of cloud service (surely not iCloud), but you can get some work done that way.

Beyond Office, however, you’ll soon fall into the abyss and then on your way down you’ll find it’s a bottom-less pit.. at least you won’t die since it’s not the falling that kills you. There is very little serious business-minded productivity software on the iPad and there quite possibly will never be. The reason for this is that nobody writes productivity business software for fun. Serious people write serious (aka boring) software for profit and there is none to be made on the iPad.

Apple’s App Store has long been a particular gripe of mine. Its business model encourages throw-away getting-rich-quickly software (games) and free (aka get-big-quick venture capital funded) software but nothing in between. Professional grade productivity is sold on a pay-up-front basis and relies on a constant upgrade revenue stream.

The solution so far has been for companies like Adobe or Microsoft to make the software free on the iPad and require an out-of-App Store subscription to a “service” like Office 360 or Creative Cloud. This gets around the 30% Apple share of anything sold on the App Store and its lack of upgrade options. This option is, however, neither available to most App Store developers, nor practical for most software.

The current state of the App Store is not tenable for Pro-level productivity software. About the only people making any serious money with productivity apps on the App Store is the OmniGroup. They prove that it is at least possible, but they benefit from intense promotion though Apple. Without that constant promotion of their products on the App Store one doubts  that they would be able to sustain their business.

This also shows the fragility of making software for the App Store: Make fun of Eddie Cue’s shirt while he’s standing next to you at the bar and your company is finished. More seriously, you are putting the fate of your company into Apple’s hands and Apple is not known for taking good care of its partners (developers included) and very well known for brusque unapologetic changes of direction that put people out of business.

The worst thing about the App Store is, however, the pricing. It takes a lot of time to make professional level software. Porting Adobe Photoshop to iOS would consume more than a man-lifetime; probably very much more. God only knows how much the Office port has cost Microsoft and they are still a long way from having parity with their PC versions.

You can’t expect anybody to put in that much time and money for a small and shrinking market where everything is $0.99 (or I guess $1.99 if you have an iPad, iPad Pro, iPhone, Apple Watch & Apple TV universal app).

The once vibrant Mac productivity software market shows that a marketplace where the majority of users are prepared to pay a fair price for high-quality software is possible, but even the Mac market is suffering through a combination of unsustainable race-to-the-bottom pricing and the other ill-effects of the Mac App Store with its stifling rules and arbitrarily enforced “guidelines”.

There are products on the Mac App Store that are doing very well, but it’s only the ones that get promoted by Apple. Apple tends to promote software that looks nice and/or is cheap and/or is written by people with a strong voice in the Mac community. You can’t rely on that.

Where in my opinion does this leave the iPad Pro? Between a rock and a hard place.

Apple is used to having people queue up to write software for their devices no matter what. The early days mobile gold rush is, however, slowly coming to a halt. There are today many more developers who have tried and failed to make money from the App Store than those who have had positive experience (the stats suggest something like 10,000 to 1). As a result, most developers have grown more cautious on how they spend their time. iPad sales are faltering. Many developers already regard the iPad market as “dead” with no money to be made; they are probably right.

It is hard to see who is going to be willing to invest much more time and effort to make much more complex and feature rich applications for a new niche within a shrinking market. Worse yet, because Apple is hiding the true cost of the iPad Pro by making keyboard and pencil optional extras, developers won’t even be able to rely on these accessories being present. How many iPhone developers are going to be spending $1,000+ to test their software on a huge iPad? Not many. This makes me believe that main-stream support for adequate keyboard navigation and pen input is going to be very slow in coming, if it is coming at all.

For the foreseeable future then, the iPad Pro is destined to be no more than a curiosity and its users will be just as frustrated as Microsoft Surface users are today. The hardware is there, but the software isn’t and probably won’t ever be.

Changing this will require a change of heart from Apple and Apple, regrettably, has become too big to be nimble, too successful to be humble, too set in its ways to welcome change.. and I suspect too afraid to change a winning formula.

After all that moaning: Will I get one? Hell, YES!

I’ve been waiting for an iPad with a decent stylus since it first came out. I’ve been wanting a bigger iPad to read my Magazines (I’m 43 and my eyes could be better) and Comics (I’m still young damn it) on for just as long. So count me in.

Will I be writing long blog posts on it? No. That might be a good thing :-)

A Better Finder Rename 10 on the horizon


Since the beginning of the year, I have been working flat out on version 10 of A Better Finder Rename and we are nearing the first beta release.

There are a few things that I want to get out there before the first beta ships and those are mostly to do with the Mac App Store and upgrades.

As many of you will be aware of, the Mac App Store is not much loved by Mac OS X software developers, because it is very different from the “traditional” Mac Indie software distribution that many of us feel is superior in very many ways.

Nonetheless most of us “old timers” have made our software available on the Mac App Store due largely to popular demand. Clearly the Mac App Store is better for some customers.

A few years ago, the Mac App Store started to demand that all applications be sandboxed and that was the beginning of the end for many professional productivity applications on the Mac App Store.

Sandboxing itself is a good idea. In a nutshell, it just means that applications cannot access your entire computer, but are restricted to a “safe” container with their own memory and disk space. Access to anything outside that “container” needs to be specifically allowed either by the user or by Apple during their review process.

Many categories of software (i.e. games) work very well in their sandbox, but most professional applications require fairly unfettered file system access, inter-application communication and/or internet access.

Tools such as BBEdit (an awesome text editor), TextExpander (an awesome snippet expander), Panic’s Coda (an awesome web development tool) and many others (many of them awesome) are leaving the Mac App Store because of these limitations.

A Better Finder Rename 9 is in the app store as “Better Rename 9” and we have managed to keep it non-sandboxed by only shipping “fixes” and no major upgrades for years.

By its very nature, a file renaming tool needs unfettered access to the file system. There’s no chance of Apple granting us an “entitlement” to do that during the review process. The reason is that this pretty much defeats the objective of being sandboxed in the first place.

In the idealized sandbox world, it is the user who implicitly grants permission to manipulate files by selecting them in a Open File… dialog or by just drag & dropping them onto the application or its icon. This works fine for our other file utilities such as File Multi ToolA Better Finder Attributes, but not for A Better Finder Rename.

The reason for this is simple: on a Unix system such as Mac OS X, the name of a file is not stored in the file itself but in the folder that contains it. Dragging & dropping files only gives access to the file and not to its “parent folder”, so you can change everything except its name.

We would thus either need to ask the you to give Better Rename 9 permission for the parent folder every time you want to rename something, or store that permission somewhere after the first time. Alternatively, we could also ask you to give us permission for the entire disk.

This is not an elegant solution and Apple may or may not accept it. Having played around a bit with other programs that have similar problems, it seems that Apple would most likely allow this kind of “hack” where the program brings up an Open File… dialog and says “Sorry I want to access this file but I can’t, please select it for me!”. Yuck.

We have most of the code necessary to do this and are ready to ship it, but it will undermine the usability of the tool, so we are not certain whether we will continue to support a Mac App Store version beyond version 9.

The next huge problem is how to implement paid upgrades. Nobody wants to pay for upgrades, but upgrade revenue is important for developers and customers alike. The economics of software development are currently bifurcated: you have the traditional developers such as Panic, OmniGroup, BareBones, Red Sweater to name but a few, who diligently plug away at making their products ever more awesome.. then you have the newer App-Store generation authors who create an app, launch it, get a good pay day (or more likely not) then see revenues collapse and move on to the next app product.

Abandonware is okay for some categories of software. Who cares whether Flappy Birds gets updated for iOS 9? Professional software, however, is used for more than mere entertainment. Customers buy into professional software, learn how to use it and expect to be using it for many years to come. They expect the software to supported, for bugs to fixed, for it to work with the latest operating system version and to continously evolve with their own growing needs.

A Better Finder Rename was first published in 1996 on System 7 running on PowerPC-compatible Macs and has constantly evolved since. Version 10 is the most awesome version yet and contains many improvements that would have been just as relevant in 1996 as they are today, as well as many that nobody could have predicted back then. At this point, it has probably broken through 100,000 hours of development and support time. A substantial amount of this time was paid for by upgrade fees.

Paid upgrades have another crucial advantage for long term customers: while fire-and-forget developers optimize for immediate appeal, paid upgrades are almost always targeted squarely at the needs of long term users. It’s a different mind set: The success of a new app depends on how many people buy it now, the success of a paid upgrade depends on how many people are willing to pay for the improvements and the new features.

Paid upgrades are great for professional level software because they allow software developers to spend time addressing the needs of existing customers. That’s why it’s particularly troubling that Apple does not allow for any upgrade pricing on the Mac App Store.. and that’s why developers like me are not very happy about it.

Apple makes the Lion’s part of its revenue on hardware. Software for them is something that makes people buy their hardware, so they can afford to give their software away for free to make you buy more hardware.

Indie software developers are only selling software and don’t get a cut from the hardware sales. In fact if we sell through the Mac App Store, Apple gets a 30% cut of our revenue and that’s after sales tax in most countries (though not most parts of the US). For a 19.99 EUR sale in Germany for instance, a developer only gets 11.76 EUR paid out; the missing 41% goes to Apple and the German VAT office. After the tax office and social security payments here in Luxembourg, there is less than 6 EUR left for me of any one sale of Better Rename 9.

Apple has changed software pricing on mobile devices but also on the Mac quite dramatically. They started by offering iLife (iPhoto, iMovie, etc.) for $19.95, then added iWork (Pages, Numbers,…) again at bargain basement prices. At those price points, just charging you another $19.95 every year is perfectly fine. In the end, all those products are now completely free and Apple makes all its money off the hardware.

Most importantly, Apple has never had to finance the development of those software titles by their actual purchase price. They produced these titles to sell $2,000 MacBooks and iMacs, not for the sake of the $19.95 upgrade pricing. Not surprisingly, none of those applications has seen real effort put into maintaining either backwards compatibility or expanding their feature sets. They are entry level applications because Apple has no real interest in driving their development forwards.

Unfortunately, neither charging the full price for each upgrade or making upgrades free, works for applications such as BBEdit, OmniFocus, Coda or indeed A Better Finder Rename. I don’t want to ask customers to pay another $19.95 for A Better Finder Rename 10, but I can’t afford to make it free either.

Many developers have tried to overcome this problem in a variety of creative but imperfect ways. The ball has been in Apple’s court for years, but it’s very clear that they don’t mean to ever pick it up.

I’m not excluding bringing A Better Finder Rename 10 to the Mac App Store eventually, but in a first phase, A Better Finder Rename 10 will only be available from the website.

Our upgrade terms have always been quite generous: paid upgrades cost 50% of the initial purchase price, are fairly infrequent (every 2-5 years), you can get forever upgrades which cost 100% of the initial purchasing price and if you have only recently bought the product, you get a free upgrade.

For A Better Finder Rename 10 the upgrade terms are as follows:

  •  if you have purchased A Better Finder Rename or Better Rename 9 after the  1st of January 2015, you get a free upgrade
  • if you own a forever upgrade, you get a free upgrade
  • otherwise, you have to purchase a discounted paid upgrade

As you may or may not be aware of, anybody who has purchased Better Rename 9 from the Mac App Store can also run A Better Finder Rename 9 from our website for free. In 99% of all cases, A Better Finder Rename will automatically detect that you have previously bought Better Rename 9 and unlock automatically.

If it does not unlock automatically, all you need to do is to download Better Rename 9 to your machine and run it once. After that you can delete it and A Better Finder Rename will still remember that it was there once.

Once released, A Better Finder Rename 10 should automatically unlock if you have purchased Better Rename 9 from the Mac App Store after the 1st of January 2015. So if you buy Better Rename 9 from the Mac App Store now, or even after A Better Finder Rename 10 is out, you are covered.  If you run into any problems, contact us at and we will sort everything out with you.

Likewise, if you own A Better Finder Rename 9 or Better Rename 9 but have bought it before the 1st of January 2015, you can buy the discounted upgrade to version 10 from the upgrade page. You can do so even before A Better Finder Rename 10 comes out.

After version 10 has been out for a while, we will reconsider whether we’ll submit Better Rename 10 to the Mac App Store complete with the crippling “please let me rename this” dialog or leave things as they are.

For us, the important thing is that no matter whether you buy on the Mac App Store or from us directly you will have access to the same versions and will not be penalized in any way.

Unfortunately, Apple does not tell us the identities of anybody who purchases our products on the Mac App Store, so we cannot contact existing customers to let them know of these arrangements.. so if anybody wants to post a comment (developers can’t leave or reply to comments) saying “you can get a free upgrade from!”, you’re more than welcome.

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 :-)