publicspace.net

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 change, too little communication, too 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.

Image Capture Workflow Updated for A Better Finder Rename 9

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

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

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

Vitamin-R 2.0 Upgrades & Mac App Store

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

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

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

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

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

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

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

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

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

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

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

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

This puts software developers like us into an awkward position.

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

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

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

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

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

1. Direct and Mac App Store customers alike will be able to buy a discounted upgrade from our web store via http://www.publicspace.net/Vitamin-R/upgrade.html

2. Direct customers who have purchased Vitamin-R after the 1st of January 2013 will be able to obtain a free upgrade code to version 2 from http://www.publicspace.net/unlockCodeDB/index.html

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

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

Vitamin-R on the Mac App Store

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

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

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

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

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

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

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

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

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

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

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

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

Other changes include:

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

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

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

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

Well, I’m gutted about the whole thing.

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

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

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

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

Vitamin-R & the Mac App Store Sandbox

It is finally happening. Apple have made good on their promise/ threat of requiring all applications on the Mac App Store to adopt the Lion Sandbox technology by June 1st.

You may already have heard many Mac developers moan about this, while others are trying to see the bright side or are at least putting on a brave face. It’s all true and it’s all a lie.

First off, sandboxing does improve security. The idea is that every application that is launched by the operating system works in its own “sandbox”. It can do anything it wants within its sandbox, but when it tries to interact with the rest of your system by accessing files, connecting to the internet, talk to other applications, etc.. it is restricted by its “entitlements”. All this so that even if your application is infected by a virus or is deliberately “naughty” (aka malware), it can only do so much damage.

The kinds of entitlements that exist are defined by Apple and while it is the developers who decide which entitlements they believe their application needs, it is Apple that grants or rejects each entitlement.

The basic equation is this: the less your application is allowed to do, the less damage it can do. So if Apple is serious about the security aspect of the sandbox, it will grant what it deems to be the minimal entitlements required by the application.

Even though it means more work for developers, the sandbox in itself is not a bad idea. Security is good, right?

The rub lies in the fact that unlike iPad and iPhone applications which effectively take over your whole device, most Mac applications live in an eco-system together with other applications. They share files, they interact with other applications and the system to deliver an integrated user experience.

The sandbox gets into the way of all this. Sandboxed applications can only access files on your disk after you have opened them in the “Open…” or “Save…” dialog. They can only interact with other application via AppleScript if they have a specific entitlement for that specific application and that means that Apple has to grant that specific entitlement during the review process. Worse yet, there are no entitlements for a whole range of things that a powerful app could potentially want to do.

For many applications, this will mean that existing application features that have existed for a long time will need to be removed in order to comply with Sandboxing rules.

I have finished sandboxing Vitamin-R and I have managed to keep most of its features alive and well.

Some features, however, did not make the cut. So I have removed the following features from the Mac App Store version of Vitamin-R:

  • the ability to quit other applications from the “Eliminate Distractions” screen
  • the integration with NeuroSky’s MindWave brain computer interface

(There are entitlements for either of these things).

Other features require “temporary entitlements” that Apple may or may not grant.

The features “at risk” are:

  • Things integration
  • Things beta integration (new if accepted)
  • OmniFocus integration
  • Growl integration
  • The Hit List Integration

There is no rational reason for doubting that Apple will grant these entitlements, but the MAS review process is notoriously capricious. The term “temporary” also does not fill one with great confidence, so these features may well disappear somewhere down the line even if accepted now.

I will be submitting Vitamin-R 1.81 to the Mac App Store as soon as version 1.80 is released next week and if everything goes smoothly and Apple isn’t backlogged, it should be available within a fortnight.

On a personal note: I do not want to remove a single feature from any of my applications. Apple is forcing my hand and I’m doing what I can to preserve functionality. The versions of my software distributed via my own website will remain outside of the sandbox and thus unaffected.

I’m also looking into ways of allowing users who have purchased via the Mac App Store to download and use the “full” version of Vitamin-R from my website for free. This is made more difficult by the fact that Apple does not share customer data with third party developers and I thus have no idea of who buys my software on the Mac App Store.

I hope to have a simple solution ready sometime in June, but this again depends on whether the Mac App Store review team accept the solution.

If you are upset about losing features, the best idea is to let Apple know about it. We developers have already done all we can. There’s a “Support” link in the “Quick Links” section of the Mac App Store front page and of course there are Apple Stores all over the world.

twitter..

