Some things I wish I had know before starting to automate Mac Developer ID Notarization

It’s Day 5 of Notarization Week and it’s time to wrap up and write down my experiences.

Notarization itself is not incredibly difficult. You can learn the basics by watching the 40 minutes talk from WWDC 2019. Unlike sandboxing, notarization should not have any detrimental effects for most Mac apps.

As always the real trouble starts when you are trying to inject Notarization into the tangled web of modern Mac software development: entitlements, certificates, automated Xcode build chains, build settings, etc..

First you need to adopt the “Hardened Runtime” for your application. For the two apps that I tested with, this was simply a matter of switching it on in the “Capabilities” tab of your target. By default, all the hardened runtime features are switched on and I was able to leave them all on without any problem.

The first gotcha is that you can’t really test your application’s compatibility with the hardened runtime in Xcode, because it will run in debug mode. Since the hardened runtime would not allow inspection of your code, the default “CODE_SIGN_INJECT_BASE_ENTITLEMENTS=YES” build setting   will inject the “com.apple.security.get-task-allow” entitlement into the debug version of your build product. This is a “normal” entitlement, just like those used for sandboxing.. and no the sandbox does not need to be turned on for notarization to work (sigh of relief).

Another gotcha is that your app will not be notarized as long as this entitlement is switched on, so we need to turn it off for the release build. This should not be a worry, but you will probably spend many frustrating hours chasing down this very problem nonetheless..

The next thing on the compliance list is that secure timestamps for codesign need to be turned on. Many developers have a “–timestamp=none” flag somewhere in their build settings.. because the Apple timestamp servers are slow and often down (at least here in Luxembourg) and you can no longer build a release without an internet connection. So if you have a build server without internet connection.. that is about to change. To make doubly sure, you should probably add “OTHER_CODE_SIGN_FLAGS=’$(inherited)  –timestamp” to your build settings.

In this context, it would have saved me a lot of time if I had known how to find out whether a product has in fact been signed with a secure timestamp. Executing “codesign –verify –deep –strict –verbose=4 –display  -r- /path/to/my/product” will display loads of things. If there is a line with “Signed Time” among it, that means that you did not sign with a secure timestamp. If you have a line with “Timestamp” in it, it means you do have a secure timestamp. It’s another brilliant example of how an Apple engineer’s language choice can cost tens of thousands of lost developer hours. “Signed Time (insecure)” would have been a great help.

In a similar vein, “codesign -d –entitlements :- /path/to/my/product” displays all the entitlements for the product and will reveal the dreaded “com.apple.security.get-task-allow” entitlement if it is still present.

Once you have a build product, you can send it to Apple for notarization with the “xcrun altool –notarize-app -f /my/archive –primary-bundle-id my.primary.bundle.id -u username -p apps-peci-fic-pass-word”.

This is where things get a little weird. You can send either a disk image or a zip archive, but not an application bundle. I distribute my software as disk images and my software updates as zips. If you send a zip file, make sure that you use the “ditto” tool as instructed by Apple, so that you don’t run into problems with extended attributes. You need to supply your username (email address) and a password. You can generate an application specific password and that worked fine for me straight away.

The command line will upload the archive and then return a “request-id” which is a UUID that you can use to look up the state of the notarization. This is not a real-time, synchronous affair. It was fairly quick when I used it, taking usually only a few minutes, but it is obviously a challenging problem for automation. You could write a script that extracts the request-id and then polls the Apple servers for its status before continuing, but realistically you probably want to have a two or three stage build process now.

I subdivided my own build process from one into three phases: build, request notarization and a combined stapling and verification phase.

Which brings us to stapling, which is the fun and easy part. You just type “xcrun stapler staple my.dmg” or “xcrun stapler staple my.app” and that’s that.

One thing to note is that the entire notarization process is completely free of build and version numbers, which is so wonderful. If only app review worked this way! There is no mention on how it works; it could be that Apple uses the entire archive as a hash code or that they create a hash of your upload. In any event, there is zero problem building a thousand different versions of your program and getting them all notarized.

The second thing to notice is that you can either staple app bundles or disk images, but not zip archives. Not sure which is weirder, but it kind of makes sense. In practical terms, this means that you can staple your notarization receipt to a dmg without having to open it, which is super easy. If I have understood this correctly, this means that both the dmg and the app are stapled and will open without any funny user warnings. Not being able to staple zip files, however, complicates things somewhat, because you now have to zip the app bundle to notarize it, staple the original unzipped app bundle and then re-zip it.

