Tag Archives: Apple

How to notarize your software on macOS

** Please note: WordPress keeps mangling my code examples by changing double dash to single dash. I tried to fix it. But it changed them all back again! If anyone knows how to get around this, please put something in the comments. **

Apple now wants you to ‘notarize’ your software. This is a process where you upload your software to Apple’s server so it can be scanned and certified malware free. This will probably become compulsory at some point, even (especially?) if your software isn’t in the Apple app store. Apple says:

Give users even more confidence in your software by submitting it to Apple to be notarized. The service automatically scans your Developer ID-signed software and performs security checks. When it’s ready to export for distribution, a ticket is attached to your software to let Gatekeeper know it’s been notarized.

When users on macOS Mojave first open a notarized app, installer package, or disk image, they’ll see a more streamlined Gatekeeper dialog and have confidence that it is not known malware.

Note that in an upcoming release of macOS, Gatekeeper will require Developer ID signed software to be notarized by Apple.

Documentation on notarization is a bit thin on the ground, especially if you want to notarize software that wasn’t built using XCode (I build my software using QtCreator). So I am writing up my experiences here.

First you need to ensure you have macOS 10.14 and XCode 10 installed (with command line tools) and you need a current Apple developer account.

Codesign your app with ‘hardened runtime’ using –options runtime :

codesign –deep –force –verify –verbose –sign “Developer ID Application:<developer id>” –options runtime <app file>


codesign –deep –force –verify –verbose –sign “Developer ID Application: Acme Ltd” –options runtime myApp.app

A ‘hardened runtime’ limits the data and resourced an application can access. I’m not sure what the exact ramification of this are. But it doesn’t seem to have restrict my software from doing anything it could do previously.

You can check the signing with:

codesign –verify –verbose=4 <app file>


codesign –verify –verbose=4 myApp.app

Now package your app into a .dmg (e.g. using DropDMG). Then upload the .dmg to Apple’s servers:

xcrun altool -t osx -f <dmg file> –primary-bundle-id <bundle id> –notarize-app –username <username>


xcrun altool -t osx -f myApp.dmg –primary-bundle-id com.acme.myapp –notarize-app –username me@acme.com

You will be prompted for your Apple developer password (or you can include it on the command line).

You now have to wait a few minutes. If the upload is successful “No errors uploading ” will be shown and a unique ID will be returned. You then have to use this to request your upload be scanned:

xcrun altool –notarization-info <notarize ID> -u <username>


xcrun altool –notarization-info xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx -u me@acme.com

You will be prompted for your Apple developer password (or you can include it on the command line).

Hopefully you will see “Status Message: Package Approved”. If the notarization fails, you should be sent a link to an online log file describing the issue. If the notarization completes successfully you need to ‘staple’ the results to your .dmg:

xcrun stapler staple -v <dmg file>


xcrun stapler staple -v myApp.dmg

The stapler outputs a log including some odd phrases. Mine included: “Humanity must endure”, “Let’s see how that works out. “, “Adding 1 blobs to superblob. What about Blob?” and “Enjoy”. Weird. Hopefully it will end with “The staple and validate action worked!”.

Finally you can unpack your .dmg into a .app and verify it with:

spctl -a -v <app file>


spctl -a -v /Applications/myApp.app

On macOS 10.14 (but not earlier OSs) it should say “source=Notarized Developer ID”. Your software should now run on 10.14 without a warning dialog. Congratulations!

It all seems rather clumsy. As you have to wait asynchronously for the unique ID to be returned from step 1 before you can complete step 2, it is not easy to fully automate in a script. This is a major pain the arse. If anyone works out a way to automate it the whole process, please let me know.

Here are some links to the various posts that I gleaned this information from:


Is it worth advertising Mac software on Google Adwords?

I learnt a long time ago that people will happily click on totally irrelevant pay per click ads. For example, if you bid on “seating plan” I can assure you that a significant percentage of people searching for “boeing 747 seating plan” will happily click on your ad titled “wedding seating plan”. They won’t buy anything, as they aren’t interested in wedding seating plans, but you still have to pay for each click. You can stop your ad showing to these searchers by adding “boeing” and “747” as negative keywords. Problem solved.

