Dropbox today announced that it will be rolling out a limited version of its Dropbox Passwords password manager to users with a free Dropbox Basic account in early April. The feature launched last year for paying subscribers only.
Dropbox Basic users will be able to store up to 50 passwords, with automatic syncing on up to three devices.
See also: Dropbox Launches Password Manager, File Vault, and More Across iPhone and Mac.
Previously:
Google today announced that, starting July 1, it will be lowering its Play Store commission from 30% to 15% for the first $1 million of revenue developers earn using the Play Store billing system each year, as reported by TechCrunch.
Google estimated that 99% of developers that sell goods and services with the Play Store billing system will see a 50% reduction in fees.
Also kudos to Google for simply applying it to the first $1M rather than making a whole complicated program you have to apply for / get booted from if you go just over $1M / etc; hopefully Apple will grudgingly decide to do the same.
Anyway the fact that as of July 1st none of my revenues will be taxed at more than 15% is going to open up some very interesting possibilities in terms of licensing.
I’m happy to see more App Stores going down the 15% route but the “progressive taxation” nature of it just seems weird to me. It’s not like the Store’s cost/unit go up as more units get sold. Just go 15% across the board.
Neither do the store’s costs go to zero when distributing free apps that monetize through advertising. The weird structure is a great fit for Apple and Google’s goals. It quiets most of the complainers and increases the supply of apps without greatly reducing the stores’ revenue, which mostly comes from a small percentage of top apps.
Previously:
Update (2021-03-19): Mike Peterson (also: MacRumors):
If the App Store program was in place throughout 2020, for example, Apple would have been short $595 million in revenue. That’s about 2.7% of its estimated $21.7 billion it makes form App Store commissions. Google similarly would have made $587 million less in revenue, or just about 5% of the estimated $11.6 billion in Google Play fees it collected in 2020.
70/30 percent just feels harder and harder for Apple and Google to defend. Make it 85/15 across the board and it all becomes simpler.
In the meantime, thanks to Epic and others for improving the deal for us small developers. I don’t think Apple and Google would have done this without them.
Lorenzo Franceschi-Bicch (Hacker News):
Adobe wants Twitter to take down a tweet from five years ago that links to a site that allows visitors to download a 27-year-old version of the company’s PDF reader.
On March 6, a company that works on behalf of Adobe sent takedown requests for three tweets and several short URLs. One of the people who received the DMCA takedown request, well-known security researcher Mikko Hypponen, revealed that Adobe wanted a tweet of his that linked to the MS-DOS version of Acrobat Reader taken down. The news was first reported by TorrentFreak.
Matthew Panzarino (tweet, MacRumors, tweet, Slashdot, Hacker News):
Apple has discontinued its original HomePod after four years. It says that it will continue to produce and focus on the HomePod mini, introduced last year. The larger HomePod offered a beefier sound space but the mini has been very well received and clearly accomplishes many of the duties that the larger version was tasked with. The sound is super solid (especially for the size) and it offers access to Siri, Apple’s assistant feature.
John Gruber (tweet):
I love my HomePods, but clearly the market deemed them too expensive.
I know there are some people that really like the HomePod so I don’t want to harp on how it was an overpriced, over-engineered, fiddly, gimmicky, rudderless, Siri-hampered, mono speaker, and hurt the feelings of dozens of people. R.I.P. 🙏
Don’t forget its lack of an aux-in jack. My iPod Hi-Fi is going to outlast it.
I wish I had good things to say on the eve of the HomePod’s death, but it was just never a great product. I was never happy with the audio quality of a standalone unit, and Siri+HomeKit is incredibly inconsistent, and nowhere near as fun as a voice assistant as Google’s/Amazon’s
[…]
I expect the original HomePod to be dropped like a stone from future OS updates — it’s saddled with a CPU no longer supported by mainline iOS (they moved it to a tvOS core recently, just to stay afloat), and the HomePod mini is built on Apple Watch chips
For < $100 Google gives you an entire screen, which is pretty cool at doing things like showing the weather and providing more info on searches. Does a passable job at showing doorbell camera video too.
Don’t even get me started comparing Siri vs Google Assistant.
Also, HomePod mini discontinued ~2023? I’m afraid Apple is simply too late to the market here – cheaper, more diverse options from the competition, available everywhere, in multiple languages, with smarter assistants.
I try to use a HomePod pair with my Apple TV. When it works, it sounds fantastic. However most days it doesn’t. I get all kinds of failures — with content pausing, or one of the HomePods failing.
I think Apple fell into the trap of people who care about audio, thinking that everyone feels like they do. The vast majority of people are fine listening to music on cheap Bluetooth speakers, or ever from their phones, and paying that much for what might be better audio just doesn’t make sense.
You may still think four HomePods is a bit ridiculous, but trust me when I say that they really work well for our needs in this space. We can watch TV, or play music in one or both areas and it all sounds good. You might think “sounds good” would be table stakes, but so much consumer audio, especially wireless speakers, simply don’t sound good. Even my wife, who doesn’t typically care about this sort of thing, asked if we should by another pair when I told her that HomePods were being discontinued.
Am I a little sad that the original HomePod is going away? Sure, but do I have regrets owning four discontinued wireless speakers? Not at all.
Honestly, the decision to cancel it feels like a misstep. The HomePod was overpriced but it was differentiated. The HomePod mini doesn’t really excel at anything. The mediocrity of the Mini’s sound quality means it leans much more heavily on the ‘smart’ component of being a smart speaker, and we know that Siri lags behind Alexa and Google Assistant in many ways. By focusing on the HomePod mini, Apple is implicitly focusing on Siri.
See also: TidBITS.
Previously:
Update (2021-03-19): Andrew Abernathy:
My living & dining areas are “separated” by these little ledges, and due to the all-around design, a stereo pair of HomePods sends good audio to both sides. (It doesn’t appear to me that the newer minis would do as well.) For me, these have been perfect.
Michael Kukielka (via Ryan Jones):
The 2nd HomePod I bought after their cancellation is also from the launch stock.
Apple’s documentation should also state provisioning profile requirements of API.
I just burned a day thinking I’d be able to use HomeKit on a Developer ID app.
There’s no way the App Store will approve my utility; so the feature (which I thought was quite cool) is instead cut.
The documentation should also state which APIs work when sandboxed.
I have codesigned the application using hardened runtime and the
com.apple.developer.security.privileged-file-operationsentitlement (although this is outside App Store and no sandboxing).It doesn’t work and I see this error in the console:
(libsystem_secinit.dylib) com.apple.secinitd.fileoperations: xpc_pipe_routine() returned [5: Input/output error]
NSWorkspaceAuthorization apparently requires a provisioning profile.
Previously:
Update (2021-03-19): Jonathan Deutsch:
I was trying to use HomeKit in a Catalyst helper app on macOS. It can’t be provisioned for Developer ID, but would work for the App Store.
HomeKit is only available on macOS via Catalyst and UIKIt for Mac.
Underused GCD patterns:
Making a serial queue that’s less aggressive about creating threads (“non-overcommit”):
let q = DispatchQueue(…, target: DispatchQueue.global())All serial queues ultimately target a global queue, which is responsible for actually executing the work; but, for historical reasons, the default target is an overcommit queue. That means it has a higher max thread cap and creates threads more aggressively. This avoids that.
Multiplexing work onto a single serial queue efficiently:
theQueueWeAreAlreadyOn.async { … }This pushes towards architectures with small numbers of well-known queues and/or explicitly passing queues into things.
Probably overused GCD patterns:
- Global queues as anything but targets
- Almost any use of concurrent queues
- Queues as locks;
os_unfair_lockis more efficient (sadly a little trickier to use in Swift; no ideal solution here yet)- Turning async into sync with semaphores
Another overused GCD pattern I forgot: manually specifying QoS. Most of the time you can/should rely on automatic propagation, you only need to do it manually if you want to override that for some reason.
even when you do not set a target queue you have the autorelasepool of last resort, but you should never rely on it ever.
Nowadays you should always pass the “autoreleasing” attribute at queue creation. we couldn’t make it default due to things too horrible to mention.
See also: Modernizing Grand Central Dispatch Usage.
Previously:
Update (2021-03-22): Jonathan Joelson:
The lack of official GCD documentation is baffling given the complexity. Why isn’t any of this stuff explained here?
I haven’t found any better way to avoid these scenarios than by not blocking in the kernel unless you know for a fact that doing so will arbitrarily scale; and consequently, you need only launch a limited number of tasks: with rare exceptions you will not need libdispatch to schedule an unpredictable number of them to reach full core occupation.
[…]
If that queue is a serial queue, however, you have a real problem: as soon as your task has “returned” after calling the asynchronous API, there is nothing that prevents another unrelated task on the serial queue from launching, and finding the state not as it was when you usually start a task, but as you left it at the point you needed to call the async API.
So that leaves you with a rotten choice: either keep the synchronous call instead and risk thread explosion, or factor your code so your state is consistent at the point you hand over to the asynchronous API. But, wait. I don’t call that a choice: I call that a fake dilemma. Presumably, you were using the serial queue for the purpose of state protection, and if that queue can’t ensure its purpose, then the problem is with the queue. I haven’t found any way to “reserve” the queue until the completion has run, that does not seem to be possible with libdispatch. There is no simple solution here, to put it bluntly. If you have few enough serial queues in that situation, then I give you special dispensation to perform blocking calls from it, but in compensation every single such serial queue you create has to be considered equivalent to creating a thread, resource-wise.
dispatch_workloop_t is great stuff btw. It’s a serial dispatch queue that runs blocks in priority order instead of first-in-first-out. This can be considerably more efficient when you just need the thread + mutual exclusion aspects of a queue.
But it is not available in Swift.
