Safari 14 added WebExtensions support, so where are the extensions?(sixcolors.com)
sixcolors.com
Safari 14 added WebExtensions support, so where are the extensions?
https://sixcolors.com/post/2021/01/safari-14-added-webextensions-support-so-where-are-the-extensions/
223 comments
>Xcode development, the Apple Developer Program, and the whole experience of trying to ship your application on the Apple ecosystem is the fucking plague.
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.
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.
I’ve used Xcode for many thousands of hours at this point and I have to say I actually think it’s pretty good now that I understand how it is supposed to work. But for a web developer who just shipped some JavaScript for Firefox and Chrome…just no, this is stupid however you look at it. The fact that you have to download a dozen gigabytes just to get access to what’s a glorified shell script, then packaging some web code in an app bundle for no reason and mandating that it is signed and distributed on the Mac App Store is just dumb. It’s an awful experience from Apple all around if they are trying to get people to port their extensions to Safari.
IMHO Xcode is at most "barely acceptable" when compared to most other IDEs, there's a lot more bad things than good things.
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.
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.
Xcode is…not very extensible IDE, I'll grant you that. The true impact of XcodeGhost is felt to this day :( I wish it was more extensible, and have myself done sketchy things to make it so, but I entirely agree with you that this is not a positive by any means.
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 :)
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 :)
> IMHO Xcode is at most "barely acceptable" when compared to most other IDEs, there's a lot more bad things than good things
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'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.
Valid complaints in this thread, but just a quick correction that Xcode has supported tabs since 2010 (https://stackoverflow.com/questions/1184997/enabling-tabs-in...).
>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).
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).
Multi-cursor support is something I want maybe once every few months? Certainly nowhere near a crucial feature, and barely one that makes a list of nice-to-have things.
Multi-cursor editing is frequently a very good substitute for inscrutable vim or awk.
Or even just test things in safari. Guess I have to spend at least 200$ on an ipod touch if i want to test in some sort of version of safari, significantly more if i want to test on a non iDevice (with an actual console etc)
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
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
>Obviously for a business this is a neglegible cost but for someone just making a hobby app, it's ridiculous.
Sorry, why do you want to make a hobby app for a platform you don't own?
Sorry, why do you want to make a hobby app for a platform you don't own?
Because you want it to be cross-platform? Just because it's a hobby project doesn't mean you don't give a shit about the user experience. I mean it's not like you have to recreate it from the ground up to make your webapp work in safari, it'll mostly be small tweaks.
For scratching one's own itch? A hobby app can still be a useful tool, even if nobody else is using it.
All three of those developers started writing Mac software (or NeXT software, in Omni's case) in the 80's and 90's, before Xcode or the Apple Developer Program. The wider Mac developer community was hollowed out by the iPhone in the late 2000's-early 2010's and never really recovered. Who is starting a Mac-only software shop in 2021?
Are anyone doing Windows or Linux only software shops in 2021 (web services not included)?
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.
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'd argue that the Mac developer community was hollowed out by mandatory Sandboxing in the Mac App Store, introduced in 2011, not by the iPhone (2007). Sketch, arguably the most successful third-party Mac-only app since OS X, was released in 2010, several years after the iPhone, but almost immediately before mandatory sandboxing.
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.
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.
Sketch is an interesting one, gained so much traction for having a superior interface but after several years in the lead it's getting devoured by a cross platform web app with superior collaboration.
It's relevant that has also been essentially 10 years of stagnation on the frameworks that Sketch is built on, i.e., AppKit, as Apple focuses on UIKit. In this case specifically Apple hasn't added best-in-class collaboration features to AppKit (or UIKit). I'm not sure whether it would have made a difference in Sketch vs. Figma, but the fact that they haven't has made it difficult for Sketch to compete, as Sketch's MO is leveraging Apple's built-in technologies.
On one hand I think macOS sandboxing can be a bit too restrictive and buggy, but on the other I think it's somewhat unreasonable for developers to continue to expect unfettered access as a given on the desktop, because it's been proven time and time again that unfettered access will be abused, often by big companies that users tend to implicitly grant a higher level of trust to.
I agree 100% in principle, the problem is Mac App Store apps compete with non-Mac App Store apps that have unfettered access, and macOS itself competes with other OSes where unfettered access is expected.
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...).
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...).
>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 yet, MS Office, Lightroom and others are on the App Store.
And yet, MS Office, Lightroom and others are on the App Store.
I'm not quite sure what your point is, but those are 100% the most interesting cases of apps conforming to the Mac App Store that I wouldn't expect to. Here are my explanations:
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.
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.
> And yet, MS Office, Lightroom and others are on the App Store.
Microsoft has received special sandbox exceptions from Apple that are not available to other developers.
Microsoft has received special sandbox exceptions from Apple that are not available to other developers.
>Who is starting a Mac-only software shop in 2021?
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...
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...
> A lot of people?
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.
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.
>Name them. This is a serious request. I'm a longtime professional Mac developer who knows a lot of other Mac developers.
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...
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...
Keka: 11 years old! https://changelog.keka.io/
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...
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...
What does any of that have to do with supporting the WebExtension open specification?
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?
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?
Yes it does sound right.
Do you ship untested software?
Do you ship untested software?
You mean like web devs ship websites only tasted in latest Google Chrome? How Microsoft ships Windows tested only on a handful of hardware configs? How game devs ship games only tested on the latest graphics card?
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.
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.
>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).
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.
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.
That is my whole point though: the WebExtensions API is a standard, so it's not like you can't test your extension without owning a Mac. If your extension works on both Firefox and Chrome, it really should work on Safari too. If it doesn't, that's Apple's fault for violating the standard, not yours for not testing on their broken platform. If you want to specifically test it you can, but if you don't see a reason to, you should be able to just port it over and let people use it and beta test it for you.
>If your extension works on both Firefox and Chrome, it really should work on Safari too. If it doesn't, that's Apple's fault for violating the standard, not yours for not testing on their broken platform.
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...
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...
Which is why I mentioned both Chrome and Firefox, as while both implement some non-standard features, those tend to differ, so the intersection of their feature sets is pretty much the standard itself.
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 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 think the point of standards is portability. You still have to do testing on different platforms, especially when porting the first time.
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
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
I mean, I guess... since among the things I've shipped are, uhm, WEBSITES, yes?
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?
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?
More than right, sounds like the responsible thing to do.
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!
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!
Developers can and should test their code in a high-fidelity simulator for some configurations–limiting myself to just Apple platforms, I certainly don't have every Mac, iPhone, or Apple Watch in every combination of versions in front of me. I shipped support for iPhone X and Apple Watch Series 4 without having either of those devices on hand–for the latter, as you probably know, without even recompiling it. None of my personal Macs have a Touch Bar, but that hasn't stopped me from writing code for it.
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.
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.
I'm pretty confident the top apps for Mac include Photoshop, Illustrator, Premier, After Effects, Microsoft Word, and other cross platform apps.
Mac users are just fine with cross platform apps.
Mac users are just fine with cross platform apps.
Those are top-tier professional staples. Mac users can't chose another Photoshop, because there's no other at that level (Affinity and co are great, but nowhere as comprehensive).
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.
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.
True, but at the same time the Adobe apps certainly doesn't feel as "native" as they could have. Affinity feels much better for example.
Affinity is also cross-platform.
A better example would be Pixelmator.
A better example would be Pixelmator.
As true as this is, when it comes to Adobe products there's also no shortage of griping about things like UIs getting progressively more glitchy and less responsive and bad or nonexistent hardware acceleration… gripes that largely didn't exist 15 years ago when those same Adobe products were more closely tuned for the platforms they ran on instead of going all-in on one-size-fits-all.
Those gripes are universal cross platform gripes. Nothing to do with them being Mac specific. 15 years ago was CS2, already a cross platform app
While you might be true in that Apple tries to cater to a different band of Devs dedicated to their eco system, let's also not kid ourselves that they have had their experience at heart when making decisions about their platform. Are you telling me that dedicated apple devs have the greatest dev enviroment and experience there is? Or are you merely saying that they have a less shittier experience because they decided to drink the coolaid and get into a one sided relationship with Apple?
> Are you telling me that dedicated apple devs have the greatest dev enviroment and experience there is?
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.
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.
>instead on relying to 1000s of half-ported apps, with shared functionality on Windows and Mac, and horrible cross-platformy UIs
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.
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.
> 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.).
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.
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.
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..
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.
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.
>Here on HN there's at least one horror story a month about issues someone had with Apple
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....
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....
+ There's plenty of commercial software available for Linux
+ 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.
+ 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.
You are right, multiple desktop environments are not an issue -- unless you are toolkit author; the different corner cases in different Wayland compositors can be issue, but only for toolkit authors. We are talking about such a layer in the stack, where Apple or Microsoft won't even let you play. Anyone, who uses the multiple DEs as an excuse is firmly put into doesn't know what he is talking about box.
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.
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.
> "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"
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.
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.
Okay, but then you're going to have to be content with the fact that extension developers are largely going to just ignore Safari.
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.
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 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.
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.)
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.)
> 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.
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.
> am curious what the future of Mac as a development platform is going to be.
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.
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.
> Apple tho wants macOS developers (and users prefer apps from people dedicated to macOS).
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.
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.
This.
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.
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.
Yeah but there's nothing that says the Xcode experience has to be so painful[1] or that people have to pay Apple or that software has to be approved by Apple in order to preserve this flexibility. Purchasers should have options, including the option to write software (for themselves) that works on the computer they paid for but might not work if Apple introduces computers based on a new architecture, which the existing Apple customer may or may not choose to buy in the future.
1. Painful for the parent commenter. It is painful for me, too. It might, or might not, be painful for others.
1. Painful for the parent commenter. It is painful for me, too. It might, or might not, be painful for others.
I haven't used Xcode much, so it's not for me to say if it's good or bad. However, I would assume that Apple uses Xcode internally, if it was a pain to use, in general, would Apple fix it? At least to save on development cost internally.
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.
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.
They do use it internally and a lot of teams do complain about it. I hope there is some real work going on to improve some parts of it (how about shipping patches rather than an entire 11gb binary every version). I think a lot of devs also pin certain issues on Xcode that are actually issues with the Swift compiler (slow or missing autocomplete, unhelpful error messages or slow compilation times for example) ObjC is far far quicker to compile.
Apple uses Xcode internally very heavily, and it's less about it being tuned to Apple's needs (which it is, but as an app developer your needs and Apple's match pretty closely) but that Xcode tends to not scale very well.
>Yeah but there's nothing that says the Xcode experience has to be so painful
Well, who says it is objectively painful (as opposed to just not what the grandparent is used to or prefers)?
Well, who says it is objectively painful (as opposed to just not what the grandparent is used to or prefers)?
Its pretty bad.
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.
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.
Xcode with Swift is a bit odd in that its performance varies greatly depending on project structure and as nonintuitive as it may be, the way the developer writes code.
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.
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.
To summarize, this is the most Apple of arguments, that you're making:
"You're holding it wrong."
"You're holding it wrong."
Not quite - the origin of "You're holding it wrong" was a response to someone who was quite literally trying to illustrate the cellular signal attenuation issue by pressing down with their fingers on the gap between the two antennas.
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 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.
Yeah its 2021. There's no excuse for shipping software you know crashes every few hours of normal use. Or lags so badly you can't type sometimes. I doubt XCode in its current form would make it through Apple's own app store review process. Fix your software or replace your staff with people who can.
I choose to abandon programming for Apple's devices entirely rather than put up with xcode.
I choose to abandon programming for Apple's devices entirely rather than put up with xcode.
I think the parent was just trying to help. I’ve had similar problems with IngelliJ when I had the wrong project view open.
I’ve noticed similar issues, it’s especially a problem with SwiftUI as nesting closures often feels natural there, my brand new M1 mini will still give me the “expression too complex” error on larger SwiftUI components.
... Or maybe it is not factually true?
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.
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.
>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).
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).
Given that Apple has explicitly stated this benefit and given that Apple has explicitly utilised these exact benefits in the real world on multiple occasions, it's rather bold to propose that it might not be factually true.
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.)
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.)
Linux with gcc supported plenty of architectures without much fanfare.
is downvoting even a thing in HN?
The barrier for entry to the Apple ecosystem is extremely high though.
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).
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).
Well, I have been programming for 30 years now. I started with Apple when iPhone SDK was released. Had no problem with Xcode then, have nor problem with it now. How can actually IDE or editor be HARD (memes about quitting vim aside). I've used a bunch of them: HomeSite, SKEdit, Textmate, Sublime Text, PHPStorm/RubyMine/WebStorm, NetBeans, Xcode, AppCode, VSCode, Nova. I liked some more, some less, but neither was HARD.
How is moving cursor not standard? Mac OS has a very consistent way doing that, across the system.
How is moving cursor not standard? Mac OS has a very consistent way doing that, across the system.
>Even things like selecting text, or moving the cursor around are super non-standard and complicated
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?
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?
>they hook in to new platform-only capabilities
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?
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?
Apple cannot justify their transgressions against the modern development workforce as "a matter of platforms". The future cannot be segregated by platforms - that's part of the goal of a private and secure web. We need to work together to create secure infrastructure that everyone can trust, not huddle away and say that "Apple isn't looking for people like you". I understand that you're probably pretty impartial on the topic, but even you can acknowledge that their treatment of developers is unhealthy.
>Apple cannot justify their transgressions against the modern development workforce as "a matter of platforms".
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.
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.
You mean GP is partial, right?
To top it off, if you put a donation link in your about box when you release your totally free software in their App Store, they will reject it in review. Free apps are not allowed to include a donation link to their own website.
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 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.
Donations is just another model of making money from software. So you're going to use App Store for free and make money without Apple getting their cut. It's understandable why Apple does not accept it.
> So you're going to use App Store for free
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...>
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...>
I still can't get my head wrapped around the complaint that the developer program costs $100/yr, as though this were some great barrier to entry. To put it in perspective, I subscribe to <deep breath> Prime, Netflix, Hulu, Disney+, HBO Now, Apple One, Office365, PS+, and Xbox Live, and that's just off the top of my head. Most of them are for purely-optional entertainment, and all of them cost more money than the developer program. I suspect most people who frequent this board pay for several of these too. In comparison, the $100/yr for the developer program is not a lot of money. It's certainly comparable with other optional digital services. It's less than a single restaurant lunch per month.
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 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?
A Chrome/Firefox user expending some effort to make their existing extension available to Safari users is doing those users a favour. Generally one doesn't have to additionally start donating money to someone's preferred charity when already doing them a favour.
You're going to have plenty time to Wrap Your Head Around this dynamic by simply observing how the Safari WebExtension ecosystem plays out.
You're going to have plenty time to Wrap Your Head Around this dynamic by simply observing how the Safari WebExtension ecosystem plays out.
> I still can't get my head wrapped around the complaint that the developer program costs $100/yr
> 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?
> 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?
I'm struggling to understand how I could have been misunderstood. $100/yr is $8.33/mo. Even a burger meal at a fast food joint is that much now. Ergo: less than a single lunch PER MONTH. Where did I lose you?
> I'm struggling to understand how I could have been misunderstood.
Wow you must be superhuman. I misunderstood you. Now I get it.
Wow you must be superhuman. I misunderstood you. Now I get it.
If you believe that donations accepted by authors of entirely free/open source software are "just another model of making money from software", I don't know what to tell you.
I don't understand it, so I don't think it's fair to call it "understandable".
I don't understand it, so I don't think it's fair to call it "understandable".
Would the hobbyist projects whose development is effectively inhibited by Xcode and the Apple Developer Program, i.e., the hoops Apple makes programmers jump through, be more interesting than the apps people pay developers to create.
I think capitalism works. That's how apple does it.
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.
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"
Writing AS is not a pleasant experience, I agree. IMO, it was internally abandoned long time. There was a push to move the automation framework to JS with JSX, but after the initial half-broken release nothing came and as far as I understand, the team was dissolved. Shortcuts on iOS may be the model for future automation on MacOS.
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.
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.
well, that is their business model. Take it away and then sell it back.
In addition to the money argument raised in another comment, the Apple development experience is a major annoyance when all you need is a couple lines of JS.
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).
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).
We recently converted a chrome extension into safari extension using the tool provided by apple [1]. While the conversion is smooth in general, the generated app (not the extension) got UI issue during extension review! Reviewer insists the app does not fit the UI guideline. I need to write back and explain the entire app is actually generated by the official Apple tool. The only use of generated app is open the preferences page of Safari. Anyway, after two back and forth, the extension is finally launched.
[1]: https://bartsolutions.github.io/2020/11/20/safari-extension/
[1]: https://bartsolutions.github.io/2020/11/20/safari-extension/
> 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.
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.
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.
Publishing extensions on Chrome/Firefox is annoying, and we probably would have more extensions if it was easier.
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.
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.
Come on you can’t compare what it takes to submit an update on those two. Literally 5 clicks and drop a zip on the page, so long as they don’t single you out for manual review.
Apple requires a thousand clicks, a 11GB app on your computer and the manual review every time.
Apple requires a thousand clicks, a 11GB app on your computer and the manual review every time.
I push my extension to Firefox, Chrome, and Edge. Updates for me take less than five minutes to upload and appear within an hour or so.
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.
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.
> I push my extension to Firefox, Chrome, and Edge.
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.
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.
> Do you automated this or are there manual steps?
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.
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 agree with your point on a whole, I do want to add that tamper monkey does indeed work on Safari so you could just add that line of JS there
Thanks. I've been wanting to check it out but put it on the back burner. I'll revisit it at some point.
>In addition to the money argument raised in another comment, the Apple development experience is a major annoyance when all you need is a couple lines of JS.
>
>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.
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.
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.
Extensions don’t appear unless you go to the develop menu and turn on ‘Allow unsigned extensions’.
And the "develop menu" doesn't show either unless you go in advanced settings, and select that it should be visible.
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.
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.
Yup, it's mentioned here: https://developer.apple.com/documentation/safariservices/saf....
I'm fairly confident I did that. Either way, the process is very unclear - what actually notifies Safari that an extension is available and whether it's updated?
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".
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".
> what actually notifies Safari that an extension is available and whether it's updated?
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.)
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.)
> 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.
Nope, which is why uBlock Origin is still not possible.
As an extension developer, I am keen to put my extension on Safari however what is preventing me at this moment is dealing with Dun & Bradstreet to get a DUNS number. A DUNS number is required to sign up to the Apple Developer Program as a corporation. So far I have been pushed to 3 different departments by D&B who keep just hand-balling me to the next department without solving my issue, and this is taking on the order of months. I wish Apple would remove this requirement.
If you haven't reapplied lately, you may want to try again. My corp was just approved for the developer program without having to deal with D&B directly, just a phone call with someone from Apple. I think they simplified the enrolment process.
This appears to be the link to make one: https://developer.apple.com/enroll/duns-lookup/#/request
Found here: https://developer.apple.com/forums/thread/90090
Found here: https://developer.apple.com/forums/thread/90090
a D&B # was required in the 90's to get most commercial SSL certs. if we wonder why SSL took so long, we can look at this long before we can look at what it took for let's encrypt to break into the market.
The key to D&B is understanding that they have two very separate businesses. Think of it like the TurboTax free filing division and the paid division.
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.
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.
I would normally suggest being a bit concurrent - contacting Apple and seeing if you could sign up as an individual and then migrate the registration to a corporate registration.
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.
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.
[deleted]
I came here to say this exact thing. It took me literally a month just to sign up for the Apple developer program, mostly due to the DUNS nonsense. It makes no sense, and is a huge pain.
This is ridiculous.
I used to maintain a small Safari extension, back in my “Apple honeymoon” years. Had very few users, but it scratched my own itch and tried to give Safari some basic feature parity with Firefox when dealing with Xml feeds. At the time the relevant Apple directory of extensions was so poor, I had to serve the update mechanism from elsewhere (which was a pretty bad security practice, in hindsight). Eventually Safari was just lagging in so many areas, I went back to Firefox, but kept maintaining the extension; the burden was small, basically just re-testing it once a year.
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.
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 are working on a new native macOS browser based on Webkit with native web extension API support built in.
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.
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.
The problem with browsers is that it is hard to monetize unless you go down some shady rabbithole. So exactly how are you going to make money and make your first million dollars?
It's actually not that hard to monetize browser extensions, and I think this is changing as the quality of extensions gets better — people are more willing to pay for software that solves their problems, regardless of the format. Here's an extension that makes $38k / month! https://www.indiehackers.com/podcast/187-jordan-oconnor-of-c...
And here's one that made at least $100k: https://www.indiehackers.com/product/css-scan/100-000-in-rev...
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 monetize browser extensions
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
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
Not a really fair reply. I was pointing out that there's nothing inherently hard about monetizing extensions and you definitely don't have to "go down some shady rabbithole" to do it. The services to charge for extensions exist and all that really matters is providing value, which as you're pointing out, can be hard.
> there's nothing inherently hard about monetizing 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.
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.
> 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.
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
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
> 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?
That's cool. I may look into this. Do you have a list of extensions using the service?
May I ask what your business model is or would be, since you require people to email you with specific information to beta test your product?
Sure. We are also building a search engine and we believe that you need to think holistically about replacing Google, by offering other infrastructure as well and a browser is a part of that (privacy friendly, with ad blocking built in). Btw we are starting to take beta testers for the search engine as well.
The extra info is only because I want to devote full personal attention to our beta testers, so some context helps.
The extra info is only because I want to devote full personal attention to our beta testers, so some context helps.
So, why not start with building a search engine? Why browser first?
Gotta start small
Yes!
uBlock origin is the biggest thing keeping me from going to Safari, that and the Stylus extension(or something like it).
uBlock origin is the biggest thing keeping me from going to Safari, that and the Stylus extension(or something like it).
Cascadea is a decent Stylus stand-in for Safari, though it isn't free (currently costs US$2.99).
Been a Safari user for years and still consider Apple doing anything to lose uBlock support one of their worst moves in that space. My browsing honestly feels so less safe without uBlock Origin, almost never had a dodgy popup or banner do something weird that wasn't blocked but once you're in the much weaker Safari only blocker ecosystem it happens constantly.
Interesting, is this planned to be an open source project?
Yes eventually. We are currently laser focused on getting the hardest part of the work done. The webextensions API layer is pretty substantial and had to be rebuilt from scratch on top of Webkit core which is a giant project on its own. It has been two years in the making and we are at about 70% webextensions api coverage with a small but passionate team.
I wonder if the bigger hurdle here is that you have to spend money to get into the developer program (unless this is waived for these kinds of apps, I couldn’t tell when trying to dig up an answer)
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.
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.
> unless this is waived for these kinds of apps, I couldn’t tell when trying to dig up an answer
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"
https://developer.apple.com/support/membership-fee-waiver/
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"
https://developer.apple.com/support/membership-fee-waiver/
That is definitely the reason I haven't tried to develop anything for the Apple ecosystem even though I've used it for more than a decade. $100 a year is wasted money for hobby projects which may not even be published in an app store.
I dunno, I think it’s both. I’ve paid the $100 a year fee for over a decade, even though I don’t have anything in the App Store right now. For me, it’s worth it for access to the betas and to be able to self-sign and notarize stuff on GitHub.
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.
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.
Yeah. The $99/year is big enough to pretty much block out all hobby devs and open-source projects, so what's left are generally commercial and closed-source. Apple says that they do their own vetting of extensions, but I don't trust Apple to prevent extensions from reading my browsing history, especially considering spyware extensions like Honey are served on the App Store without warning.
> especially considering spyware extensions like Honey are served on the App Store without warning.
You have to explicitly grant permissions as a user for safari extensions.
You have to explicitly grant permissions as a user for safari extensions.
Yes but every extension that does anything remotely interesting needs access to "your entire browsing history," which is a comment much scarier than it usually is. The truth is that it is impossible for a computer to distinguish malicious javascript from useful javascript, meaning all trust and verification needs to come from the user.
[deleted]
I suspect that extensions on the App Store that are popular make more money compared to being, well, free on Chrome web store. Or, developers are pricing their extensions to recoup costs on dev program costs.
My startup has two Chrome extensions, and we also have an Apple developer account. But even still, we haven't prioritized releasing an extension for Safari. We'll probably do it eventually, but over the last 6 years we just haven't received that many requests for Safari (desktop) support. It literally might be 3 requests per year.
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.
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.
Other possible explanation for low number of Safari support requests: there's already a competing product.
Good thought, though in my case there definitely isn't one.
Regular web extension support downloaded from the Chrome web store? I’m interested
Not exactly — it's a combination of regex on the URL and then JS injection and the like.
They're in beta now and launching soon: http://insightbrowser.com
They're in beta now and launching soon: http://insightbrowser.com
We finally ported Wappalyzer across to Safari. The process was fairly straight-forward but Safari doesn't implement every API that Chrome, Firefox and even Edge support, so we had to do a bunch of work to get a single version of the extension to work consistently in all four browsers. I'm glad it's finally here though.
https://apps.apple.com/app/wappalyzer/id1520333300
https://apps.apple.com/app/wappalyzer/id1520333300
The most popular web extensions are those that deprive sites of direct and indirect revenue, which necessarily means they can’t charge for the service or their userbase would revolt and steal their rule sets (which is easy to do for a web extension). Having to pay money for such things goes against the grain of those users, and the sort of breakage that people think is acceptable for content blockers isn’t quite as acceptable in the wider Safari userbase as it is for the pi-hole folks. Imagine pi-hole charging a monthly subscription or else it allows ads through, and you can see immediately why this category is dead on arrival in revenue terms.
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?)
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?)
Not everything needs to be a business. Not everything needs to make money. Not everything needs to grow 100% year on year.
Extension examples: Reddit Enhancement Suite, Firebug, uBlock Origin, YouTube Ultrawide fixer.
Extension examples: Reddit Enhancement Suite, Firebug, uBlock Origin, YouTube Ultrawide fixer.
If that ‘revenue is not relevant’ logic holds true, then it follows that the $99/year annual fee is not relevant to why developers are not releasing extensions. Which negates the most popular (and unsupported) argument against Apple’s model. But if it’s not that fee, then what is it that keeps people from releasing extensions for Safari?
I develop PredictSalary (https://predictsalary.com), a browser extension that can predict the salary range of job opportunities. It's free but one person told me that he didn't mind to pay me if I added support for job opportunities in his country (UK). The extension has 700+ users now. I don't know whether this number can be considered as significant user base or not.
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.
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.
That is extremely cool. But why don’t you support Safari?
There are plenty of quality paid extensions:
* 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/
* 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/
Cool. But, Closet Tools and Spider don’t support Safari, and they make so much money that it’s not because of the $99/year fee. Why else wouldn’t they, if not that?
So your argument is that there's no market for paid browser extensions on Safari and thus no incentive to make extensions? But how do you explain that Firefox & Chrome have thousands of free extensions?
> What browser extensions other than content blockers exist, that 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?
Language-learning extensions are reasonably popular, though most aren’t making the big bucks.
Grammarly is probably one winner of note.
Language-learning extensions are reasonably popular, though most aren’t making the big bucks.
Grammarly is probably one winner of note.
Language learning on Netflix is great :) also Yomichan for Japanese. I’d assume there’s a lot more money though for people trying to learn English due to the market being much bigger.
That’s a reasonable one, thanks.
Vim/emacs key bindings for the browser like Vimium.
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.
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.
> Imagine pi-hole charging a monthly subscription or else it allows ads through
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.
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.
Sounds like you’re describing the BBC model, where the government funds them to produce high-quality broad-spectrum content without them having to deploy ads and tracking. I approve.
Hey check out the App Store, it’s full of paid Safari content-blockers. I begrudgingly bought one on Mac because the alternatives are trash.
Indeed, I referenced two of them in my comment.
Why would any developer who doesn't use a Mac even consider bringing their extensions to Safari? The vast majority of developers use Windows or Linux: https://insights.stackoverflow.com/survey/2020#technology-de...
People downvoted you as if this wasn’t a sensible comment.
It’s not just “why would” a developer do it; It’s how can they do it without a Mac? They can’t.
It’s not just “why would” a developer do it; It’s how can they do it without a Mac? They can’t.
I use Safari on the laptop because it's most efficient but it doesn't block all ads like ublock origin does. Particularly for YouTube so I need to use Firefox with ublock for viewing videos.
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.
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.
Try Wipr.
Seconding Wipr. It’s the one I use in Safari on Mac and in iOS. It isn’t as good as uBlock Origin, but it works fairly seamlessly.
Yeah, I use Wipr with Safari, it's the best one I've tried (for Safari's content blocking) and it does well blocking YouTube ads. Like a lot of these extensions, I find it still breaks a bunch of sites though so I still find myself jumping over to Firefox with uBlock Origin a lot...
Here's mine: https://apps.apple.com/app/id1532523816
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`
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`
So this is is a MAJOR flaw with WebExtension design.
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: ???
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: ???
WebExtension was started by Mozilla, and is based on Chrome's extension API. Google has no incentive to support the project.
It’s funny that they have their own corner of the web where they own the entire API and the rest have to follow. Just because Mozilla and Apple share most of the API it doesn’t mean that Google won’t change it, in fact Manifest v3 is coming soon.
Mozilla has implemented additional APIs that are never going back into Chrome because Google doesn’t care and doesn’t have to.
Mozilla has implemented additional APIs that are never going back into Chrome because Google doesn’t care and doesn’t have to.
Although Google is actually moving toward the standard in Manifest v3: https://developer.chrome.com/docs/extensions/mv3/intro/mv3-o... (mostly with a Promise-based API)
It could be, if you submit an RFC for a common format.
Frustratingly this is only for macOS Safari, and not for iPad ("laptop replacement") Safari.
That said, there are other great extensions like RECAP and I wish they could come to Safari too.
That said, there are other great extensions like RECAP and I wish they could come to Safari too.
The 1Password extension is way better now. I assume that’s due to this new support?
Is Safari a privileged process on OSX? Could someone develop a ptrace-style solution to disable signing and allow installation of Firefox WebExtensions?
Somewhat: it enables library validation and getting rid of that will break Apple’s signature on it and render it unable to access its data vault. Plus, such a thing would be a significant amount of effort, especially on an “API” that isn’t designed for this at all…see ‘freediver’s comments above for an idea of how much work needs to go into implementing Web Extensions even with full, source-level control of the browser.
Unlikely. As far as I can tell, Safari WebExtensions are built on top of the pre-existing Safari App Extension API. This was likely done so Safari could continue to rely on the macOS App Extension API instead of needing to duplicate all of that in Safari itself.
Seems like it ought to be scriptable to wrap a little boilerplate around the custom js and call xcodebuild on it.
Unfortunately "ought to be" != "easy". But if someone could do this it would be a service to extension developers and Safari users alike.
Unfortunately "ought to be" != "easy". But if someone could do this it would be a service to extension developers and Safari users alike.
It practically already exists. Xcode can import an existing WebExtension and generate an Xcode project for it. Assuming you are happy with the default behaviour of the companion app (which basically just gives you info on the extension, whether it is enabled in Safari, and how to enable it if not), you can just hit build and submit it to Apple.
That sounds pretty low friction (to me -- but I already develop with Xcode) in exchange for being signed and available in the App Store.
UsersScripts extension looks useful
https://apps.apple.com/app/userscripts/id1463298887
superkuh(2)
Just here to say A Memory Called Empire is an amazing SF novel. At first I was like wait is this article picking up my amazon history from nefarious cookies? Nope, OP author just agrees.
Well, it's not like Extensions are that much useful. Most people (the huge majority) don't use any (or even know how to install them, in Chrome or elsewhere).
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!
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!
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.