Marco Arment (tweet):
With today’s 2019.4 update, you can now share audio or video clips, up to a minute each, from any public podcast. Simply tap the share button in the upper-right corner.
[…]
For podcasting to remain open and free, we must not leave major shortcomings for proprietary, locked-down services to exploit. Conversely, the more we strengthen the open podcast ecosystem with content, functionality, and ease of use, the larger the barrier becomes that any walled garden must overcome to be compelling.
This is really cool.
Timothy Buck:
Marco also updated Overcast.com’s episode and show pages. Now when you click an Overcast link on any device and you’re not logged into Overcast, you’ll receive a page with links to the Overcast app, Apple Podcasts, Castro, Pocket Casts, and a generic RSS Feed link.
As a podcast creator with 80% of my traffic coming from Overcast and Apple Podcasts, this is a hugely welcome change. This doesn’t solve the link sharing problem entirely, especially for shows who have large Android listenerships, but it will reduce the need for me to tweet 3 different links of the same episode.
Marco Arment:
I experimented with automatic transcripts from Apple, Google, and other various providers during clip-sharing development. But none were reliably usable.
They’re OK for search-indexing, but not for humans to read. Imagine the way your voicemail transcribes. It’s like that.
Marco Arment:
Clips are file attachments to wherever you’re posting them, so they’ll stay exact.
The web links load the file directly from the publisher each time and seek to the specified timestamp, so if they use DAI with variable-duration ads, they’ll be off by a bit. Another DAI problem.
Marco Arment:
I tried sending both the video and URL to the share system to see if various apps would do the right thing and share both, but most didn’t. So I offer separate URL and video sharing buttons.
My recommended workflow is to copy the URL, then share the video to wherever, and paste.
Federico Viticci:
Not only is @OvercastFM’s new clip sharing great for podcast listeners, but it’s also a terrific tool for creators who want to share better previews on social channels. I love this addition to the app.
Nick Heer:
Sharing just a clip is the audio equivalent of a blockquote. And because these things are generated as video clips by default, they work with Instagram and Twitter and all the other typical destinations for sharing. Brilliant.
Previously: Luminary Proxying Podcasts Without Asking.
Update (2019-05-31): Pádraig Kennedy:
Full credit to @marcoarment for bringing easy video clip sharing to podcast apps. I genuinely hate copying features from other apps, but once in a while a competitor does something really fucking cool and you have to respond.
Marco Arment:
I sometimes have the same dilemma. I always try to be original and do my own take on things (as do they; Castro is by far my most innovative competitor), but sometimes, a competitor does something the best/only/right way, and the best choice is to do it the same way.
We’re cool.
Pádraig Kennedy:
Thanks man, try this in the export session exportSession.outputFileType = .mov and you might not need an automatic kicking machine... 💚
Castro iOS iOS 12 iOS App Overcast Podcasts Web
Brent Simmons (tweet):
That’s where automation — Apple events — comes in. It doesn’t get in the way of the UI, but if you can find your way to Script Editor (or a similar app: there are others), you can learn how to write any feature or workflow you can dream of (as long as it’s technically possible).
Part of the genius of this is that you’re scripting the apps you already use. You’re scripting these great GUI apps that you know and love. No command line, no piping/launching/closing. Just pulling information from apps and telling them to do things.
[…]
An outside observer might think Mac users just use pretty — and pretty simple — apps, and that’s the whole story. But that completely misses the power and genius of Macs.
I can’t think of another platform with the sheer level of automation power that OS X (now macOS) has.
Jon Gotow:
With Marzipan reportedly coming in macOS 10.15 this year, Apple is further de-emphasizing the cooperative nature of macOS apps, and will most likely not support Apple events in the “iPad apps adapted to run on the Mac” context of Marzipan.
[…]
And as Brent says (and as I detailed in an earlier post), many Mac apps use Apple events to directly integrate with other applications. They tie everything together for you, taking your Mac experience from ‘good’ to ‘great’. Just in my own apps, Default Folder X communicates this way with the Finder, Path Finder, ForkLift, Terminal and iTerm2 to give you seamless access to folders no matter where you need them. App Tamer uses Apple events to make sure it doesn’t interrupt iTunes and Spotify when they’re streaming music for you. And there are numerous other examples throughout the Mac ecosystem (and probably on your Mac right now).
Previously:
Update (2019-05-02): Jason Snell:
I have a million questions about the future of user automation on Apple’s platforms, beyond just the scope of the changes in macOS 10.15. Are URL schemes really the future of inter-application communication, or is Apple working on a new system that’s a successor to AppleEvents that will offer a more robust pathway than a giant string of plain text? Is Shortcuts going to gain more low-level capabilities on both platforms? Will third-party automation utilities like Keyboard Maestro be able to control UIKit apps effectively?
In the end, I’m not as concerned with how user automation is preserved on macOS as I am concerned that it is preserved. Shortcuts is a remarkably powerful app, and even URL schemes can be richer than you might think—though they’re definitely inelegant.
They can do a lot more than you might think, but they’re definitely not a replacement for something like Apple events.
AppleScript Catalyst (Marzipan) Default Folder X History Mac macOS 10.14 Mojave Programming
Jack Nicas (Hacker News):
Over the past year, Apple has removed or restricted at least 11 of the 17 most downloaded screen-time and parental-control apps, according to an analysis by The New York Times and Sensor Tower, an app-data firm. Apple has also clamped down on a number of lesser-known apps.
In some cases, Apple forced companies to remove features that allowed parents to control their children’s devices or that blocked children’s access to certain apps and adult content. In other cases, it simply pulled the apps from its App Store.
[…]
“We treat all apps the same, including those that compete with our own services,” said Tammy Levine, an Apple spokeswoman. “Our incentive is to have a vibrant app ecosystem that provides consumers access to as many quality apps as possible.” She said the timing of Apple’s moves were not related to its debut of similar tools.
[…]
Apple told the companies that their apps violated App Store rules, like enabling one iPhone to control another, although it had allowed such practices for years and had approved hundreds of versions of their apps.
Apple allows corporations to use such software to control employees’ phones. But last year, the company stopped apps from using the software to enable parents to control their children’s devices.
[…]
The app makers said they were most frustrated by the process of meeting Apple’s sudden demands. In many cases, Apple alerted them that their apps would be removed — and their businesses crippled — via a short note, according to correspondence viewed by The Times.
When app makers asked for more information, responses were often perfunctory and slow in coming.
The article doesn’t do a very good job of presenting Apple’s point of view.
miki123211:
So, let’s get the facts straight here:
1. The apps used MDM profiles, intended for control of employee’s smartphones and/or vpns to filter access to apps.
2. Those approaches gave the app makers enormous control over the devices. If they used vpns, all internet traffic from the device could be intercepted. If they used MDM profiles, they had deep access to all the device’s settings. It was a huge privacy risk.
3. This was clearly against Apple’s policies. APIs were used for the purpose they were not intended for. That was what Facebooks’s certificates were revoked for. They should’ve feared removal since the day they wrote their first line of code.
4. I guess that Apple understood the need for parental control apps and allowed them, with the privacy risks, as there was no other way to get parental control at the time.
5. Apple knew how important iPhone addiction has become and developed their own, privacy respecting solution, screen Time.
6. The need for parental control has now been filled and the privacy risks of those apps now outweigh the benefits. Apple made the decision to remove.
Eric Slivka:
The report quotes several developers who had their apps removed, including one who says the removal came “out of the blue with no warning.” Apple is facing several complaints related to the moves, with a pair of developers filing with the European Union’s competition office and Russian cybersecurity firm Kaspersky Lab filing an antitrust complaint in that country.
Apple (via Phil Schiller):
Over the last year, we became aware that several of these parental control apps were using a highly invasive technology called Mobile Device Management, or MDM. MDM gives a third party control and access over a device and its most sensitive information including user location, app use, email accounts, camera permissions, and browsing history. We started exploring this use of MDM by non-enterprise developers back in early 2017 and updated our guidelines based on that work in mid-2017.
MDM does have legitimate uses. Businesses will sometimes install MDM on enterprise devices to keep better control over proprietary data and hardware. But it is incredibly risky—and a clear violation of App Store policies—for a private, consumer-focused app business to install MDM control over a customer’s device.
[…]
When we found out about these guideline violations, we communicated these violations to the app developers, giving them 30 days to submit an updated app to avoid availability interruption in the App Store. Several developers released updates to bring their apps in line with these policies. Those that didn’t were removed from the App Store.
I think Apple’s heart is in the right place, but I don’t like the way they’ve handled this.
It’s hard to believe that Apple only recently figured out that these very popular apps had been using MDM for years or that MDM was potentially dangerous. Their spin is basically that App Review was asleep at the switch—which I guess sounds better than that they just decided to change the rules and pull the rug out from underneath these developers and users.
The framing is that the developers are choosing not to bring their apps into compliance, but it sounds like it’s not possible for them to do so—hence the quotes in The Times about Apple being unwilling to provide specific guidance.
There’s no evidence presented that any of these developers abused the power of MDM. I’m sure they would prefer to have a more tailored API, but there isn’t one. In the meantime, they seem to have provided useful features that customers liked and that are not available in Apple’s first-party solution.
John Gordon:
This is a complicated area I know well. Overall Apple is wrong and abusive. OTOH these apps all failed my testing. OTOH Apple’s solution has huge unfixed bugs ...
Colin Cornaby:
The point about MDM is fair, but the lack of an alternative to MDM for these use cases is problematic.
John Gordon:
In my testing, for a user with two iOS devices, Apple’s remote control “Content & Privacy Restrictions” only work for one of a user’s devices. The other is not affected …
… I don’t think anyone else on earth has actually tried using Apple’s Screen Time… It’s as broken as their keyboards.
… interestingly looking at Screen Time on either the controlling or controlled device shows that account cannot be changed … but it can be changed (not grayed out)
Nick Heer:
App Review should, at the very least, prevent rule breakers from getting into the App Store in the first place. They failed to do that by allowing high-profile parental control apps into the store that cannot work without violating their rules. But they should at least be very clear about the circumstances of rule violation, particularly when an app has already been approved.
It’s also clear that there is a demand for these apps. I think it would be great if there were APIs for Screen Time data, perhaps tied into HealthKit.
Benjamin Mayo:
The timing of Apple discovering the MDM abuse does line up almost too conveniently with the launch of Apple’s own Screen Time features in iOS 12, but realistically Apple has no real incentives to push Screen Time over third-party offerings.
However, there is a nuance to Schiller’s words. He welcomes developers to continue making parental control apps that are not based on MDM profiles. The problem is, making such a service results in a significantly limited user-experience. The iOS app sandbox prevents a normal app from gathering phone-wide data like which apps were opened and for how long, or support ‘downtime’ behaviours like blocking an app from working after a timeout.
Schiller names an app called Moment – Balance Screen Time as an example of a great app for parents. This app relies on user’s manually screenshotting their Battery screen every day to upload to the Moment app, which uses optical character recognition to read the rows of most used apps. It’s a big hack and nowhere near as seamless as the always-running-in-the-background, official, Screen Time.
Tony Fadell:
Apple’s Screen Time still has many holes & deficiencies. Their v1.0 solution was a rush job & it’s very non-intuitive to use. Apple should be building true APIs for Screen Time so the “privacy” concerns are taken into account instead of limiting users App Store choices.
[…]
Apple until you have a real API, let the 3rd party apps be available to App stores users. Those devs are trying to help, not steal data. The only reason they have to do what they do is because you don’t provide a proper API.
John Gordon:
I’m so glad you wrote this. I felt like only user. We need API to build solutions for special use cases. Great need for cognitive disability users who age out of “traditional parental controls”. OTOH, no 3rd party solution actually works. I tried them.
Will Strafach:
Apple seems to now be very serious about apps capable of access to certain data. we had to fight tooth and nail to get approval for Guardian, and the nature of Apple’s questions indicated to me that they would like to avoid another Onavo.
Previously:
Update (2019-04-30): Shawn King:
While becoming more common, it’s still a fairly unusual move for Apple to respond so quickly, directly, and on a weekend to stories like the one in the New York Times.
Timo Perfitt:
Is it possible that Apple didn’t know that companies were using MDM for parental controls? Why were the apps approved in the first place?
All of this seems like a communications / feedback failure.
Ryan Jones:
This is a really bad look for Apple. These apps have been using MDM for years and years.
Either they allowed apps that “put users’ privacy and security at risk” for 3+ years or they only now care for competitive reasons. Has to be one (or both).
Rene Ritchie:
What was Apple’s full statement to the times? Unless and until the Times posts it, we don’t know.
[…]
Apple opens up this way:
Apple has always believed that parents should have tools to manage their children’s device usage. It’s the reason we created, and continue to develop, Screen Time. Other apps in the App Store, including Balance Screen Time by Moment Health and Verizon Smart Family, give parents the power to balance the benefits of technology with other activities that help young minds learn and grow.
And, really, I think that’s just about the worst way to open. No other apps currently permissible on the App Store has the capabilities to really offer similar features in a convenient, effective way.
My guess is that Apple is doing what Apple typically does: Introducing Screen Time as a built-in feature, dog-fooding it, adjusting it if and as needed, and then, a year or two later, introducing an API — application programming interface — that other apps can use to securely, reliably, privately tap into the same data and offer alternative implementations and value-added services.
I would say: “typically” for areas where Apple wants to have an API. I’m not sure that this is a case where they do. They haven’t added an API for Night Shift, and I doubt that they will. There’s no API to make third-party e-mail clients or Web browsers that can do what Mail and Safari can (Schiller’s comments notwithstanding) or even set a default app.
Update (2019-05-01): OurPact (via Zac Cichy):
We present here, point by point, Apple’s recent claims in defense of removing apps that use MDM, to be contrasted with quotes from their own MDM documentation.
[…]
To date, OurPact has been approved by Apple for release to the App Store 37 times, with documented use of MDM.
In Apple’s public statement, they claimed that they gave developers 30 days to modify their apps in line with their guidelines, even though their guidelines make no mention of MDM. We did not receive any notice before OurPact’s child app was removed by Apple.
More importantly, there is no way for any company offering a parental control app to remove MDM functionality and still have a viable product. If Apple offered alternate APIs to achieve the robust parental controls that OurPact provides we would happily use them. Unfortunately, no such API exists. All attempts to open a dialogue with Apple to create those APIs have also been refused.
[…]
The takeaway from the call was that the technology in use was not the issue, but the act of blocking or restricting the use of third party apps was. Once again, user privacy was never raised by Apple as a concern.
Update (2019-05-02): Joe Rossignol:
In the days since, a handful of developers behind parental control apps including Qustodio, Kidslox, OurPact, and Mobicip have responded to Apple's press release with open letters, calling for the company to make the APIs behind its Screen Time feature available to the public for use in third-party apps.
See also: Techmeme.
Update (2019-05-10): See also: Accidental Tech Podcast.
Antitrust App Store App Store Rejection Business iOS iOS 12 iOS App Mobile Device Management (MDM) Parental Controls Phil Schiller Privacy Screen Time Tony Fadell