But what do you do if you are selling software that only runs on Mac OS X? The vast majority of searchers are running Windows. Indiscriminate clicks by them could quickly turn your Adwords ROI negative. In your Adwords campaign settings you can choose to only show ads on desktop computers and laptops. But you can’t choose the operating system.

As discussed above, putting “Mac” in the title is unlikely to be enough. You can’t use negative keywords, because the vast majority of Windows users searching for, say, backup software will type “backup software” not “Windows backup software”. You can just bid on searches containing keywords “Mac”, “Apple” or “OS X”, but will this be enough? My general advice to Mac only software vendors was to avoid Adwords, unless the ticket price of their software was in the hundreds of dollars. But, as my software runs on both Windows and Mac, I didn’t have any data to back this up.

Recently I got some data on Adwords clickthrough rates for a Mac only app (www.puzzlemakermac.com) by Hokua Software. They have kindly allowed me to share the data.

Initially they bid on generic keywords, such as “crossword maker” and ran ads such as the following with “Mac” displayed prominently in the title:

The results from analytics: 60% of the people clicking on the ads were on Windows and 40% on Mac.

Then Google banned them from the word “Mac” in their ads (it is possible to get this reversed with the express permission of Apple, but I don’t know how likely they are to grant this). So they switched to “OS X” in the ad, which hasn’t been blocked (yet).

The results from analytics: 73% of the people clicking on the ads were on Windows and 27% on Mac.

Then they restricted their bids to Mac targeted keywords such as “mac crossword maker”.

The results from analytics: 23% of the people clicking on the ads were on Windows and 73% on Mac. But there was a big drop in the number of impressions.

I think it is going to be almost impossible for anyone to get a return from Adwords when the majority of their clicks have no chance of generating a sale. So only bidding on Mac specific keywords seems to be the way to go. But there will still be a significant number of wasted clicks from Windows users. Also any Mac users who don’t use the appropriate keywords won’t see your ad. Consequently the return on time and money invested is likely to be a lot lower than Windows, cross-platform and web developers can expect. If you have a Mac only product with: a high ticket price product, well-defined keywords and limited competition, it might be worth trying Adwords. But otherwise it is probably better to wait and see if Google release OS targeting.

Of course, you could always use one of the free Adwords vouchers that Google are handing out like confetti (I get one every month in my PC Pro magazine) and try for yourself. This is how Hokua software got the results above. If you do, I would be interested to know how your results compare.

App stores set to dominate future software sales?

Following the success of the iPhone app store (over 6 billion downloads to date), app stores are becoming more and more of a feature of the software landscape. In case you missed it, Apple announced yesterday that there will be an App Store for Macs  ‘within 90 days’. In summary:

  • The Mac app store will be tightly integrated with Mac OS X, including automatic install and update.
  • There will be restrictions on technology, for example Java apps will not be allowed.
  • Apple will keep 30% of any revenue from sales.
  • $99/year subscription for developers.
  • Developers will still be able to sell their software outside the App store.

It is easy to see why Apple would want to do this:

  • A potentially huge new revenue stream from third party Mac software sales.
  • They get even more control over the customer experience.

And this could have advantages for Mac users:

  • Simpler payment and installation.
  • Screening out of low quality apps and malware.

And potential advantages for Mac developers:

  • Mac users might buy more software if it is easier to do so.
  • One main channel to concentrate your marketing efforts on.
  • Some of the boring infrastructure of selling software (licensing, shopping cart etc) can be taken care of by Apple.

