All posts tagged ‘Apple’

File Under: APIs

Rails App Details Apple’s New ‘Passbook’ Web Service

Apple’s new Passbook app. Image: Apple.

Apple’s recent iPhone announcement contained one tidbit of interest for web developers — Passbook.

Passbook is a new app coming in iOS 6 that collects your boarding passes, movie tickets, retail coupons, loyalty cards, and more and stores them all in one place. Checking in for a flight? Just pull up Passbook and you’re done. Ditto for redeeming coupons, getting movie tickets and so on.

What makes Passbook interesting for web developers is that on the back end there’s a REST-style API for sending updates. The API allows developers to register web services which can then automatically update content on the “pass,” as Passbook entries are known. For example, you could update a coupon or add more credit to a pass based on a transaction on your website.

Passbook communication happens through Apple’s new PassKit web service. The PassKit API offers endpoints to get the latest version of a pass, control push notifications for a pass and query for passes registered for a device.

As with all things Apple, you’ll need a developer account to build anything, but if you’d like to get some idea of how

And: everyday, Murray’s got coconut-vanilla plavix use with ppi it. A, product. And colors feel. I plavix and bruising colognes work. Zero off asked and of melt for it get years and viagra ice cream to done hair I human several spending shampoo.

the web service end of Passbook works, check out Mattt Thompson’s passbook_rails_example. Thompson has put together a basic Rails app that shows how to work with Passbook, including how to register devices, get the latest version of a pass, get serial numbers for passes on a device and unregister a device.

For more details, head on over to GitHub.

File Under: Web Standards

Is Apple Using Patents to Hurt Open Standards?

Opera developer Haavard Moen has accused Apple of repeatedly using patents to undermine the development of web standards and block their finalization.

World Wide Web Consortium (W3C), the industry group that governs and oversees the development of web standards, requires that every specification it approves be implementable on a royalty-free basis, barring extraordinary circumstances that justify an exception to this rule. The specifications can contain patented technology, as long as royalty-free patent licenses are available.

Members of W3C—a group that includes representatives from Apple, Microsoft, Google, Mozilla, and Opera—are required to disclose any patents that they hold that are relevant to each specification. Depending on how far the specification is through the standardization process, they have between 60 and 150 days to make this disclosure.

If royalty-free licensing is available, the specification can proceed as normal. Participation in the development of a particular specification obliges W3C members to offer royalty-free licensing for technology used in that specification. Nonparticipants can also voluntarily offer a royalty free license, but they are not obliged to.

If, however, there is no commitment to offer royalty-free licensing for the patents in question, a Patent Advisory Group (PAG) is formed. The PAG will then assess whether the patent is truly applicable to the specification, and if so, how best to address the issue. The PAG might then seek prior art to invalidate the patent, or it might recommend that the specification be modified, to work around the patent. It might even advise abandonment of the specification. Only in exceptional circumstances will it decide that the specification should stand, in spite of the lack of royalty freedom.

Without an appropriate patent grant, browser vendors—whether open source or proprietary—cannot implement the specification without opening themselves up to a lawsuit. Such specifications would be, at best, an extremely risky proposition for anyone seeking to develop a browser, and none of the major browser vendors would even consider implementing a specification with known unlicensed patents.

Haavard identifies three separate occasions, twice in 2009, and again in 2011, where Apple has disclosed patents and not offered royalty-free licensing. In the first 2009 patent claim, Apple said that it had a patent covering W3C’s “widget” specification. A PAG was formed, and determined that Apple’s patent was not relevant. In the second 2009 claim, Apple claimed to have two patents covering W3C’s widget security specification. A PAG was again formed. It decided that one patent was not relevant, and the other didn’t apply. With both 2009 claims, Apple waited until the last minute to disclose its patents.

Touch Events

This time, Cupertino is claiming to have three patents, and an application for a fourth, that cover some of W3C’s touch event specification. This time the disclosure was made with about a month left to go. Again, the lack of royalty-free licensing means that a PAG is likely to be formed.

