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.

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.

Michael Jurewitz, a.k.a. Jury:

There is no doubt that free can lead to huge user bases and massive adoption. In the face of venture capital or existing cash stores, the siren call of free often sounds like a low-risk bet on future profits. In practice, free is a costly mistake that businesses and small developers should avoid, and users should run away from like the plague.

I’m going to assume for a moment that if you are reading this blog you care about making great product. Selling to lots of users is at least as important to you as being proud of what you build. Most folks in this camp aren’t looking for a quick sale or to flip their business to a big buyer. If you care about the long term success of your business, you want users handing you money for what you build. You want the acquisition of money closely aligned with what makes your users happy.

This is a big part of why I’ve never made my iOS apps free, even when sales have been relatively slow.

A strange pricing trend has emerged as a number of high-profile newspapers have started charging for access to their web sites. Specifically, newspapers are charging less for Sunday paper delivery and unlimited web access than they charge for web access on its own. For example, the Boston Globe charges $3.50/week for Sunday-only delivery and web access, but $3.98/week for web access alone. The New York Times has a similar model, and the Washington Post is apparently considering it as well. This pricing is the opposite of what you’d normally expect: you pay more to get more. Why are newspapers essentially paying people to take their Sunday editions?

The bread and butter of a newspaper is print advertising. A Pew Research Center report on the state of the news media calculated that newspapers brought in $19.1 billion in print advertising revenue, and only $3.3 billion in online ad revenue. Moreover, online ad sales aren’t growing fast enough to offset the loss in print ads:

Print advertising losses continue to far exceed digital ad gains. For 2012, the ratio was about 16 print dollars lost for every digital dollar gained—even worse than the 10 to 1 ratio in 2011.

Notably, the Pew report also documents an increase in Sunday, subcriptions:

Sunday circulation has risen thanks to more new rules for counting audience that includes more digital products and the industry’s emphasis on growing sales of Sunday issues, which are the best-read and most profitable papers of the week.

It seems that efforts by newspapers to increase their Sunday paper circulation are succeeding. In order to prop up print circulation numbers, newspapers are subsidizing Sunday-only subscriptions. By including web access with a Sunday-only delivery, papers can encourage people to buy a print subscription, even if all they really want to do is read online.

What should we think of all this? Well, firstly, that newspapers are going to have to deal with the death of their print editions sooner or later. These subsidies will last a while, but it’s pretty easy to see the writing on the wall.

As a consumer, I have just one request: Don’t make me pay more to avoid getting something I don’t want. I don’t want a print edition of the Sunday paper. Honestly, I’ll never look at it. The best-case scenario would be to charge less for web-only access than for a Sunday edition, but based on the data I’m pretty sure that’s not in the cards. But there’s another option that should help everyone out: Give readers the option to buy that Sunday-only subscription, use the online access, and donate the actual printed Sunday paper to a school, library, or charity. People like me wouldn’t have their houses cluttered by unwanted paper, needy people get access to quality news coverage, and the newsapaper gets to keep its print subscriptions up. Newspapers, make it happen and I’ll gladly subscribe!

After years of shipping only one size of iPhone, why would Apple suddenly add a second, larger “iPhone Plus” like the one that’s been rumored? Andy Ihnatko’s recent post about giving up his iPhone in favor of a Samsung Galaxy S III points the way:

The Galaxy S III’s screen has roughly the same pixel density as the iPhone 5 (they’re both greater than 300 ppi). When I’m reading a book, I can see more of the page, and the wider content margins are more comfortable. I get to see more of a map without having to zoom or scroll. I can see more of the email message, and more of the article in my newsreader. A movie or video is large enough that I feel as though I’m seeing all of the rich HD detail I was meant to see. When I’m reading comics, I don’t need to keep twisting the screen to read panels that have different orientations.

The screen of the iPhone 5 sometimes makes me feel like I’m reading a grocery receipt, not a book. And I never used to read from my phone in bed. Now, if my (still quite beloved) iPad is downstairs and the Galaxy S III is on the nightstand, I’ll spend an hour reading from the Samsung rather than risk cold feet.

Ihnatko’s point isn’t that there’s anything wrong with the iPhone. Rather, he’d simply prefer a larger size, and Apple doesn’t provide one. The taller iPhone 5 gets part of the way there, but it seems that there are a significant number of people who’d prefer an even bigger device. It’s remarkably similar to people who liked the iPad but found the Kindle Fire to be a more appealing form factor. With the iPad Mini, Apple addressed that segment of the market quite successfully. Now would be an opportune time to do the same with the iPhone.

