James Turner

James Turner, contributing editor for oreilly.com, is a freelance journalist who has written for publications as diverse as the Christian Science Monitor, Processor, Linuxworld Magazine, Developer.com and WIRED Magazine. In addition to his shorter writing, he has also written two books on Java Web Development (MySQL & JSP Web Applications" and "Struts: Kick Start"). He is the former Senior Editor of LinuxWorld Magazine and Senior Contributing Editor for Linux Today. He has also spent more than 25 years as a software engineer and system administrator, and currently works as a Senior Software Engineer for a company in the Boston area. His past employers have included the MIT Artificial Intelligence Laboratory, Xerox AI Systems, Solbourne Computer, Interleaf, the Christian Science Monitor and contracting positions at BBN and Fidelity Investments. He is a committer on the Apache Jakarta Struts project and served as the Struts 1.1B3 release manager. He lives in a 200 year old Colonial farmhouse in Derry, NH along with his wife and son. He is an open water diver and instrument-rated private pilot, as well as an avid science fiction fan.

Upward Mobility: Dig Out Your Tin-Foil Hats

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.

Read more…

Upward Mobility: Dear Apple, Please Stop Hogging All the Good Stuff

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.

Read more…

What Do the New iPhones Mean For Developers?

Sometimes earth changing moments come in fingertip-sized packages

Well, the media feeding frenzy that is an Apple product release press conference is over, and the whelmingness is definitely on the under, rather than over side. Part of the lack of drama is that, these days, it’s almost impossible for Apple to keep anything under wraps. There are just too many hands in the supply chain, too many carriers to coordinate a launch with, and too many opportunities for a stealthy cameraphone snapshot of a box or component. Add in patent and FCC filings, and your barber can tell you what’s going to be unveiled, at least a week or less from the event.

Read more…

Upward Mobility: Buddy System

This little XCode gem can handle all your plist needs

Sometimes it’s easy to forget that along with XCode, the iOS development environment also includes a ton of useful utilities that you can leverage to make your life easier. Many of them come along with the command line tools that you can install via the Downloads pane of the XCode preferences window.

Screen Shot 2013-09-06 at 8.30.55 AM
Read more…

Upward Mobility: If I Were King of XCode

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.

Read more…

Keeping Apps in the Air With TestFlight

Long a development tool, TestFlightApp wants to move into analytics

For most iOS developers, TestFlightApp has become the go-to tool when they want to distribute a development build to testers. For those not familiar with the site, you can register applications, and then upload IPA files signed with either a development or AdHoc profile, either manually or using a desktop app that integrates directly into XCode.

Once uploaded, your testers can be automatically notified via email that there is a new version of the app available, and download it directly onto their device without having to use iTunes. It can even capture device IDs for new users (or new devices for existing users), and export them for use in the Apple developer portal.

You can also add code to have the running app check in with TestFlight. You can add “checkpoint” flags, ask survey questions (“why did you come to this page”), and have console logs and crash reports automatically uploaded to the site.

The problem is, once you’re ready to ship a production version, you have traditionally had to turn everything off and make sure that the Test Flight library was not linked in to the app. This has meant that there was no way to capture crash data from customers running the app. But now that’s changing.

Recently, TestFlightApp announced that it was now OK to leave the library in copies of your app uploaded to the App Store, and to have the app check in with TestFlight. Why the change? Probably because it is needed to support FlightPath, their new analytics tool. FlightPath seems to want to be the Google Analytics of mobile, allowing developers to see how customers use their app and offering demographic data.

FlightPath is likely to be the path that TestFlightApp takes to start monetizing their service. TestFlightApp has always been free, but there has been no pronouncement about whether FlightPath will follow that same model. It is currently in an open beta, so we may have to wait and see what the pricing model for the final product is. Of course, by then, all those beta users will have become hooked.

One major caution for people intending to keep TestFlight in their production code, watch out for leakage of private data! Many test builds spit out tons of information to the console. At times, I’ve had everything going back and forth to a server dumping itself onto the log. If you don’t disable that in the shipping code, you could be accidentally capturing all sorts of sensitive data, including credit cards, HIPPA restricted information, etc. So make sure that you have compiled out (or disabled) anything like that in the production build (which you can test with an AdHoc profile.)

Upward Mobility: Black Magic Method Swizzling

Great hacks, great responsibility

This week, we’re going to depart from the basics, and talk about a piece of Objective-C black magic that, when used properly, can be a powerful tool. However, used incorrectly, it can cause devastation on a biblical scale. Let’s talk Method Swizzling.

Image that you have an app just about ready to go into the store, and your UI designer suddenly decides that all the UIButtons should use a different font.  Unfortunately, you have hundreds of them scattered over dozens of XIB files. Sure, you could go through and change each one by hand, but what happens if he changes his mind again?

Wouldn’t it be nice if you could programmatically force all the UIButtons in your app to use a new font? Maybe we can do it with a category? If we override the initWithCoder and initWithFrame methods of UIButton, we can call super and then set the font explicitly, right? Unfortunately, no, because super isn’t available in an overriden category method. But there is a way we can do it, using swizzling.
Read more…

Upward Mobility: Overly Defensive Programmer

Sometimes, the best defense is a good offensive core dump

By now, most meme-aware internet surfers have encountered Overly Attached Girlfriend  (and the Rule 63 counterpart, Overly Attached Boyfriend.) What isn’t as well known is that they have a brother, Overly Defensive Programmer (ODP, for short.)

ODP is a mobile developer who lives in the constant fear that the server-side folks are going to subtly change an API out from under him, making his app crash. To avoid this, he puts in code like this:

NSError *error;
NSDictionary *responseData =
     [NSJSONSerialization JSONObjectWithData:data 
                      options:0 error:&error];
if (error != NULL) {
   // All sorts of logging code, followed by returning 
   // from the call silently, swallowing the error
}
if ((responseData[@"payload"] != NULL) &&
    (responseData[@"payload"][@"objectId"] != NULL)) {
     self.objectId = 
       ((NSNumber *) responseData[@"payload"][@"objectId"].intValue;
}

We’ve all seen code like this. The developer didn’t want to accidentally cause a fatal error by trying to get the objectId parameter if the payload was missing, or to try accessing the objectId if it was missing. And if objectId is an optional field, this is totally the way to go.

The thing is, objectId sounds like it is probably a critical piece of data, without which the application will fail to operate properly. You want the application to crash if it goes missing, because that means it will crash during QA testing, rather than silently ignoring the problem and possibly malfunctioning in a way that QA misses.
Read more…

Upward Mobility: To Storyboard or Not to Storyboard

That is the question for iOS developers

Storyboarding was introduced in iOS 6, and it offers a way to consolidate all of your disparate Interface Building files into a single overarching whole. Although it’s tempting to jump on board and use it just because it’s the new thing, there are some things to keep in mind.

  1. Storyboards require you to make the jump to iOS 6; there’s no backwards compatibility for earlier versions. While this isn’t as much of a factor as it was a year ago, if you have legacy iPad 1 customers, you’re going to be locking them out of your app if you move to storyboarding.
  2. Having all your XIB files consolidated may sound good, but if you have a lot of them, you can end up with a new storyboard that’s so big that it is unwieldy.
  3. Storyboards are more than just a consolidation move; you also have to adopt a whole new programming style to move between your screens. Instead of explicit pushes and pulls off of view controller stacks or opening of modals, you are firing off segues that cause new view controllers to be created and transitions to occur.

The last point isn’t a bad thing per say. It’s a much more MVC-like paradigm: for example, where the overall controller knows what a transition means, and the individual views are only responsible for requesting a transition. It’s also much more like the way that Android does things. But it’s a different style of programming from traditional iOS UI development, and has a learning curve associated with it.
Read more…

Upward Mobility: A Web of Dependencies

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.