All of that legislation and bluster, however, isn’t going to solve the fundamental problem that produced the practice of locking devices in the first place: handset subsidies.

There’s a reason why carriers lock phones. They’re heavily discounting the cost of most devices, which is why you can get a $500 smartphone for $100 and many mid-range and low-end handsets for free. Carriers make their money back through monthly subscription fees that factor in those subsidy costs. For carriers to get the full value of the phone back, subscribers need to finish out their contracts, and locking devices to their networks functions as their insurance policy. It’s a hell of lot easier than repossessing phones.

The bottom line is most consumers don’t really own their phones. They’re mortgaging them. Just like you can’t sell your home without paying off your bank loan, carriers don’t want you selling your phone or taking it to another carrier without finishing your contract and paying off your handset loan.

Thus, we’re left with the locking mess, which leads to all of the problems pointed out by locking’s critics: Having to jump through hoops to get your carrier to unlock a phone when your contract is up, the inability to use another carrier’s SIM card when traveling overseas, and the difficulty of building a resale market for phones when the majority of devices are locked.

Why unlocking phones doesn’t solve the problem

Making it legal and easy to unlock phones might seem like an easy solution to this problem, but I guarantee you carriers will find some other way to protect their investments. Carriers could require deposits, implement some kind of collateral fee, institute more onerous contract restrictions, or they could simply raise prices. If carriers start losing money when customers skip out on the contracts, you can bet the customers that remain will have to make up the difference.

I’m not saying it’s right. I’m just saying that in this messed-up subsidy system, everyone is trying to protect their own interests. Consumers will try to unlock their phones, and carriers will try to stop them.

If we get rid of subsidies completely, though, all of those conflicting interests go away. Once you separate the service from the device, carriers have no interest — and no right — to lock devices. You may still be under contract, but since there is no subsidy recovery fee bound up in your monthly bill, carriers could care less what you do with your device.

Of course, paying full price for your phone is an expensive proposition. An unsubsidized iPhone 5 costs between $649 and $849, as opposed to the $200 to $400 most carriers charge with contract. But in the long run buying your phone up front will probably save you money. T-Mobile has been a trailblazer in this area, charging cheaper monthly rates for voice and data if you don’t opt for a phone subsidy. What’s more, once subsidies are gone, handset makers will be able to sell their wares directly to consumers, which could lead to a greater variety of devices and more price competition in the device market.

Ultimately, mobile voice and data rates are so high because our phones are so cheap — artificially cheap. If we reverse that equation, we wind up with cheaper subscriptions, more choice and phones we can do with as we please.

What can you do with an unlocked phone?

Unfortunately, having an unlocked device doesn’t leave you with too many options in the U.S. If you travel internationally with a GSM-capable phone you can plug in a local carrier’s SIM card and pay local rates. But in the U.S. itself there isn’t much mobility between carriers.

U.S. operators are split between GSM and CDMA camps, and while it is possible to activate a Verizon phone on Sprint’s network or bring an AT&T device to T-Mobile, there’s no guarantee that you’ll have to access every network or service they offer. U.S. carriers don’t just use different radio technologies, they use different spectrum bands. The band fragmentation problem got even worse with the introduction of LTE.

But there are signs that things will get better. T-Mobile is in the process of overhauling its network, aligning its 3G bands with those of AT&T. In 4G, we’re starting to see some LTE network convergence around the Advanced Wireless Services (AWS) band. We’re even seeing more dual-mode GSM-CDMA devices making their way into the market.

With emerging smart antenna and radio module technologies, handset makers will soon be able to pack a dozen bands into a single device. Eventually we might even see a universal phone in the U.S. that can work on any carrier’s networks, no matter what combination of technologies and frequencies they use. And if that point we’re no longer weighed down by subsidies, contracts or locked devices, consumers will be able to switch to any operator at their whim. That’s not a bad choice to have.

Mortgage image courtesy of Shutterstock user Stuart Miles; Smartphones image courtesy of Shutterstock user Reno Martin; SIM cards image courtesy of Flickr user mroach

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• CES 2012: a recap and analysis
• The future of mobile: a segment analysis by GigaOM Pro
• Mobile first-quarter 2013: analysis and outlook

The uptake of Android 4.0 and its sub-versions of late has been quick. In October, I saw that 1 in 4 devices visiting Google Play used Android 4.0 or better. At that time, I suggested that we’d see half of all Androids use recent versions of software within four to six months. We’re not at the halfway mark yet, but it’s only been four months. With the acceleration of phones and tablets running newer software, I won’t be surprised to see us reaching the tipping point next month.

