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.
Remember, even a failure can serve as an example of what not to do
The first highly visible component of the Affordable Health Care Act launched this week, in the form of the healthcare.gov site. Theoretically, it allows citizens, who live in any of the states that have chosen not to implement their own portal, to get quotes and sign up for coverage.
I say theoretically because I’ve been trying to get a quote out of it since it launched on Tuesday, and I’m still trying. Every time I think I’ve gotten past the last glitch, a new one shows up further down the line. While it’s easy to write it off as yet another example of how the government (under any administration) seems to be incapable of delivering large software projects, there are some specific lessons that developers can take away.
Remember, an idle keyboard is the devil's playground
For the first time in eighteen years, 700,000 Federal employees are sitting idle. Among them are software engineers working throughout the government, who may now find themselves with nothing to do and lots of time to do it. With that in mind, here are five worthwhile activities to while away the days and avoid watching CSPAN.
1) Learn a new language or platform. When you’re working on big government projects for years at a time, your skills can go stale. If you’ve been grinding out Enterprise Java code, learn to code Android apps. If you’ve been mired in C++, try your hand at functional programming in Erlang or Scala. C# gurus can give Objective-C a try.
Whatever you learn, you can bring it back as a new tool in your belt when you get back to work. Not only can it give you a fresh perspective on your current work, it can lead to a lateral or forward shift in your career.
There's no such thing as perfect security, and we should stop sacrificing the good for the perfect.
I’ve had a day or two to play with my new iPhone 5s, and the fingerprint scanner is one of the nicer things about it. I like the added security of being able to unlock it with my fingerprint, because I was one of those people who could never be bothered to have a passcode on it before.
Of course, the news of the day is that some inventive folks in Germany have managed to unlock one of the phones by lifting a print from the glass of the display and using a variety of fairly low tech steps to create a false thumbprint from it. This should come as no surprise to anyone who understands how fingerprint sensors work. The 5s does more than some to prevent spoofing, but pretty much no fingerprint scanner is impervious to a determined attack.
What is sad to see is the conclusion that these hackers (and the press) have drawn. “Fingerprints aren’t a good method of securing data. You should never use something that you can’t change as a password. Always practice two-factor security policies.” Of course, if someone really wants to break into your phone, and is willing to expend the effort to do it, they can. If someone wants to break into a typical house, they can. If someone wants to steal your car, they can.