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!
Reviving a 16-year-old Mac App
11–20 of 108 posts
Re: Reviving a 16-year-old Mac App
#12> 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…
Re: Reviving a 16-year-old Mac App
#13> 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?
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.
Re: Reviving a 16-year-old Mac App
#14> 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…
And before you say "security": it ain't that if someone else (Apple) has the private key.
Re: Reviving a 16-year-old Mac App
#15Earlier 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 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…
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.
Re: Reviving a 16-year-old Mac App
#16> 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?
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.
Re: Reviving a 16-year-old Mac App
#17> 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 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.
Re: Reviving a 16-year-old Mac App
#18> 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?
If your a Mac user, you can copy and paste one line in the Terminal and you can run whatever simple unsigned apps you want.
Re: Reviving a 16-year-old Mac App
#19> 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…
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.
Re: Reviving a 16-year-old Mac App
#20> 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…
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 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 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."
[1] https://www.madrau.com/support/support/srx_1011.html
[2] https://arstechnica.com/information-technology/2019/09/no-it...
[3] https://tumult.com/whisk/documentation/v2/app-security.html