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.
Reviving a 16-year-old Mac App
31–40 of 108 posts
Re: Reviving a 16-year-old Mac App
#32> 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…
[deleted]
Re: Reviving a 16-year-old Mac App
#33Every 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.
Or developers who want to write basic HTML webpages without use of any of the bloated modern frameworks...
Re: Reviving a 16-year-old Mac App
#34Every 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.
Education?
Re: Reviving a 16-year-old Mac App
#35> 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…
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.
Re: Reviving a 16-year-old Mac App
#36Earlier 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'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 wonderfu…
It's the trackpad that keeps dragging me back in... it's a hard habit to break.
Re: Reviving a 16-year-old Mac App
#37> 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?
You use a Mac because the user experience is really nice, and you develop for Mac because your users are there.
Re: Reviving a 16-year-old Mac App
#38Earlier 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'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 wonderfu…
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.
Re: Reviving a 16-year-old Mac App
#39Earlier quoted context omitted.
> 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…
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.
Re: Reviving a 16-year-old Mac App
#40The 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.
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.