This in turn will delay the development of the specification and cost W3C members further time and money. The PAG process is not quick; the widget security PAG did not deliver its verdict until October of this year.

Haavard’s conclusion is that there is a pattern of behavior here; that Apple is trying to disrupt the standards process with its patent claims. He references the touch specification in particular—this is plainly an area where Apple has lots of expertise and interest in the technology, but the company opted out of working on the specification. If Apple had worked on the specification, it would have had to disclose sooner and offer licensing, and Haavard believes that avoiding this commitment is why Apple refused to work on the specification.

Apple’s is acting within its rights. W3C obliges members to disclose patent claims, and Apple is duly disclosing them. However, it’s easy to be sympathetic to Haavard’s argument. The two prior PAGs that resulted from Apple’s refusal to offer royalty-free patent licenses delayed and inconvenienced W3C, but ultimately on both occasions the groups decided that Apple’s patent claims were irrelevant. If Apple was hoping to keep some technology to itself, it did not succeed.

Moreover, W3C doesn’t require patent-holders to give up their competitive advantage. It’s acceptable to W3C for the royalty-free patent licenses to only cover implementations of the W3C specifications; if Apple wants to permit the royalty-free use of its touch patents in HTML5 browsers, but nowhere else, this would be an option. Such terms would allow browsers to implement the standard but still keep the technology off-limits to, for example, Android. But Apple did not offer such terms before, and so it seems unlikely that it will offer such terms this time.

Further, the only likely result of this is that Apple’s patents simply get worked around. W3C’s aversion to royalties means that it’s unlikely that it would accept any non-free license (should Apple even offer one), and the importance of touch input to phones and tablets means that W3C is unlikely to abandon the specification altogether. There’s no win possible for Apple—just wasted time and money for those seeking to make the web a more effective, more open platform.

Indeed, the result might even constitute a loss for Apple; the prior art that PAGs can uncover could jeopardize the patents themselves. The PAG subjects the patents to a certain amount of scrutiny—scrutiny that could be avoided through provision of a suitable license.

Apple has thus far not responded to our request for comment.

Apple’s work on WebKit and with W3C has undoubtedly helped the web community. But actions such as this show the company’s approach to standards and intellectual property is, at best, inconsistent, and and worst downright unhelpful: if open standards and Apple’s IP interests conflict, it’s the IP interests that win out. This may be good for Apple, but it’s bad for the open web.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

Mac App Store Gems for Web Developers

The Mac App Store has launched with over 1,000 OS X applications. Our sister site Gadget Lab has more details on what that means for Apple fans.

One thousand apps for the launch is impressive, but what’s in it for web developers? Here’s a quick roundup of a few apps that Mac-loving web developers might want to check out (URLs point to the Mac App Store so you’ll need OS X 10.6.6 for the links to work).

  • iSlice (free) — This slick little app opens PhotoShop documents and slices them up. ISlice retains all the layer info in the Photoshop file so it’s easy to hide background layers and focus on what you need to extract. If you already own Photoshop there’s no point to this one, but if you frequently need to slice comps and don’t want to pay Photoshop’s hefty price tag, iSlice fits the bill.

  • OAuth for Mac ($3) — OAuth is pain if all you want to do is pull a bit of data out of say, the Twitter API. OAuth for Mac handles the OAuth calls for you and quickly generates a token. I haven’t had a chance to test it yet, but it looks like it would be handy for testing and developing quick scripts.

  • Colorbender ($2) — A nice looking color-scheme generator with hex and RGB values. There are tons of free color-scheme generators on the web, but if you’d like a Mac-native version, Colorbender looks like it would fit the bill.

  • mColorMeter ($3) — Ever wanted to know what color your favorite website is using in its menubar? With mColorMeter you can just hover over any pixel on your screen and the app will tell you the value in RGB, Hex and Munsell colors.

  • Base ($17) — Base is nice-looking graphical interface for working with SQLite databases. It’s not cheap, but $17 seems a small price to pay if it means never having to work the sqlite3 command line again.

  • Gitbox ($40) — Hardly a day goes by without someone claiming there are no good Git GUIs. We haven’t tried Gitbox so we’re not endorsing it, especially at $40, but it does offer a very nice-looking graphical UI for Git. And the app comes bundled with the official Git binaries so there’s nothing extra to install — just download the app and start using Git. Great for the command-line-phobic, but seasoned Git users will likely turn up their noses at the price. (See this thread on Hacker News for some more thoughts on Gitbox.)

  • Honorable Mentions — There are quite a few apps in the new store that have been around forever. We love the all-in-one development tool Coda ($100), Text Wrangler (free), BBEdit ($125 currently on sale for $99) and Pixelmator ($30).

