Yeah because the people hanging out with Anna Wintour are responsible for app reviews.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Reverses Course, Allows Transmit to Reinstate 'Send To' Feature
- Thread starter MacRumors
- Start date
- Sort by reaction score
Yeah because the people hanging out with Anna Wintour are responsible for app reviews.
Would you prefer they stuck to their original determination and refused to ever change?
Yeah! Very happy to see this. I don't have an AirDrop enabled Mac, so the Send To is a very convenient feature for me. Only yesterday I was making a greeting card in Pixelmator on my iPad and sent it to iCloud Drive so I could do all the crazy printer settings.
Well, maybe not for regular users like us. But you've got many companies that makes app that needs to know what rules to follow and what to and not to do. If they make mistakes their apps gets pulled and that's a few days until it comes back on the App Store. I'd yea it's important to look at the bigger picture.
Some reasons would be nice, but I guess Panic don't want to piss Apple off.
It is a bit ridiculous that Apple are doing this frequently. It's like they don't do any brain storming sessions to see what existing apps there are and how they might incorporate new features Apple is about to release.
At least Apple reacts reasonably quickly, and hey, this provides free publicity for Panic's Transmit app so I don't think they are complaining at all. Cue the conspiracy theories
It is a bit ridiculous that Apple are doing this frequently. It's like they don't do any brain storming sessions to see what existing apps there are and how they might incorporate new features Apple is about to release.
At least Apple reacts reasonably quickly, and hey, this provides free publicity for Panic's Transmit app so I don't think they are complaining at all. Cue the conspiracy theories
Seeing that this strategy did not work for most companies (out of all rejections only two got a public reversal), I wouldn't want to try it out with my apps. It is rather the other way around, only apps that are already popular enough make it onto the Macrumors frontpage and thus bring it to the attention of people at Apple beyond the original reviewer and the appeal reviewer can follow that cycle.
Last edited:
I think the app review process should be limited to making sure the app is mostly bug-free and doesn't do anything malicious like steal the user's data.
Other than that, the user should be allowed to decide if an app is worthwhile or not. If the app clutters up the dashboard and the user doesn't like a cluttered dashboard, they can just remove it. Maybe some users LIKE to fill their dashboard with crap. Let them!
Not only would this make the platform more developer friendly, but it would probably save Apple money since the App reviews don't have to be as extensive.
Other than that, the user should be allowed to decide if an app is worthwhile or not. If the app clutters up the dashboard and the user doesn't like a cluttered dashboard, they can just remove it. Maybe some users LIKE to fill their dashboard with crap. Let them!
Not only would this make the platform more developer friendly, but it would probably save Apple money since the App reviews don't have to be as extensive.
The people doing the QA are likely following a document to the letter that was written too hastily or is too brief and not flexible enough. I have seen many situations where the battle between detail required and brevity ends with no winners.
It's hard to write a single, flawless set of regulations to allow the massive number of submissions to be handled by teams who just follow procedures. What I do see is escalation to others to see if the 'violation' goes against the letter or the spirit of the rule once challenged, and some smart decisions are getting made.
That's not a bad thing, but they could attempt to control the negative PR associated with the higher profile apps better.
Note that these were removals for two quite different things, the only thing common being that they came with iOS 8 (notification widgets and iCloud drive).
But more generally, can any of you geniuses tell me what the rules for notification widgets should be? If your answer is: 'Anything goes', where does this 'Anything goes' stop? Skinning the whole OS? Installing Android on iPhones? Installing iOS on third-party hardware?
I don't know the answer, and it sure looks like Apple doesn't know the answer either (at least not comprehensively enough) and they certainly put more thought into it than any individual outside the company.
The functionality was obviously different in each case but that's hardly the point. The fact is Apple need to have clear, concise guidelines as to what is acceptable and not acceptable.
It's quite clear to see that historically Apple has always favoured the larger organisations over the little guy....discrimination springs to mind.
It all boils down to poorly defined guidelines. Guidelines should be clear and consistent, and any amendments or changes should be communicated to developers at least few months in advance.
Apple may request certain changes be made, but apps that meet the current guidelines should not be rejected during submission process.
Apple may request certain changes be made, but apps that meet the current guidelines should not be rejected during submission process.
I wouldn't get too worked up about this. This is just growing pains for new functionality. Apple needs to better understand the impact of widgets on the UI and user work flow and codify these requirements. The issue is that this will always be a work in progress. For most developers the rules will be robust enough in the next few months.
Now? Apple's AppStore has been the subject in mainstream media for awhile now. IE - inapp purchasing law suits...
That aside - I think that not allowing the sharing would have left to a lawsuit. Warranted or not. And not necc by Transit.
I was referring to the recent app rejections/reversals. It's not just a few devs whining about it on Twitter or their blog.
The outcome is no surprise. But it's typical hamfisted handling of the matter, like back when the App Store was new.
Only it's not new anymore. Apple should be able to figure these things out BEFORE issuing a rejection and embarrassing themselves. Same outcome, with less stress on good developers and less "scandal fodder" for the media.
There will be unexpected cases and flat-out approval process mistakes, whenever new functionality becomes available. Fine. But when those situations arise, they could be handled much better. I'm sure sometimes they are. But letting really obvious situations slip through? A process should prevent that.
Only it's not new anymore. Apple should be able to figure these things out BEFORE issuing a rejection and embarrassing themselves. Same outcome, with less stress on good developers and less "scandal fodder" for the media.
There will be unexpected cases and flat-out approval process mistakes, whenever new functionality becomes available. Fine. But when those situations arise, they could be handled much better. I'm sure sometimes they are. But letting really obvious situations slip through? A process should prevent that.
You're missing the point, and a fairly simple one at that.
Love the fanciful conspiracy theory
And another fact is that all these case relate to functionality added with iOS 8. It is hardly surprising that guidelines on new functionality aren't as clear and concise yet as those on older functionality.
I don't know the answer, either. But I know that what Apple has currently been doing in these instances is hindering the user experience and the developer experience. The user experience is something Apple pays a lot of lip service to so they would be wise to spend some time thinking about what their policy is going to be moving forward and then make sure all of the app reviewers and managers are on the same page with said policy.
Oh, stop it
This was obviously a bad decision from the start, and very quickly has been corrected. They make thousands of decisions a day. The rules have been changing from the beginning, and were MUCH stricter under Jobs. So relax.
This was obviously a bad decision from the start, and very quickly has been corrected. They make thousands of decisions a day. The rules have been changing from the beginning, and were MUCH stricter under Jobs. So relax.
And now imagine you are a developer that is not as well connected as Panic, or James Thomson...
Apple is on their way back to the 2009ish levels of arbitrarily applied rules and non-transparency.
Apple is on their way back to the 2009ish levels of arbitrarily applied rules and non-transparency.
Are you aware that the development of features costs time and money?
Apple knows every single developer. Maybe they should start to reach out to them and ask them privately what they will do with the new features?
Or maybe Apple could open a "Pre-Review" Center, where developers could send concepts of apps, and Apple discusses them internally and decides if they are okay.
There are many possibilities to solve the problem in a way that does not hurt developers.
It'll probably take them until June. And then there will be iOS9 features. And the whole thing starts again.
the message to developers is clear: don't adopt new API too quickly, or you risk to waste your time
Sorry, but Panic has been developing Mac and now iOS software for a long time and they are not going to do this just for some extra PR on a niche app.
Apple unfortunately seems to be suffering from some kind of internal bureaucratic issues that is causing them to make all these little mistakes.