Using Third-Party Code in iOS Development

Last weekend at CocoaConf DC, there was one refrain that really caught my attention: be wary third-party code. Avoid CocoaPods. Do things yourself. Speakers said it. Conference attendees said it. It seemed to be everywhere.

I don’t buy it.

Developers on other platforms thrive by making good use of third party, open source code. The Ruby community is a great example. You can find a gem for just about anything. Some are great, some are terrible, and a lot lie somewhere in between. But the existence of all these gems means you don’t have to re-invent the wheel for every new application. You can spend your time focusing on the things that are unique to your app.

Unfortunately, there seems to be a fairly deep cultural difference in the Objective-C community that rejects third-party code.

There are some key differences between writing a web app in Ruby and an iOS app in Objective-C that may account for the do-it-yourself sentiment. Most prominently, web developers have control over the system their app will run on. Servers can be configured with the exact OS and language versions that the app was designed and tested on. If developers keep the OS, language, and gem versions constant, the gems should continue to work correctly. (That said, web developers certainly use things like jQuery that rely on the browser, which changes under them all the time.)

On iOS (or the Mac), developers have much less control over the OS version that their apps run on. Sure, you can set a minimum requirement, but that doesn’t stop things from changing in the future. If Apple makes major changes in iOS 8, it could break third-party code. That lack of control over the complete environment does make third-party code a little more prone to headaches in Objective-C.

So should that dissuade iOS and Mac developers from using third party code? I don’t think so. Changes in the OS could just as easily break code that you wrote yourself, and when that happens, you’re on the hook to fix it yourself. Moreover, good third-party code shouldn’t break in catastrophic ways. Well-designed, well-maintained code should keep up with major OS releases. Apple gives ample time for beta testing before major updates, and rarely removes functionality without warning.

Just as on other platforms, the key to taking advantage of third-party code is to use it carefully and judiciously. Look first to widely-used, actively-maintained libraries. Plan how you use third-party libraries so you could replace them if necessary. Of course, don’t rely on them for everything. There’s always a time to do your own work. The power of sharing code is that you can spend more time on what makes your app unique, and less time reimplementing work others have already done.

The Age of Tim Cook

After all the product announcements and updates in yesterday's WWDC keynote, Tim Cook closed by showing a new Apple ad titled "Designed By Apple." Just as in the recent iPhone ads, we see images of people going about their lives. They might be holding an iPhone or sitting near a MacBook, but the gadgets are just barely there, almost a whisper of themselves. The focus is unquestionably on people. The voice-over in Designed by Apple reads as follows:

This is it. This is what matters. The experience of a product. How it will make someone feel. Will it make life better? Does it deserve to exist? We spend a lot of time on a few great things, until every idea we touch enhances each life it touches. You may rarely look at it, but you’ll always feel it. This is our signature, and it means everything.

After more than a year at the helm, it's clear that Tim Cook is putting his stamp on Apple, and this is it. In these commercials, the technology gets out of the way. Products aren't a goal on their own, they're a means to an end, a way to make people's lives better. You can hear that philosophy shine through when Cook talks about things like iOS's accessibility features that let a blind man to go for a walk in the woods. The focus isn't on gee whiz technology, it's on what people are able to do with it. The point of the iPhone camera commercial isn't the number of megapixels or colors – it's the photos people take of their friends and loved ones, their parents and their children.

You can also see that theme emerging in iOS 7's new design. We can quibble over aesthetics, but the goal of getting design out of the way and letting content take over is admirable. Again, the focus isn't on the technology, but what you do with it. It's not on how your email client looks and works, but on the messages you get from people in your life.

Of course, Apple is a product company, and its goal is to sell us gizmos and gadgets. But the remarkable focus, and one that's quickly becoming Cook's signature, is on doing that by making products that really enrich people's lives. It's not about being flashy, or having the most features, or checking off the most boxes. Some will dismiss that as mushy gobbledygook, but it's not the worst way a company could answer the question, "Should we build this?"

This isn't about leaving Steve Jobs behind. Far from it. Under Steve, Apple's goal was always to make great products regardless of what others were doing. But make no mistake, Tim Cook is putting his own stamp on Apple. It's a little more human, a little more personal, even down to the funnier, more casual tone of the WWDC keynote. Cook has chosen to surround himself with people and a philosophy that focus on the humanity in technology even more directly than Steve did. Sounds like a pretty good sign for the months and years ahead.

Why I Don't Use Hashtags

I've never really been clear on why I'm supposed to use hashtags on Twitter. Apparently, they're supposed to help other people find my tweet using the search function or "trending topics." But, as this great article from the Nieman Journalism Lab at Harvard points out, the volume of tweets is still too high for hashtags to matter. Daniel Victor:

According to Twitter, #SuperBowl was used 3 million times over about five hours on Super Bowl Sunday this year. Look at all those people who might be interested in our jokes about Beyonce! And yet getting any single person’s attention is just short of impossible, like a single Niagara droplet screaming for notice as it shoots down the falls.

