> In 2020, distributing requires learning the intricacies of certificates, code signing, provisioning profiles, hardening, notarization, .dmg creation, gatekeeper, and paying a $99 per year fee.
I had to manually create, sign, and notarize a Mac app the other day and it was total madness. It took multiple tabs of Apple documentation (new documentation, I might add, created this year because everyone complained last year about how the process was impenetrable) and back-and-forth with some seasoned Mac devs before I had something that would launch successfully on a fully updated, GateKeepered system.
It’s so frustrating that automation and command-line is treated as almost second-class citizenship on macOS.
You know how I log into a remote server securely without ever entering my password? I enter the command "ssh" and the server name. Why the hell isn’t notarization implemented, effectively, as "notarize appname.app" where all the details are resolved securely, just as magically, to your developer keys?
Yet if you upload something to the App Store, you understand Apple’s backwards mindset completely. The whole concept of a 6-step wizard that you have to CLICK through, EVERY time, for EVERY update, confirming stupid little things that should be in a config file, means that Apple has no idea how this stuff really ought to work. And that means that Apple must not use this themselves. They have to have some secret, simple, tolerable process internally which is why they never improve the tools that literally everyone else must put up with.
Shameless plug: I created xcnotary [1] to make command line notarization quite a bit less painful. It will poll the service and block for completion, return a non-zero failure code for CI, and will even audit your app for some common code signing issues prior to uploading it to Apple.
Shameless plug of my own: Last month I shared a post sharing a few thoughts on secure software redistribution, notarization, safe updates, and so on: https://henvic.dev/posts/cs-security/
> It’s so frustrating that automation and command-line is treated as almost second-class citizenship on macOS.
Sure, they're horrible, but I look at it as Apple generously creating jobs for engineers. I had a full-time job as a build engineer specializing in navigating the Lovecraftian nightmare of iOS build automation. Sure, they could've made it easy, but instead they chose to help transfer large sums of money from my family-friendly multinational megacorp employer to me. I returned the favor by using some of that money to buy their products.
This is a hilariously weird response to a valid criticism.
"Yeah, internet-outages are horrible. And sure, AT&T could fix that. But instead they chose to help people to disconnect from time to time and focus more on their families, which is overall the biggest contribution a company can make to society and should be rewarded by buying more of their services"
I keep seeing this kind of other-worldly self-defense only related to Apple. Positioning a brand as an element of the users' personal identity is truly an impressive thing...
A year or so back I wrote a little ffmpeg concatenation helper to make a friend's life easier. It was an OK shell script but it needed a config file to list all of the files that needed concatenation, and I wanted to just make a GUI that would let her add and reorder files to a list, then generate a temp file with the list (ffmpeg required the list to live in a file for some reason) and fire off the ffmpeg command to concatenate them both with and without sound.
This is apparently like a DEFCON 0 type operation to perform on a Mac requiring two guys in white lab coats to turn keys at the same time at opposite ends of the room, because there was no way to even ask for the permission to run the command if I remember right. It ended up being a case where I would be spending a ton of time to get more functionality than the command line script, so I quit. Plus it was one of those one plane ride projects.
Unless you wanted to submit this to the Mac App Store, you could have just turned off sandboxing. With that off, the only permission required would be Catalina’s permission dialogs when any app first accesses various folders (Documents, etc.), and those are automatic without needing any code in the app to request them.
I thought I could locally, but it crashed on her machine which makes me think I did it wrong. I could have kept at it but I think one debugging session on her computer would have wiped out any time savings she would have realized.
Exactly! The primary purpose of the `altool` for notarization is probably to do so in an automated manner, but it will not block while waiting for notarization. So to make this part of automation, nearly every developer needed to add polling loops and parse the response to figure out if it was done! The proper text to wait on also isn't obvious nor documented; if the status says "Package Approved" it may not even be complete yet.
Further, the first version would write status to standard error. Clearly a mistake, Apple did fix this in a future version... which of course broke everyone's automation around it. My polling script now logs the tool's stdout and stderr just in case.
No, it's one well documented command line tool called signtool. I've used it quite extensively and it has never failed me in an unexpected way.
I can't report much good about the Apple signing side. In the end we put that into a VM because different xcode versions will produce vastly different signatures for no obvious reason, and the older ones were more widely compatible.
App signing has always been inexplicably horrible; other than Cupertino contempt for their developers, I really don't know what would explain it, it certainly doesn't have to be that way.
But things have gotten worse for developers recently with Catalina. I should note that I don't write mac-specific code - I mainly write things that target Linux servers.
The Mac has long been the best unix workstation on the market. It is solid, generally stable (although that's been slipping), and certainly has by far the best window manager. It has nice consumer apps for when you need them and is a solid, if not always up to date, unix. The hardware is generally great.
Then the sandboxing, weird parallel fire permission systems/quarantining, new filesystem conventions/restrictions and so on made it incredibly difficult to treat, well, like a unix workstation.
We'll probably keep using Macs at work out of inertia, and it is a lot easier for me to use other resources there. And my personal Mac laptop is probably good for quite a while yet - I tend to get 7+ years out of them. But this is the end of the road for me and the Mac. I require that my tools do what I tell them, not the other way around.
> The Mac has long been the best unix workstation on the market. It is solid, generally stable (although that's been slipping), and certainly has by far the best window manager. It has nice consumer apps for when you need them and is a solid, if not always up to date, unix. The hardware is generally great.
I was on that same line of thinking until some time ago when my old macbook pro died, and I ended up again on Linux, on a thinkpad. I'm currently running Manjaro (plasma + i3), and tbh, the Mac's window manager is awful once you get used to the power of i3. Dev experience (for anything but Mac/iOS apps) is probably better on Linux, too...
If you haven't used Linux in a while (as was my case), I can highly recommend it.
I have a System76 fully loaded little NUC. It is a beast, extremely quiet, and was a lot cheaper than a Mac. System76 customer support is really really good. You send an email and you get a response back from a developer pretty quick. I've been pretty satisfied so far. They don't make their own hardware, but they make sure a customized Ubuntu distro (Debian and Fedora are also supported) is silky smooth on all their systems. You pay a little extra, but the process was so painless and still a lot cheaper than Apple, so I'm happy.
The problem on Windows is getting and/or renewing your authenticode certificate. Dealing with the certificate authority is like spending time in a Gerorge Orwell novel.
I've been a Mac user since 2006, and I currently own a 2013 MacBook Air and a 2013 Mac Pro that I both regularly use. For a long time macOS was the marriage of Unix with commercial hardware support (even if tied to a specific manufacturer) and support for major proprietary software products such as Microsoft Office. I also loved the stability and quality of the operating system, not to mention that it looked wonderful.
Unfortunately I've been disappointed with Apple's stewardship of the Mac under Tim Cook. The move toward soldered RAM and SSDs throughout most of their lineup, the increased locking down of macOS (especially with Catalina's enforced notarization), the stagnation of the Mac Pro and then the doubling of price of the entry-level Mac Pro in 2019 from $2,999 to $5,999, and the butterfly keyboard fiasco (although finally completely over as of this week) have pushed me toward a greater appreciation of the Linux/BSD ecosystem, despite its shortcomings. I'm still using my Macs (albeit they're still running Mojave), but my long-term plan is to switch to Linux or FreeBSD, though I might keep a Mac around for Keynote use unless a compelling competitor for Linux emerges. The thought of replacing my MacBook Air with an X-series ThinkPad sounds really enticing, as well as one day replacing my Mac Pro with a Threadripper build.
This exactly. I recently resurrected my MacBook Air by replacing a dead SSD (was it coincidence that it died right after the Catalina upgrade? Can SW brick an SSD?). I’m now running UbuntuStudio on there and spending great chunks of my lockdown time re-learning Linux (after a 17 year hiatus) and trying to iron out weird kinks in my config (Bluetooth detects my Logitech K670 keyboard but just won’t pair with the damn thing).
I’ve already determined that when I pick up my next contract, I’ll be buying a Lemur Pro from System76.
Apple, you had me 17 years ago. Now you’re losing me.
I actually get it a lot less than I would expect, so no need for an apology. You may find it interesting that I actually use Linux an increasing amount of my time. However, it's still only a small fraction as of now, so the question is still valid :)
To answer the question of why I use a Mac: mostly because the hardware is good (I'm on a early 2015 MacBook Pro), the software consistent and high-quality (I refuse to run Electron) and the tooling fairly decent (I have UNIX, and MacPorts, and I can compile the rest). And it works extremely well with all my other hardware, which is something that Linux still doesn't really do well. And by this point I have enough macOS experience that while I counter-intuitively probably have more complaints about the OS than most other people, I also generally know how to fix it. While it's often compared to iOS in how annoying and locked-down it is, it's really nowhere close. Out of the box, it might be approaching that point, but macOS holds the trump card of being able to pretty much turn off everything you don't want. Want to debug a system process? Turn off SIP. Want to let your shell script manage your mail messages? Insert it into the TCC database. Apple thinks some operation is something only their code should do? Well they can pound sand, I can turn off AMFI. macOS lets you do this, and as annoying as it is to keep doing all of this it hasn't yet gotten to the point where it's enough of a drag to make me stop using it.
The answer to a slightly more on-topic question: why would I develop for macOS? The answer to that is really "I mostly don't". I have much more iOS development experience (although my most recent job in that area was actually "spotting exactly what part of your app is pretending that it's using native controls", not actual programming). I know enough of AppKit to be useful, but actually write very few apps. Most of the code is just regular old stuff that would work equally well on Linux and I just happened to compile for macOS. The rare exceptions are if I am writing something for myself (in which case I care little about any codesigning stuff) or I am contributing on an open source project (in which case Xcode takes care of this for me). I only hit these notarization/Gatekeeper hurdles recently because this particular thing needed to run on other people's computers and and had to be manually cobbled together for complicated reasons which I cannot describe at the moment.
The reason to use a Mac is because the hardware and the trackpad are so good! The OS in general is pretty good, with multi-touch gestures and homebrew [1] picking up a lot of the slack. I just bought a new (2020) MacBook Air and it's the best computer I've ever owned (bought my first computer in 1996). The keyboard is fantastic now! No Touch Bar either; only real F-keys and a real escape key.
Yes, the killing of 32-bit apps in Catalina and the code signing issues are very frustrating. It's still worth it though. People are finding ways around it. The biggest annoyance (for me) has been the breakage of 32-bit Wine. I bought a license for Crossover [2] though, so it should hold me over until the upstream Wine has 32-bit-on-64 support working.
The issues noted are specifically about the process of submitting apps to the macOS app store. A process that for iOS and macOs has been notoriously confusing and problematic with regards to the signing process.
You think you have it sorted... then boom! it wont pass signing validation and you cant submit to the app store.
It's much better than it used to be though. And it's one of those things that you do once, get it working, then forget how you did it and come back to it a year later and it's confusing all over again :-)
The dev tools themselves (XCODE) are actually pretty good.
Submitting to the store is actually not too bad, because Xcode has gotten much better at automating the process. The problem is that the steps it goes through are not very well documented, and it cannot handle some non-standard cases.
For me it's simple: it runs all the software Linux does, but also runs all the software Linux doesn't. I can use those familiar and powerful CLI tools, but I also have real Office and real Photoshop when I need it.
While things have certainly taken a tumble in the last few years with the faulty keyboards and slipping software quality, I am still yet to find a better laptop than a MacBook Pro, when considered as a complete package.
Because there isn't any other operating system that makes all the things I want to do with a computer any simpler. We've got only 3 major desktop operating systems, and they're all overly complex and poorly designed in lots of ways.
Since the late 1990's, I've alternated: I use a Mac for a while until I get fed up with it, and then I use Linux for a while until I get sick of that, and then I go back. (I've used Windows at work, and it's not any better.) I just need enough time to forget how much I hated the other one.
> I just need enough time to forget how much I hated the other one.
This is exactly how it is for me! Except I switch between all three. It's like StarCraft, each has its strengths and weaknesses.
Same way with iOS and Android. iOS is much nicer to use until I run into the inevitable, "Oh, i'm not allowed to do that", so I just carry two phones around...
I think it is less about Mac development and more about submitting it to Mac App Store. You can still make an app for Mac without submitting it to the app store, without having to deal with majority of those issues. It's just sometimes there are good reasons for wanting to have it in the app store.
No personal experience with either, but I would wager that you would encounter somewhat similar roadblocks if you try submitting things to Chrome App Store or Microsoft Store.
> You can still make an app for Mac without submitting it to the app store, without having to deal with majority of those issues.
Not any more. Apple is so much of a control freak lately that non-app-store apps on Catalina are still required to go through them for "notarization" to be allowed to run on an unmodified OS — and yes that requires the $99 account. For me personally, that's the reason I'm staying on Mojave. That and 32-bit apps.
Yes, it is really just a different set of tradeoffs now.
It isn't just notarization, it is also that notarization requires app hardening which has very strict rules. Shipping an app with 3rd party binaries that supports older versions of macOS is especially tricky to get right.
Also using direct distribution you have to deal more with Gatekeeper.
One particularly fun issue is that if you distribute your app as a zip and a user downloads (to their standard ~/Downloads/ folder) and runs it, then Gatekeeper will use path randomization (aka app translocation), which effectively makes the app look like it is on a read-only volume. Older versions of the sparkle update framework would not show update prompts if on a read-only volume (as what's the point?), and therefore if a user continued to run an app from their downloads folder they would never get updates!
Apple made this change without informing any developers that their users could be left behind for a while. I imagine this security feature prevented users from getting many security fixes.
The way to disable the app translocation is to have a user manually drag the app to their Applications folder, which is why so much software is distributed in DMGs now with the Applications folder symlink.
TIL. I thought this was just so that all apps are in one place for ease of access. When I first tried OS X in the form of hackintosh around 2009, most apps were already distributed in dmgs with "drag to install" so I just thought it's a very neat, Apple-ish way (ugh Windows install wizards) and assumed it's always been like that. Older PPC Macs were basically never really a thing where I'm from.
Now I remember seeing these weird long paths pointing to weird places with the word translocation in them — never really dug into the why. I've also seen apps ask to move themselves to /Applications when launched from ~/Downloads.
Anyway, with all these Gatekeeper changes, it's almost as if Apple doesn't want non-app-store apps at all.
> Anyway, with all these Gatekeeper changes, it's almost as if Apple doesn't want non-app-store apps at all.
Of course that's their idea, The Mac Store has been a moderate failure, so now they are pushing people into it slowly more and more every release.
As Apple and Microsoft (with their Windows Store) have learned, if there's a real choice between an app store and a standard install, nobody will pick the app store. They cannot promote it naturally, they have to push it through by force.
Well, then people have the choice of not updating because why would I if the only change that's noticeable brings more restrictions. I'm on Mojave and I don't really feel like I'm missing on anything. Both Mac OS and Windows are more or less feature-complete at this point.
Heh, I actually prefer the app store version wherever I can download it, because I like not having to think about updates; I let the software updater do it. Is this an uncommon attitude?
Developers care a lot about updates, your average user does not. For them, an update means there's a chance the app isn't going to work like it used to be.
People went as far as disabling all windows updates manually.
Also as a second point, you can totally have a software updater without an app store.
Apps did start doing this before, definitely. I always felt they were arrogant in assuming they deserved a spot in my Applications folder. I should be able to put the app wherever I'd like. At the same time dmgs seem backwards-looking since disks were "old" technology so why use an image format for them? So I was personally against distributing my software this way, but Apple forced my hand with the Gatekeeper app translocation change.
Apple themselves ships some software, like the non-Mac App Store versions of Xcode, as xips (signed zips), but for some reason decided 3rd party developers cannot use these.
Apples recommendations are in the "Shipping your Signed Code" section of this tech note:
> non-app-store apps on Catalina are still required to go through them for "notarization" to be allowed to run on an unmodified OS
Apple tries to hide the option, but you can still run non-notarization software on a Mac. The first time you run the application, open in from the right click menu. It'll give you a warning, and if you select OK it'll run. After that you can just run it by double clicking like normal, and it won't warn you.
Can't help but wonder why no apps ship with instructions on how to disable SIP and AMFI, thus effectively neutering the entire signature/notarization requirement thing for good.
And before you say "security": it ain't that if someone else (Apple) has the private key.
I've definitely seen apps that do provide instructions on how to do this; off the top of my head I know SwitchResX requires it for a lot of the features [1]. There was also the "varsectomy" bug debacle of Avid Media Composer users disabling SIP, which then lead to a bug where a Chrome update broke macOS [2].
I won't say "security" :) but I'm sure a lot of app developers do not want to be held responsible for jeopardizing users' machines or data.
While Whisk doesn't have to deal with SIP, it still has to get around sandboxing on the Mac App Store version to be able to read files that are associated with the .html page (like in an <img> tag). We pretty much need to throw up a scary dialog asking users to allow access via an Open Panel. On any "normal" (non mac app store) app this is implicitly granted, and I'm sure users don't give it a second though. I personally was worried about what the reaction to asking for permission would be and so wrote up a whole explanation on the sandboxing technology and reasons for our request [3]. Originally I did prompt the user to choose the root level of their file system, but App Store review would only approve of "project folders."
I created a commercial Mac desktop app in 2008. I sold it off late last year (2019).
It stopped being fun somewhere along the way. This was partly because I never knew what new requirement Apple was going to add with each new annual release of macOS. Would my app work? Would it not work? How many days, weeks, or more of work would I need to do to keep my app working while not actually making it better for my users?
> I don’t think it is an exaggeration to say the amount required to learn to distribute software exceeds the amount I needed to know to write the first beta of HyperEdit! I wonder if it would have gotten off the ground if I started today.
This mirrors my feeling. It might be easier to learn to program say TypeScript or Go today than it was to learn php or C in the late 90s, but actually creating a complete program, distributing it, having it run or accessed by users is much harder than when I learned to program back then.
Same story in cloud. It takes less effort to write the program than to properly set up CI/CD, permissions, auth, auto-scaling, backup, monitoring, and so many more.
To be fair, bare-metal dedicated servers are still a thing, end up cheaper than the equivalent cloud offering on bandwidth alone (as they usually come with unmetered bandwidth), and you can just SFTP your project in there and run it with nohup (not saying it's a good idea, but if you're just playing around then it's perfectly fine).
I think that's doing it wrong because you don't need those features until you do... At which point you should invest in them. Otherwise, I don't see the benefit of having them. If all you end up with is one user.
You can blame the rise of authoritarianism (for lack of a better term) and centralised control, which Apple has been very good at. The increasing bureaucracy is ultimately beneficial to Apple's bottom line.
Maybe I was just the right age as a teenager back then and it does feel cliche to say, but there really was something special and magical about Mac software like this back in those days. I miss the pinstripes and aqua glossiness, but also the fact that software in other platforms just seemed so boring in comparison!
Removing color from toolbar/sidebar icons and fixing all line weights reduces the personality of software as well as increasing usability cognition. Even with years of use, I still have trouble quickly discerning the difference between many of Mail.app's toolbar buttons!
I was thinking initially that it'd be an especially challenging thing bringing code from OS 9 into the modern era, then I realized that MacOS (formerly OS X) is almost twenty years old.
I've got some old PHP code that dates back to the 90s and is still running although I had to make some changes when my web host EOL'd PHP5 (I'd note that some of the files have a .php4 suffix).
The old app really still looks quite nice. Even windows 98-era apps look pretty good in a way.
One part of me doesn't like how much space is wasted by the new Mac UI trends shown in the second screenshot, mostly the left side panel. But I understand screens are different these days as well.
Thanks! Apps back then also tried much more to adhere to the Mac HIG, and in doing so it was pretty easy to wind up with at least not an unattractive app.
I assume you are referring to the inspector panel on your other left; the two main reasons it is wider are (1) that it shows HTML5 validation error text descriptions in the 3rd tab and (2) this is the same width we use in our other application Hype, so they now look like they belong together. I did have a moment of feeling that I was contributing to the "war on information density" with this change.
One thing I really noticed when 98.css did the rounds the other day: Old UIs were _discoverable_ in a way that modern UIs are not. It's clear what's clickable, what's grouped together, where you can grab and drag.
I think Mac apps have settled into a pleasant place for the most part, though I'm not a fan of the look of Apple's newer apps like the App Store and News.
I'm glad that the brighter colors are more subdued now, annoying UI elements like drawers and palette windows have mostly been replaced by inspector panes, and brushed metal is long gone.
I'm not sure it has that much of an effect, after all Macs aren't exactly cheap. I'd assume most people who are cost conscious are going to be targeting Android.
I don’t think Apple want hobbyist apps in the store. They want apps that will create revenue and the fee creates a filter of sorts.
It would be good to be able to side load hobby apps, but that’s never happening.
The fee does also get you 2 tech support requests, which should connect you with their engineers if you need help (never needed this, can’t say how extensive it is).
Also, I did read somewhere that they waive the fee for some nonprofit/education institutions.
Google Play store has a 25$ one-time fee. Much more affordable IMHO than 99$ annual fee. If I am being charged a 99$ fee, I simply can't share my creation without finding a way to make money off of my users. That isn't easy. Future hobbyists will be created on non-Apple platforms.
That's the whole point - making it not too affordable so that users browsing the App Store don't have to wade through too many nonserious hobbyist apps. Lowering the bar too much hurts users.
I mean, all this is about mass distribution to unsophisticated consumers, not hobbyists - without that $99 you can work on your hobby projects and you can share them with other hobbyists; the only place where that $99 is a barrier is the distribution channel to non-hobbyist users.
In essence, the message from Apple to hobbyist developers is to 'go big or go home' - if you're seriously developing something useful, then $99 is insignificant; and if the time effort you're putting in that app is not much, much more than $99 then it's reasonable to draw a line that they don't want such hobby projects on the app store. You can experiment with it and share it in small communities and when (if!) you think this project has become serious enough to go beyond hobbyists to the mass market, only then you need to pull out that symbolic $99 to demonstrate that you mean it.
Sadly, this does not work for everything, as users can't always override the notarization requirement that was introduced in Catalina. I had the issue with Aerial, it's a screensaver which, technically, is a plugin and not an application. As such, the user will never get prompted for anything (and I'm putting aside the compounding effect/slight madness that screensavers are now a plugin to an appex to two different applications with different permissions set ! Oh Catalina...).
The only solution was to sign/notarize it, and I have to admit it took me more than a few days to figure it out, as finding exactly what works for distributing a plugin was not documented. And this is just to distribute a usable plugin on GitHub !
I still use Tumult's Hype 3 (Pro, I think) to do HTML5 animations - it's pretty great, even if moving to 4/Pro for the (very few) features I'd like to have seems a bit steep at $99.
Whisk appeals to me because I _know_ it's going to be a polished, lightweight app, but with VS Code having quite usable previews I don't see the value of its current price point (to me).
Cool story. In a way I'm surprised one would try to adapt the old code after so much time has passed, rather than just starting fresh. It can definitely be interesting, just more... frustrating.
I guess Objective-C/Cocoa might have not changed much between the last HyperEdit version and now. If the developer organized his codebase well, replacing the old webview with the new stuff and so on should be less work than rewriting the whole app (IMHO).
I haven't coded for the mac in more than a decade but what I remember from ObjC/Cocoa was that it was quite pleasant to use and very powerful. By powerful I mean that the ratio between LoC and smiles on my face was skewed towards smiling.
That's true. I maintain a couple of obj-C iOS apps (one of those ~10 years old) and apart from framework upgrades (iOS 6-7 was a big one) and dealing with a few deprecations, it's been surprisingly friction-free.
macOS is probably even more stable.
Swift, on the other hand... it's been a moving target for sure, and I'm glad I didn't just rewrite everything (like I did for one app).
I imagine in the end not much old code was left, but if his initial code was well structured I can also see how it helps to not start from a blank slate. The structure you see in the names of files, classes etc. can make it easier to keep a mental model of the app that you’re building.
Every modern web framework has auto reload, so this is an app that’s only targeting people who know HTML well enough to hand write a page but don’t know about modern web development. Good luck, but I can’t imagine it’s a growing market.
I absolutely wondered the same thing when doing the update as the world isn't 2003 anymore. But I have found it useful even when doing modern web development as a quick playground to try snippets. "Live as you type" speed can change your iteration flow vs. an often slower rebuild+auto reload cycle.
This was more of a passion/craft project than one I expect will make a gigantic impact. A side motive was to help move out some code of our Hype app to an "app shell" where I can more quickly make other applications with the same trial/licensing/windowing/etc. components.
I build my website with Jekyll 4 and use livereload, but have actually found some use out of this tool for writing small snippets. Seeing your CSS come to life with every keystroke in real time (without having to press CMD+S in your IDE) is surprisingly useful.
The main use-case where this tool has been useful, though, is when I'm working on my Mac app that uses WKWebView and Javascript pretty extensively. It's much faster to get little JS snippets right compared to the really slow build+run cycle in Xcode.
I had to manually create, sign, and notarize a Mac app the other day and it was total madness. It took multiple tabs of Apple documentation (new documentation, I might add, created this year because everyone complained last year about how the process was impenetrable) and back-and-forth with some seasoned Mac devs before I had something that would launch successfully on a fully updated, GateKeepered system.