Clearly helping this phenomenon is Android’s changing pace. It has slowed over the past year or so, and that’s a good thing. It means that Android is more on par with iOS and other platforms than ever before. That’s part of the reason some prominent long-time iPhone users are now checking out Android — listen to our latest podcast to hear more on that topic, because there are other reasons as well.

Hardware makers have also “caught” up to the software changes. Even after Android 4.0 arrived in late 2011, it took a good six months for phones to ship with a recent version of Android. By and large many of these now ship with Android 4.1 and not Android 4.2, but the differences between the versions aren’t that great. If the average consumer were to compare an Android 4.1 phone to one with Android 4.2, it’s safe to say they’d be hard pressed to tell the two apart.

The feature differences brought by distributed Android software updates has been a key target for iOS users when looking to criticize Android. These points have definitely had merit; particularly early on in Android’s life-cycle. But I’d argue that Google’s issue has largely diminished and it’s really not that different on iOS; it’s just handled differently.

Some iOS features found in software aren’t applicable to older devices and yet, these are reported as having the same version of iOS as devices that can use the new features. The last three iPad models Apple has produced can run iOS 6, which includes Siri, for example, but only Apple’s third- and fourth generation iPad’s can actually use Siri; different code is actually pushed by Apple to different devices, yet all have the same public version number.

Regardless of which platform you use, this should help Android developers target more devices for mobile apps. And they shouldn’t have to worry as much about version numbers or supported API levels as more Androids run newer versions of the platform.

This story was updated at 2:18 pm to correct the point about iOS 6 compatibility with iPads. Originally, the post incorrectly stated that all iPads can run it.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Analyzing the wearable computing market
• Is Android broken and if so, will Google fix it?
• CES 2012: a recap and analysis

However, these services all have something in common: they test the apps on real devices. And they rightly advertise the fact, because they want to demonstrate the superiority of that method over the standard emulator found in the Android SDK. But the question is, is this approach always necessary?

TestObject, a German startup that this morning announced €1.1 million ($1.47 million) in funding from the Investitionsbank Berlin and S&S Media, would say not. The outfit is planning to use that cash partly to build up a bank of real devices later this year, but in the meantime it’s approaching the task differently.

“At the moment we’re running on virtual devices,” co-founder Hannes Lenke told me. “You can upload your application and see a device in the browser and just record a test, and we play the test back on multiple devices in multiple situations – with a good internet connection, a not-so-good connection, higher screen resolutions and so on.”

Keeping it cheap

What TestObject is doing is effectively to host Google’s Android emulator and automate testing on it across different device profiles. The efficiency benefits are clear – features include the ability to automatically run old recorded tests on new versions of the app, for example – but it still begs the question of why a developer would choose to do this rather than test across real smartphones and tablets.

The answer, according to Lenke, is cost. Because the service is still in beta, its actual pricing is yet to be determined, but even when TestObject steps up to its real-device competitors the company intends to maintain its virtualized-device service as a cheaper second option for early-stage testing.

“Real devices are more expensive. What we say is that virtual devices are 90 percent reliable,” Lenke said. “Our customers know 90 percent that their app will work on these devices, but if you want 100 percent reliability you can also test your app on real devices.”

The other big difference between TestObject and the majority of its competitors lies in its pricing model, which is pay-per-use rather than subscription-based — in that sense, it’s more of a genuine cloud outfit than most in this space. With that and its two-pronged approach to testing, the company may find itself able to stand out.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Survey: How apps can solve photo management
• Analyzing the wearable computing market
• Is Android broken and if so, will Google fix it?

Clearly, a large number of devices are still running Android 2.3, also known as Gingerbread. I can think of two reasons. First, the software arrived in Dec. 2010, with new handsets launching in 2011 using the software; some consumers that bought those phones haven’t yet upgraded. Second, handset makers have been slow to push out updates to Android 4.0 for these devices as the hardware has cycled since then. We’re now in the midst of higher-powered, more capable smartphones with faster dual- and quad-core processors. These phones are starting to launch with Android 4.0 or 4.1.

As an Android user for the past three years, I won’t try to defend the software version fragmentation issues that has affected Android to date. Simply put: I can’t. And I’ve called for the parties involved to fix the problem. But Google is closer than ever to resolving or minimizing the issues. Why? Because Android 4.0 — and its follow up, Android 4.1 — is, at least in my opinion, up to par with Apple’s iOS software. The user interface is now intuitive, the software is more stable than ever, and it performs well on quality hardware.

