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.
GUI Prototyping, Linux Containerisation, Searchable Apple Text, and Infosec Wargames
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.
Worth the Blood, Sweat, and Tears?
Joshua Smith (@kognate) is a Lead Mobile Developer at iRx Reminder, frequent Cocoa Conference speaker and author of an upcoming book with O’Reilly on core data. We recently sat down to talk about core data and its complexities.
You can view the entire interview in the following video:
If Jenkins is good enough for Apple to use, why not give it a try yourself?
One of the pleasant surprises I learned last year at WWDC is that Apple uses Jenkins to automate their iOS app builds. Since we were already using Jenkins to do the same thing at the Day Job, it was a nice confirmation that we had taken the right approach.
However, until recently, getting Jenkins to fire off an Xcode build, bundle it into an IPA, and sign it correctly was a real pain. Thankfully, in 2012, a Jenkins plugin for Xcode integration was released. It can be installed directly from the Jenkins plugin management page, and once installed, gives you a new build step called Xcode that you can add to a build.