Here's a couple of Big Questions that may take generations to answer
I spend a lot of time on this blog focused on the very short term issues regarding mobile. Is Apple better than Android. Will Blackberry survive? What’s the best strategy in Candy Crush? But sometimes you need to pull up to 30,000 feet and look at some of the bigger questions, such as:
What are the real long-term health effects of cell-phones? Wearable mobile technology has only been around for a few decades, and in true widespread use for less than 10. Are there health risks to having an RF transmitter that close to your head for long periods of time? More importantly, are there effects on offspring to carrying a two watt transmitter in close proximity to your reproductive organs for 18 hours a day? This is even more significant for women, where the effect would be cumulative from birth, since eggs are carried for a woman’s entire lifetime. Short term studies have shown mixed results, but lifetime exposure hazards are hard to gauge when the technology itself is so new. We really didn’t understand the cost to society of lead in our gasoline until half-a-century after its introduction. A decade of data on cell phones is unlikely to hold all the answers to the scope of the potential problems.
Brace yourself: Address exhaustion is coming
IPv6 is the global warming of the computer industry, an impending disaster that most folks don’t seem to be taking as seriously as they should be. We’re well into the exhaustion phase of the IPv4 address space, but most ISPs are still dragging their heels on supplying the wider protocol to the end user.
Getting apps into the store is a non-deterministic process
One of the major topics of my Enterprise iOS book is how to plan release schedules around Apple’s peril-filled submission process. I don’t think you can count yourself a truly bloodied iOS dev until you’ve gotten your first rejection notice from iTunes Connect, especially under deadline pressure.
Traditionally, the major reasons that applications would bounce is that the developer had been a Bad Person. They had grossly abused the Human Interface standards, or had a flakey app that crashed when the tester fired it up, or used undocumented internal system calls. In most cases, the rejection could have been anticipated if the developer had done his homework. There were occasional apps that got rejected for bizarre reasons, such as perceived adult content, or because of some secret Apple agenda, but they were the rare exception. If you followed the rules, your app would get in the store.
Why innovate in the product space, when you can leech money instead?
It is with some amusement that your humble servant read this week of Microsoft’s lucrative business licensing their patents to Android handset makers. How lucrative? Evidently, over two billion dollars a year, five times their revenue from actual mobile products that the company produces. What is harder to discover, unless you do a lot of digging, is what the Android vendors are actually licensing. You have to dig back into the original suit between Microsoft and Motorola to find a list of patents, although they may have added to their portfolio since then through further acquisitions. The thing is that, unlike many parts of the software industry, the cellular portion actually has some valid patents lurking around. Cell phones have radios in them, and there are continual improvements in the protocols and technologies used to make data move faster. As a result, it is a perfectly reasonable assumption to make that Microsoft has acquired some of these cellular patents, and is using them as a revenue stream. Unfortunately, a look at the Motorola suit patent list tells a different story. Read more…
Mobile Payment is going to take a lot of cooperation by a lot of competing interests, or a clever end-run
There was a time when the two big unsolved puzzles of online finance were micropayments and mobile payments. Micropayments were a problem because no one seemed willing to make sub-dollar transfers economically viable, while mobile payments had a chicken-and-egg solution / vendor paradox. Sites like PayPal and Square seem to have finally resolved the micropayment issue, as are more out-of-left-field ideas like Bitcoins. Mobile payment is still a morass of competing solutions, however.
For a while, Near Field seemed to be the sword that would slay the dragon, but Apple’s continual refusal to adopt the technology would leave a big segment of the mobile market out of the play. Even if someone comes up with a new point of sale (POS) terminal leveraging the more universal Bluetooth Low Energy, the real challenge isn’t the hardware. The problem is getting dozens of POS vendors and all the banks that issue cards to sign onto a new standard, and getting enough stores and retail venues to adopt it. Chicken and the egg once again.
It's much easier to change an iPhone's case design than to retool an entire ecosystem of apps
As with every Apple iOS release, iOS7 started to become a serious item for developers at the WWDC held the summer before the release, when all the ins and outs of the new capabilities start to be made available to the development community under NDA. In most cases, the technologies that are announced fall into two broad categories: new toys and better ways to do existing things.
New toys are always seen as a positive, because they don’t tend to require anyone to change anything in existing code unless they want to, or need to take advantage of the new capabilities. Examples of this have included Storyboards and Autolayout. If you wanted to use ‘em, you could. If you liked things the way they are, no problem either.
Get ready for a new generation of position-aware apps
Fans of near field communications payment solutions were, yet again, disappointed when the new batch of iPhones failed to include NFC in their list of features. While it might indeed be nifty for iPhone users to be able to join the Google Wallet revolution, another game-changing technology that Apple has launched has largely gone unnoticed. That would be the iBeacon framework built into iOS7.
iBeacon leverages Bluetooth Low Energy (part of the Bluetooth 4.0 standard), which has been incorporated into iPhones since the iPhone 4S. There are already a ton of applications using Bluetooth LE, notably the gaggle of Kickstarter-funded “find your lost keys” devices that use a small BLE dongle. What’s new is the framework, which allows applications to determine proximity to BLE beacons simply, and even when the app isn’t running. And BLE beacons are relatively cheap, you can get three of them for $99.
What is Apple going to stick on our wrists?
By all accounts, we won’t be seeing the iWatch until sometime next year. This is giving the press lots of time to speculate about exactly what the device might be. Since I can wildly speculate as well as the next tech pundit, I thought I’d take a shot myself.
To start, we can pretty safely say what the iWatch won’t be, and that’s a standalone cellphone. As clever as Jony Ive is, he has yet to become master of the laws of physics, and the limiting issue for cellphones is the size of the battery. Most of the actual bulk of a modern phone is the battery, and even if an iWatch uses a power-miserly processor and display, the cellular radio itself is going to put too much of a drain on the device to make it practical. Consider that the Galaxy Gear (which is trying to steal the iWatch’s thunder by getting to the market first) lasts about a day between charges, and has no phone inside it.
More Lessons from the Collapse of healthcare.gov
Last week, I wrote in some detail about some of the specifics of how the Federal healthcare portal seems to have violated basic principles of good software delivery. Now I want to talk a bit about the more general factor that I think led to all those cut corners and shoddy deliverables.
One of the oldest and shortest jokes in the computer industry is “Time. Money. Features. Pick any two.” To some extent, you can swap quality out for features, because poorly delivered functionality is essentially non-existent functionality. In almost all commercial software projects, time and money both end up being the parts that give in the end. In other words, the original feature set almost never gets cut, but the project goes over budget and delivers late.