The biggest downside to Apple’s new App Store for Mac is that there are no trial versions of the software. For that, you’ll have to head to the developers’ site and (assuming there’s a trial version available) download a good ol’ .dmg file.

See Also:

File Under: Browsers

Apple Updates Safari, Turns on Extensions

The new Safari browser with the Twitter toolbar extension installed

Apple released an update to its Safari web browser Wednesday.

Safari 5.0.1 is available from Apple as a free download for Windows and for Mac OS X (Leopard or better). Mac users can also find it in Software Update.

This is an incremental upgrade, but it comes with one big new feature: Safari now has a real platform for third-party extensions, a feature that Firefox and Chrome have had for some time.

Safari 5 arrived in early June, and in addition to dozens of other enhancements (including the much-discussed Reader feature) it included a new architecture for creating lightweight browser extensions that enhance and personalize web pages and web services. Wednesday’s update now lets you install and run those extensions. Apple has also launched a new Extensions Gallery where you can browse the available extensions and download them.

All the major browsers — Safari included — have had a variety of plug-ins, add-ons and toolbars available for years. But Safari’s new extension architecture is much closer to the format recently adopted by Google Chrome and Firefox. This new breed of extensions can be written using HTML, JavaScript, CSS and other web standards. It makes for a much gentler learning curve for potential developers, and for an experienced web programmer, the effort required to create and distribute a standards-based extension is almost trivial. For users, these extensions are easier to maintain and less likely to slow down the browser.

Mozilla calls its lightweight extension project Jetpack, and it’s being incorporated into the newest Firefox releases. The next version of Google’s browser will let users sync their extensions across multiple installations of the browser.

Go to to see the gallery of extensions being promoted by Apple. Also, keep in mind that anyone can create and distribute a Safari extension, so distribution isn’t controlled like the App Store. For safety’s sake, Safari extensions are sandboxed inside the browser and signed with a digital certificate so you know you’re getting updates from the same person who created the original.

Apple is promoting a few big-name creations in the gallery. There’s an official Twitter extension, which integrates a simple toolbar Twitter client into your browser, one from MLB that displays scores and headlines, and an eBay manager sidebar for keeping a close eye on your auctions. There’s one on the way from Instapaper.

Of course, the irreverent extensions are more interesting. There’s Defacer, which hides “Like” buttons and other Facebook cruft you find around the web. Shut Up hides comments by default on blogs. A Cleaner YouTube removes visual distractions from video pages, promising to turn YouTube into “a clean and tranquil place” as if that’s even remotely possible.

There are around 100 extensions to choose from right now, and since the new extensions framework in Safari is so simple to develop for, we expect the list to keep growing quickly.

There is one other notable safety enhancement to Safari 5.0.1 — the form auto-fill vulnerability has been patched. This fixes a vulnerability that hackers could exploit to grab personal information from a user by forcing the browser to auto-fill a hidden web form with locally stored data. So, even if you may not care for extensions, you should upgrade Safari for this reason alone.

See Also:

File Under: Browsers

Compelling Reasons To Upgrade to Safari 5 Right Now

Update: Apple has fixed the rendering issue shown here, but this is what it looked like at launch. Pretty funny…

Apple’s Safari 5 info page in Safari 4:

Apple’s Safari 5 info page in Firefox:

Apple’s Safari 5 info page in Chrome: