I'm polishing up a macOS app for the store. How much time should I expect to budget for the initial signing/notarizing/submission process?
[deleted]
The Gates to Hell: Apple’s Notarizing
131–140 of 214 posts
Re: The Gates to Hell: Apple’s Notarizing
#132Earlier quoted context omitted.
Looks like this explains how: https://www.digicert.com/kb/code-signing/mac-os-codesign-too... but... "only Apple Developer code signing certificates are compatible with GateKeeper" Does code-signing with an ad hoc certificate and no notarization provide any better experience than just unsigned code? Do you get a friendlier message (c/f "malicious software: Move to Trash") when Gatekeeper blocks it?
Unsigned (arm64) binaries don't run at all on M1 Macs, so yes, an ad-hoc certificate provides a better experience ;)
I just tried an unsigned bin on M1 Big Sur and the experience is the same:
it's initially blocked with a "Move to Trash" dialog
but you can go to security prefs and click "allow anyway"
Then try again, click "open" rather than "move to trash" on another warning dialog and the file does get run.
I haven't tried a signed+un-notarized one but it sounds like it'd be similar?
Re: The Gates to Hell: Apple’s Notarizing
#133Earlier quoted context omitted.
Don’t use codesign --deep, it’s mostly broken. Sign manually from the inside out.
You're gonna need to expound on --deep being broken, considering I've not run into a single issue with it, and judging by the majority of blog posts/docs that cover this, others have the same experience.
I'm assuming it doesn't work well with nested bundle signing. As per my other thread it also seems to be picky about which subdirectories it signs, and there are lots of weird paths (LaunchDaemons, XPCServices, LoginItems, etc) you can put stuff in that needs signed. Not to mention if you put anything needing a sig in Resources.
Re: The Gates to Hell: Apple’s Notarizing
#134Earlier quoted context omitted.
Well yeah, "software", including drivers and OS integration, not just "apps". Linux phones no longer seem limited by hardware or cost (at least judging by my PinePhone), more stability and support. Once stability is there in terms of reliability of the core "Minimum Viable Phone" apps, which seems relatively close, there will be a great opportunity for design-oriented founders/brands to craft highly polished experien…
Branded phones have been a thing for a very long time, and not enough people are interested in them to make any of them successful. I'm glad that you're happy with your PinePhone, and I hope that one day in the future it achieves perhaps 1% of the global market for smartphones. I doubt it, but that would be nice.
Where's a good branded phone?
Linux is already running on the majority of smartphones, individual manufacturers and distros seem less important. Any Android user would switch to another Linux phone with the right features, price, etc.
iOS seems poised for a slow ride into irrelevance as developers start suing them and begin leaving (Basecamp, Spotify, Epic...), before long they'll be the dusty old devices in schools like 25 years ago. Apple (legacy Mac OS) and Microsoft (Windows Mobile) have both lost before because they lost the developers.
Microsoft has been very smart in their recent plays in this regard, regaining a huge amount of developer trust over the past 5 years or so.
Re: The Gates to Hell: Apple’s Notarizing
#135Earlier quoted context omitted.
You're gonna need to expound on --deep being broken, considering I've not run into a single issue with it, and judging by the majority of blog posts/docs that cover this, others have the same experience.
I'm assuming it doesn't work well with nested bundle signing. As per my other thread it also seems to be picky about which subdirectories it signs, and there are lots of weird paths (LaunchDaemons, XPCServices, LoginItems, etc) you can put stuff in that needs signed. Not to mention if you put anything needing a sig in Resources.
Hmmm, well I'm willing to believe it then, yeah (although I definitely have a nested bundle setup in a project where --deep works fine... odd).
This is good to know though, and hopefully this exchange helps someone in the future too (actually, this would make for a good blog post - this kind of nuance is lost in most of the docs/existing posts).
Re: The Gates to Hell: Apple’s Notarizing
#136Earlier quoted context omitted.
Coined? We talked about web apps, desktop apps, mobile apps back in the early '00s, before Jobs unveiled the iPhone, which initially supported only web apps, if you missed those days.
okay so you don't know who coined the term "app", got it
Who first shortened the word "application" when referring to software? Maybe someone in the '80s, or earlier?
Looks like it's attested by '92.
Re: The Gates to Hell: Apple’s Notarizing
#137Earlier quoted context omitted.
Coined? We talked about web apps, desktop apps, mobile apps back in the early '00s, before Jobs unveiled the iPhone, which initially supported only web apps, if you missed those days.
okay so you don't know who coined the term "app", got it
App is shorthand from application, no known person "coined it", because that term is going back to eighties or earlier.
Apple had MacApp (which was application framework) in 1985, that time app was already well known shorthand, for example Atari had file extension .app.
Unrelated, but TOPS-10 operating system had executables named with extension .exe, that happened somewhere in 1967-1970. TOPS-10 had lots of interesting stuff, that later is similarly done by newer OSes. Probably my favorite is ctrl+t, which sends SIGINFO in FreeBSD, giving you status from current running program. And what we see in TOPS-10 manual: "When you type CTRL/T (control-T), the monitor prints status information pertaining to your job on your terminal."
:)
Re: The Gates to Hell: Apple’s Notarizing
#138Earlier quoted context omitted.
Branded phones have been a thing for a very long time, and not enough people are interested in them to make any of them successful. I'm glad that you're happy with your PinePhone, and I hope that one day in the future it achieves perhaps 1% of the global market for smartphones. I doubt it, but that would be nice.
Where's a good branded phone? Linux is already running on the majority of smartphones, individual manufacturers and distros seem less important. Any Android user would switch to another Linux phone with the right features, price, etc. iOS seems poised for a slow ride into irrelevance as developers start suing them and begin leaving (Basecamp, Spotify, Epic...), before long they'll be the dusty old devices in schools…
BMW, Facebook, KFC, and Yahoo! are branded phones I remember off the top of my head, but even Microsoft gave up on the phone business because they couldn't gain traction.
"iOS seems poised for a slow ride into irrelevance" is quite a thing to say the same week Apple announced all-time record Q2 revenue on the back of their iPhone business. It's up there with "this is the year of Linux on the desktop" as a perennial statement that will eventually have to be right*, sometime between now and the heat death of the universe.
You're focused on where the developers are, as if that were the leading indicator, but I think history tells us that developers go where the users are more often than the other way around. Neither users nor developers seem to be much discouraged by Android or iOS, and neither are stampeding toward PinePhone, either.
In any case, you're making a lot of future claims that I find ludicrous, but I'm not a betting man, or I'd take your money.
* Not really
Re: The Gates to Hell: Apple’s Notarizing
#139For our small software company, notarization took at least 40 hours of additional work, and slows down releases. Anyone knows if "stapling" the distributed bundles files (.app .pkg executable files etc.) is useful in any way ?
I rearranged my CI graph to run notarization in parallel with my unit tests, and turned on GitLab's DAG to allow jobs from different stages to run at the same time as long as their dependencies are satisfied, so the impact of the notarization step has been small. My CI pipeline is build -> test -> deploy. The Mac "build" job uploads the app for notarization as a side effect. There is an additional "mac archive" job d…
Oh, I do notarization after building my .zip containing my .pkg, are you saying I could notarize each bundle separately and I dont need to notarize the final .zip ?
Re: The Gates to Hell: Apple’s Notarizing
#140I wrote a little sh script to notarize HandBrake two (or maybe three) years ago, and that's was it. It's not rocket science. But like every new thing, it required a bit of time to read the documentation and to understand what's going on. The plugin issue described in the article is probably related to the hardened runtime, so it's unrelated to the actual notarisation process.
While you only have to update your build process once, you now have a noticeable delay for every single release build, and worse, a few times per year, your build will break because you haven’t signed Apple’s latest contract.
And for what? There is no way Apple can make it impossible to get malware notarized.