So far so good. Now enter the much dreaded Sparkle.framework, the foundation of all automated software updates across the Developer ID world, maintained by a clever, intrepid group of volunteers that deserve our eternal gratitude.. and the bane of my developer life.

For most of my products, Sparkle is the only framework that I bundle, so I blame it for the entire dreaded complexity and wasted time of framework signing.. which is a lot of blame. Signing frameworks is hell.. or used to be hell.. and now is hell again.

I don’t use Carthage or other “download stuff from all over the internet written by who knows who, run buggy build and install scripts and then ship the whole lot with my product” build systems. I actually just place a binary copy of the framework into the /Library/Frameworks/ folder and work with that. If you are using one of those build systems, you probably will have different problems.

The current (as of 26/July/2019) binary distribution of Sparkle is neither signed, nor built with the hardened runtime, so is unusable for notarizated apps. Downloading the source as a zip archive leaves out crucial files. So I did a “git clone –recursive https://github.com/sparkle-project/Sparkle” to get what I assume must be the master branch version (I have some deeply strange git expertise that overlaps with nobody else’s).

Building it with “make release”, despite affirmations to the contrary, did not result in a hardened version. One of worst things (I’m pretty sure it’s unavoidable and I’m not dissing its developers at all, but it is still absolutely dreadful) about Sparkle is that it includes two executables as well as the framework. Autoupdate.app and fileop always cause incredible signing headaches. The default option of just ticking the “Sign upon copy” option in Xcode, won’t sign these properly and you inevitably end up with gatekeeper problems.. even though it had just gone through a phase of actually working.. but no more.

I’m sure that at the heart of all my signing problems is a lack of understanding, aka ignorance. The thing is that I’m a Mac developer, not a cryptography geek. Knowing just enough to get by in the context of cryptography means knowing quite a lot about quite a few things, followed by endless trial and error that eventually ends for unknowable reasons.

After a very long time, I finally got a Sparkle build that I could use by opening the project in Xcode, adding the “OTHER_CODE_SIGN_FLAGS=’$(inherited)  –timestamp”, “CODE_SIGN_INJECT_BASE_ENTITLEMENTS=YES” to every relevant target and manually adding my Developer ID signing identity to all targets. I have no idea why this was necessary; as far as I understand the framework does not need to be signed at all, and will in any event be re-signed when it is copied into my app, but it would not work without this. Perhaps the entitlements only get added during signing?

I then spent most of a day chasing down the origin of the “com.apple.security.get-task-allow” entitlement on the “fileop” executable that steadfastly refused to go away, despite having no debug build and having plastered the “CODE_SIGN_INJECT_BASE_ENTITLEMENTS=YES” build settings everywhere throughout the Sparkle project. Around 11PM, I decided to just delete Xcode’s “Derived” folder (what else was there left?).. and that promptly solved the problem.

With the Sparkle problems solved, the rest was fairly straightforward.

All told I’ve spent an entire week on learning about Notarization and integrating it into my build system.  It’s not badly designed. In fact it works fairly well and I would even go as far as calling some of the design decisions enlightened. It is certainly a lot better thought through than either App Review or the Sandbox.

Unfortunately, it adds yet more complexity to an already incredibly complex development environment. Today’s apps are not much more complex than those from the 1990s. Phone apps are mostly much less complex. It should be easier to develop for the Mac today than it was back in the 1990s. Yet nearly 30 years of development tool, framework and API progress has yielded a development context that is no more productive and far more complex. Notarization adds yet another layer of complexity and yet another time sink for Mac developers.

There are some positives: Apple can now revoke specific builds of an app, rather than just turning off all apps from the same developer id. The hardened runtime gives the developer the possibility of shielding his/her software from malicious modification, but allows him/her to decide which “holes” need to be blasted into runtime for the program to continue working. Actually scanning apps for malware adds peace of mind when you release a program into the world.

In an ideal world, Apple would turn around and ditch its Mac App Store sandbox requirement. It could even offer notarization as a way to side-load software on the iPad. After all, notarization gives it the tools to prevent malware from being published and to switch off on every single Mac in the world should it get through anyway.

As a long time Mac developer (since 1994), however, I can’t help thinking though that the security people at Apple would have done better ironing out the bugs and limitations of the sandbox to get it work properly and be less of a nuisance, rather than adding yet another security approach.

If early reports about Catalina are to be believed, it looks like there are so many people working on Mac security that they have to roll out new security features at each release, whether they are a net benefit to users or not. Perhaps, these people could be tasked with making macOS great again instead?

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.

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.

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

Hi,

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 publicspace.net 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 support@publicspace.net 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 publicspace.net!”, 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.