Next article: Friday Q&A 2010-05-14: What Every Apple Programmer Should Know
Previous article: Another Week Without Friday Q&A
Tags: apple iphone rant
During a recent discussion on Twitter about Apple's draconion App Store policies, I mentioned that there's a long list of apps I want which Apple does not allow, and thus these restrictions directly hurt me not only as a developer, but as an iPhone user. This made @pbur curious, and he indicated he'd like to know what those apps are. So I sat down and came up with a list of apps that I really want for my iPhone but that Apple won't let me have. To the best of my knowledge, every single one of these ideas is completely feasible in a technical sense, wouldn't destroy the cell network, wouldn't make your phone's battery life unusably short, and are kept out of my hands solely because Apple thinks it knows what's best for me.
Airfoil
I'm a little biased, of course, since the company I work for makes it, but I'd love to have Airfoil on the iPhone so I can send music directly to an AirPort Express, instead of having to leave my computer turned on and fart around with various substandard remote control solutions. It's impossible to get audio from other apps on the iPhone (even once multitasking happens in 4.0), and apps aren't even allowed to access the audio data in the user's music library. While Airfoil could conceivably be implemented to send audio, there no way for it to get any interesting audio for it to send.
Hardware brightness control in Kindle
This is a simple one, but also highly desirable. I much prefer Kindle to iBooks on the iPad, because Kindle lacks the distracting visual elements in iBooks, and also has a far superior selection. iBooks does have one nice feature that Kindle lacks: control over the strength of the backlight. Kindle fakes it by adjusting the background color, but it's nowhere near as good. The hardware brightness adjustment is a private API, which third parties like Amazon are prohibited from using. Of course, the rules do not apply to Apple.
Automatic pasteboard synchronization
I often use my iPhone/iPad at home while also using my Mac, and often want to get data from one to the other. It would be great to have something that would automatically synchronize the pasteboards between them. Currently you can do this by launching a separate app to transfer pasteboard contents, but that's enormously inconvenient compared to a transparent background service. However, launching a separate app is the only option, because Apple doesn't allow us to build a pasteboard sync daemon.
Text macros
It would be great to have customizable macros that can be inserted into text boxes, either by typing a shortcut or hitting a custom button on the screen. It could be simple stuff like my e-mail address or my phone number, or it could be more complicated stuff like my current latitude and longitude. There's no way for a third party application to manipulate another application like this.
Alternate keyboards
I use the Dvorak keyboard on my Mac. Although Apple supports Dvorak on the iPad for external hardware keyboards, it's not an option for the on-screen keyboard. While adding a custom layout would probably be a trivial modification, no such activities are allowed.
Custom input methods
A more generalized version of alternate keyboards, it would be great to be able to load custom input methods that could be accessed in addition to the alternate keyboard. Apple already supplies a method which lets you write Chinese on the screen by drawing the characters with your finger. How about adding one which lets you write English in the same way? Maybe an input method which lets you trace words over a keyboard without lifting your finger, for a speed gain? But again, no such thing is allowed.
Scripting
I love scripting my computer. I have scripts bound to hotkeys that control my music or upload screenshots to my web site. I have scripts that automatically run backups. I have scripts that take actions when new mail arrives. I build once-off scripts to make different apps work together. Scripting is something that makes a system become far more than just the sum of its parts. Scripting doesn't exist on the iPhone, and is impossible for third parties to add under the current regime.
Tor/ssh proxy
I go to China every year or two, and when I'm there, I get to enjoy the Great Firewall of China. This means that I can't directly access Facebook, YouTube, and many other sites. Luckily, it's easy to work around the Great Firewall by using services like Tor. This allows me to access the full web, despite being in a country that tries to censor the internet.
(If anyone is getting worried, don't be. The Chinese government doesn't care if a few foreigners bypass their blocks to access information they're able to get in their home country anyway.)
Last time I went to China, I took an iPhone with me and got it up and running with a Chinese carrier, complete with cellular internet access. However, I couldn't access any blocked sites from the iPhone, because tools like Tor simply don't exist there.
Even in the US, it might be nice to keep some activity hidden from AT&T or my local WiFi provider, but there's no nice way to do it.
Call recorder
While the RAZR I had before I got my iPhone didn't have a lot to recommend it, one nice thing it did have was the ability to record calls. If somebody gave me directions over the phone, I didn't have to scramble for paper, I could just hit a button and record what they said, then transcribe it later at my leisure. I'd love to have this for my iPhone, but third-party apps can't access phone audio, so my only choice is to hope Apple adds it themselves someday.
WiFi sync
Another nice RAZR feature was the ability to sync contacts and photos with my computer over Bluetooth. I find it wonderfully ironic that my cheap crappy Motorola phone could do wireless sync, but my expensive and enormously powerful iPhone can't. It would be great to have this capability, whether by doing a custom syncing protocol, or just faking out iTunes and making the wireless link look like a USB connection. But again, this can't ever happen, so I'm stuck waiting on Apple to get around to it. In the meantime, my contacts are constantly out of date and it's an annoying ritual to plug my phone into my computer so I can get pictures off of it.
WiFi hotspot
There are third-party apps that allow you to connect to the internet through your phone with WiFi, but of course none of them are allowed in the store, so they're jailbreak-only. This is a highly desirable capability that's not all that technically difficult, but Apple's loyalty to AT&T is greater than their desire to benefit their customers here.
WiFi mapper
It would be a bunch of fun to wander around the neighborhood with my phone in my pocket and have it automatically map out all of the networks it came across. Really easy to do from a technical standpoint, but the WiFi APIs are all private, so I'm out of luck.
Thermal mapper
As some of you may already know, I fly gliders. One of the challenges of glider flight is to map out the location of thermals while climbing. I thought that I could get my iPhone to help with this. By getting vertical velocity information from the GPS chip, and correlating it with horizontal position, I could build a map over time of where the thermal was strongest. Although full three-dimensional velocity data is an inherent output of any GPS calculation, CoreLocation does not provide access to vertical velocity data, only horizontal. And direct access to the GPS chip is forbidden, so I had to give up on my project.
DOSBox
I have a flight recorder for my glider, which uses GPS to record my position every few seconds so that the flight can later be analyzed (and claimed for a badge or record, if eligible). To dowload the flight record after flying, I have to take the recorder out of the glider, connect it to a PC that we keep at the airport, download the flight, then transfer the record to a flash drive so I can take it home. It's a pain in the ass. The software for downloading the flight is provided by the manufacturer and runs in, yes, DOS. Its computational requirements are low, so it should run reasonably well even in an emulator on a slow ARM chip. It would be great if I could run DOSBox and connect some sort of serial adapter to the iPhone so I could use it to dowload my flights directly, rather than screwing around with keeping a whole PC laptop at the airport. But Apple hates emulators, so this shall never be.
Location/time based configuration changes
When I'm at home, I want my ringer on. When I'm out walking, I want the phone on vibrate. When I'm flying, I don't want incoming calls at all. I have to make all of these changes manually, even though my phone knows where it is at all times. I don't want audible calendar alerts when I'm at home and my computer will alert me. I want to have it only use a passcode lock if I'm in a place I don't normally visit. It should be able to detect my location and change its configuration to suit. But third-party apps can't change this kind of configuration, so it's impossible to add.
Time-based changes would be interesting as well. I could have the ringer be quieter at night, and loud during the day. I won't bother doing this manually (especially since I don't want to risk forgetting to turn the ringer back up) but it would be great to have the phone do it automatically. I'd also like to have audible new mail alerts during the day, but not at night, and only when I'm at home. But again, it can't be done.
This sort of thing would get even more interesting when combined with scripting. I could have my phone automatically respond to incoming instant messages from people I know to tell them that I'm at the airport and may be slow to respond. My phone could automatically message my wife when I leave for home. It could detect when I'm driving and use voice synthesis to speak incoming messages from certain people I want to be able to hear from on the road. I could set up a reminder to buy cat food that would pop up next time I'm at the store.
Utilities
So there you have it, 15 apps I'd love to have on my iPhone but that Apple won't let me have, purely for political reasons. Every one of these apps is technically feasible, and many of them not even particularly challenging, but I can't have any of them. They would dramatically increase the utility of my phone, but Apple thinks they know best.
These ideas almost all fall under the category of "utilities". And this is no coincidence: utilities are largely tools which work in concert with other software to offer more power in combination than you get separately. Apple prohibits third party apps from influencing anything outside themselves, so this sort of utility is impossible. The Utilities section of the App Store is a joke. Most of what it contains is either useless or miscategorized, because Apple forbids the creation of any true utility software for this platform.
And so you can see, Apple's restrictions don't just rankle on principle, and don't just hurt me as a developer, but they dramatically reduce the usefulness of the iPhone to me as a user. And they dramatically reduce the usefulness of the platform for millions of other users as well, even if they don't know what they're missing.
Comments:
For example, the custom input methods. I agree that I want them as a user (I would love to try out Swype on the iPhone), and if I could convince Apple to implement them as out of process plugins in a hosted input server where the system manages RPC and what not that would be great. But in order to implement such a thing on the system today you would need to have the system load code bundles into apps which means letting foreign code into an app's sandbox. There is no in-process access control, that is the perfect place to hide a trojan or a worm.
So yes, I agree with your premise that there are plenty of things Apple doesn't allow that would be cool, but I dispute your claim that there are no technical challenges. I would claim there are no technical challenges to implementing them in they have been done on previous OSes (Windows and Mac OS X), with all the inherent security issues that those OSes have because of them, but there are genuine technical issues involved with doing them in a way that doesn't open the OS up to the sorts of structural vulnerabilities that exist in desktop OSes.
That doesn't means I think you should stop pushing for the capabilities you want, but I personally want them to be introduced as they are thought through with respect to the security implications they entail, not just because we know how to do them on legacy OSes that have legacy security problems.
For reference, there is no way in hell I want apps being able to muck with user input, audio routing, or network routing until Apple comes up with a coherent mechanism and UI for the security policy of the system. Conveying security concerns and access controls to the user in a way they can understand is in fact a very hard a problem.
A desire for security is a reason for procedure, process and some protective default settings. It is not a good reason to remove capabilities entirely.
To claim that Apple's wilful removal of user freedom in the name of security/quality is appropriate is, at best, an apologist view; at worst it enables an arrogant authoritarian attitude towards iPhone OS customers.
Robert Paulson: What was the point of posting that link?
Louis Gerbarg: I tend to side with Matt here. Disable anything remotely dangerous by default, but don't take away the switch. I should be able to get root on my iPhone device. From there, I can do anything. If that makes it more dangerous, that's my own problem. I've never had a virus/trojan problem on the Mac, and haven't heard of any major problems on jailbroken iPhones.
I fully support sandboxing by default, and creating a safe, easy App Store that normal users can download from in confidence. I'd be fine if none of these apps ever showed up on the App Store. All I want is the ability to use an alternative distribution mechanism without having to hack my phone first.
If they officially allow any mechanism that effectively jailbreaks the device, then they are in a position where they are likely to have to provide support, since it almost certainly untenable for them to put a switch in the UI that unlocks the device and cancels your warranty.
There should be a way for serious users to unlock their devices, but allowing it to be done easily and in a widespread manner has tangible costs for a platform vendor. Honestly, I think the hassle of jailbreaking is actually an appropriate cost, the only problem is that the feasibility of jailbreaking could go away at any time because it fundamentally depends on exploits that should be fixed. On the other hand just putting a switch in the UI to do it is too cheap, users enter their passwords whenever they are asked, lots of users would hit the switch when some app told them to without ever understanding the consequences. Unfortunately, I don't have a suggestion for an appropriate way to directly and immediately convey the cost to them, short of actually charging them money or disabling other functionality.
While jailbreakers are probably able to hack most of these things, making them possible in a safe, uninstallable, distributable and future-compatible way is not just the trivial task of changing policy. It's also the difference between a simplified OS and a desktop OS.
Maybe the iPhone OS will grow up to that point, maybe it won't. But certainly that list would have been longer 12 months ago. Some problems were solved by new APIs.
Totally agree on the lack of emulation, though.
I fully agree with everything else, along with the ability to be given free reign on the device. I get what Nik says that there's a difference between a supported configuration and blue-sky hackability, but no one's saying Apple has to support this. You should be able to use private APIs at your own peril for your own use; even for others' use, as long as they are aware of the risks. Matt's got it right.
That's a really lame false dilemma. Why can't an iPhone be simple enough for most people but powerful/flexible enough for power users? And don't use the argument that doing so gives people the power to make their phones crappy or not work properly. That's like like telling an adult they must use butter knives to cut everything, and can't use steak knives because they might cut themselves.
Mike:
Just last night I was thinking how helpful it would be to be able to script my iPhone. See, I wake up every day at 5am and start working after 10 mins so I can call it an early day around 2:30ish. But this means I need to go to sleep at 9:30 sharp. And to wake myself up, I use the iPhone's built in alarm and put my phone on vibrate. It's nearly fool proof. BUT, last night at around 10am I was awoken from almost being asleep, because my phone vibrated from an email it received. You can imagine my eagerness to find a setting I can toggle in the clock app that would turn off vibrations for everything except the alarm. But of course, Apple left that out of the clock app for whatever reason. Instead, you have to go into Settings.app and turn off vibrations manually, and them turn them on manually in the morning. This is where the scripting comes in. Not a difficult thing to script, if Apple would just allow me to do so. Then I could get a solid night's sleep without the possibility of accidentally missing vibrating phone calls if I forget to turn the phone off silent mode.
Mike stated that the Kindle does have a "brightness control" but that it fakes brightness by changing the background color. It's not real brightness control, and that's the fault of Apple for only providing the true brightness control to themselves, and no one else (as it's a private API). Not sure how you missed all of this from Mike's post, he was extremely succinct. Or perhaps you intentionally "misunderstood" in order to find any excuse you can to defend Apple?
That's just the issue at hand: it's ridiculous that we need to wait for Apple's express permission to do anything currently not supported by APIs and by their license, if and when they give it. I think that's what many of us are upset about.
I can see a possible direction to take from here to there: convincing enough people to demand it. But it would have to positively affect Apple's bottom line. Actually, Apple (Jobs and Forstall) would have to believe it would have a significant probability of taking market share away from Android.
It looks like Android market share gains come down to price at the moment. Apple doesn't want to compete on price, thankfully. So they have to be able to make significant gains in features without offsetting those gains with other costs--like support, as Louis mentioned, or legal, or a much more involved app approval process, or by being able to charge a reasonable pro-user upgrade fee.
I think you have to make a good sell that opening up the phone will sell more units and more apps. But there is one possibly even bigger obstacle. But we know that as soon as the device is easily unlocked, the AppStore loses its relative monopoly. I can't claim to understand the revenue implications, but I think the new Ad framework is probably pretty tied into it, and I suspect they expect that to make a lot of money.
The big unknown, from Apple's point of view, is whether opening up the iPhone would damage the brand by eroding the user's confidence in its reliability and ease of use. I guess Jobs is pretty sure it would damage it a lot. His attitude comes from his intuition, and we all know that his intuition is pretty powerful, and unlikely to be affected by any amount of noise or argument from so-called pro users.
This is a pretty hard sell. And since you apparently already bought an iPhone, you have a terrible negotiating position, unless you are willing to pay a hundred bucks or more for more openness, or a whole lot more for a special pro model with a different legal agreement. But then you're in a very small minority. Not only are most users not going to do that, thus making it unattractive to Apple, but very few (paid) apps are going to be written with you in mind, meaning a net financial loss for them (anytime a company does anything that is not a significant gain, it's a loss in terms of potential revenue).
You are much better off to just jailbreak your phone already.
Louis Gerbarg: I won't deny that the current regime is good for Apple in a lot of ways. Obviously they're enjoying enormous success. But that doesn't make me feel any better about how their choices impact me.
Nik: I don't care about safe, uninstallable, or future-compatible. Apple doesn't need to protect me from myself, I can handle that.
I think the point you're missing is that all of these apps are things that third parties could build without any help from Apple, if Apple would let us. Yes, these are largely things that could be done with the appropriate API. But there is no appropriate API, and no sign that one is coming. On the Mac, I have tons of useful software that does things for which no official API is available. Yet, they accomplish them anyway. Is this dangerous? A bit, yes. Is this future-compatible? Not too much. And yet, this software is incredibly useful despite that. I would much rather sacrifice some safety so that I can have this power. If you'd rather make the opposite tradeoff, that's your right; nobody would force you.
Jesper: Why is GPS disallowed on a flight? I'm not talking about an airliner, I'm talking about my own personal airplane. The silly no-electronics rules for airliners do not apply.
agaddo: You're absolutely right. I'm a power user, and the iPhone is not for power users. The thing is, the Mac is for power users, and also for normal people. Apple managed to build a platfor that's fantastic for both. Now they're abandoning me. I don't want them to abandon me, I want them to build another awesome power-user platform.
Dpc: No, not an example of yet another myth being perpetuated by lazy people, just an example of yet another lazy person failing to read and understand before commenting on an article.
Brent: I take the long view. In the long view, I see Apple driving an industry-wide move toward closed platforms. In a few decades, everything will be closed, and they'll have locked out the jailbreakers. Then where will we be? I agree that the odds of changing Apple's strategy are extremely small, but that doesn't mean I won't try.
alastair: I know it supports VPN connections, but I don't know how to set up a VPN server. I could learn, but I'd rather use what I'm familiar with. Why should I have to use a completely different technique just because Apple has decided that's all they'll let me use, on hardware which I bought and is now mine, not theirs?
But that's not correct. You can jailbreak your phone, which is yours, and do whatever you want with it. You can write any software you want and run it.
What Apple isn't doing is selling that software in their store. You bought the hardware and can do anything you want with it. They built the store and can sell/not sell whatever they want.
Brent: Taking your points out of order, I don't have any idea for a coherent strategy either. I think that making posts like this and getting the word out is something that may help. I think a lot of people are unaware of the problems Apple is causing but would be sympathetic if they understood, and a lot of other people don't like what Apple is doing but feel that they're alone. As far as worst-case thinking goes, you might be right, and I don't think it's inevitable, but I do see it as a high probability event. Apple has actually opened up smartphones a great deal compared to how things were before the iPhone, and that's great, but after that huge initial swing, they seem to be going back the other way, and everyone else is trying to emulate them.
alastair: I understand what you're getting at. If I really need it, I'll certainly look into setting up a VPN. When I was in China, I just used my computer to visit blocked sites, and that was good enough. Maybe next time I go I'll figure out how to set up a VPN. I'd still like to be able to make my own choices for how to accomplish this stuff, but you're right that there are other ways.
Could it be that early reports to the contrary on private APIs being the only way to do this are incorrect?
Remember the Logitech drivers that screwed up Leopard installs because they did completely unsupported things with an old version of APE? Who bore the initial PR costs of that, and the support costs of it? Apple did. Most users never even conceived they were doing anything risky, they just typed in their password when the installer from a big manufacturer asked them to. What happens when some popular app does the exact same thing the phone, and a new firmware comes out the places the phone in an unbootable state because of unsupported software mucking with the system in unsupported ways? The answer is that Apple gets bad PR for the new firmware, and ends up having a lot of extra genius appointments and RMAs, not to mention a bunch of pissed off users for whom running unsupported code turned out to be a serious misfeature since their phones are bricked and need a DFU.
If you can have a proposal that does what you want while still preventing that situation then you have a serious case to make, until then I just think you are arguing that you want a feature (running arbitrary code) that Apple sees in opposition to a feature they want to provide to most users (reliability, without having to understand computers), and that whenever two features are in opposition one group of users will be pissed.
On the Mac, users get an admin account by default. They're conditioned to type their password for everything. There's no difference, in the GUI, between an app that wants to twiddle permissions on something and an app that wants to install a dangerous kext.
On the iPhone, bury the "allow arbitrary code" or "give me root" switch deep. Surround it with warnings. Require using iTunes to install software, if you must. That won't be any more dangerous than now, but it will let me do what I want with my stuff.
Not that this is a viable option, but I am curious if you would find it acceptable:
What if you needed to send a signed letter to Apple requesting the device unlock and waiving all software support for the device?
As for the signed letter, no, that's no good. Such a situation still gives Apple the ability to refuse, even if in practice they never exercise it. Just like the iPhone developer program gives Apple the ability to disallow developers from even installing software on their own devices, even though in practice they accept pretty much everybody.
I might go for something where you have to sign an electronic agreement (provided the agreement is reasonably narrow) on the phone (with your finger), and then it unlocks without waiting for permission from the mothership. I think such a regime would be excessive, but at least control would rest with the owner.
The issue I was trying to convey was Apple taking away something that unlocking may make expensive for them (support) when unlocking the device. The cost I was trying to convey was discontinuing technical support for the device (in other words, making the user bear the actual cost of unlocking), the point of the signed letter was that use just tap through warnings and if a user sued over it I would suspect that simply tapping a window saying you waived technical support would not be adequate.
For my example, just imagine they included a guarantee with every iPhone they would not refuse any signed unlock request and were posting a $30 billion dollar bond to collateralize the guarantee.
Or, if you want to convert it over to your example, what if there was a hardware fuse in the device that could not be reset, and that would be blown when the device was unlocked, and Apple would refuse any technical support for devices with blown fuses?
When you say discontinuing technical support, do you just mean phone/genius bar, or do you mean replacing defective hardware? If the former, absolutely fine. If the latter, I think it would be extremely lame, and may fall afoul of the law, but still doesn't have the disturbing control implications of the current situation.
I've been kicking the tires on Google Voice lately. I miss the advantages of a native dialer, but for inbound calls it's pretty transparent, and it has a call-recording feature.
When you get around to setting up a VPN server, the IPSec VPN in OSXS is far easier than most. You just need to forward some ports (500, 1701, 4500). We've successfully set up an OSXS VPN server in a VM instance before, which makes this approach pretty feasible if you already have a Mac Pro and a dev membership at your disposal.
OpenVPN support in the iPhone would be even better, but there's no sign 4.0 will deliver it.
Tell you the fee for a software support incident
Take your credit card number
Figure out what is going on
Charge you if it turns out to be software
Louis Gerbarg: I'd even be fine if they required wiping the phone clean in a situation like that. I don't know if it does, but the iPhone could have something like Firewire Target Mode so that a clean, happy OS can always be forced onto the device no matter how hosed it is software-wise.
I do have one other question for you. Do you think developers should be able to restrict their apps to only locked phones? In the physical world a vendor can refuse to sell a product to an individual, and I know I have dealt with clients who I am certain would prefer their products only run on stock systems (some for perceived security reasons, some for support reasons). Assume any such limitations are disclosed in the apps metadata on the app store.
When I think about what is wrong with Apple's stewardship of the iPhone platform, it isn't the closed APIs or the lack of the ability to write kernel extensions or other system-level modification. I actually see that the security and stability benefits are worth the loss in functionality.
Rather, I see it as much more problematic that Apple must manually approve every program that a user might wish to run and that they have tightened their grip over time, forbidding legitimate developers tools from being used in some kind of pissing match with Adobe.
Put another way, I'm more more bothered by the fact that apps that "duplicate functionality" of Apple apps (that is to say "compete with them") are forbidden.
Installing Xcode, properly configuring the device and/or the OS image for enhanced development features (including provision), accepting responsibility for what you're about to do, etc., seems reasonable to me. You have to pay for a developer license, granted, but all they would have to do is allow * as the list of devices in the provision for a dev app.
Of course this would mean people could effectively sell their hack apps directly to end-users (other developers), but something like this might still be feasible, filter out the n00bs automatically, and make everybody happy. It would be cool if someone could just crack the provisioning system to enable this.
I also sometimes wonder if I'm the only Mac owner out there whose Mac is completely stable and has never had any trouble with viruses or other malware. It often sounds like everybody else's Macs have constant trouble, and the iPhone is the first time they had a computing device that Just Worked. Not so for me! I actually have more instability on my iPhone OS devices than on my Mac. Of course, this means that I have to reboot them once every month or two instead of once every two or three months, so it's not exactly a big deal, I just don't get this concept that an open system has to be dangerous or difficult.
Brent: Remove the requirement to pay Apple for a developer license and I'd be right there with you.
It is very familiar because it is entirely consistent with how Apl,e has made products for years. Traditionally Apple omits features and options that they think most users won't use, because each additional feature adds a little more code to support, and a little more confusion for the user. When it is a particular feature that you want it bites really hard, and it seems very unreasonable because often adding that one thing seems like it would not add much complexity, but in aggregate it is a substantial effect.
Obviously this is a bigger deal then most small features, and Apple does include some options for things they feel are necessary and cannot infer without user input, but those are viewed as UE failures. Apple clearly does view clean simple settings as a feature, which means removing as many options as possible, and it has been quite successful for them. The argument to make is why this feature should be an exception to that.
Mike:
If you object to paying more to unlock then then you also need to petition the mobile carrierrs. I assume you using a subsidized phone? Even if Apple allows the phone to be unlocked, I guarantee you there is no way most carriers will allow their carrier subsidized SIM locked phones to be unlocked, if only to prevent people from installing software NATs and tethering, and your contract with them almost certainly explicitly grants them that right.
I would make the assumption that if Apple ever allows an official mechanism for unlocking phones it would only work on unsubsidized devices.
If it weren't for carrier subsidies, you wouldn't have locked phones, and this whole business of smartphones having draconian rules for third-party apps probably never would have happened.
If Apple actually sold unlocked phones, I might be ok if they were the only ones that allowed it.
As it stands right now, not only are all iPhones sold locked (in this country), but Apple's control extends to lots of devices that can't even talk to the cell network (iPods touch and iPads).
Having said, in order for unsubsidized phones to be economically viable the carriers need to start having pricing plans that omit the subsidy payments from the default monthly fees. Unless they completely eliminate subsidized phones that would mean that people could see what the subsidy cost is, which most providers really don't want customers to see (t-mobile has unsubsidized bring your own device plans, but I suspect a big reason for that is because they can't offer a subsidized iPhone, so they need to. Offer some plan to people who import them). I imagine doing something like that would require legislation telling cellphone providers they had to list subsidies as an itemized entry in bills. Independent of all the unlocking issues in this thread, that would probably be a very good thing for consumers.
I think a law like that was pasted in the last year or two in Japan, and I recall reading that it had a significant impact on consumer cell phone spending..
From a purely financial standpoint, there shouldn't be any need to lock phones just because of subsidies. Add an early termination fee to the contract, and you're good. It doesn't matter if you use it with other carriers, you either keep your contract with the original, so they still get your money, or you break your contract and pay them the remainder of the cost of the phone.
I think locking is more about collecting extra fees for things like text messages, overage, international rates (AT&T wants $20/MB for roaming internet in China!) and such. And thus why even an unsubsidized phone is locked. Subsidies are more a way to convince people to buy locked phones so they can collect this extra stuff.
I think some legislation as you mention would be a good idea. I'm not usually in favor of that sort of thing, but with only four major carriers in the country, with little differentiation between them, the cell phone market is close to an oligopoly.
Obviously as a customer how they structure their plans so they can recoup their subsidies should not be a concern you have to worry about, aside from them giving you ann ETF appropriately sized for your device. Verizon attempted to increase their smartphone ETFs relative to their normal phones. Customers screamed and Senators called for hearings, but based on everything we know about phone pricing from other markets it seems that the fair market value of high smart phones demands a larger ETF. Consequently they structure their pricing and lockout policy to (statistically) recoup it in other ways, and pickup whatever advantage they can as well.
That is a perversion of the pricing model that is probably brought on explicitly because customers do not understand the actual cost of their devices. Ultimately having unsubsidized phones with cheaper plans and ETFs large enough directly cover the device (even if it is larger than current ETFs) is probably a win for consumers, even those eho have to pay the ETF,u, but when users can't directly see how things are accounted for they don't properly perceive costs, and demand the wrong thing from carriers (cheap phones) which they carriers happily provide by screwing them in other ways ;-)
I imagine you probably don't tend to approve of government regulation as much as I do, but I don't see heat having only 4 carriers has to do with it. Even if one believes a marketplace of informed consumers will eventually pressure companies into doing the right thing, that still depends on the consumers having information. I think that telling companies that sell complicated aggregated products and serivces that they need to itemize their billing statements is hardly onerous, and likely result in better consumer choices in a lot of industries, even ones with healthy competition.
Also, the discussion on how to properly provide the possibility to run unsigned code/jailbreak/etc. is pretty pointless: while some of the "applications" you mention are advanced stuff, many would be useful for most people, and these people do require support; so it's a bit elitist demand these features for people who know what they are doing, the aim should be to provide them in a supported way to everyone (one counter-argument could be that Apple should make running unsigned code/etc. available to people who know what they are doing for them to have these features "in the meantime", but these "temporary" provisions have a tendency to remain forever).
Oh, and you ask for direct access to the GPS data? Imagine the GPS chip changes in a future model. Oh, I know you will update your application, but what about the gazillion developers who won't, or will do so very slowly? Any system that relies on completely cooperative third-party developers is doomed to fail.
Regarding the Senate hearings and such, I wonder how it would work to structure the subsidy like a loan instead of calling it an ETF. You pay $X for your phone, and the phone company loans you the remainder, the amount of which is listed on your bill. Each month, you pay $Y for service and an additional $Z to pay off the loan. Maybe people wouldn't get so upset about that... plus your bill would go down once you paid off the phone.
Pierre Lebeaupin: You're making what is IMO an artificial distinction between applications and system features. There's no reason an application couldn't provide most of those ideas on a more open system. Certainly pasteboard sync, macros, custom input methods, Tor, audio recording, and location/time based configuration changes can all be implemented as simple applications on a Mac. You appear to be begging the question here by assuming that "application" must mean what Apple has defined it to mean, and then saying that I'm stepping outside the box and thus don't qualify. Well, that's my whole point: Apple has put down some very narrow rules which are excluding a lot of useful things.
Regarding elitism, I think you misunderstand. I don't think such things should be reserved only for advanced users. I think they should be allowed for everyone. However, I'm in a very small minority here, and I know that position is hopeless. If given the choice between the current regime, and a regime which allows advanced users to run software of their choosing, well, the latter is way better than the former.
As far as GPS, I'm not a child, and I don't need a nanny. If I want to write software that depends on hardware features, that's my choice. It's not like Apple doesn't already provide data through CoreLocation that is unavailable on some devices: try getting altitude data on an iPod touch and see how far you get.
Of course, any chip which outputs NMEA (which is, as far as I understand it, all of them) will continue to Just Work with existing software.
This "Apple knows better than you" attitude is unbelievably irritating. Apple makes horrible choices constantly. I do not want to be beholden to Steve's idea of what's best for me.
Not sure how to change that... Perhaps if more and more developers put their apps on the Cydia Store...
I imagine the cellphone companies would structure the loans in such a way to discourage leaving early (either by discounting the interest rate so long ss you have an active plan, or making the balance due as a ballon payment if you discontinue your plan), but it would be a win for those of us who would just buy phones outright.
You have to walk into a store to request this unlock. They dont accept it over the phone or the over the net.
There is no reason I can think of that this couldnt be done for a jailbreak type unlock. The requirement to walk into a store raise the cost for the user and the store can inform him what it actually means.. And Apple knows the id:s so their support would know if a phone is officially jailbreaked.
I think some legislation as you mention would be a good idea. I'm not usually in favor of that sort of thing, but with only four major carriers in the country, with little differentiation between them, the cell phone market is close to an oligopoly.
Comments RSS feed for this page
Add your thoughts, post a comment:
Spam and off-topic posts will be deleted without notice. Culprits may be publicly humiliated at my sole discretion.