Apple Makes Panic Remove Transmit’s Export Feature
Panic, introducing Transmit for iOS in September:
Then came the introduction of iOS 8. It’s an exciting update for users, and a really exciting release for developers, not least because of a little something called App Extensions. By utilizing App Extensions, Transmit could effectively provide standard file transfer protocols for any iOS 8 app. Overnight, this idea that made very little sense suddenly made all the sense in the world.
[…]
You’re probably already familiar with the Share button in iOS. If you’re, say, looking at a photo, you can tap the Share button and send the photo by email, iMessage, AirDrop, and so on. With Transmit iOS installed, you can also now send that photo (or other document) to any FTP, SFTP, WebDAV or Amazon S3 server, right from Photos.
In other words, any iOS app that supports the Share sheet magically gains support for these protocols when you install Transmit iOS.
This sounded like a great feature, finally a way to easily share files between iOS apps and other devices, using any of a number of protocols.
Nate Boateng, yesterday:
Ugh, Apple is messing with Transmit too.
Apple now forcing @panic to remove iCloud Drive functionality. Why? Dozens of apps can “send” to iCloud Drive.
Specifically, export feature removed. No more export to iCloud Drive, Dropbox, etc. Before and after.
The thing that PCalc, Drafts, and Transmit all have in common is that they’re power user tools. I’d wager heavily that their users are more likely to be longtime Apple supporters and very tech savvy. Never mind the silliness of going after developers who actually use the new APIs; the stupidity of taking on software used by Apple’s most ardent supporters is baffling to me.
Update (2014-12-08): Cabel Sasser:
Also, at Apple’s request, we had to remove the ability to “Send” files to other services, including iCloud Drive.
In short, we’re told that while Transmit iOS can download content from iCloud Drive, we cannot upload content to iCloud Drive unless the content was created in the app itself. Apple says this use would violate 2.23 — “Apps must follow the iOS Data Storage Guidelines or they will be rejected” — but oddly that page says nothing about iCloud Drive or appropriate uses for iCloud Drive.
If the issue is just iCloud Drive, why did we remove the other destinations? We had no choice.
[…]
We haven’t shared, and likely never will share, most of those stories. To be clear, we always work all of the angles available to us to keep our software great, and there’s no doubt there are countless great people at Apple who are doing wonderful work and want the best for all developers. But we have to remember Apple is now a massive organization with countless divisions — the App Review team isn’t even in Cupertino, for example — and sometimes that means the wheels turn slowly, or the car, well, drives backwards. It’s hard to describe the legitimate emotional toll we feel when we’re angry or frustrated with a company we love so deeply. But then we realize it’s never Apple we’re frustrated with. It’s always the App Store.
Another great iOS 8 feature crippled by capricious, unwritten, after-the-fact policies.
[…]
This sure feels like the ramifications of an internal turf war.
The “Export to iCloud Drive” feature has become popular among apps that deal with files and user documents: it can be found in hundreds of apps updated for iOS 8 such as Pixelmator for iPad and Apple’s own GarageBand. Restricting the pool of similar apps to apps that can download files, the same feature can be found in popular file managers such as Documents 5, GoodReader, and FileApp – all of them updated for iOS 8 and available on the App Store.
I thought the whole point of iCloud Drive, and iOS 8’s new sharing sheet for storage services like Box and Dropbox, was to allow users to do exactly what Transmit enabled.
There doesn’t appear to be a common understanding of what rules the app reviewers should be focusing on, or even what rules exist — as far as I can tell, there’s no written rule that prohibits what Transmit was doing here. The lack of consistency is especially frustrating for developers. They become increasingly unsure of how much effort they should invest in features that shouldn’t be controversial. They don’t know if they’re the next ones to be rejected for some feature while dozens of other apps remain on sale with a similar feature.
In this particular case, I don’t understand what Apple gains by having Panic remove their export to iCloud Drive feature. I don’t understand what Apple or their users would lose — financially, morally, ethically, or in any other way — by allowing Transmit to retain this feature. If anything, this entices people to use iCloud Drive.
Update (2014-12-11): Charles Arthur (via James Thomson):
The Guardian understands that Panic will be allowed to reinstate sharing - but that only raises the question of why it was stopped in the first place. Apple declined to comment to the Guardian on the banning or reinstatement of the functionality.
[…]
The Guardian understands that the reversal over PCalc was the result of internal discussions at Apple where the initial rejection by the App Store team was overruled by executives.
After a considerate conversation with Apple, Transmit iOS 1.1.2 has been released with restored “Send To” functionality.
11 Comments RSS · Twitter
It's stuff like this that makes me wish there were some other UNIX-like technology ecosystem as usable as Apple's. I've been feeling this way for a couple of years now.
I found this pretty annoying. I don't have that many uses for FTP on my iOS devices, but the ability to use Transmit as a swiss army knife for file transfer did mean that I was using it more than I thought I would.
I'm excited for the promised Panic blog post on Monday...
Now we have not heard Apple's arguments, but the most charitable interpretation I can think of is that Apple considers a share extension not suitable for purposes that can already be fulfilled by a document provider extension (which Transmit iOS still provides, thankfully). So at the very least, this means Apple still has the pretense of dictating to app developers what's best for the user even absent any security justification or other reasoning based on any traditional "platform steward" responsibility. *sigh* This change is slow going…
Well, after reading Cabel's post, I've gotta say, I don't see the problem here. This AppStoreMonster rejection doesn't interfere with Candy Crush gameplay in any way, shape, or form. And what else is iOS there for?
Oh, silly me, reading the Panic blog post I realize what they had to remove was their ability to act as a host for share extensions, not the share extension they themselves provide to other apps. This does not change my analysis much, though, in fact I just blogged about it.
[…] latest events, of which the Transmit iOS feature expulsion is but the most visible, have made me think and eventually reach the conclusion that the iOS (and […]
"This does not change my analysis much, though, in fact I just blogged about it."
While I. of course, agree with your solution to the AppStoreMonster's issues, Pierre, I think you miss the central point.
To begin with, all app review decisions must refer to normative texts published before the app was submitted (no retroactive application).
Since day one, Rule #1 of the AppStoreMonster has always been the real rules are unwritten. From Cupertino's POV, this is a significant and major feature, not a bug.
It lets them implement their objectives without having to spell them out in any way that could get them in trouble, in either a publicity or legal sense.
For example, I believe Apple's issue with Transmit has absolutely nothing to do with the official explanation, and has everything to do with Apple's desire to avoid making it easier to use non-iCloud solutions. Apple obviously has incentive not to make that clearly spelled out.
Implementing your (eminently sensible) solution would require a full 180 degree reversal in how Apple achieves its platform objectives through the review process, and thus is simply not going to happen.
The whole point of a velvet rope & bouncer system is that the club doesn't have to have explicit admission policies open to criticism. Admission to the club is all up to the discretion of the bouncer, who is enforcing the unwritten objectives of the club, with no paper trail to be criticized.
(Psst, Mr Chucky! I've got a secret for you: comments are enabled on my blog post. It's true! Go ahead, try it, the water's fine.)
[…] with the Transmit case, I don’t think there was ever a written guidelines that was being […]
I'm starting to wonder what the enthusiasm will be next WWDC when they announce some new developer APIs for user-facing stuff.