I stumbled on Clean My Mac 2 the other day and was immediately impressed. Since switching to an SSD instead of spinning hard drive on my main Mac, space has been at a premium. Clean My Mac does some pretty slick scanning to find unneeded files. For example, it scans your iPhoto library and locates all the photos that have been rotated but otherwise left untouched. It then offers to delete the original file, since it’s not really needed. It can also get rid of unnecessary language files or old universal binaries. I thought I had my hard drive cleaned out pretty well, but Clean My Mac found about 11GB of stuff I didn’t need. Recommended!

Apple’s iCloud service has generated its share of criticism. Some (rightly) centers on lingering bugs, particularly involving Core Data. Other critics focus on missing features, notably the inability to share documents between users and apps. Many developers frustrated by iCloud’s limitations have turned to third party services like Dropbox, or developed their own app-specific back ends. But these other services do more than allow users to communicate between users or apps on one device. They allow developers to make use of the power of the web to grow and promote their app. What iCloud needs most is the ability to share content on the web.

Over the past few months, a number of high-profile iOS apps have introduced web sharing. Loren Brichter’s hit game Letterpress can share “replays” of games to the web. Marco Arment’s The Magazine just launched a web version. Even Instagram, which made its way to a billion-dollar buyout by Facebook on the strength of its iOS app, has launched a web-based photo sharing. Clearly, even strongly iOS-focused developers feel the need to enable at least minimal web sharing. Notably, all of these apps remain iOS-centric. The developers aren’t abandoning iOS or moving their focus to Android. Rather, web sharing is a great way to introduce apps to a wider audience. Posting a Letterpress replay on Twitter or Facebook is a more compelling advertisement for the game than simply saying “Hey, download this app!”

iCloud’s lack of an external API inhibits this kind of sharing. Reliability issues aside, I think this is a key reason that Dropbox remains appealing to a lot of iOS developers. To fill the void, Apple should devise a non-iOS API for iCloud to allow developers to extend their services onto the web and draw users into the app.

At the outset, the API could even be read-only, or mostly read-only. Photo Streams are a great example of this concept in action. An iOS user can create a shared photo stream to send to other friends on iOS devices, or share a public URL that’s viewable on the web. Nobody expects to be able to create full new photo streams on the web, but its great to allow Grandma to view and comment on pictures, even if she doesn’t own an iPad. (Maybe she’ll like the web experience so much that she’ll consider buying an one, but that’s a topic for another time.)

It would be exceedingly difficult for a third party iOS developer to create an experience like Photo Stream web sharing using iCloud. There’s simply no way to access iCloud data from the web. Most likely, a developer interested in such a feature would bypass iCloud and develop their own API or use a service like Dropbox. There’s nothing wrong with those as options, if Apple is serious about driving iCloud adoption, they need to address web sharing as a key requirement. Doing so would also make developers’ and users’ lives easier. Using Dropbox requires that users have or sign up for accounts. Building a new API requires developing and maintaining a whole server-side infrastructure. Both add new dependencies to an app, and create additional layers between users and a great product. Apple can and should make things simpler.

An external API could do for iCloud what iTunes for Windows did for the iPod and iTunes Store. By allowing iOS developers a simple way to share content from their iCloud-enabled apps on the web, it would help those apps (and iOS by extension) gain exposure to a much wider audience. Because iCloud is still tied back to iOS or Mac device sales, a sharing API simply helps extend the reach of Apple’s platforms.

What is there to lose for Apple? Developers are already creating web-sharing features; they’re just doing it by bypassing iCloud in favor of other services. The iCloud API would only be accessible to members of the iOS or Mac developer programs, whose yearly membership fee should offset costs involved in running the service. Killer apps using iCloud can only help sales of iOS devices. If people use iCloud more, Apple even make a few extra bucks selling extra cloud storage capacity.

Apple’s first priority with iCloud needs to be fixing implementation issues with the current product. After that, a public-facing, sharing-oriented API should be high on the feature list.

Yahoo! generated a lot of buzz recently by announcing they’d no longer allow employees to work from home. It’s a pretty daring change, and one that goes in the opposite direction a lot of companies are moving. If you read my post about why I love working from home, you won’t be surprised that I think Yahoo! is making a big mistake. The new policy is needlessly antagonizing to existing employees, and discouraging to potential hires. It perpetuates a culture of workaholism without a convincing case that face-to-face interaction is always better.