At this point, the amount of change in Android going forward is likely to be far less than it was while Google played “catch up”: Version after version of tweaks that brought constant change for all involved. That change is slowing down and both hardware makers and developers can take advantage of the more relaxed pace of change. My guess: In four to six months, the majority of Android devices are running on Android 4.0 or better. And I anticipate the next version of Android to introduce far less change and be easier to get on more devices.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Is Android broken and if so, will Google fix it?
• CES 2012: a recap and analysis
• Survey: How apps can solve photo management

Called Advanced Communications Suite (ACS), the platform is both a developer tool as well as an enterprise app store of sorts. AT&T is populating ACS with bunch of business communications apps already built by Twilio customers. They range from appointment reminder services; mobile polling and surveying software; ad hoc workgroup communications clients and geo-tagged messaging apps. What they all have in common is they tap into AT&T’s network APIs.

AT&T business customers can buy those apps through the ACS portal, but more tech-savvy customers can build their own using Twilio’s tools. For instance a large enterprise developing its own internal sales force collaboration tool could use the APIs to allow work group members to immediately initiate voice calls to each other with a touch of a button. Or a corporate calendar app could generate automated company-wide SMS alerts for important events.

The biggest problem with these carrier network API programs is fragmentation. AT&T’s APIs and policies could be completely different than Verizon’s, making cross-carrier development difficult if not impossible. By targeting the enterprise, AT&T greases the wheels a bit for developers since many businesses select a single or small subset of carriers to work with.

AT&T also solves the cross-carrier problem in part by working with Twilio, which has built its business model on developing a common development platform bridging all carriers’ networks. To get its SMS services to work, Twilio hooked into the SMS APIs of more 1000 operators in 150 different countries.

AT&T claims ACS will be network neutral. “ACS will offer cross-carrier enablement, meaning apps from the ACS portfolio are free to run on virtually any network,” AT&T said in its announcement. It didn’t offer more details, but that could mean Ma Bell and Twilio are striking up deals with other operators. Or it could have a far more revolutionary implication: AT&T could become an over-the-top provider on its competitors’ networks. There’s certainly a precedent for this. T-Mobile offers its own VoIP service, Bobsled, to anyone with a smartphone.

AT&T also plans to make more APIs available through ACS, starting with video. It’s already started offering access to its Watson voice recognition APIs through a separate program. If voice commands and natural language understanding become part of the ACS toolkit, developers could build some very powerful apps.

The company has been promoting Watson’s capabilities heavily in recent months as it tries to draw interest away from speech-recognition titan Nuance Communications. On Wednesday AT&T also launched its iPhone and iPad remote control app, which uses voice commands to search for programs and channels as well control basic set-top box and DVR functions.

Image courtesy Flickr user Horia Varlan.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• CES 2012: a recap and analysis
• Report: How Mobile Cloud Computing Will Change Tech
• A look back at mobile in Q1

Here’s how Amazon explains it:

“While it is easy to support optional APIs and device capabilities within a single binary, you may decide that it is easiest for your apps to generate different binaries for the Kindle Fire and Kindle Fire HD.   For each title, you can now offer separate APKs for Kindle Fire, Kindle Fire HD 7″, Kindle Fire HD 8.9″, and general Android (all non-Amazon) devices. “

This type of feature is needed now more than ever for Amazon. Why? Because instead of just supporting various Android phones and tablets with different hardware and screen sizes, the company has recently expanded its own line of devices. The original 7-inch Kindle Fire is now supplemented by a higher resolution Kindle Fire HD in both 7- and 8.9-inches.

Developers could simply try to manage the variances from within a single application so that their software automatically works in the proper combination of resolution and screen size, but Amazon is now supporting the ability to create apps specific to the different hardware combinations. This could mean vastly better tablet apps for the higher resolution Kindle Fires similar to the improved iPad apps that iOS developers made instead of scaled-up iPhone software.

Amazon says this new device targeting support helps in three ways:

• Better search relevancy for your app. Instead of having multiple apps (i.e. an HD version and a SD version) for a single title, your app’s Customer Reviews, page views, downloads, etc. are consolidated to a single app—pushing your app up in search and relevancy rankings.
• Reduced customer confusion. Customers won’t be confused by multiple device-specific versions of your app.
• Device-specific feature optimization. You can tailor your APK for screen size and density, OpenGL compression format, and API version.