But the disadvantages are all too obvious:

  • Your app could be rejected outright. And you won’t know until you submit it for approval. Apple are judge, jury and executioner. The iPhone app store has been infamous its capricious and opaque approval process.
  • 30% is a huge chunk of revenue. Typical payment processors take 5-10% of revenue. Where the new app store cannibalises existing sales (and it is hard to see that it won’t) vendors will lose 20-25% of existing sales revenues.
  • New apps and updates will be delayed by days or weeks as they go through the app store approval process.
  • A single centralised app store is likely to make it harder for niche/long-tail apps to make any sort of living. Certainly this is what seems to be happening in the iPhone App store.
  • Apple are control freaks and have traditionally taken a rather heavy handed approach with developers, including the liberal use of NDAs. The app store will give them even more control.

And worse might follow:

  • Apple makes a lot of their money from selling over-priced hardware. It may be in their interest to drive software prices down so they can sell more hardware. $5 is considered expensive in the iPhone App Store.
  • This could be the first step to making Mac OS X a closed system, like iPhone, where only Apple approved apps can be installed.

I guess they can’t piss off developers too much – a computer without third party applications isn’t going to be very attractive to customers. But I am finding it hard to work up any enthusiasm for a Mac app store. If it is successful I can either be in the store and give up a lot of freedom and cannibalize exisiting sales at a much lower margin, or stay out and be shut out of a large chunk of the market. It isn’t an attractive choice. As my app is written in C++/Qt, rather than Objective-C/Cocoa, I am not even sure that it will be eligible for inclusion in the store. I could just abandon Mac OS X, but Microsoft is also rumoured to be working on their own app store (despite the failure of DigitalLocker). That is a truly terrifying prospect given the awfulness of their ‘Works with Vista’ approval process (I speak from personal experience).

Suddenly web apps are looking more interesting.

iPhone App store economics

If you believe all the hype about iPhone apps, you can just hammer out an App in a few weeks, let that nice Mr Jobs take care of all that sordid marketing for you and then sit back to collect a big cheque every month. However the numbers in a recent sobering post about the economics of paid iPhone apps tell a rather different story:

  • average annual income for a paid iPhone app (after the App store 30%): $3,050
  • median annual income for a paid iPhone app (after the App store 30%): $682

The numbers are based on various published data from Apple and other sources, plus a few assumptions. I haven’t gone through the numbers and the analysis with a fine tooth comb, but I can’t say I am surprised.

The disconnect between the hype and the reality is so large because Apple (understandably) only want to tell developers about the success stories. The media and the public seem quite happy to go along with this because it makes a more interesting story. But when there are 225,000 apps shouting for attention, only one way to access them via a notoriously dictatorial third party and $5 is considered expensive, it is likely that the majority of developers will do badly. Hence the median is so much worse than the mean. Before you write your iPhone App I think you should ask yourself if it has got a realistic shot at making the top 10 in its App store category. If not, don’t give up the day job just yet.

Further reading:

The Sparrow problem

How to Evaluate a (paid) iPhone App Idea

Using a Mac mini for development

mac miniI have been using a Mac mini to port my C++/Qt based code to Mac OS X for the last 3.5 years. This is one of the early PowerPC based Mac minis, upgraded to 1GB of RAM. Being Apple hardware, it is expensive for what you get. But it has served me well. The small form factor (approx 17 x 17 x 5 cm) has also been useful in my cramped office, where I have it attached to the same monitor, mouse and keyboard as my Windows box through a KVM switch. But it is struggling to keep up with PerfectTablePlan’s ever increasing code base. A clean build of the PerfectTablePlan source into a Universal (fat) binary now takes an eye-watering 36 minutes to compile and link on the Mac mini. Building a PowerPC-only debug version still takes nearly half that time. That is painful, even just for occasional porting work.

As my main development environment is Windows, I can’t really justify the cost (or office space requirements) of a Mac Pro. So I decided to buy a new Mac mini, with an Intel Core 2 Duo processor. I did look around to see if I could find one at a discount. However, this being Apple hardware, no-one dares sell  at anything significantly less than Apple’s RRP. I bought the smaller (120GB) disk variant and had the dealer upgrade it to 2GB RAM, which tests on my old Mac mini indicated should be plenty for compiling and linking. I didn’t want to do the memory upgrade myself as I know, from experience with my first Mac mini, that removing the case involves putty knives and some very worrying cracking noises.

