ENTRIES TAGGED "apple"
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.
Thanks NSA, you've spoiled mobile crowdsourcing for everyone else!
The continual drip-drip-drop of NSA secrets, courtesy of Monsieur Snowden, has provided many of us with a new piece of daily entertainment. But as much fun as it can be to see No Such Agency’s dirty laundry being aired in public, it has a real and lasting affect on how consumers are going to see interacting with their mobile devices. Specifically, it could provide a major setback to the new universe of applications that use crowdsourced data.
There are lots of examples of highly successful apps that are essentially just aggregations of user-provided data. Yelp comes to mind immediately, but another good example is Waze. In both cases, users are providing the service with some fairly private information, where and when they were at a particular location. Waze is even more sensitive, because it is also recording your speed, which might be a bit higher than the posted limits.
Forget Touch ID, we're still waiting for access to Siri!
As I mentioned last week, the new Touch ID feature of the iPhone 5S is (at least for the moment) only usable by Apple created software. What this means is that a developer can’t take advantage of the feature to authenticate a user inside an application, it can only be used to unlock the phone and authenticate to iTunes.
This continues a troubling trend we’ve seen with Apple lately. Nearly two years after the release of Siri, the voice UI is still locked out for anyone but Apple and their chosen partners (such as Wolfram Alpha.) I understand that opening up a technology for third party usage takes planning and work, but twice in a row now, Apple has released what could be a transformative technology, and left the developer community out of the picture.
Even a great development environment has room for improvement
As the not-so-mysterious September 10th Apple event approaches, it’s widely anticipated that the final version of iOS 7 will be released at the same time. Along with it will come a new version of XCode. While XCode is a pretty awesome development environment (in my opinion, at least), there are a few things that just irk the heck out of me. So, if anyone at Apple happens to be listening, here’s my laundry list of things I’d like to see fixed.
The App Store model has increased the uncertainty of the software release process
The recent unavailability of the Apple Developer’s Portal just underscores how increasingly dependent developers have become on third parties during the software lifecycle. For those who are not following the fun and games, the developer.apple.com sites, which include much of the functionality needed to develop Mac and iOS applications, has been unavailable for more than a week as of this writing. Although iTunes Connect, the portal used to actually deploy apps to the App Stores, has remained available, the remainder of the site territory has been off-limits. This is all thanks to a security intrusion (evidently by an over-zealous researcher.)
The App Store model has fundamentally changed how software is distributed, mostly for the better (IMHO), but it has also removed some of the control of the release process from the hands of the developers and companies they work for. As I have spelled out previously in my book on iOS enterprise development, the fact that Apple has the final say on if and when software goes into the store has required more conservative release timelines. If you want to release on the first of September, you need to count back at least two weeks for “gold master”, because you need to upload the app, potentially go through a round of rejection from Apple, and then upload a fixed version.
Android apps don’t suffer from this lag, because most of the Android stores don’t do any significant checking of the applications uploaded to them. The Devil’s Deal that Apple developers have made with Apple is that in return for the longer wait time to get apps in the store (and having to follow Apple’s rules), they get a de facto seal of approval from Apple. In other words, it is assumed that apps in the iTunes store are more stringently policed and less likely to crash or do harm (deliberately or else-wise.)
The current downtime has brought that deal into question, however. Suddenly, developers who need new provisioning certificates, passbook certificates, or push notification certificates find themselves with nowhere to go. Even if iTunes Connect is available, it doesn’t do you any good if you can’t get a distribution certificate to sign your app for the store. I’m sure that there are developers at this moment who have had their finely tuned release strategies thrown into disarray by the in-availability of the developer portal.
Being essentially at the mercy of Apple’s whims (or Google’s, for that matter) can’t be a pleasant sensation for a company or individual trying to get a new piece of software out the door. The question that the developer community will have to answer is if the benefits of the App Store model make it worth the hassles, in the long run.