From a consumer standpoint, this should improve the Amazon Appstore for Android experience, and not just on Amazon’s Kindle Fire. Any Android device that has the Appstore loaded will benefit, which could in turn lead to more app sales for developers along with additional app revenues for Amazon. That’s important as Amazon has previously sold its Kindle Fire near cost, if not below, in order to get consumers to make Amazon-related purchases.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Is Android broken and if so, will Google fix it?
• Analyzing the wearable computing market
• A look back at mobile in Q1

Apple’s official iPhone 5 specs show two GSM models and one CDMA model, with the critical differences between them being which global LTE bands they support. As we’ve pointed out before, the huge number of global LTE bands means that Apple can no longer make a single device and expect to capture a majority of the world’s networks. So Apple is now following the same strategy as Samsung, Nokia and other smartphone makers: tailoring its devices for specific carriers and markets.

Oddly the CDMA model appears to be the global version of the device. It not only has the support for the most LTE bands (including Japan, Korea’s and some of Europe’s 4G bands along with Verizon and Sprint, it also has support for global GSM and HSPA+ frequencies.

The two GSM models aren’t just regionally focused, one is targeted specifically at AT&T. The LTE bands in one GSM version line up exactly with AT&T’s 4G networks, a configuration that no other operator in the world uses (though half of its bands will also support Canada’s LTE networks). The other GSM model appears to be targeted at Asian carriers, but has additional support for the 1800 MHz bands used by UK’s Everything Everywhere and a few other European operators. All of those bands are supported in the CDMA version, but Apple is likely looking to cut down on its radio components cost by targeting this phone specifically at particular regions.

What’s most surprising though is that Europe’s primary 4G frequency bands 2.6 GHz and 800 MHz aren’t supported in any of the three devices. That means that most European operators deploying LTE next year will have to wait for the next generation of the device to offer 4G services over the iPhone.

Here are the detailed specs if you want to interpret them for yourselves:

• GSM model A1428*: UMTS/HSPA+/DC-HSDPA (850, 900, 1900, 2100 MHz); GSM/EDGE (850, 900, 1800, 1900 MHz); LTE (Bands 4 and 17)
• CDMA model A1429*: CDMA EV-DO Rev. A and Rev. B (800, 1900, 2100 MHz); UMTS/HSPA+/DC-HSDPA (850, 900, 1900, 2100 MHz); GSM/EDGE (850, 900, 1800, 1900 MHz); LTE (Bands 1, 3, 5, 13, 25)
• GSM model A1429*: UMTS/HSPA+/DC-HSDPA (850, 900, 1900, 2100 MHz); GSM/EDGE (850, 900, 1800, 1900 MHz); LTE (Bands 1, 3, 5)

The last time Apple did this was when it launched the CDMA version of the iPhone 4 for Verizon, but shortly afterwards it combined both versions into a single global iPhone. But the implications of this strategy could have huge implications for the industry at large. If Apple has gotten over its reluctance to split the iPhone supply chain, it could mean it could start making iPhones for carriers it has previously ignored such as China Mobile, NTT DoCoMo and, yes, even T-Mobile.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• CES 2012: a recap and analysis
• Mobile 2012 and beyond
• The future of mobile: a segment analysis by GigaOM Pro

But there are signs that at least some carriers are willing to play nice with one another. In France, the big three national operators Orange, Bouygues Telecom and SFR have formed a consortium called YouConnect that exposes an API that allows m-commerce apps to auto-fill in purchase information (name, address, credit card, etc.) from carrier subscriber databases.

Developers don’t have to tap into three separate APIs. They don’t have to negotiate three separate business deals with each operator. They build to a single API and  they single set of revenue share terms.

Three carriers aren’t 400. Universal carrier APIs was the Wholesale Application Community’s goal before its inevitable demise, but those three carriers represent the vast majority of France’s mobile subscribers. So far YouConnect only has one partner, online overstock retailer Vente-Privee.com, but the consortium is bring on other e-commerce companies soon, according to Alcatel-Lucent, the vendor who manages YouConnect’s APIs.

Achieving a truly universal carrier API framework is going to take a lot of time, but that doesn’t mean that smaller groups of carriers can’t band together, said Laura Merling, Alcatel-Lucent SVP of application development platform and strategy. Country-wide cooperation in particular makes sense as there are many developers that are only thinking within the confines of national borders. Think regional retailers or national airlines and rail providers.

“You’re going to see earlier results with a more focused strategy,” Merling said. “Three other countries have already expressed interest in joining YouConnect.”

The Alliance of Telecommunications Industry Solution is another organization trying to come up with a set of core network APIs for developers. While I initially questioned whether ATIS could succeed where WAC failed, the Alliances’ marketing VP Lauren Laymen told me that the ATIS’s ambitions are much smaller – and far more realistic — than WAC’s. As a North American focused institution, ATIS isn’t trying to create a global API framework for consumer development. It’s trying to develop useful APIs for vertical business markets like healthcare and government, which don’t need to cross borders and span carriers as much as they need to access reliable and highly secure interfaces.

This week Alcatel-Lucent launched its own API consultancy and professional services business with the aim of helping carriers develop and manage common interfaces. Like API specialists Apigee, Aepona and Locaid, Alcatel-Lucent is yet another option in an increasingly fragmented carrier development market, though the Franco-American vendor has the advantage of actually building the network infrastructure it’s trying to expose to the outside world.

Merling, however, said that those separate companies aren’t necessarily working at cross purposes. No matter whom a carrier selects to manage its APIs, technically they’re all gravitating toward standards established by organizations like the Open Mobile Alliance. Alcatel-Lucent is already in discussions with U.S. operators – each of whom work with different API enablers — to develop frameworks like YouConnect, Merling said.

Phones image courtesy of Shutterstock user Reno Martin

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Sector RoadMap: Content personalization in 2013
• Mobile 2012 and beyond
• Cloud computing infrastructure: 2012 and beyond

The WAC seemed like a good idea when it was founded in 2010. Carriers being were cut out of the exploding application market by smartphone makers, and instead of just playing cutthroat defense and start blocking apps, carriers came up with the idea to actual offer developers something of value — their network APIs — to entice them into their app portals and into revenue sharing deals.

The WAC intended to create a run-time environment, which could support HTML5-based apps that could run on any phone from the most sophisticated Android device to the lowliest feature phone. Those apps would then tap into carriers’ location, presence and billing APIs, making them significantly more useful especially on feature phone platforms. The carriers were promising something unheard of the mobile industry: build an app once and have work anywhere and on everything.

Well, that was a pipe dream. WAC’s failure wasn’t just brought on by carriers’ ingrained inability to cooperate with developers. Carriers couldn’t even cooperate with one another. The organization had just gotten off the ground when it dropped this bombshell: While it would create a common set of technology APIs for carriers it would take no steps toward creating a common distribution framework. Sure, a dev could create a WAC app that would work on any operator’s network, but it would have to negotiate individual deals with individual carriers to gain access to its APIs and then work out a revenue sharing model with each.

Imagine if ever iPhone developer wasn’t just required to submit its app to Apple for approval, but also to 200 separate operators. Apple’s smartphone revolution would have gone nowhere. That’s exactly what the carriers were asking for though, and it just shows how they had learned nothing from the demise of their walled garden content stores. WAC was pretty much doomed from the get go, as my colleague Colin Gibbs wrote when the initiative first launched.

Two years and little activity later, carriers seemed to have realized their initial mistake. In February, a group of nine carriers including AT&T, Telefonica and Deutsche Telekom implemented WAC’s first common payments API. In addition to standardizing their interfaces, those nine pushed out a common distribution and billing platform so a developer could submit a single app to a group of carriers in one go.

That step came a bit too late, though, as enthusiasm for the WAC had dwindled. Those nine operators were only a handful of the community’s initial 48 members, and a fraction of the total global carrier base. Why would a U.S. developer build a WAC-based app, knowing it would work on AT&T, but not on Verizon Wireless or Sprint to say anything of Vodafone’s networks around the world?

So what remains? The GSMA may try to pick up the pieces of the initiative, but I doubt it will have much luck. Apigee is a smart company that has done wonders in helping carriers like AT&T simplify their byzantine and proprietary APIs, but for Apigee to become the common link between carriers and developers, then more than a handful of the latter will need to work with the company. The GSMA has agreed to act as go-between among its carrier members and Apigee, but its members may have their own ideas.

Many of WACs most ardent supporters are now backing Mozilla’s HTML5-based Firefox OS. Verizon, Vodafone, China Mobile and Softbank — which collectively have well over a billion subscribers, have been working on their own widget-based app platform for years in a project called the Joint Innovation Lab. When it comes to apps, it’s a fragmented, fragmented world, and carriers seem to like it that way.

Feature image courtesy of Shutterstock user Rebelf

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• The future of mobile: a segment analysis by GigaOM Pro
• Where new opportunity lies in the mobile operating system space
• Takeaways from mobile’s second quarter

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• CES 2012: a recap and analysis
• Who and what to watch in the new era of the living room
• Tablet market to hit over 377 million units by 2016