Though there were peaks and valleys, 3 million tweets over five hours comes out to an average of 167 tweets per second. To say that someone would have to search for “#SuperBowl” in the split-second you sent it would actually be a little generous; assuming they’ll notice your tweet if it’s in the most recent 10 tweets, users would have a window of 1/17 of a second to find you.

Basically, you're stuck between a rock and a hard place. Use a hashtag that's too common and your tweet will be lost amidst the thousands or millions of others using the same one. A hashtag that's too specific won't be noticed or searched for. A hashtag that's "trending" hides individual tweets almost by definition, since it means there are many people using the same tag.

I also have trouble believing that people do very much searching on Twitter. Anecdotally, I don't see or hear about friends using Twitter's search function often at all. Victor points out that hashtags are occasionally useful at conferences or among other small groups. I agree, to a point. If the conference is too large or high-profile (take South by Southwest for example), filtering by hashtag is still an exercise in reading a lot of junk tweets. Again, it's only useful if you can thread a pretty small needle between too not enough posts and too many.

The problem is compounded by the fact that hashtags feel like marketing. It's as if companies convinced us to append the little trademark (™) symbol every time we write the name of a product. Maybe I'll start posting about Coke™ on Twitter™ while using my Mac™. #Winning! Doing so doesn't add any information to the message. In fact, hashtags detract from it – clogging up my post with what is, essentially, advertising. (Look no further than TV commercials, which now often contain a "suggested" hashtag.) Plus, as Victor points out, they're ugly.

So, to sum up. Hashtags aren't likely to get a tweet more exposure, they don't add any information, and they look bad. Why are people using them, again?

Why Developers Shouldn’t Use iCloud Syncing, Even If It Worked

Brent Simmons has a number of reasons not to use iCloud, including one that lines up with my recent post on the topic:

We’ve been living in a social world for years. But iCloud syncing is not social: it’s per-user syncing.

If you write your own server, you can write the social bits, so your users can share recipes, weather forecasts (look, Mom, it’s going to be sunny on Thursday!), favorite articles, or whatever-it-is your app does.

He offers another great reason, which is iCloud's inability to interact with server-side services:

iCloud can’t poll Twitter to see if your follower count has gone up or down. iCloud can’t generate weather forecasts. iCloud can’t track ships.

There are all kinds of services that make sense on the server side. You could do some of them on a client, but at the expense of timeliness and battery life. If it’s a good idea, and you don’t do it on a server, your competition just has to write a server that does it, and your app is finished.

Even if you wanted to write your own server and then integrate with iCloud for syncing, it's impossible. There's no API that would allow a server to connect to iCloud.

At this point, implementation problems are by far the biggest obstacle to iCloud adoption. But once those are solved, the limitations designed into the platform will still be a big barrier.

Flying iPads

The New York Times reported yesterday that the FAA is getting closer to allowing people to use electronic devices on planes during takeoff and landing. From the Bits blog:

According to people who work with an industry working group that the Federal Aviation Administration set up last year to study the use of portable electronics on planes, the agency hopes to announce by the end of this year that it will relax the rules for reading devices during takeoff and landing. The change would not include cellphones.

Marco Arment is concerned about the term "reading devices."

Is the Kindle Fire a reading device since it’s named “Kindle”, even though it can do a lot more? Are iPads reading devices? How about an iPad Mini with an LTE radio? I assume iPhones would be prohibited as “cellphones”, but what about iPod Touches?

I agree that "reading devices" is a silly and probably self-defeating standard to use, but I think Marco may be taking the Times article a little too literally. I doubt that the FAA would use the term "reading devices" in an actual regulation, because they'd have to device on a definition for a reading device. As Marco points out, that's a tall order. If the FAA released a statement talking about reading devices, I'd be very worried. But in this case, I think we're looking at a case of a reporter being a little loose with his words.

The most likely scenario is that the FAA will use similar rules during takeoff and landing as it does during the cruise section of the flight. That is, radios that send and receive signals must be turned off. During flight, WiFi is OK; during takeoff and landing, it's not. I imagine the rules will look something like this:

  • All electronic devices must be set so they do not send or receive a signal.
  • After takeoff and before landing, you may use WiFi but not cellular communications.

The second rule is basically the status quo. The updated version simply replaces "please turn off all electronic devices" with "please set all electronic devices so that they do not send or receive a signal." (I wouldn't be surprised to see an additional rule banning headphone use during takeoff and landing, so that you can hear crew announcements. Right now you can use headphones for TV on airlines like JetBlue, but crew announcements preempt the TV audio.)

Will some people get it wrong and leave radios enabled on their phones? Sure, but some people forget (or "forget") to turn off electronics now, and it doesn't seem to be a problem. Will flight crews have trouble determining whether people are really complying with the rules? Yes, but again, that's pretty much the status quo. Will different devices do different things in "airplane mode," leading to inadvertent violations of the rules? Probably, but having a standard set of rules about use of electronics use during flight will gradually help standardize airplane modes.