Safari 14 added WebExtensions support, so where are the extensions?
sixcolors.com
sixcolors.com
Xcode development, the Apple Developer Program, and the whole experience of trying to ship your application on the Apple ecosystem is the fucking plague.
I will do it if I'm paid for it - I generally charge twice my hourly rate for anything Apple - but I certainly won't go through the trouble of trying to get any of my hobbyist projects into Apple's walled garden. I like to do enjoyable things in my free time, and the timesink that is Apple's proprietary clusterfuck is anything but fun.
Apple's desktop market share being what it is, I cannot comprehend how they're generally getting away with this.
That's because you're a developer that works in different platforms ("Apple, Android, Windows, Linux"). So you probably spend most of the time working in some other platform, and doing macOS work for you is just an annoyance, having to context switch to another process, etc.
Apple tho wants macOS developers (and users prefer apps from people dedicated to macOS). That's because such vendors (e.g. Panic, BareBones, Omni, and so on) won't do lowest common denominator apps, they keep up with the platform, they understand it, they hook in to new platform-only capabilities, etc.).
>Apple's desktop market share being what it is, I cannot comprehend how they're generally getting away with this.
Apple's market share is what it is, in part because they enforce things like this. This means they can add new OS/hardware features and devs will add support for them fast (instead on relying to 1000s of half-ported apps, with shared functionality on Windows and Mac, and horrible cross-platformy UIs).
That's also why (forcing more people to use XCode, and thus the official APIs, BitCode, and so on), they can introduce a whole new architecture like AS, and have macOS apps support it from day one, or old x86 apps running smoothly translated.
Why is it such a hassle to install a vim extension, requiring code-signing shenanigans? In other IDEs and text editors this is at most a few button clicks to install an extension.
The "Scheme" system to manage per-target options is a joke even when being used to it.
The debugger variable-view-panel is extremely bare-bones.
Xcode used to be slick, but since a few years everything gets bigger, slower and laggier. Starting up, loading projects, starting into the debugger all takes much longer than it should.
It's unclear how the "new" build system is any better than the "old" one. Apart from being slower than the old one I haven't found any differences so far.
The one thing where Xcode shines and was ahead of the competition is the easy integration of C/C++/ObjC validation tools like clang analyzer, ASAN, UBSAN and TSAN.
If you are dealing with Xcode settings, move everything you can into xcconfigs, full stop. Just do it. It will save you countless merge conflicts, you'll be able to do mix and match and inheritance easily, and you'll actually understand what your build process is doing rather than it being a black box. I have no qualms blowing away targets and schemes now because I can just make them on demand and let Xcode autocreate the rest. I can "rebrand" an app in seconds and undo the changes in the same amount of time. Things which get used by other people always have ⌘B do the full build rather than some strange dance of "oh CocoaPods changed those settings so you should try to not set your development team on these targets and the dependency analysis is a little broken so…".
Debugger variables are…fine, I guess? I think the biggest issue I have with it is that it's placed in a not-so-great place, where it is generally to small to really see things. So usually I grab that information myself through a combination of p/po.
Xcode is still slick, IMO. Performance wise I haven't seen a huge change–it gets steadily bigger and slower and more complicated, but at about the rate that I update my computer. The people testing Xcode are clearly not using an Early 2015 MacBook Pro like I am, so I write off some of the features like Playgrounds or Previews or many simulators, but other than that I guess it's fine? I certainly value that it opens "immediately" rather than "initializing" (looking at you, Java-based IDEs…).
Where Xcode really shines is the things you touched upon: its integration with LLVM is first-class. It's certainly my preferred frontend to LLDB. The ability to flip on a bunch of diagnostics with one click has surely found many bugs, and the the built-in tooling for debugging memory graphs and view hierarchies is quite good–yes, it breaks sometimes, but it gives me useful results that I can't quickly get anywhere else nine times out of ten. Instruments is certainly unparalleled on macOS for external developers, and in comparison to tooling elsewhere it's a very solid offering.
Finally, of course, it's a nice native Mac app that plays well with all the other ones. That has to count for something :)
It's the text editing portion of it that's really lacking IMO. It's only has multi-cursor support and tabs (tabs!!) for a couple of years.
It has had tabs since forever. As for multi-cursor support, that only got really popular in the past few years (first on Sublime Text iirc).
Obviously for a business this is a neglegible cost but for someone just making a hobby app, it's ridiculous. microsoft at least offers VMs with edge and ie on it
Sorry, why do you want to make a hobby app for a platform you don't own?
Even the ones reaching hacker news seems to fiddle down after just a couple of years and die out.
I’m starting to wonder... here around 4 out of 5 business close down within a couple of years, how is that ratio for business making a software product? Is software a victim of its own success? The market is clearly there, but the competition is ruthless, the stacks ever changing and the risk seems to increase year for year.
At the same time we code on our free time and happily give away our code for free.
Tried to find a study where they showed that gambling addiction and programming addiction operated similarly but it seems to have been scrubbed of the internet.
IMO median(!) salaries will go down relative to other diciplinaries. coding is just too fun.
I believe the reason sandboxing destroyed the Mac software ecosystem is because it's too restrictive to support the kinds of productivity utilities that have historically thrived on the platform. And those apps are too small to handle promotion without Apple's help, Apple's help now being reserved for apps in the Mac App Store, which are by extension sandboxed.
So while I agree in principle, in practice the real result is Mac App Store apps are just getting utterly destroyed in the marketplace, it's truly a slaughter as I've cataloged here (https://blog.robenkleene.com/2019/08/07/apples-app-stores-ha...).
And yet, MS Office, Lightroom and others are on the App Store.
1. Lightroom is easy, Lightroom Classic is not in the Mac App Store and is still supported. Anecdotally Lightroom Classic appears more popular than Lightroom, especially among professional photographers where it's fair to say Lightroom is shunned. So Lightroom is Adobe's attempt to have it both ways.
2. Office is much more interesting. I honestly find it shocking that Office is in the Mac App Store, since I don't think it's in Microsoft's best interest. I think the reason is that the Mac versions of Office are really stripped down and separate code bases than the PC versions, and I'd guess that this decision was in some way made possible by that separation (e.g., if there's a feature that's not possible in sandboxed version, it can just be stripped from the Mac version, which would be more difficult with a shared code base). I'd also guess that this will eventually be reversed as Microsoft is on a path to making cross-platform web-based (Electron/React Native) versions of all their software, and I don't expect those to be sandboxed.
For the record, by productivity software, I didn't mean things like Office and Lightroom (my fault for not being clear). I meant utilities like LaunchBar, Keyboard Maestro, Moom, etc... e.g., launchers, window managers, and the like, which generally need more privileges than sandboxing allows, because they involve scripting, interacting with other apps, etc... A lot of the indie Mac app community centered around these apps because they allowed users to get a lot of value without much code (relatively) by adding smaller, system-wide, features.
Document-based apps work much better with the Mac App Store, but those apps tend to be an order of magnitude more work to make, therefore there were always much fewer of them. Document-based apps also have a lot of problems with Sandboxing, but at least they're possible to make sandboxed.
Microsoft has received special sandbox exceptions from Apple that are not available to other developers.
A lot of people?
There are more Mac users (and thus app buyers) today than ever were, several times more than in the 80s and 90s.
If people don't do it it's because they can make a quicker buck elsewhere (e.g. web SaaS and such), not because it's a worse market in absolute terms.
It sure beats being an indie game dev, that's for sure...
Name them. This is a serious request. I'm a longtime professional Mac developer who knows a lot of other Mac developers.
> There are more Mac users (and thus app buyers)
The premise is true, but the conclusion is not necessarily true. The crap store and the iOSication of the Mac have really hurt the Mac software market.
I get all kinds of great new Mac apps from new devs, so not sure what you mean. Some examples I've personally use and bought in the past year or so: Darkroom, CleanShotX, Bear, Amadine, Wipr, Keka.
If we can go a few years back there's tons of other stuff that's still going strong too with new versions regularly and everything...
Bear: 1) Bear is not Mac-only: https://apps.apple.com/us/app/bear/id1016366447 2) Bear is more than 4 years old 3) Shiny Frog, the maker is Bear, is even older than that
Wipr: 1) Again, not Mac-only. In fact, Wipr started as iOS-only. https://apps.apple.com/us/app/wipr/id1030595027 2) Wipr is more than 5 years old
Darkroom: 1) Not Mac-only https://apps.apple.com/us/app/darkroom-photo-video-editor/id... 2) Darkroom is 6 years old
Amadine: 1) Not Mac-only https://apps.apple.com/us/app/amadine-vector-drawing/id13391...
It sounds like, to me, I can't ship a WebExtension for Safari because I don't own a Mac. Is that right?
Does that sound right to you?
Do you ship untested software?
The whole point of having standards, conventions and stable interfaces is that developers do not have to test their code on every "platform" (in this case browser). If there are platform-specific differences from the standards, that is the platform developer's problem.
And keep in mind we're mostly talking about individuals here - companies rarely develop extensions and those that do can probably afford an old mac to use as a complie box. Extensions are usually developed by individuals in their spare time and rely on beta testers anyways, as it is already impractical for one dev to test them on every possible config.
Well, we don't have standards for native apps, only partial standards for different APIs and protocols, so there's that.
And the change Apple made, to allow for Chrome-like extensions, is already more "standard" than before (where it was Safari-only extension APIs). It just requires one more step.
Chrome is notorious for building this that are not standards and forcing them into standards bodies later. That's part of "but it works on Chrome" web issue.
So not working on Safari doensn't necessarily mean it's the fault of Safari for "violating the standard". Could very well be for upholding the standards over Chrome ad-hoc/de-facto "standard" additions...
I was actually referring to "your extensions following the standard", but since you can't exactly test against the standard directly, I used testing against both browsers as a good approximation.
I maintain a cross browser webextension (chrome and Firefox) and I would not release it on a new platform without testing. I have already found bugs in the API implementstions on Firefox and confident I'll find more. There are also differences in implemention between just those two browsers that I have to work around.
YMMV, of course
Because there are more browsers than any person could conceivably have time to rigorously, thoroughly test. Yes, things like Browserstack exist.
But why do I have to test my Web Extension differently from my website. Should Safari start blocking websites whose TLS certificate lacks a "issued-to-a-mac" extension?
Sorry, I don't trust extensions or programs from people who won't even own a machine to test them on for that particular platform!
It's completely fair–actually, it should be expected–that extensions targeting standardized APIs should function correctly regardless of platform. If you're coming from a position of trying to incentivize people who largely don't care about a tiny, strange platform to begin with, locking them out entirely based on hardware requirements is frankly about the worst thing you could do to drive adoption.
Mac users are just fine with cross platform apps.
But even so, Photoshop, Premier and co, has ties to native functionality, gets the native look and feel for things like file dialogs and such, is quick to move to Apple Silicon / M1 natively (and even has a native iPad version, complete with native UI) and so on.
It's not some lowest-common-denominator cross platform affair, like most cross platform lesser GUI apps are.
Also, Word and co. Microsoft apps are not cross-platform. They are special codebases for macOS, complete with macOS native UI and everything.
A better example would be Pixelmator.
The have some approximation of the best environment given Apple's priorities, where customer experience, security and privacy, and the bottom line are considered significantly more important the developer experience.
Most people I know day to day who insist on Macs spend all their days using Chrome, VSCode and Slack with little else.
The days of the Mac UI apps built by passionate Mac developers being the Mac advantage are over. People like myself who still use native Mac software like TextMate, Safari, Transmit for the Mac UI are absolutely a small and shrinking minority.
I think while Apple has been looking the other way to iOS the past 10 years this moat of MacOS better 3rd party app experience through native ui frameworks has been completely eroded and now most MacOS users are just doing their work via Chrome wrappers.
What about thousands of small devs/companies who are not Panic or others having contacts inside Apple and a privileged position? Here on HN there's at least one horror story a month about issues someone had with Apple, from ever changing terms, to review process that takes for ever - while still doesn't manage to catch many real offenders (especially in terms of privacy issues), but slows down legit devs trying to quickly fix bugs and close the security holes in their apps. It has become a layer over a layer of bureaucracy which more and more seems to be it's own purpose. Honestly there are much easier ways to make money as a programmer.
Looking at that pragmatically, if Apple are managing to keep "media worthy" problems down to about 12 cases a year they're doing an amazing job.
With 2 million programmers, a marketplace of 100billion, and millions of apps, "one horror story a month" (i.e. "somebody was annoyed on the internet and posted about it") sounds like a huge success story. And many of these are non-stories, or stories of the kind "Me, one of 1.5000.000 programmers on iOS/macOS stores, had an app rejected for some reason".
We never hear the Linux horror stories of commercial developers trying to sell native apps. If we did it would be more like:
"I tried to make a living with a native desktop app - FOSS or proprietary - for Linux, but nobody seems to care and fewer would pay, plus between GNOME, KDE, XFCE, and 10 popular distros, the landscape is a fragmented mess. Oh, god I wish there was an App Store for all, and $100/year to give me access to customers who will actually pay and a way out of this mess".
>while still doesn't manage to catch many real offenders
Why would one expect it to? No system is perfect, it's enough that it catches most offenders, or more offenders than alternative systems. E.g:
https://www.pandasecurity.com/en/mediacenter/mobile-security....
+ Desktop environments aren't the issue, they're just graphical shells. It's the rendering toolkits like Qt or GTK which matter more. And even then, you basically just pick one and move on.
+ Yeah the multiple package managers situation can be annoying for non-free software. But then that's still better than a monopoly like on iOS.
I've seen you've posted multiple comments attempting to defend Apple's ecosystem (ironically some of them contradicting other posts of yours in the same thread) but you're still missing the point that developing software for Apple platforms is a massive headache and a massive drain on the wallet in ways that isn't true for any other platform. I honestly don't think Apple care much for developers outside of their own in house teams because the process is so mindbogglingly shitty for everyone else.
Multiple package managers are not an issue either. In this day and age, you should be using Flatpak. That would also allow you to target very specific ABIs in a cross-distribution way, thus removing the fragmentation excuse.
And how is this different for AppStore? More and more abandonware, and more and more cheap/freemium clones and garbage - noise to signal ratio is much lower than on say Linux. From a dev perspective, unlike a decade ago, now there's very little room to make any significant money just by building and selling simple desktop apps as indy dev. Now you need a SaaS, or some freemium upsell scam and a lot more marketing skills, plus Apple takes their share of every possible income channel you have and gives very little in return. That's at least my experience.
There's a little bit of mutual blindness that happens here both with anti-Apple commenters and pro-Apple commenters. It's absolutely true that Apple's tight integration and control over how developers work allows them to do things with their platform that no one else can do. It is also true that Apple is playing a very dangerous game with the MacOS ecosystem, and a lot of developers are looking at it and saying, "this is not a healthy relationship, there's zero reason for me to ever support this platform."
To a certain extent, Mac users don't care -- many of them are happy to be part of a diverging software ecosystem and to use apps that only work on their computers. Apple critics sometimes underestimate just how OK Mac users are with the idea of living in an isolated software world. To many Mac users, being in their own isolated, incompatible world of software is the point. But, it is also true that browsers like Safari are tangibly suffering for this, that Open Source developers and tool authors are starting to look at Mac as a losing battle, and that ultimately, if things continue in the same direction, this is going to mean that there is a lot more pivotal indie software/games/tools that decide not to support Mac -- and some of those will be programs that people on Mac actually want.
As an Apple critic or at least an Apple skeptic (even though I do some development on Mac hardware), I am curious what the future of Mac as a development platform is going to be. There was a period where I recommended Macs as a next-best alternative to Linux because of that Unix base. Now it is a very cautious recommendation, if it is a recommendation at all. I've run into more than a few really weird dev problems on Mac over the past year that have been kind of disruptive, and I haven't even updated to Big Sur yet -- which, from what I can tell introduces even more problems. In contrast, developing software (especially web-based software) on my Linux machines is pretty painless. And when I need to test in Windows, I can spin up free, official VMs. I don't have to have a special secondary computer to run tests on. So unless I'm building software specifically for Mac, it just kind of doesn't make sense to support anymore.
And frankly, if you're a solo developer who's into Open Source development or tools development or game development, you're very probably not going to be building software specifically for Mac, and you're probably willing to drop Mac if it means you can easily target Linux/Windows -- given the choice between MacOS and Windows, most devs are not going to choose to drop Windows. I mean, we can debate OpenGL and Vulkan, but I'm sure as heck not going to write a game that targets Metal, that would just be a colossal waste of time for realistically a rounding error in market share. This is something that Mac users are currently able to just shrug off (in no small part because of 'lazy' cross-platform apps/games that use Electron, QT, and Unity), but it might be a harder problem to ignore in the future.
As an Apple fan -- albeit one who came back to the platform after years with FreeBSD, Windows 2000/XP, and BeOS (yes, full-time for over a year) and who uses Linux via ssh daily -- I am concerned what the future of the Mac as a development platform is going to be. I think your first paragraph is right on point.
I don't mind Apple going their own way with Safari to some degree, and there are things I just like about it as a browser -- it's fast, I find its minimal UI a bit more to my taste than either Chrome or Firefox, and I like that it syncs tabs and bookmarks between all my devices. (Yes, I know I could get that if I fully committed to either Firefox or Chrome.) But adapting WebExtensions support and then requiring developers to wrap those extensions in Xcode-built Mac applications that have to be published on the App Store just seems like Apple shooting themselves in the foot. It may be a handsome space gray gun milled out of a single block of aluminum, but it's still a problem.
(I'm also not sure why Apple won't at least support Vulkan in addition to Metal, but that's probably a different discussion.)
Likely for the same reason Microsoft doesn't support Vulkan - they want to have full control over their own graphics API.
The only commercially licensed/supported platform that requires Vulkan AFAIK is Android 10+ on 64-bit devices. However, I don't believe Google ever stepped up to standardize high performance graphics, so Vulkan was their best jump after OpenGLES started to sink.
iOS is the future of Mac as a development platform. You can't develop for the iPhone without a Mac, many more developers care about iPhone than Mac, and Mac now offers (bad) support for running iPhone apps and cross-platform apps with Catalyst.
This is a very strange argument to make in the context of Safari Web Extensions. Safari already had its own Apple-specific app extensions API, but it seems that Apple decided this was not sufficient, so they implemented the cross-platform WebExtensions API too. Clearly Apple is trying to recruit non-Mac developers with their command-line conversion tool for existing Chrome and Firefox extensions, and automatic generation of a Mac app wrapper.
If Mac developers were sufficient for this purpose, then WebExtensions support would not have needed to be added to Safari at all.
So many Apple complaints boil down to "it's not Windows or Linux". If you learn the platform, little about Xcode/the dev program/etc is surprising. Perhaps slightly annoying in an extra step or two, but nothing too unmanageable.
IMO, the bigger problem with developing for Apple's side of things is documentation - particularly, for things that need to exist outside of Apple's "blessed" path. If you're just in Xcode, things will mostly work - if you're outside of it, it can be confusing at first, for sure.
That's also why (forcing more people to use XCode
and thus the official APIs, BitCode, and so on),
they can introduce a whole new architecture like AS
and have macOS apps support it from day one, or old
x86 apps running smoothly translated.
1. Painful for the parent commenter. It is painful for me, too. It might, or might not, be painful for others.
Of cause it could be that Xcode is very finely tuned to Apples needs, which may be radically different from those of 3. party developers.
Well, who says it is objectively painful (as opposed to just not what the grandparent is used to or prefers)?
XCode (with swift) seems to crash on me regularly just with normal usage. The last time I used it occasionally it would lag so badly that it sometimes lost characters I was typing, and my code would come out completely garbled (what!?). A few weeks ago I tried to do a local build of Signal's iOS app and the swift compiler errored out on some random function. Apparently it spent so long doing type inference that it decided to just generate a compilation error instead. I guess I'm not wealthy enough to even compile swift code slowly. (For reference, this on a $3000 (AUD) macbook pro from 2016 with 16 gigs ram, the latest xcode and nothing else open).
Back in the objective-C days I used to really like XCode and loved interface builder. The documentation and ecosystem seemed top notch. But in the last few years its gotten much, much worse. Its like the old guard have left and a young generation have come in to develop the swift ecosystem - and they just don't have good judgement yet. The documentation is halfbaked at best. The whole environment is an overcomplicated, buggy, laggy mess. Its a pity too, because I think Swift is a lovely language and I love what they're doing with SwiftUI.
In comparison I find microsoft's tooling around their languages to be excellent. Visual studio + vs code are fast, stable, feature rich and responsive. Particularly with microsoft's own languages: C# and typescript.
For instance a sprawling project with an even split of Objective-C and Swift that constantly call into each other can bring SourceKit to its knees, as can some CocoaPods setups. Going Swift-only or even just reducing the surface between Objective-C and Swift to the absolute bare minimum can speed things up a lot.
As for writing style, there's a few things that can trip SourceKit up but I've found that the main things to avoid are chaining optionals too deeply and nesting closures too deeply (recommend keeping both to 2-3 tops) as well as casting to/from Any too often.
"You're holding it wrong."
I believe the parent was saying that the performance of xcode varies based on the project. This is true - breaking projects up into more modular setups has long optimized project build speeds. The quality you get out of your tools is in many cases based on how you use them.
"You're holding it wrong" would apply if you were deliberately using the tools in a sub-optimal way to try to prove a point.
I choose to abandon programming for Apple's devices entirely rather than put up with xcode.
You can't beat Hyrum's law by simply "forcing more people to use official API", with enough code people still depends on every implementation details in your code.
That's neither here, nor there though. You can still beat the biggest part of fragmentation by "forcing more people to use official API".
Doesn't have to be perfect, just good enough to make moving forward, porting to your new architectures and APIs, etc, easier.
In fact, Apple just showcased it works with the move to M1 (and to a lesser degree earlier with the move to x64 and the move to 64bits).
Obviously it's not the only reason that Apple does things the way they do. It's probably not even the number one reason. But it's certainly one significant reason which seems to fit the objective criteria of being factually true.
(To be clear, I am stating no personal opinion about whether Apple's approach is "good" by any criteria.)
Xcode is extremely hard to use. I've been programming for over 20 years, and used lots of different editors and IDEs and languages.
But Xcode is just TOO HARD. Swift was nice and easy to understand. But just editing (or even typing) code on the editor is a huge pain. Even things like selecting text, or moving the cursor around are super non-standard and complicated (and this is coming from someone who's managed to become proficient with vim).
How is moving cursor not standard? Mac OS has a very consistent way doing that, across the system.
This doesn't even make sense. Those things in XCode are as bog standard as it gets, and I've also used vim, Eclipse, Idea, ST and nowadays VSCode.
I'd buy the UI setup (with connections between actions etc) being confusing in XCode (especially things like Storyboards), but text editing? Cant even understand what you could mean. Any concrete example?
Contrast the situation to Microsoft, where not even their own in-house teams are willing to add support for new platform capabilities.
There was no touch native version of Office for the Surface RT, despite it being sold as a tablet.
There are several of their own products that still don't have native ARM versions for the Surface Pro X.
Xcode works natively on an M1 Mac. Where's the native version of Visual Studio for the Surface Pro X?
Sure they can, and I for one, am fine with their justification. I don't want everything to be "secure web apps", I want to have native apps, and I want to have a choice of different platforms (Windows, macOS, Linux, etc.) each doing its own thing their way.
I don't want to use Linux as my desktop because I don't like their choices, the same way I don't want to use Windows or macOS as my server, because I don't like their choices.
>The future cannot be segregated by platforms
That's a monoculture dystopia then, not a future where many competing ideas about what platforms can be, what OSes offer, what their core tenets are, etc. flourish.
It's to the point where they won't even let people enrich their ecosystem for free unless you dance to their tune. It's very, very hard to take anything other than a dim view of such despicable behavior.
It's not free. There's a $99 membership fee every year, even for an altruistic person offering nothing but a single useful extension/app that makes zero income.
---
Let's imagine a feature request on GitHub:
USER: Safari supports the WebExtension API now. Please port your cool extension to Safari.
DEVELOPER: Cool. I'll maybe try doing that this weekend!
USER: Oh, by the way, you'll need to be on the hook for $99/yr for the rest of your life, so that Safari users can install the extension.
DEVELOPER: <...RADIO SILENCE...>
You can complain that it's not right to charge for the program, but the developer program has a cover charge to keep out the riff raff. I don't think this is a bad thing. We all know how much junk is in the App Store as it is, and how long it takes to get a review. Imagine if they didn't charge for the opportunity to submit apps? How much soon-abandoned junk would suddenly appear, and how long would it take for proper apps to get approved?
You're going to have plenty time to Wrap Your Head Around this dynamic by simply observing how the Safari WebExtension ecosystem plays out.
> the $100/yr for the developer program is not a lot of money. [...] It's less than a single restaurant lunch per month.
Is that $100 for a meal for a single person? Where do you eat and how much do you spend on food a month?
Wow you must be superhuman. I misunderstood you. Now I get it.
I don't understand it, so I don't think it's fair to call it "understandable".
That said, I was attracted to computers since an early age because it's fun to make them do things.
But I think apple's ecosystem takes the MOST EFFORT of any of them to actually do anything.
For example, on linux there are probably 100 scripting languages that can do fine-grained automation of just about anything you want to do.
With apple.. ugh. It's either applescript, or you're into xcode and a compiler and a license agreement and high complexity and lots of only-apple-does-it-this-way.
Here's a simple one: how do you have two icons in the dock - one to open an 80x25 terminal window, one to open a 140x50 terminal window. This takes way too much energy to automate.
You can do it in applescript, but it's such a horrible language.
tell process "Terminal" to click menu bar 1's menu bar item "Window" menu 1's menu item "Open Window Group"'s menu 1's menu item "group1"
This said, one of the biggest reasons I still clamp to macOS is, actually, the state of automation tooling - even in this half-abandoned state. Your example would be trivial to implement with tools like Keyboard Maestro or hammerspoon. Then there are tools like Alferd/Launchbar, Karabiner elements or bettertouchtool for touchpad gestures... It is really a vast ecosystem which is to match.
I have an extension idea; it's literally a single line of JS. However, to get it into Safari, I need to create a (useless, and empty) Mac app with a specific configuration in Xcode that'll allow it to appear in the "extensions" list in Safari. Then I need to deal with all the signing & App Store distribution stuff if I actually want to distribute it.
The money isn't even an issue (I have a developer license for other reasons - creating actual apps), it's just the annoyance and insane barrier of entry when the majority of extensions don't need anything but JS.
There's also the issue of how Safari discovers extensions and what actually causes your extension to appear in its list. Is it opening the associated "app"? Not always as I've had trouble with that before - the app is compiled, it's open, but the extension is nowhere to be seen in Safari's preferences. It mysteriously self-resolved after some more trial and error. Updating the extension's JS while developing is also unclear. Does it happen upon app recompile? App relaunch? Who knows - I gave up before even reaching this stage - this whole process is bullshit.
The whole idea that browser extensions are "apps" is stupid and annoying. They should be separate, and while apps install on your OS, browser extensions install in your browser. They should have their own file format (openable directly by Safari, with optional code signature checks) and their own Store (a website within Safari). At least that would solve the problem above - you open an extension file in your browser and it installs in your browser - no ambiguity there. To update you open a new file (which overwrites the previous one based on a potentially signed Bundle ID or similar) and it updates.
The worst is that they had all of the above already and then decided to shit all over it about 2 years ago (in addition to removing much-needed APIs that allowed uBlock Origin to work and replaced it with something way less powerful).
[1]: https://bartsolutions.github.io/2020/11/20/safari-extension/
Probably less annoying, but there's still a time and effort cost to publishing on both Chrome and Firefox as well. They don't have the same policies, the APIs have differences, they have their own bugs, and the submission/review process is different for each. It's a real drag, compared to pushing updates to a website.
Also, with the Chrome store right now, once you push an update for review, there's no way to replace it with a newer update until the (up to 3 weeks) review process finishes so say goodbye to pushing quick fixes, automated deploys and fast iterations. It's ridiculous.
But, it's not so annoying that the entire platform is being abandoned. This is a matter of degree, but there's a point where the effects of that annoyance become very obvious.
If publishing on Apple devices was just a tiny bit more annoying, devs would complain and then still publish their extensions. But that doesn't seem to be what's happening, it seems Apple has crossed a line where extension devs have decided to just ignore the entire thing.
Apple requires a thousand clicks, a 11GB app on your computer and the manual review every time.
Maybe it's because I don't have many users, or don't use any minification, or something else?
I'd like to publish for Safari but it's a much higher bar. Similar to the old Edge extensions which required Microsoft Store hoop jumping.
Do you automated this or are there manual steps?
> Updates for me take less than five minutes to upload and appear within an hour or so.
https://developer.chrome.com/docs/webstore/faq/#faq-listing-...
"Review times vary; some reviews complete in a few hours, others take many days, and in some cases a review can take several weeks. ... If your item's status says "pending review" for more than three weeks, you should contact support."
Reviews are meant to take longer if you ask for e.g. permission to all URLs (which a large number of popular extensions need to because of lack of permission granularity). Maybe your extension isn't impacted here? There's no guarantee the next update won't get trapped in the review queue either, which is not going to be fun when a critical fix is pending.
Manual for the time being.
> Maybe your extension isn't impacted here? There's no guarantee the next update won't get trapped in the review queue either,...
Mine does need all URLs, though it is possible the next review could take days or weeks. Yet it's all still so much simpler a process than Safari.
I've shipped an extension like this, and it took me an hour to build (which included testing), and then I hit "archive" and submitted it.
The signing pieces "just work" in modern Xcode if you have a developer account associated.
Apple has no issues putting 200 hoops in front of you to get a simple thing done.
This is just another one of those hoops, and another reason developers don't like doing things with Apple-technologies.
With most browsers it's clear, you open a specific file with the browser, the browser loads it and that's it. To update, you open the updated version of the file.
With these apps it doesn't even seem like the app itself is doing any work - there's no code in there to for example connect to an internal socket or do some IPC to notify the browser and supply it with extension files - instead it seems to be handled out-of-band by "magic".
Since extensions are made available via app extensions, it is:
- installation of an app from the app store
- first run of an app which is not from the app store
This is actually the big reason why they require you to use apps - all system customizations (device drivers, web extensions, photo plugins, fonts, etc) are supported with an application life cycle, and support appstore-style review and updates.
I haven't done enough development of safari app extensions in particular to fully understand how _live_ updates work. I typically just enabled the extension with Safari Tech Preview as the only extension, loaded on a test page, and would restart. There may well be logic now to do a page refresh when an enabled extension is updated, however.
> With these apps it doesn't even seem like the app itself is doing any work - there's no code in there to for example connect to an internal socket or do some IPC to notify the browser and supply it with extension files
The app extension has a global JS file loaded, and the safari.extension object allows one to send IPC to the corresponding native Mac app. This is (for example) how 1Password and other password managers integrate with the native password store.
The native app is a pretty good place to put all the configuration options for your extension, which may eliminate the need to surface browser-bar buttons and the like.
(FWIW: my Safari extension was a prototype that was abandoned because Safari didn't surface enough HTTP request/response access in their old API. I haven't checked yet if their Web Extension API surface includes what I needed.)
Nope, which is why uBlock Origin is still not possible.
That's better suited as a userscript.
Found here: https://developer.apple.com/forums/thread/90090
D&B make buckets of money off of paid services which are like credit counseling and business reputation rackets. If you want to borrow money as a business you’ll probably have to pay their tax along the way.
Their quasi government mandated monopoly is handing out the number you need. God forbid you try to get one from the former however. Also don’t try to update your registration through the paid side either. They’ll try to charge you even though they can’t get it done any faster than you can yourself through the correct link.
The key to getting one quickly is making sure your corporate registration is updated with your state. And the officer getting the Apple ID is listed with the state as an officer.
However, if you have had months of issues getting a DUNS number you likely are beyond wanting to move around a temporary roadblock, and on to trying to remove a more permanent roadblock first.
Getting a DUNS number for my LLC was free and not difficult, but it was confusing. There are a lot of wrong ways to try to go into the process - to the point where the DUNS sign up now has "Apple Developer" as one of the reasons you are asking for a number.
Then they decided extensions should go “full Apple”, requiring the developer fee and so on. It was clear they didn’t want any developer who wasn’t already committed to iOS, they just didn’t care about Mac hobbyists. I dropped my extension and never looked back.
Apple basically had two children: one of them became a superstar multibillionaire (iOS) and the other (MacOS), well, he kinda “gets by”. Now iOS keeps MacOS in a job, and tells him what to wear and who to talk to. The poor thing is humiliated and increasingly lonely, but what you gonna do? Meanwhile his old friends Linux and Windows, who used to be so envious, are doing pretty well for themselves and don’t look up to him anymore.
We have uBlock origin and many others extensions working already. By doing this we get best of both worlds - performance and energy use of Webkit and extensions from chrome/firefox.
Screenshot: https://ibb.co/7V8sfyX
We are open for beta testers. Please email me if interested with short background and area of your interest.
And here's one that made at least $100k: https://www.indiehackers.com/product/css-scan/100-000-in-rev...
It's actually not that hard to become a billionaire [points at some billionaires]
By the way, here are some stats on Chrome extensions: https://www.debugbear.com/blog/counting-chrome-extensions
Over 95% of Chrome extensions are completely free, as in no form of payment whatsoever. This makes extensions one of the worst of all software markets. Users just expect extensions to be free.
Also, the browsers vendors themselves can make it difficult to monetize extensions. Firefox eliminated its extension store several years ago, and Google is eliminating Chrome Web Store payments next month. If anything, the Mac App Store is now the easiest place to monetize extensions IMO.
Most Chrome extensions are low quality, too! But to me that just means there's a lot of opportunity. I've seen enough paid extensions succeeding (I can send more links if you're interested) that I'm readily convinced the market isn't that bad at all, and it will only get better as people encounter more quality extensions that provide enough value to pay for.
> Also, the browsers vendors themselves can make it difficult to monetize extensions. Firefox eliminated its extension store several years ago, and Google is eliminating Chrome Web Store payments next month. If anything, the Mac App Store is now the easiest place to monetize extensions IMO.
Yeah, it's annoying that neither Google of Firefox stores have easy payments — it makes taking payments less accessible for developers. But obviously it's still possible to roll your own payments or using things like my own https://extensionpay.com
That's cool. I may look into this. Do you have a list of extensions using the service?
The extra info is only because I want to devote full personal attention to our beta testers, so some context helps.
uBlock origin is the biggest thing keeping me from going to Safari, that and the Stylus extension(or something like it).
I don’t know that effectively slapping an app shell around an extension is a big hurdle, but no other web extension store charges for entry, so that very well could be the real barrier here.
Mostly, no.
"You can request to have the annual Apple Developer Program membership fee waived if you’re a nonprofit organization, accredited educational institution, or government entity that will distribute only free apps on the App Store and is based in an eligible country."
"Fee waivers are not available for: Individuals and sole proprietors/single person businesses"
So I already pay the $100 a year. But there is a browser extension I help maintain that has a very limited audience (it is essentially an internal tool, though it is in the Chrome and Edge stores). I would like to bring it to macOS/Safari and started the process of doing it. But there are so many hoops, it will vastly change the build pipeline (I’ll literally have to package every single update differently than the other platforms), and the process is so convoluted that honestly, I’ve given up for now. Bear in mind, I’d be the primary user of said extension and even for me, I can’t make the internal argument to waste time doing it over just using Chrome or Edge when I need that feature.
Having said all that, I should go ahead and port it to Firefox. That at least is a lot more straightforward.
You have to explicitly grant permissions as a user for safari extensions.
I think this is because people who use extensions just don't use Safari, and therefore anyone who is savvy enough to want a tool like ours is already on Chrome or Firefox. There are a few people who use Safari for the battery life and are willing to live with the very few extensions that it offers, but I don't know many people like this.
We'll probably release a Safari extension eventually, but for now it is not a priority. We are actually going to be launching with a new iOS web browser that includes extension support, and given the trend toward mobile that's more of a focus for us right now.
They're in beta now and launching soon: http://insightbrowser.com
And, for the content blocker extensions market, there’s essentially no point in releasing it as a paid web extension for iOS/macOS users, because there’s already better paid app competitors that do this, like 1Blocker or Guardian VPN or etc, that are full native apps on the platform with the appropriate hooks to be performant and such.
Therefore: What valuable browser extension ideas other than content blockers exist, that could have any significant user base and value, that isn’t already met by better and more capable native apps on macOS and iOS, and somehow could charge people money for the extension with their willing cooperation? They’d obviously have to use a subscription model, so factor that into consideration when assessing the market.
I’m unable to come up with anything that would make this segment of the App Store market worth my time to invest code into, and I already have a developer account for other reasons, so I don’t even have the annual fee barrier to consider. I remain hopeful that I’m wrong, but no one’s made a convincing argument yet. Prove me wrong, HN.
(I see most people taking the “wrap WebKit” route instead, which makes more sense since it provides the capabilities an extension can’t offer, and is dead simple by virtue of the platform’s capabilities. Makes more sense to me, anyways, and then too. So: now what?)
Extension examples: Reddit Enhancement Suite, Firebug, uBlock Origin, YouTube Ultrawide fixer.
Later, I'll add the capability to predict the salary range of people from their Linkedin profiles. I would make this a premium feature. Let's see how it goes.
* Closet Tools makes $38k/month: https://www.indiehackers.com/podcast/187-jordan-oconnor-of-c... * CSS Scan made over $100k: https://www.indiehackers.com/product/css-scan/100-000-in-rev... * Spider made $10k in two months: https://www.amie-chen.com/blog/making-paid-extension/
Language-learning extensions are reasonably popular, though most aren’t making the big bucks.
Grammarly is probably one winner of note.
Prevent me from quitting the browser accidentally - Ctrl + Q
Tree Style Tabs which I would happily pay for.
Third party bookmark service like Pinboard, although this could be accomplished by an app as well.
I absolutely wouldn't mind paying additional 100% on top of my Internet subscription monthly if this could officially get me 100% ad-free, tracking-free, DRM-free and paywall-free web.
If only there were easy and efficient means for an Internet provider to distribute part of their revenue to content providers so they wouldn't have to deploy ads and tracking - that could be a beautiful world.
It’s not just “why would” a developer do it; It’s how can they do it without a Mac? They can’t.
I tend to not trust extensions otherwise and would really prefer Safari to have built in total ad blocking - zero tolerance for any ads at all.
It runs the exact same underlying code as for Google Chrome/Firefox etc. I converted to Safari 14 using a one liner:
`xcrun safari-web-extension-converter /app/path`
Each uses a separate URI scheme.
So Chrome uses chrome-extension:
Firefox uses firefox-extension:
... etc.
which means web extensions for Firefox won't work with Google Firebase because they only support chrome-extension.
Why the heck isn't it web-extension: ???
Mozilla has implemented additional APIs that are never going back into Chrome because Google doesn’t care and doesn’t have to.
That said, there are other great extensions like RECAP and I wish they could come to Safari too.
Unfortunately "ought to be" != "easy". But if someone could do this it would be a service to extension developers and Safari users alike.
Case in point: "Beyond20, an excellent extension that connects the D&D Beyond character sheet to virtual tabletop services like Roll20"
Wonder how Safari users will make it without this usability booster!