
At Apple’s request, we removed the ability to “Send” files to other services - Mowsh
http://www.panic.com/blog/transmit-ios-1-1-1/
======
milen
This is actually just one of the many ridiculous decisions taken by the App
Store review team. The truth is that developers keep getting forced to remove
functionality, sometimes the decisions are reversed but not always (and it
might only work if you've got a large enough following).

I've had enough of this stuff and I've voted with my feet - I no longer
develop for iOS and I'm back to the Mac, outside the MAS.

My absence won't make any difference to Apple but it makes a huge difference
to my wellbeing and health by not having to deal with this stuff. It pains me
so much to see fellow developers' efforts just thrown down the garbage bin.
It's extremely demotivating to have your work crippled when you're striving to
create the best software. The reason why this keeps happening and will
continue is simple - there are hundreds of thousands of people developing for
iOS, it's Apple's playground and their rules - if you don't like it, you can
leave. If you're an indie, you have zero leverage, that's the reality. I
honestly hope things improve in the future but until that happens, I'm done
with it.

A few recent examples where the (Mac) App Store cripples apps:

\- Drafts get asked to remove widget while other widgets to do the exact same
[http://www.macrumors.com/2014/12/02/apple-drafts-widget-
remo...](http://www.macrumors.com/2014/12/02/apple-drafts-widget-removal/)

\- Rejected for slide to start, which is a gesture not even used anymore:
[http://mjtsai.com/blog/2014/11/25/racesplitter-rejected-
for-...](http://mjtsai.com/blog/2014/11/25/racesplitter-rejected-for-slide-to-
start/)

\- Sandbox forces feature removal
[http://mjtsai.com/blog/2014/12/02/garagepays-encryption-
remo...](http://mjtsai.com/blog/2014/12/02/garagepays-encryption-removed/)

\- Notification Center rejection [http://www.macrumors.com/2014/11/18/apple-
cracks-down-on-nea...](http://www.macrumors.com/2014/11/18/apple-cracks-down-
on-neato/)

\- PCalc got asked to remove calculator but then decision reversed
[http://www.macstories.net/ios/apple-asks-pcalc-developer-
to-...](http://www.macstories.net/ios/apple-asks-pcalc-developer-to-remove-
ios-8-widget/)

~~~
eridius
> Notification center rejection

Wait, that app had a fake keyboard _inside_ a notification center widget?
That's truly awful and roundly deserved to get rejected.

> Sandbox forces feature removal

I don't see how this is relevant to your comment. This wasn't a decision by
app store review, or anything like that at all. This appears to simply be that
the app was using functionality that is not possible to do inside the sandbox.
If he was shipping on the MAS before, he must have been using a temporary
exemption and would have known that it would have to get removed once those
temporary exemptions stopped being allowed. This is a purely technical
limitation and has nothing to do with the sort of management issues you're
complaining about.

> Slide to start

That seems like a legit rejection to me as well. Looking at the actual
screenshots, they tried to make their control look and feel pretty damn close
to the official Apple control. This is a control that Apple spent years
training people meant "unlock" (or more specifically, "unlock device"). So
even though Apple isn't using it right now, they're still well within their
rights to claim that it is too similar to Apple's own UI widget (especially
for something that does completely different functionality).

I bet that if the slider didn't look so intentionally similar to Apple's own
widget, he wouldn't have had an issue. But he deliberately aped Apple's UI,
and should have expected this to eventually happen.

I'm also a bit irked that he's trying to play this up as a big "I got a bogus
rejection!" thing and completely ignored the fact that Apple told him to
remove _or revise_ it. The issue is not that the act of sliding a finger
across a screen to start the race is verboten. It's that his widget is _too
similar_ to Apple's UI. Note the actual quotes:

> 8.3: Apps that appear _confusingly similar_ to an existing Apple product,
> interface, or advertising theme will be rejected

[emphasis mine]

> The “slide to start the stopwatch” is similar to the “slide to unlock in iOS
> device”.

> Thank you for your message. In order for the app to be reconsidered for the
> App Store, please remove _or revise_ the Slide To Start feature. Have a good
> day.

[emphasis mine]

> Specifically, the Slide to Start Race UI element is not appropriate and not
> in compliance with the App Store Review Guidelines as it is _too similar_ to
> the iOS Slide to Unlock UI.

[emphasis mine]

Instead of trying to stoke public outrage, he should just accept that his UI
widget, which was very obviously based directly on the slide-to-unlock widget,
should be altered to not look so similar.

\--

Yes, there are bogus decisions. PCalc is a good example. But there are also
plenty of valid rejections too (many orders of magnitude more). And it's a
mistake to think that every publicized rejection is invalid.

~~~
milen
> Wait, that app had a fake keyboard inside a notification center widget?
> That's truly awful and roundly deserved to get rejected.

While the tastefulness of that solution might be questionable, I believe users
should be able to decide for themselves whether it's acceptable or not. Of
course, this is Apple's turf and they can make any decisions they like. Note
that lots of users quite liked Neato - should we be making decisions for them?

The real question is: where do we draw the line? Different people will have
different opinions but I think most people would agree that the Panic
situation, Drafts getting asked to remove their widget while others had the
exact same functionality is not acceptable.

The examples I listed demonstrate a problem that's endemic on the App Store -
while we might disagree on particular rejections, it's quite obvious there are
issues.

With regards to the sandboxing issue on the MAS, it's relevant because Apple
are themselves exempt from the restriction to ship sandboxed apps - this is
hypocritical. Moreover, it objectively leads to a worse experience for
customers, which I feel is against both Apple's and developers objectives.
It's an example how the MAS effectively cripples 3rd party apps without
leaving them a choice, while 1st party apps enjoy special privileges. Again,
there's nothing inherently wrong in Apple making the rules - it's their
platform after all but developers need to be aware what they sign up for when
they decide to distribute their software on the MAS.

\---

Responding to your updated post:

> ... But there are also plenty of valid rejections too (many orders of
> magnitude more). And it's a mistake to think that every publicized rejection
> is invalid.

Of course, I totally agree with you. I don't think anyone is arguing that
every publicised rejection is invalid - I was trying to make the point that
we're seeing increasingly questionable rejections that a lot of people would
agree are hurting the platform itself.

~~~
eridius
> Apple are themselves exempt from the restriction to ship sandboxed apps -
> this is hypocritical.

What makes it hypocritical? Apple developed the OS that you're using, so
there's hardly a trust issue when talking about running applications from
Apple on top of the Apple-developed OS. Sandboxing doesn't exist because of
some high-minded ideal, it exists to solve the trust and security problem.

Apple should sandbox any apps they ship if at all possible, but only because
it protects the app and the user from any security issues. If an app can be
remotely exploited somehow, then being sandboxed prevents the exploit from
having full access to the local filesystem. But beyond that one concern (which
may not even be relevant for apps that don't really do anything with the
network), there's no real reason to care whether Apple sandboxes a given app
that they ship.

> Moreover, it objectively leads to a worse experience for customers

What does? You're being a bit unclear here so I don't know what you're
referring to with "it" here. Apple being exempt from sandboxing restrictions
leads to a worse experience for customers? Doubtful.

> It's an example how the MAS effectively cripples 3rd party apps without
> leaving them a choice

What do you mean, without leaving them a choice? The MAS is just one of many
storefronts available to Mac users. 3rd-party apps that don't wish to sandbox
always have the choice of not using the MAS. They can continue to work exactly
as they have done for the past several decades. The MAS is relatively new and
is not replacing any existing software delivery mechanism, nor is it imposing
any restrictions on apps that choose to ship outside the MAS. It doesn't even
prevent users from migrating to a non-MAS variant of the app later; it's been
well-known for a long time now how to have an app that supports both MAS and
non-MAS distribution channels and have the non-MAS app still validate the MAS
license.

~~~
milen
> But beyond that one concern (which may not even be relevant for apps that
> don't really do anything with the network), there's no real reason to care
> whether Apple sandboxes a given app that they ship.

The concern is that if you want to ship software on the MAS, like some of
Apple's, that requires certain functionality which does not have a way to be
accessed if you're sandboxed, then you cannot - while Apple can. As I
mentioned multiple times, it's Apple's platform, they make the rules and can
do whatever they want but this means that there are certain classes of
software that cannot be distributed via the MAS by 3rd parties, only by Apple
as they are not bound by the same rules.

> What does? You're being a bit unclear here so I don't know what you're
> referring to with "it" here.

The request to remove functionality due to (M)AS rules leads to an inferior
experience for customers, as those customers can longer access that
functionality.

> Apple being exempt from sandboxing restrictions leads to a worse experience
> for customers? Doubtful.

I don't know how you came up with that, it was never said nor implied in any
way whatsoever.

> What do you mean, without leaving them a choice?

It means that if you want to distribute via MAS, you have to cripple (or
remove) part of your app's functionality in order to pass review. Again,
nothing inherently wrong with that but the net effect is that your software
might be inferior when distributed via the MAS vs outside.

~~~
eridius
The MAS is Apple's storefront. Of course their own software is going to be
distributed via it, whether or not that software is sandboxed. The existence
of non-sandboxed Apple software on the MAS does not impact 3rd-party MAS
software in any way, shape, or form.

Basically, the goal of the MAS is to be able to sell software that users can
implicitly trust to not be harmful. For Apple software, users can trust it
because it's Apple. For 3rd-party software, the only way to ensure the
trustworthiness is to require sandboxing. Apple software should be sandboxed
when possible, because that minimizes the downside of certain classes of
software bugs, but beyond that one scenario, there's no reason to care whether
Apple software is sandboxed.

Yes, there are certain classes of 3rd-party software that cannot be shipped on
the MAS because of sandboxing. But Apple allowing their own software to ship
un-sandboxed has no bearing on this. The sandboxing requirement would prevent
this 3rd-party software from shipping on the MAS regardless of whether Apple
sandboxed their own apps.

The only real argument to be made here is claiming that 3rd-party apps should
be able to ship on the MAS without being sandboxed, but that runs counter to
the entire purpose of the MAS and will never happen.

The only really useful thing to actually try and get Apple to change is to
expand the sandboxing capabilities to allow certain things that 3rd-party apps
want to do and cannot do today. They've added more and more capabilities over
time. The question is what functionality can be effectively exposed to
sandboxed apps without opening up a security hole.

> The request to remove functionality due to (M)AS rules leads to an inferior
> experience for customers, as those customers can longer access that
> functionality.

That functionality should never have been in the MAS app to begin with. In the
case of GaragePay I'm assuming they used a temporary sandbox exception, as
Apple allowed those when sandboxing was new to give 3rd-party apps time to
adapt, and to find out what exemptions were commonly requested in order to
figure out in what ways the sandbox needed to be extended. If that's the case,
then GaragePay's developer should have known from day 1 that they'd eventually
have to remove this functionality (assuming the sandbox would eventually allow
for invoking `hdiutil` should have been obviously unlikely from the start).

In most publicized cases, the app that gets the rejection that requires
removing functionality was always in violation of the rule, and were just
hoping to not get noticed. Sometimes that works, sometimes they get caught.
And when caught obviously violating an existing rule, there really should be
no surprise at all that Apple requires compliance with the rule. And there
should be no outrage either, or claims that Apple should allow the app to
continue violating the rule. The only really valid argument here is that Apple
should be consistent in applying the rules, and I think everybody (including
Apple) agrees on that point.

It's the cases where Apple rejects an app for what many believe is an improper
application of a rule that deserves community outrage. In this case, I think
the App Store reviewer is incorrectly applying rules meant for regular
document storage as if it had anything to do with iCloud Drive. But please
note that Panic is not asking for community outrage. They're just explaining
to their users why the functionality is gone. I expect they're taking the
right steps privately, talking to the Review Board and whatnot.

Also note that the claim "Apple shouldn't apply that rule, because it removes
app functionality, and that's bad for users" is quite ridiculous. Apple not
consistently applying certain rules is the #1 complaint people tend to have
with the App Store review policies. And claiming that "user functionality" is
so holy that it must be preserved even when it obviously violates the rules
makes no sense. The fact that an app manages to sneak rule violations past the
review board in the past does not in any way mean it should be able to do so
in the future, and the fact that an app relies on rule violations in order to
provide functionality does not mean it _deserves_ to be able to violate the
rules.

> It means that if you want to distribute via MAS, you have to cripple (or
> remove) part of your app's functionality in order to pass review. Again,
> nothing inherently wrong with that but the net effect is that your software
> might be inferior when distributed via the MAS vs outside.

If your app requires violating app store rules for certain functionality, then
you shouldn't be using the MAS as your distribution channel. It's that simple.

> I don't know how you came up with that, it was never said nor implied in any
> way whatsoever.

That was the subject of the immediately prior sentence. It provided the
context for the subsequent sentence, and was the natural choice for the
meaning of the word "it", except in that it didn't make much sense. Which is
why I asked for clarification.

~~~
milen
> The only real argument to be made here is claiming that 3rd-party apps
> should be able to ship on the MAS without being sandboxed, but that runs
> counter to the entire purpose of the MAS and will never happen.

The argument that I've been making for years is that proper entitlements
should have existed for all the functionality necessary before the requirement
for all apps to be sandboxed was introduced.

> The only really useful thing to actually try and get Apple to change is to
> expand the sandboxing capabilities to allow certain things that 3rd-party
> apps want to do and cannot do today. They've added more and more
> capabilities over time. The question is what functionality can be
> effectively exposed to sandboxed apps without opening up a security hole.

Exactly, that's what should have been happening and has been to some extent
but not aggressively enough. Part of the problem is that a lot of things pose
no security threats but there are still no way to access that functionality in
a sandboxed app - that's the crux of the problem.

In the case of GaragePay, it used an external utility to deal with encrypted
disk images. The app has already been given access to the file via the
powerbox [1], there is no additional security threat. Unfortunately, there are
no APIs to operate on such disk images except the external hdiutil utility.
The correct way to have resolved this was to expose APIs to access that
functionality or else allow a temporary exception until such APIs exist.

> That functionality should never have been in the MAS app to begin with.

Why shouldn't it be? In almost all cases, the functionality can be sandboxed
if Apple provided an API to access it securely but there just isn't a
entitlement for those cases - not because it's not possible but because it's
just not implemented.

> Also note that the claim "Apple shouldn't apply that rule, because it
> removes app functionality, and that's bad for users" is quite ridiculous.

I never claimed that. I only claimed that removing functionality objectively
leads to an inferior experience due to the lack of said features. In an ideal
world, the correct way to have gone about it would be to provide the necessary
security mechanisms to make that possible. While Apple did add additional
entitlements over the years, there are still many operations that reasonable
and do not pose a security threat that are still not supported.

> If your app requires violating app store rules for certain functionality,
> then you shouldn't be using the MAS as your distribution channel.

While that's true a statement, that's not the crux of the problem. The root
issue is that if the required entitlements were available, then the app
wouldn't be violating any rules at all and we wouldn't even be having this
conversation.

[1]
[http://en.wikipedia.org/wiki/File_dialog#Powerbox](http://en.wikipedia.org/wiki/File_dialog#Powerbox)

~~~
eridius
> The argument that I've been making for years is that proper entitlements
> should have existed for all the functionality necessary before the
> requirement for all apps to be sandboxed was introduced

In that case, sandboxing could _never_ be introduced. It is quite literally
impossible to provide entitlements for any and all functionality under the
sun, unless you include the entitlement "allow anything" in the mix.
Sandboxing is by its very nature restrictive, requiring bits of functionality
to be whitelisted. That's the only way in which it can possibly ever be even
remotely secure.

However, Mac apps are _not required_ to be sandboxed. Only apps distributed on
the MAS are. If you cannot ship your app with the sandbox, then you can
continue to be distributed the way all apps were for the past few decades.

> Part of the problem is that a lot of things pose no security threats but
> there are still no way to access that functionality in a sandboxed app -
> that's the crux of the problem.

Can you give examples? I do not blindly accept that GaragePay's use of
`hdiutil` is harmless, like you are claiming. `hdiutil` is not sandboxed, and
I have no idea what kind of security audit, if any, has been done on it to see
if there's any security vulnerabilities that would be exposed by allowing it
to be run from a sandboxed application.

> The correct way to have resolved this was to expose APIs to access that
> functionality

Yes, APIs that allow for manipulation of disk images would be nice. But that's
not even remotely a trivial task.

> In almost all cases, the functionality can be sandboxed if Apple provided an
> API to access it securely

That's practically tautological. "The functionality can be sandboxed if Apple
allowed it to be sandboxed". Some missing entitlements would be trivial to
add. Others would require massive work. I suspect that exposing proper APIs to
manipulate the Disk Images infrastructure would require a massive security
audit, and probably significant work modifying the APIs as well as I expect
they probably don't meet the usability standard expected of public API.

> removing functionality objectively leads to an inferior experience due to
> the lack of said features

And implied that this means Apple should allow third-party apps to continue
violating rules because the existing experience of using that 3rd-party
application somehow trumps everything else.

Beyond that, I don't necessarily agree that this does objectively lead to an
inferior experience as well. Removing insecure functionality, or functionality
that relies on non-public APIs, can lead to a superior experience, because the
application is now more trustworthy, much less vulnerable to exploitation, and
perhaps more stable or future-proof (in the case of non-public API). So it
really can be quite subjective, and quite dependent upon the particular merits
of the functionality in question.

> The root issue is that if the required entitlements were available, then the
> app wouldn't be violating any rules at all and we wouldn't even be having
> this conversation.

Again, tautological. "If the app wasn't violating any rules, it wouldn't be
violating any rules".

~~~
milen
> In that case, sandboxing could never be introduced. It is quite literally
> impossible to provide entitlements for any and all functionality under the
> sun, unless you include the entitlement "allow anything" in the mix.

That doesn't follow. Sandboxing privileges present a wide spectrum ranging
from providing no entitlements on one end to providing an "allow anything"
entitlement on the other. Obviously, as developers, we want as much
functionality exposed in a secure way but the unfortunate reality is that
Apple either do not have the resources or willingness to do so.

> However, Mac apps are not required to be sandboxed. Only apps distributed on
> the MAS are.

While that's technically true, an argument can be made that due to the
inclusion of the MAS as part of OS X, it's practically required for an app to
be on the MAS as that's where a lot of the users are and it's how they get
their software.

> Can you give examples?

Yes, Coda 2.5 [1] was not released on the MAS due to sandboxing issues. There
are some radars on openradar [2] referring to other sandboxing issues, too -
some of them are reasonable. Obviously, I do not have access to Radar itself
otherwise I would have provided more examples.

> But that's not even remotely a trivial task.

I don't see that as a valid excuse for not providing an API while at the same
time rejecting the usage of a temporary entitlement due to lack of said API.
It's a given that providing functionality in a sandbox compatible way would
not be trivial - the work needs to be done if we want everything to be nice
and secure. I'm perfectly aware that the effort required to implement such an
API would be considerable and it might not be worth it but that doesn't make
it the right approach. And that's why I accept the current situation - it's a
compromise between what could be and what Apple have decided to implement at
present.

> Others would require massive work.

Yes and in an ideal world, if we're fully committed to sandboxing, that work
would be done. You said:

> Apple developed the OS that you're using, so there's hardly a trust issue
> when talking about running applications from Apple on top of the Apple-
> developed OS.

Sandboxing is not just about trust, it's also about security. Apple's own
software not being sandboxed means its vulnerable to exploits, exactly what
sandboxing is trying to prevent. If you check Activity Monitor, you will see
plenty of Apple and others' apps being non-sandboxed - all of these are
potential targets. A system is only as secure as it's weakest link, so if we
want a more secure system, we should working towards having more sandbox
entitlements.

As a side note, the trust side of things is taken care of by code signing.

> And implied that this means Apple should allow third-party apps to continue
> violating rules because the existing experience of using that 3rd-party
> application somehow trumps everything else.

No, the implication is that Apple should be working towards exposing more
functionality in a secure, sandbox compatible way.

[1] [http://www.panic.com/blog/coda-2-5-and-the-mac-app-
store/](http://www.panic.com/blog/coda-2-5-and-the-mac-app-store/)

[2]
[http://www.openradar.me/search?query=sandbox](http://www.openradar.me/search?query=sandbox)

------
api
I've never liked the idea of files "belonging" to apps, for numerous reasons.
It strikes me as an irreversible institutionalization of the "WIMP" model --
"weakly interacting massive programs." It also makes me uneasy. What happens
to my data if I uninstall an app? What happens if that app disappears?

A lot of the data handling choices in mobile and iOS in particular seem
predicated on the hidden assumption that user data is not very valuable. Hell
will freeze over before I use one of these platforms for anything I deeply
care about.

... yet another reason mobile has a ways to go before it can "take over the
world."

~~~
Logmix
That's very well put. If you uninstall an app, all its data is gone. Unless
you stored that data somewhere else of course, but the main thing is how Apple
approaches data storage is not very professional or confidence inspiring.

For me this awkward storage makes it difficult to take the device seriously. I
don't consider the iPad a work device, more of a device to surf the net on the
couch. In Q4 2014, iPad sales were down year over year from 14M to 12M. Maybe
other people are starting to think along the same lines?

The sad part is that this does not have to be that way. The iPad has more than
enough resources to be a fully functional computing device.

But until Apple grows up and removes all those mandatory training wheels
(can't develop equal citizen apps on the device itself and give it to anybody
I like without Apple having the power to party pooping any of it), I don't
consider iPad + iPhone real computers.

~~~
api
"The iPad has more than enough resources to be a fully functional computing
device."

The thing preventing mobile "convergence" is not hardware capability and never
really has been except at the high end. Mobile won't displace PC due to design
choices that firmly exclude whole application categories. These include what
we're discussing here, as well as jailed app stores and other policies.

A lot of people assume mobile is "the next platform," etc. based on what I
consider to be faulty reasoning by analogy with the PC's displacement of
mainframes and minis. The PC displaced mainframes and minis due to Moore's Law
and economies of scale. Those same forces are in effect in mobile, sure, but
there are other barriers in effect that are completely unrelated to CPU power
or cost that will prevent this displacement from occurring.

Whenever I talk to valley people I feel like an atheist at a tent revival for
questioning the idea that mobile is categorically "the future." It could be if
it wanted to, but it'd have to fix some of its problems.

~~~
Htsthbjig
"A lot of people assume mobile is "the next platform," etc." based on what I
consider to be faulty reasoning by analogy with the PC's displacement of
mainframes and minis. The PC displaced mainframes and minis due to Moore's Law
and economies of scale. Those same forces are in effect in mobile, sure, but
there are other barriers in effect that are completely unrelated to CPU power
or cost that will prevent this displacement from occurring."

I was one of those in the past, now it is just obvious, just look at the
number of mobile devices out there compared to PCs. The fact that you don't
like it does not make it less true.

Old people said the same about the command line, it was never going to be
replaced for real work.

You assume that current restrictions will be maintained in the future. I don't
think so.

Apple was right and created a product useful for many common people.
Programmers and power users believed that it was not necessary because they
were fine and frankly because knowledge gave them power over them.

I am using Ubuntu on a tablet and I like it. It is coming slowly but it will
be possible to create much more content on tablets that on pcs.

~~~
vezzy-fnord
Number of devices in of itself is not sufficient for a paradigm shift. A
crucial event that needs to happen for mobile to displace the PC is that the
major mobile platforms (Android, iOS, Windows Phone, etc.) need to become
self-hosting development environments. They are still a far cry from that.

------
pavlov
In the comments, Cabel from Panic explains in some more depth the interactions
they've had with the App Store reviewers. The comment ends on a peculiar note:

 _" 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."_

I can't tell if this is sarcasm or not because it has a such a strange echo of
both Kafka and Stalin. "It's never the Revolution we're frustrated with, just
those over-enthusiastic types at Cheka..."

~~~
Karunamon
It is possible to hate a smaller part of a larger whole without hating the
larger whole outright...

~~~
pavlov
But it doesn't usually make sense to claim to be completely pleased with the
whole, while disliking a part. "This meal is perfect. It's just the sauce
that's awful." Isn't that cognitive dissonance?

~~~
Karunamon
Depends on whether Apple's approval process is bad enough for you to tar the
entire company with that brush. For a lot, it isn't.

------
chetanahuja
To me, the most telling part of the whole writeup is in the postscript:

 _" 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"_

This almost sounds like Stockholm syndrome to me. The whole completely
controlled apple ecosystem is baffling to begin with. Add to that the
capricious and high-handed way Apple treats app developers and it's incredible
that developers like Panic not only keep developing for Apple platforms, they
_only_ develop for this platform. That pain felt when the hammer falls is the
natural reaction when you realize that the emotional connection you've built
with this company is mostly (or entirely) one-sided.

~~~
kenferry
> This almost sounds like Stockholm syndrome to me.

I read that as more Cabel trying as hard as he can to keep cool and
constructive.

He's trying to remember that it's all people, not monoliths, and is trying not
be unfair to people uninvolved in this and related messes.

Which is admirable, but you can see why it's hard. This is incredibly
frustrating.

~~~
chetanahuja
The Apple vs app store is a distinction without any difference though. The
whole idea of controlling what users can run on their own hardware is 100%
Apple through and through. If you remember the history of iPhone, even _that_
was granted as a concession only after devs started jailbreaking and started
developing native apps without Apple's permission.

Now, if with that history and culture, some app store middle manager makes an
autocratic decision to remove core functionality from a beloved app, you can't
just lay it on "one bad apple" so to speak. This is the culture the whole
company is seeped in. This can't be a surprise to someone who has decided to
"love so deeply" this entity for so many years.

------
DiabloD3
Honestly, this just further proves no one should develop for Apple, because
Apple can just come in and shit all over your hard work.

Tranmit on OSX is an invaluable tool for people who don't understand how to
use scp and sftp from the command line, and I've recommended it to many OSX
users who were unwilling to learn how to use the command line.

Edit: I don't care if people downvote me, this is my opinion, and as a
software developer, it is my opinion that governs if I write for iOS or not.
As long as Apple continues to treat devs this way, I will continue to not care
about iOS.

~~~
threeseed
Give us a break. Apple has clearly defined rules for what is allowed on the
App Store.

If you can't be bothered to comply then don't act all surprised when your app
gets rejected.

~~~
DiabloD3
Read the linked blog entry. Apple cites rules that are vague, and then Apple
gives no solution to app developers to block iDrive usage since the UX is
controlled by iOS itself.

So, yes, Apple just doesn't care if they break apps by haphazard application
of poorly written rules. And Transmit wasn't rejected, it was in the app store
before this, and it is in the app store now.

If you're going to comment, at least read the link first.

------
veidr
It is painful to watch a company as awesome as Panic have to go through these
contortions, and make these kinds of gobbledygook doublespeak statements.

 _" 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."_

It's quite similar to the feeling of having a friend or roommate in a
dysfunctional relationship. You like your friend but... yuck, you really wish
they would break up.

EDIT: Also, as a Transmit user, I'd just like to add my own _fuck you, Apple_
for forcing the removal of a very useful feature.

------
kayoone
And yet most iOS developers just swallow their anger and keep on developing
for iOS which in turn enables Apple to keep on ridiculing their devs.

~~~
zmmmmm
The saddest thing is how uncritical they try to be of Apple in these kind of
posts. It's pretty clear that they fear retribution if they are seen as
publicly complaining - which, along with the same approach to journalists,
tells you a lot about Apple's attitude and culture. I wish Apple would see
that in the long term, insulating themselves from criticism is not in their
own interests.

------
PythonicAlpha
That is just the reason, why I restrain to use Apple hardware.

Apple products are really very good and they have invented the smartphone it
it's current functionality. But Apple has a very restrictive mindset. I as
user, feel that it is like being in a nanny-state, where everything is
controlled, what I am allowed to do.

I want to decide myself and not let Apple decide for me, what is good for me.

~~~
eridius
This particular issue is about Apple deciding that they don't want _their_
software (iCloud Drive) being used in a particular way. It's not about
deciding what's good for users.

~~~
Thimothy
Not true. Apple doesn't allow them to use ANY cloud-based sharing software
becouse all share the same iOS API, so it's impossible to allow users to use
dropbox and not iCloud.

~~~
eridius
Yes, that's unfortunate, but Apple isn't intentionally trying to prevent them
from using the other software. It's just a bad consequence of the way the API
works. Note that they would be free to use these services if they used an
alternate mechanism of talking to them (e.g. built direct support into the
app).

------
markchristian
Apple's App Review team has been merciless lately. They won't accept any
further updates to my app, Timebar
([http://whimsicalifornia.com](http://whimsicalifornia.com)), unless I get rid
of its only feature (drawing a progress bar on your menu bar). Frustrating.

I think Apple could go a long way to locking down developer trust by just
vowing to never reject updates for non-technical reasons, ever. If they have
to make the initial review much more brutal, it would still be worth it.

~~~
driverdan
Why don't you just take it out of the app store and sell it on your website
like everyone did for many, many years?

~~~
0x0
Probably because that's where the casual users market is.

------
protomyth
Let me get this straight. I can put any old file on iCloud via Finder on OS X
or using iCloud for Windows, but somehow on iOS this is dangerous and not
allowed?

~~~
noarchy
Abstracting away the file system seems to be a "feature" of iOS.

------
jhund
Reminds me of an article by Tim Bray from 2003 where he talks about
sharecroppers:
[https://www.tbray.org/ongoing/When/200x/2003/07/12/WebsThePl...](https://www.tbray.org/ongoing/When/200x/2003/07/12/WebsThePlace)

------
robmccoll
Apple is so blase toward developers that it will cut them off at the knees on
a whim usually to protect its own interests.

Microsoft will intentionally build in scary hacks to maintain backward
compatibility and tries to build developer-friendly tools and environments but
tends toward a mess.

Linux tends to maintain strong backward compatibility to the point that
everything has incredible inertia, but in general doesn't too much care about
developers one way or anothet.

Google moves so quickly and deprecates so hard that building software on their
platforms is like building a house in a continuous earthquake but using better
tools and materials each time.

Moral: nowhere is perfect, consider your trade-offs, then choose Linux (of
course).

------
mcherm
It is precisely because of this that I refuse to build for the iOS platform
(for my own projects) and avoid using it. Freedom matters.

------
emsy
I generally choose smartphones based on which gives me the least problems. In
the past this was iOS, because the only problem I personally had was the
restrictivness of their platform. But lately the OS quality went down the
drain and they became even more erratic about their App Store rules. Anyone
else here who can't really enjoy smartphones because of the deep flaws every
OS seems to have?

edit: typo

~~~
JohnTHaller
An Android phone with a pure Google Android experience or very close to it is
really the best smartphone experience. Sadly, this is a relatively small
percentage of the smartphones available.

And no, rooting and adding a custom ROM doesn't really cut it. Even the
world's most popular ROM (cyanogenmod) is still stuck on Android 4.3 Jellybean
with 4.4 stuck in perpetual testing land even though it's over a year old and
5.0 has been released.

~~~
fernandotakai
nexus 5 still is a really good device, with stock android and it's sold with
no contract.

moto x 2014 and moto g 2014 are also really really good devices, with almost
stock android (motorola added only a couple of stuff to them -- so little that
moto x already has jellybean) and are not that expensive (the official
motorola store has the new moto g for $180).

~~~
emsy
If I want to buy a stock Android device, I'm close to Apple's device range
(exaggeratively spoken). Also, I no longer have the time and nerves to
Jailbreak or Root my device and install custom Roms, and if I pay up to 700$
for a devices it should work and get me at least 2 years worth of updates.

Not everything is bad though. Apple is working on their device portfolio and
the Android update policy has significantly improved, since I last used an
Android device full-time.

~~~
JohnTHaller
A brand new base Nexus 5 16GB is only $349 direct and unlocked. A far cry from
the $649 that the base iPhone 6 16GB costs.

The Nexus 6 is more a competitor to the iPhone 6 Plus (screen size and all)
and is priced appropriately. It's $699 for 64GB compared to the iPhone 6 Plus
at $849 for 64GB. The base models of each are a bit cheaper as well, $749 for
an iPhone 6 Plus 16GB and $649 for a Nexus 6 32GB. As a premium phone, the
Nexus 6 is unavailable in the small 16GB size.

Both the Nexus 5 and the Nexus 6 will be getting updates for quite some time.
Neither one requires rooting or a custom ROM of any sort.

------
Htsthbjig
There are fantastic products on iOS that suffer from this behavior.

For example Garageband for iOS is so good, but the fact that you can not share
your work with others(or import it) easily makes the app almost useless.

------
general_failure
This is a demand and not a request by apple. Big difference

------
blueskin_
Random policies just because they can. This is why Android will always beat
Apple for market share.

------
wanda
Unrelated: what monospace font is used in that GIF image?

[http://www.panic.com/blog/wp-
content/uploads/2014/12/delete-...](http://www.panic.com/blog/wp-
content/uploads/2014/12/delete-3.gif)

~~~
micampe
I think it's Input: [http://input.fontbureau.com](http://input.fontbureau.com)

Note that some glyphs (g, l, i) can be customized and may look different from
the screenshot in the default download.

~~~
wanda
Ah, yes, that's why I didn't recognise it. I've tried Input before but I
customised it to more closely resemble Monaco; I had no recollection of how
Input looked by default.

------
chappi42
This is wonderful.

Just one more example what happens if countries allow _closed_ app
distribution systems. What a wonderful world with nice critical/ironical phone
stories
([http://phonestory.org/index.html..](http://phonestory.org/index.html..). I
wish the (at least European) politicans had the balls to shut down such closed
ecosystems!

~~~
carlob
I remember following molleindustria games back in the day when they were
flash-based. Thanks for sharing this (but fix your link, so that it gets a
wider audience).