I’ll admit it, I’m not a great Twitter fan. Perhaps at 30 something, I’m already well past it.

I find myself agreeing at least partially with notorious software pundit, Joel Spolsky who announces his retirement from blogging with this little tidbit:

l appreciate that many people find Twitter to be valuable, I find it a truly awful way to exchange thoughts and ideas. It creates a mentally stunted world in which the most complicated thought you can think is one sentence long. It’s a cacophony of people shouting their thoughts into the abyss without listening to what anyone else is saying. Logging on gives you a page full of little hand grenades: impossible-to-understand, context-free sentences that take five minutes of research to unravel and which then turn out to be stupid, irrelevant, or pertaining to the television series Battlestar Galactica. I would write an essay describing why Twitter gives me a headache and makes me fear for the future of humanity, but it doesn’t deserve more than 140 characters of explanation, and I’ve already spent 820. [Joel on Software Blog]

Nonetheless, despite the fact that I have never advertised the existence of a twitter feed in my name (you’ve got to see what all the fuss is about after all), I do seem to have acquired a very small following anyway, so I feel honour bound to make an effort.

So henceforward, at least until I completely forget about it again, here’s a link to my official twitter feed.

Snow Leopard Update

Right, Snow Leopard has officially been released, so we can start talking about it..

Like many  in the Macintosh community, I thought that “sometime in September” would mean.. sometime in September, so I felt that it was safe to go on holiday until the second of September and that would leave me plenty of time for a nice orderly rollout of Mac OS X 10.6… silly old me, of course it meant the 28th of August!? I’m not really sure what Apple stands to gain from this kind of exercise, but it sure doesn’t make it easy for third party developers.

The good news is that I have tested all current products including A Better Finder Rename, A Better Finder Attributes, “The Big Mean Folder Machine” and MacBreakZ with the latest beta release, which rumor has it is the gold master of what appears on the shelves today and it’s all running just fine.

A Better Finder Attributes displays some odd behaviors on certain file date changes which I’m fairly certain are  due to actual bugs in Snow Leopard. I’ll report them to Apple when I get back to the office next week. The workaround is simple: click on the “OK” button twice and everything is fine.

Snow Leopard also appears to no longer allow the creator part of the creator & type legacy codes to be set!? This isn’t a great loss since creator & type codes have been on their way out ever since 10.1 came out and the creator part is arguably of less relevance than the type part. I’ll investigate.

A Better Finder Rename runs just fine with no problems at all, so assuming that the beta I had was indeed the Gold Master, it should be smooth rollout.

“The Big Mean Folder Machine” and MacBreakZ have displayed no problems at all.

Of course, once you put a new operating system into the hands of a couple of million actual users, inevitably quirks are discovered, so please let me know immediately if you find something. I can only fix problems that I know about..

One more thing..

How to get the Finder context menu on Snow Leopard

Snow Leopard finally does away with contextual menu item plug-ins, which is definitely a good thing. This ancient technology is replaced with “Services”.. you know that weird menu that appears in every application’s menu bar and you have no idea of what it does.

The gotcha here is that you need to activate the A Better Finder Rename and A Better Finder Attributes services to actually see them in the Finder context menu or the new streamlined Services menu.

  1. A Better Finder Rename and A Better Finder Attributes now definitely need to reside in your Applications because that is where Snow Leopard looks for “Service Providers”.. so if you have them installed somewhere else you need to drag them into the proper folder now.
  2. go to the Finder, open the “Finder” menu and select “Services Preferences…” from the “Services” menu
  3. in the Services Preferences tick the A Better Finder Rename 8 and A Better Finder Attributes 4 items

Voila.

If the items don’t appear in the Services Preferences, you might need to

  1. launch A Better Finder Rename 8 once
  2. and if that doesn’t work, log out and back into your account/ reboot

The reason for this complication is that the Finder only finds new services when it starts up. A Better Finder Rename 8 nicely asks the Finder to update its services list when it starts up , but it’s only a request..

I wish you all a good transition..

Frank

Snow Leopard Compatibility

One question that is certain to be on everybody’s mind at the moment is “Will it work on Snow Leopard?”.

I couldn’t possibly comment.. as I’m under NDA.. but surely it’s okay to just say: “Yes.”

There’ll be more info posted here on the 28th of August, the official Mac OS X 10.6 release date.

I’m on holiday right now and normal service will be resumed on the 2nd of September, so expect a few minor updates to iron out some minor issues that are sure to occur when tens of thousands of users simultaneously get their hands on a new operation system.