Tag Archives: macOS

Moving from altool to notarytool for Mac notarization

This is an update to my 2018 article How to notarize your software on macOS.

I have been using altool to notarize my Mac apps for some years. However Apple, being Apple, have deprecated altool in favour of the new notarytool. altool will stop working at some point in 2023. And Apple, being Apple, have made little attempt to keep consistency between the two.

I didn’t find anything online to tell me how arguments between the two tools related. Consequently I spent a while trying to guess which arguments mapped to which. I got locked out for a while for trying to wrong combination too many times. In the end I went from this:

xcrun altool -t osx -f <mydmg>.dmg --primary-bundle-id <com.company.product> --notarize-app --username <apple-account-email> --password <password>

... wait for approval email ...

xcrun altool --username <apple-account-email> --password <password> --notarization-info <RequestUUID>

To this:

xcrun notarytool submit <mydmg>.dmg --apple-id <apple-account-email> --team-id <teamid> --password <password> --verbose --wait

On the plus side the --wait option doesn’t exit until the notarization is complete, which means you can easily do you whole build, sign and notarize process in a single script. Hoorah.

Note that you still need to run the ‘stapling’ step after notarization:

xcrun stapler staple -v <mydmg>.dmg

More details on notarytool arguments at:

https://keith.github.io/xcode-man-pages/notarytool.1.html

Qt visual artefacts on Mac OS X 10.6

deploy_nearly_everywhere The release of Mac OS X 10.6 (Snow Leopard) snuck up on me while I have been working hard on a major new release of PerfectTablePlan plan. I didn’t really want to risk messing up my stable Mac development machine by installing it, so I asked testlab2.com (who have been doing some third party testing for me) to test my latest beta on it.

Bad news. All the combo boxes in my application (which work fine in Mac OS X 10.3, 10.4 and 10.5) have visual artefacts on Mac OS X 10.6. They work fine, but they don’t look right. I wondered if the artefact could be unique to some weird configuration on testlab2’s test machine, so I asked the fine folk on macsb mailing list to see if they could replicate it. 4 of them tried (thanks Cesar, Jon, Aaron and Pierre) and they all saw the visual artefacts. Damn.

I posted a question on the qt-interest forum. The single response (thanks Francesco) mentioned that this issue had been reported in the Qt development blog. I managed to find the blog post, applied the recommended single line code patch to Qt 4.4.2 and rebuilt everything. Cesar from macsb kindly re-tried the new binaries and reports that this improved things, but some artefacts are still visible the first time a combo box is shown. Perhaps the patch works better for Qt 4.5.

Note the artefacts at the top and bottom of the combo box drop-down list

It looks like I am going to have to release it like this, unless someone knows of a better patch. This is very annoying after the months of hard work I have put into the new release. Aesthetics are important for commercial software, especially on the Mac. This could cost me quite a few sales.

I am not on the very latest release of Qt, but apparently this issue would still occur even if I was. Qt/Nokia have announced that they don’t expect to support Mac OS X 10.6 until they release Qt 4.6, whenever that might be. What use is a cross-platform toolkit that doesn’t support the latest major OSs?

Developer releases of 10.6 have been available for a while – I believe the Qt team should have burnt the midnight oil to make sure they had a release that properly supported 10.6 as soon as it became generally available. I know that isn’t easy given the size of the Qt framework and Apple’s penchant for secretiveness. But that is the game they are in and that is what I expect. I think they have seriously dropped the ball here, and this is coming from a longtime Qt fan-boy. Perhaps they have spread themselves a bit too thin by moving to LGPL licensing.

I have written this post as a quick heads up to other Qt developers. Thanks to everyone that helped me get this far.

Using a Mac mini for development

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

connect the 2 machines with a Firewire cable
start-up the old machine with the ‘T’ key depresses to put it in ‘Target’ mode
start-up the new machine
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.

Of 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.

% 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.

Installing MacOSX 10.5 (Leopard) on an external harddisk

I need to support both MacOSX 10.4 (Tiger) and 10.5 (Leopard) for the latest release of PerfectTablePlan. I could have created a new partition on the current harddisk for 10.5, but apparently you can’t do that without erasing the whole disk. I really didn’t want to mess with my existing 10.4 setup, so I purchased a 320GB WD MyBook USB/Firewire external harddisk to install 10.5 on to. 320GB for £75, bargain! But I had quite a bit of trouble installing Leopard on to it. After about the tenth time looking at a “Mac OS X could not be installed on your computer. The installer cannot prepare the volume for installation.” message I finally got it working. In case anyone else gets stuck, here are some hints:

When you set up the new harddisk partitions using Disk Utility make sure you choose Apple Partition Map using the Options button (it may be set to Master Boot Record if the disk is shipped set-up for Windows).
Disconnect the harddisk USB cable. Just use the Firewire cable.

I hope this saves someone else a few hours. Thanks to Jeff B for a hint that got me moving in the right direction.