This is a result of trying to retrofit a series of tighter security measures on top of a system that was not originally designed for them, in a way that is both understandable to users but also doesn't break back-compat with APIs (and therefore a lot of existing third-party apps that are seldom updated) too badly. I'm not saying Apple did a perfect job here, but it's a hard problem.

Yes, the problem could probably be "solved" by adding more UI, but "more UI" is not always a good solution. The more UI that exists, the less likely the user is to successfully navigate it. On the other hand, adding additional complexity to an existing UI is also fraught with potential for new bugs and edge cases. Again, not defending the status quo, but I can see how it might have ended up like this.

This is worth spending more time on trying to improve, and perhaps it is reasonable to expect better from an almost-$4tn company. But at the same time, a potential solution is far from easy or obvious, and there is a risk of making things worse if not done with an extreme level of thought and consideration.

(Alternate pessimistic take: A large number of users don't care or read anything, they just click "allow" on anything that gets in their way. A smaller set of users are terrified and disgusted by repeated invasions of the privacy and click "deny" on everything. None of these implementations are doing any good for either group. The allow/deny design pattern is badly broken and in need of rethinking.)

--

Lately I’ve been unsatisfied with available options for music players on the Mac. Everyone focuses on mobile (I know, that’s where the money is) and it feels like there’s not as much good stuff for Mac as there used to be. Well, I’ve been using the Mac for a long time and I still like it, and I wanted a good music player, so I made my own.

I started with SwiftUI, since that’s what I’ve used most recently at my iOS jobs, and I like it well enough. I soon found that SwiftUI is quite a bit rougher on macOS, so I ended up rewriting a few components in AppKit, although it remains mostly SwiftUI.

I know it’s risky to build on someone else’s service, so my first and main priority was to support local files on a disk, the simplest possible way of playing music. I layered on top of that an optional SQLite db (which I call “Librarian”) for indexing and search. I used AVPlayer (part of AVFoundation) which meant I didn’t have to worry about any audio playback details, I just let the system play whatever it can play (MP3, AAC, FLAC, etc. - but not Ogg Vorbis, sorry).

But I also still use Apple Music for discovering new music, so I integrated that too. That API (MusicKit) was a bit of a mixed bag. The upside was easy onboarding (no need to sign in, just a single permission prompt) and few restrictions on what I could do with it. The downsides are a lot of missing functionality (compared to what the first-party app can do), functionality that is present often tends to be under-documented and/or broken, and the API provider has shown little interest in fixes or improvements lately, especially on the macOS platform. The most absurd point was when I realized there is (apparently?) no way to make a volume control (!).

I briefly looked into Spotify, but they don’t have a macOS SDK, and their terms prohibit commercial and multi-source use. So it seems like that possibility is going to remain closed to me.

Finally, I added Plex and Jellyfin integrations, because once I had a system that could support multiple sources, I figured why not add some more that people might be interested in.

Since I got laid off last year, I’ve been working on this full time, just by myself. I think it’s in pretty good shape for release, but I really need some more eyes on it, since we all know that devs aren’t good at testing their own code (as much as I try).

I’d also love to get some more general feedback from others; I made this all to my own taste, but people’s music listening habits vary widely. I’m sure I’ll never be able to make everyone happy, but I’m open to considering just about anything. So, let me know! And thanks for taking a look.

-dmd

Comments URL: https://news.ycombinator.com/item?id=45213235

Points: 7

# Comments: 2

Note that it works as either a prefix or a suffix - it might be easier to put the insertion point at the end of the text box.

If you're using Safari, you can use my Safari extension to do this with a toolbar button or keyboard shortcut: http://horizon-nigh.org/re-search/

People often look at me like I'm crazy when I tell them this. I haven't quite figured out why.

If I need to look up some personal thing in the middle of the day, I reach for my phone. If I find I've been reaching for my phone too much that day, I get up and put it on the other side of the room. Now every would-be distraction requires me to physically move my entire body.

As far as I can tell, Final is not really about reducing fraud, which, as you correctly state, is mostly a non-problem for customers. Instead, its value is in increasing my personal convenience, by reducing the annoyances the credit card companies force me to deal with as a direct result of their absurdly outdated technology.

Open it up though, and the deception ends immediately. Just your usual tacky, glossy printed brochure.

This is been public knowledge for as long as the App Store has existed: http://www.macrumors.com/2008/08/11/30-million-in-app-store-...

Jailbreakers found it almost immediately: http://forums.macrumors.com/showthread.php?t=549203

Technically, the third-party could simply make up a list of random (but valid) numbers, send them to the carrier to subscribe, and the carrier would do it. There is no technical means in place to stop this. The only thing that (in theory) stops it is the carrier noticing the high number of customer complaints and deciding not to do business with the third-party any more - a clear conflict of interest, since deciding to ignore the problem benefits the carrier financially.

What many of these services do is toe the line, by enticing a customer to give up their phone number for some completely unrelated reason, and bury somewhere in the fine print that they are signing up for a recurring charge on their phone bill. The customer has absolutely no idea that this is happening unless they read through pages of legalese. This way, the charges are technically opt-in, even though no reasonable person would describe it as such.

https://en.wikipedia.org/wiki/Cramming_(fraud)

The brain-dead simple technical solution for this is for the carrier to check with the customer before adding a charge to the bill. There is no reason not to do this.

Or maybe just get rid of for-pay SMS services altogether. In the age of smartphones they are useless.

Many of the possible actions resulting from tapping that icon (on iOS) may be unrelated social sharing (e.g., copy, save to photo library, assign to contact, etc.).

[1]: UIBarButtonSystemItemAction; https://developer.apple.com/library/ios/documentation/uikit/...

If it's stored in the same place as the encrypted password, then you have gained no security over storing it in plain text.

If it's stored in a separate system, then you have substantially increased the complexity of the system, and in general, a more complex system is harder to implement securely.