I had all sorts of problems trying to get the right cables. Firstly I wanted a Firewire cable so I could copy the set-up across from the old machine to the new machine using Apple’s Migration Assistant software. But it turns out that the old Mac Mini has a Firewire 400 6-pin socket, whereas the new Mac Mini has a Firewire 800 9-pin socket. I ordered a 6-pin to 9-pin Firewire cable cable. Then I discovered that there is more than one type of DVI cable. The old Mac mini was attached to my KVM switch with a DVI-I cable. The new Mac mini only accepts mini-DVI or (via a supplied adaptor) DVI-D. So I ordered a dual link DVI-D to DVI-D cable as well.

Once I had the right cables things went relatively smoothly. The Migration Assistant software copied almost all the apps and data across from the old machine to the new one. It even preserved settings for the apps, e.g. the email accounts in my Thunderbird email client. I just had to re-install XCode (which wasn’t copied across) and rebuild my Qt libraries (to avoid copious warnings due to the fact they had been built with an earlier version of XCode/gcc).

To use the migration assistant you simply:

  1. connect the 2 machines with a Firewire cable
  2. start-up the old machine with the ‘T’ key depresses to put it in ‘Target’ mode
  3. start-up the new machine
  4. follow the on-screen instructions

Nice. If only it was was that easy to set-up a new Windows machine.

A quick test shows that the new Mac mini is nearly 6 times faster at compiling and linking a Universal binary of PerfectTablePlan from scratch[1]:

mac mini performance

The time the new Mac mini takes to compile and link an Intel-only debug release of PerfectTablePlan also compares favourably with a similar build on my Windows 2.13 GHz Intel Core 2 Duo box with 4GB of RAM[2].

mac mini performance 2

This isn’t a fair hardware comparison, as the two machines are using completely different compilers and linkers and the Windows box was running various background services. But it certainly shows that Intel-based Mac minis are worth considering for use as development machines.

[1] The newer machine is using a newer version of XCode/gcc.

[2] The Windows box is using Visual Studio 2005.

Mac OS X market share accelerates in 2008

2008 was a good year for Apple and Mac OS X. According to netapplications.com data (via sharewarepromotions blog) Mac OS X’s share of the OS market increased from 7.31% in Dec 2007 to 9.63% in Dec 2008. That is a 32% increase in market share during 2008, compared to a 22% increase during 2007.


Windows market share fell from 91.79% to 88.68% in the same time. While Mac OS X’s annual gains are impressive, it has a long way to go to catch Windows. 15 years if you project the 2008 gains forward.

macosx_vs_windows_market_share_2007_2008Of course, it is highly questionable to project 15 years from a single year of data, but it gives an idea how much work Apple still has to do.

I sell table planning software for Windows and Mac OS X. Mac visitors to my website have followed the general trend, up from 7.41% in 2007 to 8.5% in 2008 and accounting for around of 10% of visitors at the end of 2008.

macosx_visitor_percentage% Mac visitors to http://www.perfecttableplan.com

My data also shows that Mac users are twice as likely to purchase my software as Windows users (I have heard similar figures have reported by others). So Mac users currently account for 20% of my sales. I wouldn’t want to live off my Mac sales, but it is very useful additional income. Given the disparity in cost between Windows and Mac hardware it is hardly surprising that Mac users are more ready to reach for their credit card.

My software is built on top of the Qt cross-platform toolkit. The recent porting of Qt 4.5 to Cocoa gives me the opportunity to further improve PerfectTablePlan’s Mac look and feel and to release a 64 bit version. Hopefully this, coupled with increasing Mac market share, will further improve my Mac sales.

A beta of Windows 7 has just been released.  It will be interesting to see if it can repair some of the damage caused by Vista and slow the growth of Mac OS X. Personally, I doubt it – the Windows 7 feature list certainly doesn’t set my pulse racing.