MacOS client 2020

Thread to track macOS client status.

@Moisie correct me if I am wrong, but this is the stuff to be done till there is a (working) pkg again:

  • :white_check_mark: Integrate notarization into build process
  • :white_check_mark: Somehow setup builds. @Moisie do you need Apple developer membership?

Nice to have:


  • Fat-binaries for Apples ARM transition :confused:

Current test version:


That’s pretty much right, yes. At present I’m working on (as far as I can see) the last show-stopping issue otherwise, which is to integrate the wxWidgets libraries into the application bundle, so they don’t need to be installed separately.

I have Apple developer membership through the company I work for - but I’m unclear on the best practice for signing apps on a shared, open-source project. Obviously I don’t want to risk my company’s certificate being revoked for sections of code I have no control over - but contrarily, I understand you might not want to sign code that you haven’t written!

I honestly don’t know if I’m being paranoid here - but I just don’t want to jump into a situation which might be irreversible, without fully understanding the consequences…

I don’t yet know how possible this will be: full integration appears to be reserved for select developers - and Time Machine snapshots will get cleared up by the OS after ~24 hours. This might be sufficient to effect a practical solution - at least individual files won’t be transient whilst they’re being backed up, but it won’t necessarily be possible to backup a full disk snapshot within that time period.

Other items I have on my non-show-stopper list are:

  • I’m not convinced that background priority is being correctly applied;
  • Work through macOS-specific metadata backups - as per this thread;
  • A few GUI tidy-ups.

I’d link it statically (*.a files). Since there is only one executable file, you wouldn’t gain anything by dynamic linking anyway.

I’d use a separate one. I was asking because I can forward you the fees from donations, if necessary, or perhaps others could help.

I currently don’t have one. As perhaps mentioned in the other thread, the Mac stopped getting updates. Then Apple required an (up-to-date) i-Device as second factor for the developer account. At this point I couldn’t even cancel the account anymore and support wouldn’t cancel the account for me. Luckily my credit card CVC changed which fixed the issue.

I would perhaps consider building it on but if that i-Device second factor requirement still exists, I’d have to buy an Apple device anyway, so it’s cheaper if you do it :slight_smile:

Ok - I’ll look at that too - thanks!

No problem - presumably that would be best tied to an email address? I’m happy to work however’s best for you on this front - just let me know what’s best for the project, and what’s easiest for you.

I can’t exactly remember the sequence of events - but I remember this happening and being annoyed by the prospect. However, someone then just pointed out to create a second user account on my Mac, sign that account into the iCloud account, and use that for the two-factor sign-in - no i-Device required.

Certainly for the foreseeable future, I’m happy to do the build process. I haven’t yet gone through a build which ties into the get-the-version-number-from-git procedure - but I’m happy to work it out (presumably this requires coming out of the dev branch?).

Reading closely, I might be able to make it work with and SMS 2FA. I guess that would be the cleanest solution (if it works). I’ll give it a try and see how good your build instructions are, k? :wink:

(With i-Device I meant this (it doesn’t work with iCloud for Windows):

What are the system requirements?

You can enable two-factor authentication on an iPhone, iPad, or iPod touch with iOS 9 and later, or a Mac with OS X El Capitan and later.



Ah right - that makes sense. Yes - you’d need a reasonably modern Apple device to accept their custom 2FA push notifications.

Finally got that 2FA thing figured out after a lot of back and forth with support over several weeks. Result:

final-signed.pkg (5.9 MB)

It doesn’t work because /Library/Application Support/UrBackup Client/var/urbackup/data isn’t created (I think). But after that it looks good.

It doesn’t properly switch into dark mode ( ). This seems to be improved with wxWidgets 3.1.y. Any reason why you emphasize using the stable wxWidgets version in the readme?

Woop - I apologise on behalf of the Apple community, and thankyou for your persistence!

Hmmm - it does work here - I can’t think why that wouldn’t get created, just as it was previously created inside the application bundle with the old version.

Yes - it didn’t build for me at all with the later wxWidgets. Since I found 3.0.5 stable worked, I haven’t tried again - I’ll put it on my list and report back. (Sorry - haven’t had much time to spend on this recently.)

(Incidentally there’s an outstanding PR for linking the required wxWidgets into the application, so no separate installation of it is required. :wink: )

Sorry, didn’t see. The above build is statically linked (which would in this case also e.g. reduce the size). I updated the readme w.r.t. that.

Could be it was another issue… I had problems with / in the mac serial id (which is added to the default client name), but that problem was fixed server side.

Ah brilliant - thanks!

Build it with wxWidgets 3.1.y. Seems to work: final-signed.pkg (6.0 MB) Had to move min-version up to X 10.10.

The “Access/restore backups” option in the menu doesn’t work for me (open web browser).


Sorry - rather behind on my ability to test your updates at this end. However:

This is working on the build and OS (macOS 10.12.6) I’ve been focussing on.