Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reviving a 16-year-old Mac App

blog.tumult.com

Post reply on HN
Print view View original

21–30 of 108 posts

Re: Reviving a 16-year-old Mac App

#21

Post by saagarjha »

firecall wrote: post #17
kick wrote: post #12

Earlier quoted context omitted.

This may be a question you get a lot, and I apologize in advance if it is, but: Why use Mac, if it makes so simple of things difficult?

It's generally a solid OS. 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 th…

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.

Re: Reviving a 16-year-old Mac App

#22

Post by _jal »

kick wrote: post #12
saagarjha wrote: post #7

> 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…

This may be a question you get a lot, and I apologize in advance if it is, but: Why use Mac, if it makes so simple of things difficult?

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.

Re: Reviving a 16-year-old Mac App

#23

Post by tumultco »

grishka wrote: post #15
filoleg wrote: post #13

Earlier quoted context omitted.

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 su…

> 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…

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.

Re: Reviving a 16-year-old Mac App

#24

Post by makecheck »

saagarjha wrote: post #7

> 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…

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.

Re: Reviving a 16-year-old Mac App

#25

Post by tumultco »

makecheck wrote: post #24
saagarjha wrote: post #7

> 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…

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 y…

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.

Re: Reviving a 16-year-old Mac App

#27

Post by linguae »

kick wrote: post #12
saagarjha wrote: post #7

> 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…

This may be a question you get a lot, and I apologize in advance if it is, but: Why use Mac, if it makes so simple of things difficult?

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.

Re: Reviving a 16-year-old Mac App

#28

Post by chongli »

kick wrote: post #12
saagarjha wrote: post #7

> 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…

This may be a question you get a lot, and I apologize in advance if it is, but: Why use Mac, if it makes so simple of things difficult?

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.

[1] https://brew.sh

[2] https://www.codeweavers.com/products

Re: Reviving a 16-year-old Mac App

#29

Post by gwbas1c »

makecheck wrote: post #24
saagarjha wrote: post #7

> 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…

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 y…

> It’s so frustrating that automation and command-line is treated as almost second-class citizenship on macOS.

Try automating signing a windows driver. It's all GUI.

At least the mac code signing tools are command-line.

Re: Reviving a 16-year-old Mac App

#30

Post by kick »

saagarjha wrote: post #16
kick wrote: post #12

Earlier quoted context omitted.

This may be a question you get a lot, and I apologize in advance if it is, but: Why use Mac, if it makes so simple of things difficult?

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 r…

Thanks for the detailed response!
Post reply on HN