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

41–50 of 108 posts

Re: Reviving a 16-year-old Mac App

#41

Post by realusername »

grishka wrote: post #39
tumultco wrote: post #23

Earlier quoted context omitted.

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…

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…

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

Re: Reviving a 16-year-old Mac App

#42

Post by saagarjha »

tumultco wrote: post #25
makecheck wrote: post #24

Earlier quoted context omitted.

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…

altool actually blocks for some things, like performing the actual upload…

Re: Reviving a 16-year-old Mac App

#43

Post by kccqzy »

searchableguy wrote: post #10
kccqzy wrote: post #6

Earlier quoted context omitted.

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.

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.

> If all you end up with is one user.

This isn't what I'm talking about. With just one user, even for desktop software the complexities of distributing the software are negligible.

Re: Reviving a 16-year-old Mac App

#44

Post by grishka »

realusername wrote: post #41
grishka wrote: post #39

Earlier quoted context omitted.

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…

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

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.

Re: Reviving a 16-year-old Mac App

#45

Post by mypalmike »

searchableguy wrote: post #10
kccqzy wrote: post #6

Earlier quoted context omitted.

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.

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.

A lot of developers, particularly at larger companies, do actually need these things before launching a service.

Re: Reviving a 16-year-old Mac App

#46

Post by tumultco »

saagarjha wrote: post #42
tumultco wrote: post #25

Earlier quoted context omitted.

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…

altool actually blocks for some things, like performing the actual upload…

Which could sometimes be a ridiculous amount of time itself too!

https://twitter.com/rosyna/status/1194765305987227649

Re: Reviving a 16-year-old Mac App

#47

Post by 1-more »

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…

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.

Re: Reviving a 16-year-old Mac App

#48

Post by tumultco »

earthboundkid wrote: post #31

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.

Re: Reviving a 16-year-old Mac App

#49

Post by tumultco »

grishka wrote: post #39
tumultco wrote: post #23

Earlier quoted context omitted.

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…

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…

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:

https://developer.apple.com/library/archive/technotes/tn2206...

Re: Reviving a 16-year-old Mac App

#50

Post by userbinator »

saagarjha wrote: post #19
grishka wrote: post #14

Earlier quoted context omitted.

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.

Because such an action requires rebooting the computer, which is generally where your users stop listening to what you have to say.

...unless you're using Windows.
Post reply on HN