At Apple’s request, we removed the ability to “Send” files to other services(panic.com)
panic.com
At Apple’s request, we removed the ability to “Send” files to other services
http://www.panic.com/blog/transmit-ios-1-1-1/
103 comments
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.
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.
[deleted]
If things are really bad enough, why not create a federation of developers to build developer clout and threaten Apple with counter action based on Apple's action?
Apple is a single focus of power. Developers are numberless and spread all over the world. Your suggestion to try to combat that situation by concentrating, essentially "unionizing", developers, would fail for two reasons.
One, the developers are so numerous, diverse, and independent of one another that there would be an endless supply of developers willing to "cross union picket lines" and make more money with the competition reduced. In a sense, it's like a mine with a hundred times as many miners as it needs, most of whom are struggling to get more than an hour a month of paid work and would do anything to get more. Also, the most important "miners", Apple itself, Google and Facebook, have their own agendas and wouldn't care about any "developers' union", and if you combine the apps Apple, Google, and Facebook contribute to the iOS platform, the vast majority of the rest of the devs could disappear with almost no impact on Apple other than that Apple would stop announcing the number of apps in the app store during keynotes. They'll eventually stop that anyway.
Two, Apple makes very little of its money from app sales. The indie devs aren't the real miners. The miners are the actual employees of Apple and Foxconn. Apple sells hardware, and as long as they have their own apps, and apps from Google, Facebook, a couple of big game makers who are getting rich on iOS and aren't going to walk away from it, plus apps from a small percentage of the indie devs, consumers will keep buying Apple hardware. Again, the vast majority of iOS devs could "walk off the job" and the "mine" would keep operating as if nothing had happened, other than a bit of editing to the semi-annual PR message.
An "iOS developers' union" would have so little leverage over Apple that Apple probably wouldn't even "fire" developers who joined it (revoke their dev credentials). It could simply ignore them and go on with its business.
One, the developers are so numerous, diverse, and independent of one another that there would be an endless supply of developers willing to "cross union picket lines" and make more money with the competition reduced. In a sense, it's like a mine with a hundred times as many miners as it needs, most of whom are struggling to get more than an hour a month of paid work and would do anything to get more. Also, the most important "miners", Apple itself, Google and Facebook, have their own agendas and wouldn't care about any "developers' union", and if you combine the apps Apple, Google, and Facebook contribute to the iOS platform, the vast majority of the rest of the devs could disappear with almost no impact on Apple other than that Apple would stop announcing the number of apps in the app store during keynotes. They'll eventually stop that anyway.
Two, Apple makes very little of its money from app sales. The indie devs aren't the real miners. The miners are the actual employees of Apple and Foxconn. Apple sells hardware, and as long as they have their own apps, and apps from Google, Facebook, a couple of big game makers who are getting rich on iOS and aren't going to walk away from it, plus apps from a small percentage of the indie devs, consumers will keep buying Apple hardware. Again, the vast majority of iOS devs could "walk off the job" and the "mine" would keep operating as if nothing had happened, other than a bit of editing to the semi-annual PR message.
An "iOS developers' union" would have so little leverage over Apple that Apple probably wouldn't even "fire" developers who joined it (revoke their dev credentials). It could simply ignore them and go on with its business.
I think if iOS developers were able to brand and band themselves together and build clout with consumers they could make an effect on certain policies. If they notify consumers that they want to provide the services that customers want, and Apple is the one getting in the way, they can begin to influence.
Are you of the opinion that there's no amount of developers or very popular apps that wouldn't make Apple reconsider policies? I believe this is a though in an oppressed paradigm. How else (other than potential legal action) Apple's decision to start allowing bitcoin wallets (arguably a direct competitor to Apple Pay) into the app store.
Are you of the opinion that there's no amount of developers or very popular apps that wouldn't make Apple reconsider policies? I believe this is a though in an oppressed paradigm. How else (other than potential legal action) Apple's decision to start allowing bitcoin wallets (arguably a direct competitor to Apple Pay) into the app store.
[deleted]
They swallow their anger because they have no real alternative. It's the job of legislation to prevent such abbreations.
Whatever you think of the App Store's policy, users have freedom of choice in which mobile platform(s) they buy, and developers have freedom of choice in which mobile platform(s) they develop for.
Apple has made no secret of their desire to strictly control their platform. To prevent them from exercising control over their platform just because users continue to choose iOS devices and developers continue to dev for iOS devices is absurd.
We just had a post about whether or not open sourcing a repository conferred some responsibility on the releaser to maintain it and offer support. The situations are not dissimilar: putting into public a thing which becomes popular does not convey to the public control over how you shape your creation.
Apple has made no secret of their desire to strictly control their platform. To prevent them from exercising control over their platform just because users continue to choose iOS devices and developers continue to dev for iOS devices is absurd.
We just had a post about whether or not open sourcing a repository conferred some responsibility on the releaser to maintain it and offer support. The situations are not dissimilar: putting into public a thing which becomes popular does not convey to the public control over how you shape your creation.
There is not much choice, either the closed Apple ecosystem or the open Google ecosystem which aggregates your data. Everything else is unpopular. Personally I use a Jolla phone but this doesn't help an app developer who needs to make money for rent and bread.
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...
This is a demand and not a request by apple. Big difference
Random policies just because they can. This is why Android will always beat Apple for market share.
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."
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."
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.
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.
"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.
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.
"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.
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.
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.
The instant I walk into a company and see people working on mobile devices instead of PCs, I will change my mind. I don't mean trivial bits of work like note taking... I mean real work: CAD, coding, devops, serious spreadsheet/accounting work, graphic design, etc. Show me SolidWorks, Eclipse, Excel, or Creative Suite -- or equivalents -- on an iOS or Android device.
Ubuntu on a tablet is a bad example. You're running a PC OS on a tablet. For 99.9999% of users mobile = iOS or Android.
I'm talking about platform here, not just hardware. I could run Ubuntu on an old Samsung Galaxy and hack a way to connect it to a monitor, but then it would be a PC in a small box not a "mobile device."
"Old people said the same about the command line, it was never going to be replaced for real work."
They were right.
Leave "old" out of it. When I was a teenager I was a Linux head. I remember my dad telling me that stuff was stupid, since GUIs were going to replace everything. I told him (then about 40) that you'd never replace a command line with a GUI for all kinds of tasks. I was absolutely right. It's 2014 and you still can barely script a GUI. Doing devops type work on a GUI is from painful to impossible except in a few very niche areas.
"You assume that current restrictions will be maintained in the future. I don't think so."
I'll believe it when I see it. Apple in particular has no incentive to change. They love all that app store revenue, and they also have no incentive to make iOS a PC competitor since it would cannibalize their Mac platform sales.
Then there's the fact that the security problems that the app store model avoids have not actually been solved. Decouple mobile from app stores and you'll have a malware explosion.
Mobile is just a new platform. It's fantastic for a lot of things the old platforms aren't good at, but it's not going to displace old ones except at the edges. It's no more likely to displace the PC than it is to displace the server. What we're seeing is a filling-in and diversification of computing, not a displacement story.
Ubuntu on a tablet is a bad example. You're running a PC OS on a tablet. For 99.9999% of users mobile = iOS or Android.
I'm talking about platform here, not just hardware. I could run Ubuntu on an old Samsung Galaxy and hack a way to connect it to a monitor, but then it would be a PC in a small box not a "mobile device."
"Old people said the same about the command line, it was never going to be replaced for real work."
They were right.
Leave "old" out of it. When I was a teenager I was a Linux head. I remember my dad telling me that stuff was stupid, since GUIs were going to replace everything. I told him (then about 40) that you'd never replace a command line with a GUI for all kinds of tasks. I was absolutely right. It's 2014 and you still can barely script a GUI. Doing devops type work on a GUI is from painful to impossible except in a few very niche areas.
"You assume that current restrictions will be maintained in the future. I don't think so."
I'll believe it when I see it. Apple in particular has no incentive to change. They love all that app store revenue, and they also have no incentive to make iOS a PC competitor since it would cannibalize their Mac platform sales.
Then there's the fact that the security problems that the app store model avoids have not actually been solved. Decouple mobile from app stores and you'll have a malware explosion.
Mobile is just a new platform. It's fantastic for a lot of things the old platforms aren't good at, but it's not going to displace old ones except at the edges. It's no more likely to displace the PC than it is to displace the server. What we're seeing is a filling-in and diversification of computing, not a displacement story.
[deleted]
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.
No, I think it's predicated on the assumption that user data is very valuable --- to the companies that inevitably try to mine and monetise it --- that freedom should be taken away from the users and the platform should provide developers with as much control over the users' data as possible. It's an ongoing movement to lock down devices against the user; to turn general-purpose computers into restricted environments for consumption and very little creation. No doubt the media companies' DRM interests are partially responsible for this.
Even the concept of a file as an application-neutral container for data is being slowly obfuscated away by this movement, as users are gradually conditioned to open apps first, and then open their data from them. I think one of my biggest surprises upon using an Android smartphone for the first time was discovering that it didn't even have a rudimentary text editor by default (something that I was accustomed to on every other OS), nor could the standard file manager view text files although it could view movies, pictures, and music. As I understand it, the iOS situation is even more restricted than that, with not even a file manager provided as part of the OS.
As another datapoint, I've encountered quite a few beginning computer science students who didn't really know what a file is, and were quite amazed that multiple applications could work with the same files.
No, I think it's predicated on the assumption that user data is very valuable --- to the companies that inevitably try to mine and monetise it --- that freedom should be taken away from the users and the platform should provide developers with as much control over the users' data as possible. It's an ongoing movement to lock down devices against the user; to turn general-purpose computers into restricted environments for consumption and very little creation. No doubt the media companies' DRM interests are partially responsible for this.
Even the concept of a file as an application-neutral container for data is being slowly obfuscated away by this movement, as users are gradually conditioned to open apps first, and then open their data from them. I think one of my biggest surprises upon using an Android smartphone for the first time was discovering that it didn't even have a rudimentary text editor by default (something that I was accustomed to on every other OS), nor could the standard file manager view text files although it could view movies, pictures, and music. As I understand it, the iOS situation is even more restricted than that, with not even a file manager provided as part of the OS.
As another datapoint, I've encountered quite a few beginning computer science students who didn't really know what a file is, and were quite amazed that multiple applications could work with the same files.
"No doubt the media companies' DRM interests are partially responsible for this."
I think there's some truth in this, but you're wrong here. The problem isn't DRM, but what DRM is (impotently) reacting against.
This is the fault of the culture of "free." If people are not willing to pay for stuff, then the model must be turned around and the user monetized exactly as you describe. That's because nothing is actually free. Everything costs money and someone has to pay. If it's not users it must be advertisers, governments, etc.
Free "as in beer" is a socially destructive idea and is the enemy of free "as in freedom."
Edit: bring on the downvotes! Doesn't change the facts. If you don't pay, you are not a customer.
I think there's some truth in this, but you're wrong here. The problem isn't DRM, but what DRM is (impotently) reacting against.
This is the fault of the culture of "free." If people are not willing to pay for stuff, then the model must be turned around and the user monetized exactly as you describe. That's because nothing is actually free. Everything costs money and someone has to pay. If it's not users it must be advertisers, governments, etc.
Free "as in beer" is a socially destructive idea and is the enemy of free "as in freedom."
Edit: bring on the downvotes! Doesn't change the facts. If you don't pay, you are not a customer.
I'm not sure how much I agree with what you're saying, but I don't think you should be downvoted for it, so I gave you an upvote.
I think a lot of it stems from an attempt at simplicity in design. At the time, Windows Mobile was offering a fully customizable filesystem, but Apple wanted to go the route of simplicity when they introduced Apps with iOS2. You tap on them and they work, delete them when you don't want them, etc. Everything is so isolated as a result, and combined with the lack of any sort of Downloads or file creation in the traditional sense, it sort of makes you feel like the data of your apps is stored in really remote, weird locations you can't ever access.
Simplicity like that was part of what made people think not just of productivity but also of fun when they looked at a smartphone imo. Still not very fun to deal with. (Never write a document on your phone. It's not worth it)
Simplicity like that was part of what made people think not just of productivity but also of fun when they looked at a smartphone imo. Still not very fun to deal with. (Never write a document on your phone. It's not worth it)
Makes me think of a quote from another recent HN front page article on Docker vs. CoreOS and the idea of "simplicity" in the enterprise. I think it's relevant here.
"You can't avoid complexity by pretending it doesn't exist."
There's a lot of complexity and nuance around the handling of files. Mobile likes to pretend it doesn't exist, and the result is file handling choices that treat user data contemptuously and do not allow any kind of workflow whatsoever.
This is one of several very significant reasons mobile in its present form will never displace PC except for low-end use cases.
"You can't avoid complexity by pretending it doesn't exist."
There's a lot of complexity and nuance around the handling of files. Mobile likes to pretend it doesn't exist, and the result is file handling choices that treat user data contemptuously and do not allow any kind of workflow whatsoever.
This is one of several very significant reasons mobile in its present form will never displace PC except for low-end use cases.
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.
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.
That Apple could come and shit all over your hard work is simply a risk factor to consider amongst all other factors a developer should be looking at when deciding what platform to develop for. All platforms have drawbacks and advantages. It's just a matter of picking your poison.
I'd be interested to hear why you think the cons outweigh the pros of developing for iOS. Universally, across the board for every software developer? Really?
I'd be interested to hear why you think the cons outweigh the pros of developing for iOS. Universally, across the board for every software developer? Really?
because the emotional impact of "i had it working and apple fucked it up" is greater than, e.g. "i could have had it working but there's no linux driver". targeted malice/incompetence always feels worse than impersonal "lie of the land" obstacles.
I also have the exact same opinion, unless the company is fixing their terrible policies, I just won't develop anything for the iphone, the risk is just too high to work on iOS.
It's useful for me too. I know perfectly well how to use the command line, I just prefer not to when using my iPad
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.
If you can't be bothered to comply then don't act all surprised when your app gets rejected.
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.
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.
Apple has clearly defined rules for what is allowed on the App Store.
In that case, I'd like to challenge you to a game of Mornington Crescent.
In that case, I'd like to challenge you to a game of Mornington Crescent.
Except, they just started to enforce this rule (or just recently created it)
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...
- Rejected for slide to start, which is a gesture not even used anymore: http://mjtsai.com/blog/2014/11/25/racesplitter-rejected-for-...
- Sandbox forces feature removal http://mjtsai.com/blog/2014/12/02/garagepays-encryption-remo...
- Notification Center rejection http://www.macrumors.com/2014/11/18/apple-cracks-down-on-nea...
- PCalc got asked to remove calculator but then decision reversed http://www.macstories.net/ios/apple-asks-pcalc-developer-to-...
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...
- Rejected for slide to start, which is a gesture not even used anymore: http://mjtsai.com/blog/2014/11/25/racesplitter-rejected-for-...
- Sandbox forces feature removal http://mjtsai.com/blog/2014/12/02/garagepays-encryption-remo...
- Notification Center rejection http://www.macrumors.com/2014/11/18/apple-cracks-down-on-nea...
- PCalc got asked to remove calculator but then decision reversed http://www.macstories.net/ios/apple-asks-pcalc-developer-to-...
Everyone should head over to https://www.apple.com/feedback/ and drop off a quick note about this. It seemed to help in getting the pcalc decision reversed.
> 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.
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.
> 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.
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.
> 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.
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.
> 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.
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.
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.
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.
"I expect they're taking the right steps privately, talking to the Review Board and whatnot"
If I read this sentence in isolation, this could pass as a sentence from a wonderfully subtle Russian novel from the previous century.
If I read this sentence in isolation, this could pass as a sentence from a wonderfully subtle Russian novel from the previous century.
> 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
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
Wait, slow down. As far as I can tell from a quick Google, GaragePay was only using encrypted disk images as a way to store its private app data in encrypted form. But obviously there are many other ways to implement encrypted storage, within the app process rather than calling out to the OS. This would avoid the need for any holes in the sandbox; it would require some work to implement, but temporary sandbox exceptions were known to be temporary for years.
Even if the developer wanted to be able to access disk images from older versions of the program, they'd be dealing with an undocumented file format, but AFAIK there is a lot of code out there for dealing with dmgs, so it should be possible.
Even if the developer wanted to be able to access disk images from older versions of the program, they'd be dealing with an undocumented file format, but AFAIK there is a lot of code out there for dealing with dmgs, so it should be possible.
> 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".
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".
> 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/
[2] http://www.openradar.me/search?query=sandbox
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/
[2] http://www.openradar.me/search?query=sandbox
> The MAS is relatively new and is not replacing any existing software delivery mechanism
Really now? I feel like I need to preface this by saying I love all my Macs, my iPhones (all 5 that I've owned), iPads, etc. I also love the convenience and simplicity of using the MAS compared to any other way of getting free and paid software.
But even I think there is a nearly 100% chance that by, say, 3-5 years from now, Apple will prevent installing software from sources other than MAS. You can tell by the trajectory of MAS. It started out as just an equally-supported option. Now installing software not from the MAS is a warning, and installing software from a developer entirely unblessed by Apple entirely is disabled without already knowing the "right click workaround" (try successfully explaining to a casual user how to install that kind of app). It's only logical to extrapolate that to the next steps. maybe in 2015 all non-MAS will require the right-click open. In 2016 or 2017 non-MAS will probably mean not runnable without obtaining a limited-use developer or enterprise certificate from Apple for a fee. Given that iOS doesn't have any supported way to sideload arbitrary third-party apps the way, we should expect this to be the case for the Mac as well. You will be able to run apps you've signed with your own developer or enterprise distribution certificate, but I doubt you'll be able to download & just run an app from Panic or anyone else without jumping through hoops or "jailbreaking."
Really now? I feel like I need to preface this by saying I love all my Macs, my iPhones (all 5 that I've owned), iPads, etc. I also love the convenience and simplicity of using the MAS compared to any other way of getting free and paid software.
But even I think there is a nearly 100% chance that by, say, 3-5 years from now, Apple will prevent installing software from sources other than MAS. You can tell by the trajectory of MAS. It started out as just an equally-supported option. Now installing software not from the MAS is a warning, and installing software from a developer entirely unblessed by Apple entirely is disabled without already knowing the "right click workaround" (try successfully explaining to a casual user how to install that kind of app). It's only logical to extrapolate that to the next steps. maybe in 2015 all non-MAS will require the right-click open. In 2016 or 2017 non-MAS will probably mean not runnable without obtaining a limited-use developer or enterprise certificate from Apple for a fee. Given that iOS doesn't have any supported way to sideload arbitrary third-party apps the way, we should expect this to be the case for the Mac as well. You will be able to run apps you've signed with your own developer or enterprise distribution certificate, but I doubt you'll be able to download & just run an app from Panic or anyone else without jumping through hoops or "jailbreaking."
> Now installing software not from the MAS is a warning
No it's not. Where did you get that idea? The only issue is installing software that isn't codesigned with an Apple-signed certificate. Any developer enrolled in Apple's Mac Developer program can get an Apple-signed certificate and self-sign their 3rd-party non-MAS software and users will have the same experience as using MAS software. The only dialog they'll get is the standard "Are you sure you want to run this program you just downloaded?" dialog that we've had for a while now. Which, admittedly, I don't think MAS apps have, but that's because MAS apps aren't downloaded with a web browser; if you install a 3rd-party app via some mechanism other than downloading with a web browser it should similarly bypass that dialog.
> installing software from a developer entirely unblessed by Apple entirely is disabled without already knowing the "right click workaround" (try successfully explaining to a casual user how to install that kind of app)
Well, the simple answer is to change the Gatekeeper setting, but the more relevant question is why are you even providing support for such an app? Any app that isn't properly code-signed is likely to not have had an update in several years. The only excuse beyond old unsupported apps for not properly being code-signed is the rare open-source cross-platform app that provides an OS X download without codesigning, which is not something most casual users are generally expected to be using anyway.
All of this is beside the point anyway. Gatekeper and the Mac App Store are two completely separate technologies. And whether or not your application is distributed on the MAS is not relevant to Gatekeeper, except in that you cannot distribute on the MAS if your app is not properly codesigned.
> It's only logical to extrapolate that to the next steps. maybe in 2015 all non-MAS will require the right-click open. In 2016 or 2017 non-MAS will probably mean not runnable without obtaining a limited-use developer or enterprise certificate from Apple for a fee.
That's pure 100% FUD. It is not at all logical to assume that Apple will pull such an insanely stupid move. iOS being locked down does not at all say that OS X will be locked down in the same fashion; it would be virtually impossible to lock down OS X like that, and any attempt to do so would be so incredibly user-hostile that it's laughable to think Apple would do that, and would probably destroy OS X.
I have to wonder if you have some vested interest in sowing distrust in Apple and OS X. Why else would you make such an absurd claim with a straight face?
No it's not. Where did you get that idea? The only issue is installing software that isn't codesigned with an Apple-signed certificate. Any developer enrolled in Apple's Mac Developer program can get an Apple-signed certificate and self-sign their 3rd-party non-MAS software and users will have the same experience as using MAS software. The only dialog they'll get is the standard "Are you sure you want to run this program you just downloaded?" dialog that we've had for a while now. Which, admittedly, I don't think MAS apps have, but that's because MAS apps aren't downloaded with a web browser; if you install a 3rd-party app via some mechanism other than downloading with a web browser it should similarly bypass that dialog.
> installing software from a developer entirely unblessed by Apple entirely is disabled without already knowing the "right click workaround" (try successfully explaining to a casual user how to install that kind of app)
Well, the simple answer is to change the Gatekeeper setting, but the more relevant question is why are you even providing support for such an app? Any app that isn't properly code-signed is likely to not have had an update in several years. The only excuse beyond old unsupported apps for not properly being code-signed is the rare open-source cross-platform app that provides an OS X download without codesigning, which is not something most casual users are generally expected to be using anyway.
All of this is beside the point anyway. Gatekeper and the Mac App Store are two completely separate technologies. And whether or not your application is distributed on the MAS is not relevant to Gatekeeper, except in that you cannot distribute on the MAS if your app is not properly codesigned.
> It's only logical to extrapolate that to the next steps. maybe in 2015 all non-MAS will require the right-click open. In 2016 or 2017 non-MAS will probably mean not runnable without obtaining a limited-use developer or enterprise certificate from Apple for a fee.
That's pure 100% FUD. It is not at all logical to assume that Apple will pull such an insanely stupid move. iOS being locked down does not at all say that OS X will be locked down in the same fashion; it would be virtually impossible to lock down OS X like that, and any attempt to do so would be so incredibly user-hostile that it's laughable to think Apple would do that, and would probably destroy OS X.
I have to wonder if you have some vested interest in sowing distrust in Apple and OS X. Why else would you make such an absurd claim with a straight face?
>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.
The counterpoint to this is that users have a far, far lower standard for interfaces than Apple does which means developers spend less on the actual functionality of their app. While the examples you posted are unfortunate apps that got caught in cross hairs, I believe that the App Store on mobile is better due to Apple's insistence of UI control.
The counterpoint to this is that users have a far, far lower standard for interfaces than Apple does which means developers spend less on the actual functionality of their app. While the examples you posted are unfortunate apps that got caught in cross hairs, I believe that the App Store on mobile is better due to Apple's insistence of UI control.
> The real question is: where do we draw the line?
Indeed, and it's not so simple with your "users should be able to dice for themselves whether it's acceptable" belief either. What about malware? The user clearly gave permission for the app to be installed. Who are you to say they didn't want that software to run on their device?
Indeed, and it's not so simple with your "users should be able to dice for themselves whether it's acceptable" belief either. What about malware? The user clearly gave permission for the app to be installed. Who are you to say they didn't want that software to run on their device?
Personally, I think all of them are bogus decisions. Apple might be well within their rights to make bogus decisions but that does not automatically make them not bogus.
Note taking app should not have custom keyboard. Bogus. Apps are not allowed to have UX gesture similar to Apple because they become confusingly similar to Apple product. Bogus. It was a stopwatch for crying out load.
No matter how you try to spin it, these decisions is just Apple screwing over their app developers.
Note taking app should not have custom keyboard. Bogus. Apps are not allowed to have UX gesture similar to Apple because they become confusingly similar to Apple product. Bogus. It was a stopwatch for crying out load.
No matter how you try to spin it, these decisions is just Apple screwing over their app developers.
> Note taking app should not have custom keyboard. Bogus.
That wasn't the rejection.
> Apps are not allowed to have UX gesture similar to Apple because they become confusingly similar to Apple product. Bogus.
That wasn't the rejection either. It wasn't rejecting the concept of a horizontal swipe causing an action. In fact, Apple intentionally makes it extremely easy for horizontal swipes to cause actions.
> No matter how you try to spin it, these decisions is just Apple screwing over their app developers.
Yes, Apple is well known for hating their developers and intentionally trying to screw them over, and every 3rd-party developer that gets rejected is an innocent victim. Makes perfect sense.
Edit: If you didn't get it, that last paragraph was sarcasm.
That wasn't the rejection.
> Apps are not allowed to have UX gesture similar to Apple because they become confusingly similar to Apple product. Bogus.
That wasn't the rejection either. It wasn't rejecting the concept of a horizontal swipe causing an action. In fact, Apple intentionally makes it extremely easy for horizontal swipes to cause actions.
> No matter how you try to spin it, these decisions is just Apple screwing over their app developers.
Yes, Apple is well known for hating their developers and intentionally trying to screw them over, and every 3rd-party developer that gets rejected is an innocent victim. Makes perfect sense.
Edit: If you didn't get it, that last paragraph was sarcasm.
Uh, fine. Sure, some of the rejections may be appropriate. But the situation with Drafts and PCalc are still very valid examples of problems with Apple's policies.
I updated my post with a note at the bottom already. And two examples, one of which is actually not clear-cut at all (I don't agree that the Drafts case is actually necessarily an invalid rejection) and the other of which got reversed almost immediately, doesn't necessarily mean a whole lot. Do you know how many apps get reviewed every single day? And how many of those get validly rejected, for reasons that nobody here would possibly disagree with? I think the answer is probably higher than you expect.
I would love it if cases like PCalc never even happened. But I'm willing to accept that sometimes bad decisions happen, and we have to do our best to see that it gets fixed.
Edit: To clarify on Drafts, I definitely think that they need to be consistent with their policies, though that can be very hard when you have lots of different reviewers reviewing apps, as they may interpret policies differently, or simply be more or less diligent about enforcing them. But Apple has always said that the notification center is intended for information display, and it follows that having a bunch of apps use widgets that provide buttons to launch the app is in violation of the intention of the notification center. Apple should be consistent here, but I would not fault them for choosing to tell all apps (such as Evernote) that they need to remove similar buttons, rather than allowing Drafts to keep its button.
I would love it if cases like PCalc never even happened. But I'm willing to accept that sometimes bad decisions happen, and we have to do our best to see that it gets fixed.
Edit: To clarify on Drafts, I definitely think that they need to be consistent with their policies, though that can be very hard when you have lots of different reviewers reviewing apps, as they may interpret policies differently, or simply be more or less diligent about enforcing them. But Apple has always said that the notification center is intended for information display, and it follows that having a bunch of apps use widgets that provide buttons to launch the app is in violation of the intention of the notification center. Apple should be consistent here, but I would not fault them for choosing to tell all apps (such as Evernote) that they need to remove similar buttons, rather than allowing Drafts to keep its button.
The fact that any rejection is 'valid' or that there is a process for rejections to begin with, is absurd. iOS is NOT developer friendly.
I wish iOS didn't have the market share it has, it is so depressing: you either are under Apple's boot or have to abstain from a large segment of the Mobile Market.
I wish iOS didn't have the market share it has, it is so depressing: you either are under Apple's boot or have to abstain from a large segment of the Mobile Market.
[deleted]
why are you qualifying it as "the apple store review team"? it's just apple. maybe people have trouble associating this kind of bad behavior because the branding is so strong? are you mind controlled?
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
edit: typo
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.
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.
Cyanogen M releases are now considered their stable releases. These have been on 4.4 for a long time.
You're right. A google search found this... which isn't clearly linked from the download page, getting started page, etc): http://wiki.cyanogenmod.org/w/Release_Versioning
Cyanogenmod really needs to update their website. Everything under "stable":
https://download.cyanogenmod.org/?type=stable
and under "Release Candidate":
https://download.cyanogenmod.org/?type=RC
are the outdated 10.2 aka Android 4.3 Jellybean releases. The "Milestone" link is totally blank:
https://download.cyanogenmod.org/?type=milestone
There's no indication on any of those pages that you should look somewhere else.
The "snapshot" builds is when you finally start to see something modern. And snapshot usually implies 'alpha' quality... one step up from nightly, but definitely NOT something you want to be running on your real, everyday mobile device. Indeed, from the posts on the forum, it seems snapshot isn't stable. M11 had bluetooth issues, you should revert to M9. M12 has GPS and battery drain issues. Etc. I wouldn't really call that 'stable'.
Also note that this is when clicking the "Download" link right across the top on the Cyanogenmod site, which just dumps you into the kind of confusing download structure where you're supposed to understand your phone's code name (of course 'jftle' means Samsung Galaxy S4, that makes sense) and that snapshot actually means stable. They used to have a far more navigable website where you could easily see the level of support offered for your phone (stable vs milestone vs nightly) before you decided to start hacking it.
They now want you to use the CM installer which is under the "getting started" link on the main page. But the Download link should really point to a proper download page that explains things for first time visitors, not dump you off on the advanced users page with no prompting. Really not a user-friendly setup. And that's speaking as someone that used CM on my last two phones (the original G1 and the T-Mobile G2/HTC Desire Z) but never saw it work smoothly.
Cyanogenmod really needs to update their website. Everything under "stable":
https://download.cyanogenmod.org/?type=stable
and under "Release Candidate":
https://download.cyanogenmod.org/?type=RC
are the outdated 10.2 aka Android 4.3 Jellybean releases. The "Milestone" link is totally blank:
https://download.cyanogenmod.org/?type=milestone
There's no indication on any of those pages that you should look somewhere else.
The "snapshot" builds is when you finally start to see something modern. And snapshot usually implies 'alpha' quality... one step up from nightly, but definitely NOT something you want to be running on your real, everyday mobile device. Indeed, from the posts on the forum, it seems snapshot isn't stable. M11 had bluetooth issues, you should revert to M9. M12 has GPS and battery drain issues. Etc. I wouldn't really call that 'stable'.
Also note that this is when clicking the "Download" link right across the top on the Cyanogenmod site, which just dumps you into the kind of confusing download structure where you're supposed to understand your phone's code name (of course 'jftle' means Samsung Galaxy S4, that makes sense) and that snapshot actually means stable. They used to have a far more navigable website where you could easily see the level of support offered for your phone (stable vs milestone vs nightly) before you decided to start hacking it.
They now want you to use the CM installer which is under the "getting started" link on the main page. But the Download link should really point to a proper download page that explains things for first time visitors, not dump you off on the advanced users page with no prompting. Really not a user-friendly setup. And that's speaking as someone that used CM on my last two phones (the original G1 and the T-Mobile G2/HTC Desire Z) but never saw it work smoothly.
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).
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).
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.
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.
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.
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.
My big complaint with the Nexus 5 used to be poor battery life but with the improvements in Android L/5.0 I no longer have any trouble getting through the whole day on a single charge. I was planning to upgrade to a Nexus 6 but I really don't want a phone that big so I'm sticking to my trusty Nexus 5 for now.
Yeah. I have two friends with Nexus 5s that really like them. The Motos would be my 'close to stock' choice, really. Solid hardware and software available at multiple price/feature points.
I seem to rotate between all of the platforms every year. I keep switching because there is some flaw that I just can't stand and I always seem to think the grass is greener on the other side.
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.
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.
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.
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.
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).
Might be. I am not enough inside this stuff to really distinguish. But there are other examples, where Apple decides, what is allowed to run on "their" hardware. I as user feel "overprotected" to say it very polite.
Also there are other companies that provide services, but don't force the users to use it in the way they think.
Also there are other companies that provide services, but don't force the users to use it in the way they think.
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..."
"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..."
It's simple. Cabel is being diplomatic and doesn't want to burn any bridges. It's a reflection of how much power Apple has that developers are fearful of upsetting the mothership. I know a few former indie Mac and iOS developet who now work for Apple which explained why they were always shy to voice their true opinion publicly - they had a dream to work for Apple and didnt want to shoot themselves in the foot. Self censorship at its finest.
It's not sarcasm, though you draw a very nice parallel.
Cabel is correctly observing that Apple is a collection of people, and those people frequently disagree with each other.
Cabel is correctly observing that Apple is a collection of people, and those people frequently disagree with each other.
It is possible to hate a smaller part of a larger whole without hating the larger whole outright...
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?
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.
You may have noticed a certain amount of Kremlinology at play when dealing with Apple. That quote is no different.
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... I wish the (at least European) politicans had the balls to shut down such closed ecosystems!
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... I wish the (at least European) politicans had the balls to shut down such closed ecosystems!
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).
Apple's App Review team has been merciless lately. They won't accept any further updates to my app, Timebar (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.
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.
Over the last four years I've gotten pretty good at developing iOS and, more recently, Mac apps but I'm not going to invest any more time in a platform subject to this kind of arbitrary and dictatorial control. I'm shifting back to Rails and the open web. It's a much nicer developer ecosystem and potential client pool. And it's even a better business environment for all but the biggest players. In hindsight I regret investing so much time in Apple's walled garden.
I don't ever, ever use the Mac App Store for anything. I avoid apps that don't provide an alternative. Just put a download on your site and keep the old version on the store.
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.
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.
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.
"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.
> 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.
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.
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.
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.
> Which is admirable, but you can see why it's hard. This is incredibly frustrating.
So Stockholm it is then? It's incredibly frustrating because apple is mistreating the developers building the app ecosystem they themselves rely on.
There better be a shit-ton of money in this, because looking at this from the outside, it all looks like madness.
So Stockholm it is then? It's incredibly frustrating because apple is mistreating the developers building the app ecosystem they themselves rely on.
There better be a shit-ton of money in this, because looking at this from the outside, it all looks like madness.
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-...
I think it's Input: 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.
Note that some glyphs (g, l, i) can be customized and may look different from the screenshot in the default download.
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.
I think it might be Input: http://input.fontbureau.com/
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).
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).
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.
"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.
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.