From a memo sent to Yahoo! employees:

To become the absolute best place to work, communication and collaboration will be important, so we need to be working side-by-side. That is why it is critical that we are all present in our offices. Some of the best decisions and insights come from hallway and cafeteria discussions, meeting new people, and impromptu team meetings. Speed and quality are often sacrificed when we work from home. We need to be one Yahoo!, and that starts with physically being together.

Beginning in June, we’re asking all employees with work-from-home arrangements to work in Yahoo! offices. If this impacts you, your management has already been in touch with next steps. And, for the rest of us who occasionally have to stay home for the cable guy, please use your best judgment in the spirit of collaboration. Being a Yahoo isn’t just about your day-to-day job, it is about the interactions and experiences that are only possible in our offices.

If I were a Yahoo! employee, I’d be thinking seriously about whether to stay on. In the tech world, getting everyone onto a “campus” filled with “amenities” like gyms and free food is often a way to get employees to organize more and more of their lives around work. The theory here, spoken or unspoken, is that people won’t mind putting in so many hours if the environment is friendly. The company gets more bang for its salary buck, and gets to brag about their sushi chef in a recruiting brochure. The social pressure that comes along with that atmosphere is bad enough at a company that gives its employees some flexibility. Codifying it into policy makes the situation worse. This new policy sounds like a statement by Yahoo! that they no longer want to work with employees to strike a balance between the office and the rest of their lives.

This new policy won’t help recruiting either. Yahoo! isn’t exactly the darling of the tech industry that they were in the 90s. With a slate of stale and boring products, I have to imagine they have a tough time attracting top talent. High quality engineers, in particular, have a lot of choices about where to work. This new policy is going to make a tough task even tougher. Think about it: If you’re a great developer, why would you choose to work at Yahoo! when there are lot of other exciting companies that offer more flexibility? The tantalizing possibility of “impromptu team meetings” certainly isn’t goign to tip the balance in Yahoo!’s favor.

It would be easier to overlook some of the potential challenges if Yahoo! offered clear evidence that having everyone together in person got better results. Instead, the policy seems informed by outdated management-speak and the unfounded assumption that people are more productive when working in an office. The memo claims that “speed and quality are often sacrificed when we work from home,” but fails to back up the assertion with evidence. At the same time, it lists “impromptu team meetings” as a benefit of working in an office. Now, meetings are useful tools when managed properly, but as a software developer, the idea that an “impromptu team meeting” will help me avoid sacrificing “speed and quality” in my work doesn’t quite compute. If anything, it seems the opposite. Suppose I’m in a groove working on a new feature, and somebody drops by my office for an impromptu meeting. Suddenly, my work has been derailed, and it will take time to get back on track, even after the meeting ends.

Yahoo! doesn’t offer any reason why face-to-face interaction is better than working over email, instant messenger, Skype, or, God help us, the phone. Maybe Yahoo! hasn’t invested in the tools or infrastructure to make remote work as efficient as it could be. There are situations where face-to-face communication is easier and quicker, but there are also cases when it waste time needlessly.

Yahoo! has chosen to expend a great deal of effort rearranging their employees’ lives and getting everyone into a physical office together. They’d would probably be better off worrying about designing and developing great new products.

Facebook updated its iOS app recently, including changes to the “Like” and “Comment” buttons on posts. Previously, the buttons looked a lot like HTML links, just as they do if you use Facebook in a web browser. Small, colored icons appeared to the right indicating number of times the post had been “liked” and the number of comments. If there were no likes or no comments, the icons were simply absent, meaning that the mere appearance of the icons encouraged users to tap on them. Doing so quickly displayed the comments and other information about the post.

The new version of the app replaces the HTML-style links with bigger gray buttons. The increased size makes them easier to hit, and they turn blue if you’ve liked or commented the post. However, the number of likes and comments is bizarrely obscured in small, light-weight, gray text above the buttons. It’s no longer apparent at a glance that people have commented on a post, which in turn discourages users from reading the comments. The tap targets are also fairly small. For a social networking site whose whole business is predicated on getting people to view and interact with posts, this is a strange and baffling choice.

Facebook has long seemed like a company that doesn’t really “get” mobile. It took a long time for them to release an iOS app, and for years it was hampered by a slow, buggy, HTML-5 based design. This latest change doesn’t bode especially well for the future, either.