Blancer.com Tutorials and projects

You’ve probably heard about the biggest features of the new OS X, Mountain Lion, by now: Apple’s implementing some popular iOS features like Notifications, Game Center, and Reminders on the desktop OS. But unless you’ve actually played with the OS for a little while (which would mean you’re a developer with access to the beta), you might not know about all of the other little updates, smaller features that make a big difference overall, but haven’t been talked about much just yet.

Fortunately, GigaOm has found quite a few of these little features, and written them up for the rest of us to drool over. Turns out the resemblance to iOS won’t stop at the list of apps installed on the device: Finder file transfers now show off an iOS-style progress bar, and toolbars are simpler and more tactile, borrowing a lot of the button looks from Apple’s official iOS applications. There are just some new cool features as well, like Safari tabs simply splitting the distance on their bar instead of squeezed into one corner, and some new updates in System Preferences, including options for screen savers.

It all sounds great, and a list like this shows that Apple isn’t just interested in copying iOS’ best features on OS X; it’s still thinking about how to make the desktop system better on its own as well. Mountain Lion’s due out sometime this summer, and as far as we’re concerned, sooner the better.

Finding small changes in Mountain Lion developer preview originally appeared on TUAW – The Unofficial Apple Weblog on Thu, 23 Feb 2012 18:30:00 EST. Please see our terms for use of feeds.

Source | Permalink | Email this | Comments

As an unabashed iPhone fan, I often ask owners of Android smartphones why they chose their phone over an iPhone. Answers have included “I like larger screens and styluses” (from a Samsung Galaxy Note owner), “There are more choices,” and the ever-popular “iPhone apps are so expensive!” Well, a Canalys survey released today is throwing that last response into the dustbin of questionable excuses.

The Canalys survey cited in a post on Apple 2.0 notes that on average Android apps cost more than two-and-a-half times as much as their iPhone counterparts. When Canalys looked at the cost of the top 100 paid-for apps in the Android Market, the grand total was US$374.37. The top 100 iPhone apps tallied up to $147.00.

Canalys cited two factors for this discrepancy. First, Apple’s more controlled retail environment allows in-app purchases and drives competition in app prices; second, Android phone owners are less willing to pay for apps, driving developers to charge more to break even.

Analyst Rachel Lashford of Canalys noted that “achieving big volumes of paid apps on Android is no small challenge,” and she believes that more aggressive price competition within Android apps would encourage more consumers to make their first app purchases. That, in turn, would drive greater volumes of downloads and help the Android app ecosystem.

You might wonder if there is an overlap between the best-seller lists for the Android Market and the App Store. Only 19 apps appeared on both lists, and the pricing was usually higher for the Android apps. As an example, EA’s Monopoly game is on both lists and has a price tag of $4.99 for Android and just $0.99 for iPhone.

Android apps more expensive on average than iPhone counterparts originally appeared on TUAW – The Unofficial Apple Weblog on Thu, 23 Feb 2012 18:00:00 EST. Please see our terms for use of feeds.

Source | Permalink | Email this | Comments

Have a 2011 Mac mini, MacBook Pro, MacBook Air and iMac? If Software Update hasn’t yet told you about it, there’s an EFI Firmware Update available that you might want to install.

According to the release notes, “This update improves the reliability of booting from the network, addresses an issue that can prevent HDCP authentication after a reboot, and resolves an issue with boot device selection when a USB storage device is hot-plugged.”

The direct links to the updates are as follows:

• Mac mini EFI Firmware Update 1.6 – Mac mini (Mid 2011)

• iMac EFI Firmware Update 1.9 – iMac (Early 2011)

• MacBook Air EFI Firmware Update 2.4 – MacBook Air (Mid 2011)

• MacBook Pro EFI Firmware Update 2.7 – MacBook Pro (Early 2011) and (Late 2011)

2011 Macs get EFI Firmware Update originally appeared on TUAW – The Unofficial Apple Weblog on Thu, 23 Feb 2012 17:33:00 EST. Please see our terms for use of feeds.

Source | Permalink | Email this | Comments

Clear, the new todo list iPhone app from Realmac software, got a lot of buzz thanks to very impressive demos during Macworld in January. Interest in the app was so high that at least one opportunistic ripoff artist copied Clear wholesale and put a copycat app on the App Store before Clear even debuted. Our own review of Clear found that its simple but intuitive interface definitely lived up to the weeks of hype, and in my own usage I’ve found Clear an invaluable tool for organizing my day.

It turns out Clear has been extremely successful so far, having sold 350,000 copies in just nine days according to The Guardian. Those are extremely impressive numbers for a simple todo app; Clear joins Epic Games’ Infinity Blade and its sequel as two of the few apps I’ve heard of that have gained so many new users so quickly.

Widespread press coverage, a low introductory price of US$0.99, and Apple featuring it as App of the Week on the App Store helped propel Clear to the success it’s seen thus far. Realmac isn’t resting on its success, though; an update to the iPhone version is in the works, and Realmac confirmed to The Guardian that iPad and Mac versions will follow. Realmac is “open to the idea of taking it to other platforms” — Android and Windows Phone 7, in other words — but they reiterated that Apple’s devices are their first priority.

If you haven’t checked out Clear yet, I highly recommend it if you’re looking for a simple todo/list maker app with a streamlined interface that doesn’t get in your way.

Clear: 350,000 sales in 9 days, iPad and Mac versions coming soon originally appeared on TUAW – The Unofficial Apple Weblog on Thu, 23 Feb 2012 17:00:00 EST. Please see our terms for use of feeds.

Source | Permalink | Email this | Comments

There have been a lot of stories lately about websites trying all sorts of things to keep track of people and invade their privacy. First it was Facebook, and now Google.

I protect myself from Facebook tracking me by using a Fluid browser for Facebook. Because I paid the US$5 to register the app, I can use separate cookies from Safari.

Here’s how I setup Facebook in Fluid. This is how I created the app:

Once the app is created, launch it, and separate the cookies from Safari:

And then set it so that any link off of Facebook will open in another browser (note: this is the default, you don’t have to change anything to get it to do this):

Fluid for Google

I do a similar thing for Google, but it’s actually more restrictive: no JavaScript and no cookies allowed:

No JavaScript means no Google instant, which I loathe, no little popup telling you they are changing their privacy policy.

The whitelist settings only let the browser bring me to Google sites, so any results I click on will open in my regular browser. I’ve been trying to get Google to open results in a new window for years and they always forget that setting.

You can also change the User Agent which is sent to Google, which can change the format of the results. For example, maybe you prefer the iPad (oh, I mean “tablet”) format. You can get that by telling the Fluid app to report itself as an iPad:

Don’t want a separate browser? How about a fast logout?

Maybe you don’t want a separate browser, but want to make sure that Google isn’t associating your searches with your Google login. Well, assuming that Google hasn’t found another way to track you even when you aren’t logged in, you can make a bookmark shortcut to make sure that you are always logged out before you do a Google search. Just bookmark this link https://accounts.google.com/Logout?hl=en&continue=http://www.google.com/ and click it whenever you want to do a Google search. Or drag this link to your bookmarks bar:

Safe Google Search

“But if I’m always logging out of Google, won’t I have to keep logging in to check my Gmail?”

Logging out of Google is easy, but if you want to use Google services like Gmail or Google Voice, you’ll probably want to be logged in. There are a couple of ways to work around that.

Option 1: Use a different browser for Google – If you usually use Safari for your regular browsing, use Google Chrome for Gmail, Google Voice, etc.

Option 2: Use Fluid or Mailplane for Gmail – I’ve been a Mailplane user since its days in beta, and it’s my favorite way to use Gmail. Of course you could also use a Fluid browser instead.

Option 3: Use an app instead – This may be too obvious to even suggest, but there are good alternatives for using Google’s services in a web browser. You can use Mail, Sparrow or Postbox instead of Gmail, or BusyCal instead of Google Calendar. I vastly prefer GrowlVoice to using Google Voice’s website (although there are some Google Voice settings you can’t access except through the website, but they aren’t ones you’ll probably use often).

Option 4: Log in to Google quickly using 1Password – If you use 1Password , you can make a “one click” bookmark for logging into Google/Gmail/Google Calendar/etc. Just drag the entry from 1Password to your the bookmark bar in your browser of choice. Brett Kelly did a nice write-up about that feature.

“I don’t trust anyone! I want to delete everything!”

This seems like a huge overreaction, but in just a few minutes of casual web browsing, there are 44 websites which have stored cookies and other cache files on my computer. Are Google and Facebook the only companies out there doing nefarious things with tracking activity online, even if you’ve told Safari not to accept 3rd party cookies? That seems doubtful. Google and Facebook may be the largest companies, but probably not the only ones.

So maybe it isn’t a terrible idea. The question is how to do it. If you try to disable cookies, caches, and everything else from within the browser, you’ll find a lot of sites just don’t work. Instead, it’s probably easier to just let the browser work as designed, but then clean up after it. There are two ways to do this: the manual, GUI way, or the automatic, scripted way.

The manual, GUI way is to use the “Reset Safari…”

That option will bring up a whole host of “cleaning” options:

By default there’s no keyboard shortcut for it, but you can make one in System Preferences » Keyboard » Keyboard Shortcuts. I use Command + Option + R:

Note that you need to have that menu item exactly as shown: Reset Safari… with an ellipses … not three periods.

The automatic, scripted way doesn’t allow for as careful or selective deletion, but you also don’t have to remember to use it. You can automate it with a LogoutHook, which is basically a shell script which runs whenever you log out.

WARNING! This script will run as root and is going to use rm -rf which is one of the most potentially destructive commands that you can run. If you make a mistake here, you could delete data, or render your computer unbootable. “Be careful” is an understatement. “Use at your own risk” is another. As always, make sure you have a verified backup before testing something like this. If you aren’t sure what you are doing, stick with “Reset Safari…”

Create a file anywhere you like. I recommend /usr/local/bin/logouthook.sh and make it executable chmod 700 /usr/local/bin/logouthook.sh and then tell it to clean up after Safari every time you log out.

(Strange aside: if you quit Safari, delete Safari’s “binarycookies” file, re-launch Safari, and try to access one of the sites which had stored information in the cookies file, Safari re-creates the ‘binarycookies’ file. That does not seem to happen if you delete the binarycookies file via LogoutHook.)

Then you have to tell the system to use that script when you logout. You’ll need to enter your administrator password:

sudo defaults write com.apple.loginwindow LogoutHook /usr/local/bin/logouthook.sh

Note that the script will delete all of your cookies, local storage, and local “database” files from sites you log into. Plenty of good sites use those technologies to make your web browsing faster, easier, and more enjoyable. Deleting them regularly may be more hassle than it is worth. One of the drawback is that you will be logged out of all the websites which use cookies to keep track of your logins. As always, there is a trade-off between privacy/security and convenience. If you do this, I highly recommend creating 1Password bookmarks for easy re-login for sites you use most often, or create separate Fluid.app browsers for them with separate cookies.

What’s the right answer?

Truthfully, I don’t know what the right answer is. For years I have thought that concern about ‘cookies’ was much ado about nothing, but given the motivation of companies like Google and Facebook to gather as much information about you as possible to sell to marketers, I’m less confident as I once was. Instead, I find myself wondering, why not accept a little inconvenience in exchange for increased privacy?

If you do decide to use Fluid.app browsers for Google, you can find some great looking app icons at http://csi.nfshost.com/goodies/. There’s also a Flickr group for Fluid.app icons.

Protect yourself from being tracked by Google, Facebook, and others originally appeared on TUAW – The Unofficial Apple Weblog on Thu, 23 Feb 2012 16:00:00 EST. Please see our terms for use of feeds.

Source | Permalink | Email this | Comments

Yesterday we pointed you to an amazing compendium of Steve Jobs videos. Now Adweek has beat that by putting all 84 iPhone TV ads that have been released so far into one spectacular article.

All of the ads were created by TBWA (branded in the U.S. as TBWA\Chiat\Day), with the first of the series broadcast during the Academy Awards broadcast in 2007. While that ad was a teaser for the first iPhone that came out in June of 2007, most of the spots have focused on the capabilities of the iPhone as it has evolved over the years.

Looking through the videos, it’s not only fascinating to see how the technology rolled into the iPhone has changed, but how consistently they stay “on message.” The first ads showed the abilities of the iPhone and really pointed out how different it was from the other phones of the day, while a second series in October of 2007 had iPhone owners talking about how the phone had impacted their lives.

The 30-second spots are a blast to watch and a great way to catch up on your iPhone History 101 if you’re new to the world of Apple. To whet your appetite, here’s one of the vintage ads that aired on June 4, 2007 — just 25 days before the first iPhone debuted.

Thanks to Tim from Adweek for the tip.

All 84 iPhone ads available in one place for your viewing pleasure originally appeared on TUAW – The Unofficial Apple Weblog on Thu, 23 Feb 2012 15:00:00 EST. Please see our terms for use of feeds.

Source | Permalink | Email this | Comments

Dear Aunt TUAW,

In the “Post-PC” era, is there a way to get an audio file, such as one stored on Dropbox, onto an iPad? Is a tethered transfer of audio from iTunes the only solution?

Your loving nephew,

Chris R.

Dear Chris,

In a word, no. iTunes maintains its own asset library system that isn’t generally accessible (except for reading) to developers. Third-party apps can browse the unit’s iTunes music library and choose tracks and play them back (and, even access the data directly if they need to). But there’s no way for them to modify the library itself by adding new tracks.

Although apps like Dropbox can use the documents sharing API to open files in conforming apps, the onboard music app does not comply with this. It does not appear as a possibility in the “Open In” menus for m4a, mp3, and other audio data.

Basically this all goes down to digital rights. There have been numerous projects over the years to reverse engineer the iTunes library format and modify it, especially on Mac and Windows, but these projects fall outside of the normal terms and use of iTunes and the onboard iOS app.

You’d think that in the “Post-PC” era, Apple would know this and allow you to bring third party tracks like those from Amazon into the iTunes system sans computer — but we’re apparently not quite as “Post-PC” as one might imagine, yet.

Hugs,

Auntie T.

Dear Aunt TUAW: Help me transfer music into iOS iTunes originally appeared on TUAW – The Unofficial Apple Weblog on Thu, 23 Feb 2012 14:00:00 EST. Please see our terms for use of feeds.

Source | Permalink | Email this | Comments

Apple’s trying to differentiate iTunes from its competitors with a new “Mastered for iTunes” section that’s filled with high-fidelity, ear-pleasing music. These tracks are processed using a set of guidelines and tools that’ll maintain as much of the sound quality of the original, uncompressed file as possible.

As Ars Technica points out, most modern music tracks are recorded using 24-bit samples at 96 kHz or 192 kHz, depending on the processing power and storage space of the system. iTunes files are then compressed to a 256 kbps AAC “iTunes Plus” format, which loses 97 percent of the data contained in the original, uncompressed recording.

Apple’s new “Mastered for iTunes” tries to minimize this lost data by downsampling the original, high-quality music file to 44.1 kHz using a 32-bit floating-point intermediary file. This file is then converted to AAC. As Apple writes in its Mastered for iTunes guide, this process uses “every bit of resolution available, preserving all the dynamic range of the 24-bit source file.” For end users, this means your Master for iTunes tracks will sound delightful to even the best-trained ears.

For more details on the technology behind these new Mastered for iTunes tracks, you can visit Apple’s new Mastered for iTunes website. There’s also an excellent article from Ars Technica on the subject.

Apple introduces Mastered For iTunes tracks originally appeared on TUAW – The Unofficial Apple Weblog on Thu, 23 Feb 2012 13:30:00 EST. Please see our terms for use of feeds.

Source | Permalink | Email this | Comments

Apple’s announcement of Mountain Lion included many promised new features, including a stronger focus on the Mac App Store than ever before. Two significant new features, iCloud document syncing and Notification Center, are only accessible to App Store apps, and the new Gatekeeper security tool will include a setting to lock a Mac down so it can only run software purchased from the App Store.

All this has (probably inevitably) got people wondering if this is the first step towards a version of OS X that will only run programs from the App Store — a world where indie developers who cannot or will not use the App Store as their distribution platform will be frozen out altogether.

I think that’s an unlikely end state (making my headline fully Betteridge compliant), and so do some prominent indie developers, but I also think the issue is worth examining.

A brief recap of the App Store

When Apple added the App Store to iOS in 2008, it was a revolution in more ways than one. For the first time, we had a major general-purpose computing platform where software developers could not freely distribute their work to a wide audience; a platform where users could only purchase and download approved programs from a central, controlling authority. This wasn’t a new idea — gaming consoles have been using this “walled garden” model since the earliest Atari and Mattel consoles — but it’s the first time it had been applied to a device that some might consider a successor to the personal computer. So powerful and successful was this idea that we had to invent neologisms — “jailbreak”, “sideload” — to describe processes that we had taken utterly for granted for the first thirty-five years of personal computing.

Now, I’m not suggesting that the App Store is bad. Although it undeniably introduces new restrictions on how we use our expensive devices, the upside is a frictionless user experience for discovering, installing, upgrading, and uninstalling apps that had never been seen before outside of console gaming. Coupled with Apple’s economically viable micropayments infrastructure, this spawned a sprawling “appconomy.” Hundreds of millions of users spending billions of dollars on apps from millions of developers; a fluid, dynamic software market the like of which the world has never seen the like of which.

Back to the Mac

In early 2011, Apple brought some of these principles to the Mac with the release of the Mac App Store. Like its iOS ancestor, this also promoted app discovery and management — but with one key difference: it’s not the only game in town. OS X on the Mac still has its traditional ability to download and install software from… well, anywhere. The Mac App Store also brought some restrictions to what an App Store-purchased app could do, but nothing too onerous. At the same time, it offered access to Apple’s payment processing engine, meaning indie devs could spend less time looking after financial transactions and more time cranking out great code (at the cost of the familiar 30% “rake” of Apple fees). Everybody wins.

Many developers found that their users quickly moved to accept and then prefer the Mac App Store. Reports of great success with their early releases were plentiful. For example, graphics manipulation program Pixelmator grossed $1 million in 20 days after announcing it would be an App Store exclusive. The authors of the Sparrow email client were very happy with the App Store. Other success stories abounded.

Confined to the sandpit

For the best part of a year, everything was happy in App Store land… but as of March this year, Apple was going to require all App Store apps to run in a “sandbox” (although this deadline was recently extended to June). This means, amongst other limitations, that each app’s access to the underlying system is sharply curtailed, to the point where an app can only read and write to approved directories within the user’s home folder — and it requires explicit permission to do even that. An app has to specify which “entitlements” it needs (specific system permissions and capabilities) to get its work done; Ars Technica’s book-length Lion review by John Siracusa has a great sandboxing section examining how this is managed.

This set of restrictions affects many existing apps for the worse. Craig Hockenberry of the Iconfactory reported that the company successfully ported xScope (after having problems with a bug relating to symlinks in home directories). He noted, however, that some apps would never be effective in a sandbox; the example was Panic’s Transmit, an FTP client, which requires wide filesystem access and probably couldn’t be meaningfully ported to the App Store under the sandboxing rules.

Hockenberry also told me that two other pieces of popular Iconfactory software, CandyBar and IconBuilder, could never work with sandboxing. The former modifies system files and the latter is a Photoshop plug-in.

Some developers, seeing the sandbox writing on the wall, are being forced into difficult decisions regarding their App Store offerings. Manton Reece of Riverfold Software has announced that his ClipStart video library tool will be withdrawn from the App Store altogether because of incompatibility with sandboxing.

This is particularly troublesome for users who have already bought the App Store version of his app; Reece cannot easily identify them to give them an upgrade to a non-App Store version, nor can he offer them new versions of the app within the App Store’s framework. To his enormous credit, Reece is willing to “honor Mac App Store receipt files” — presumably via a tiresome manual process — and provide extra serial numbers for customers migrating to new computers.

For similar reasons, and with similar problems for users, Atlassian Software’s SourceTree is also leaving the App Store.

Even apps that don’t seem to require system-wide file access can fall foul of sandboxing. Any sandboxed app can open any file anywhere on the system via the File > Open menu, because the sandbox presents the standard OS X dialog window to the user with special elevated permissions. But Gus Mueller of Flying Meat, father of the image editor Acorn, tweeted “just discovered you can’t use AppleScript to tell (sandboxed) Acorn to open an image it hasn’t opened already.”

All this has provoked some understandable bad feelings. As Red Sweater Software’s Daniel Jakult forcefully put it, “Shame on you, Apple. Your developers shed blood, sweat, and tears to succeed on the Mac App Store. Now you drop them with misguided policy.” Jakult elaborated on his position in a blog post where he outlined the changes he’d like to see made to sandboxing to make it more workable for everyone.

Mountain Lion

Mountain Lion, the next version of OS X, will add further fuel to the fire. It adds a new security system, Gatekeeper. On its highest setting this will only allow programs downloaded from the App Store to run. This isn’t the default, however; on the out-of-the-box medium setting, the Mac will run apps from the App Store and those digitally signed by a process carried out between the dev and Apple.

This process doesn’t cost the devs anything (beyond their existing $99 annual developer membership fee) and doesn’t restrict what the app can do. It is designed to offer a halfway house solution between the locked down App Store and the anything-goes wild blue Internet. After all, Apple might not have a malware problem today, but that could change in the future. Finally, Gatekeeper’s lowest setting allows all apps to run unfettered — just like all previous versions of OS X.

It’s possible that Apple planned this split approach all along — although if so, it was rather mean-spirited to not start off requiring sandboxing for all App Store apps. Yanking the rug out under existing apps isn’t good for developers or users. It seems more likely to me that these changes are the result of a genuine strategy shift within Apple, or possibly the sandboxing/entitlements infrastructure was simply not fully baked enough in 10.7 Lion to permit most apps to work with it effectively (including those using Apple’s own AppleScript interapplication framework).

Still, after a somewhat winding road, we’re arriving at a good place with Mountain Lion. Users who don’t adjust the default setting will be able to run apps from the App Store and elsewhere with a degree of malware protection, and devs can distribute apps that fit the App Store’s slightly simplistic model there whilst also distributing signed apps via other channels. Great, right? Well, I still see a few problems with this.

Mixed feelings about the App Store

Firstly, as it stands, every third-party app on your Mac today won’t run on Mountain Lion, as they are not digitally signed. This means if you upgrade you’re going to be plagued with “this app is not trusted” messages (you can enable Gatekeeper on OS X 10.7 to get a taste of how annoying this is). If you have a lot of apps — particularly older apps that might not ever receive digitally signed updated versions — this might become the Mac equivalent of Vista’s hated User Account Control prompt. If so, many existing users might end up turning Gatekeeper off altogether, rather defeating the point.

The second problem is the ongoing FUD being generated around the Mac App Store as a result of the ongoing painful process of enforcing sandboxing. Apple has twice extended the deadline to switch it on — it was originally last November. In the mean time, I and other Mac users I’ve spoken to have found ourselves holding off on App Store purchases, or actively sought out non-App Store versions of apps, to avoid getting into a state where we have a licence for an app that is removed from the store.

The third issue is commercial pressure. What if, in the future, users come to view programs not on the App Store with disdain for missing features or even outright suspicion at a perception of lower software quality? So far I don’t think this has happened, but it’s a possibility in the future. If sales outside the App Store begin to drop, devs will come under a covert pressure to move to distributing their wares via Apple. They might then face an unpalatable choice between dwindling sales or neutering their programs to comply with sandboxing.

App Store only APIs

With Gatekeeper and app signing, Apple seems to be proposing a three-tier system — App Store apps in the first tier, digitally signed apps in the second, other apps in the third. In theory, apps in tier two and three are equal, but the ones in the App Store are limited by the sandboxing requirements.

It’s not that simple, however. A subtlety arises from the existence of features that are only accessible to the App Store apps. Two big new parts of Mountain Lion — iCloud document syncing and Notification Center — are described as being only useable to App Store programs. This widens the gap between the first and second tiers, particularly if the hunches of a few developers I spoke with are right and Apple continues to make marquee OS X features App Store-exclusive.

Now to be fair to Apple, there is a big mitigating factor, because both of these services use server-side resources Apple has to maintain with no direct income. iCloud, for one, clearly relies on cloud storage to work and cloud storage doesn’t come cheap.

Notification Center is more puzzling. At first, I thought it worked primarily like Growl — in other words, it was a way for an app already running on my Mac to bring something to my attention. Fellow TUAW writer Chris Rawson and Iconfactory‘s Craig Hockenberry told me I was wrong, so I dug deeper and talked to a few developers. Anand Lal Shimpi’s investigation showed that, in the current developer beta, Mountain Lion has two types of notifications — local ones, that can be sent by any app, and server-side push notifications, which can only be associated with App Store programs.

Jonathan George, CEO of Boxcar, told me that for his company the push notifications are far preferable, even on OS X. On iOS, any app that wants to notify the user arbitrarily (except Apple’s apps like Calendar and Mail, which can use private APIs) needs server-based push notifications as a workaround for the lack of always-on backgrounding.

It initially seemed to me that this is less important for OS X. Consider my Twitter client, which is always running on my Mac. It’s checking every few minutes for new messages and can send a ping to Notification Center without any external servers. This, however, can take a few minutes — a server-side push is realtime, or at least, really really fast. This is clearly better for some types of apps than local-based notifications coming from a polling loop.

So what about App Store-only?

To come back to the question I opened this piece with: could/would Apple mandate, in a future release of OS X, that the App Store would be the only game in town for getting software onto the Mac?

Well, perhaps “could” is the wrong word. Apple certainly could, but I think we’re a long way away from a world where most users would approve — and for those who are comfortable with it, they’ll be able to switch Gatekeeper into full-on paranoia mode and achieve the same end.

Furthermore, if Apple was planning it for the future, I don’t think we’d have seen Gatekeeper’s middle setting introduced at all. The mere existence of this feature underscores that Apple is serious about giving users some extra malware protection via code signing without mandating the App Store. Indeed, Panic’s Cabel Sasser asked an Apple representative about this when he was briefed on Mountain Lion and he reported that “for what it’s worth, they told me point blank that they value independent apps and do not want them gone.”

This code signing option is not only a technical solution, but also grants indie devs working outside the App Store a veneer of respectability that might help make some less experienced users more comfortable doing business with them.

There’s also the question of professional-level software. It seems rather unlikely that the Adobes, Avids and Microsofts of this world would be happy to hand 30% of the sales of high end programs like Creative Suite or Office to Apple, as would be required if these apps were put in the App Store. Do those companies need OS X more than Apple needs them? It’s debatable, but it’s a game of chicken Apple would perhaps be wiser to stay away from. It’s not dissimilar to the row about in-app purchases under iOS and apps like Kindle, and Apple lost that one.

A tale of two app stores

I think Apple, in simultaneously watering down the existing App Store via sandboxing and giving a non-App Store mechanism for developers to bless apps, has created a segmented market. It seems to me we’re going to end up with the App Store populated by smaller apps from smaller developers (who will find the support of Apple’s payment processing infrastructure compelling) and larger but relatively simple apps for which sandboxing doesn’t chafe too much.

Meanwhile, we will hopefully still see a vibrant indie dev scene outside of the App Store. Indeed, by enforcing sandboxing, Apple might have just given the alternative channels a lifesaving boost… but by locking key OS X features up to only be accessible to App Store software, it’s simultaneously making it harder for non-MAS indie devs to compete. It’s too early to tell which of these factors will come to dominate over the others.

This is assuming, of course, that Apple sticks by its guns. The slipping schedule for essential sandboxing suggests Apple is perhaps a bit uncertain or conflicted about the way forward here and maybe we will see sandboxing significantly relaxed or expanded before it becomes mandatory.

I’ll end with one piece of wild speculation, because I’m a blogger and because I’m under my House of Crackpot Theories quota for this month.

If an existing sort-of-an-app-store service like MacUpdate took Apple’s digital signing certificate and ran with it, it’s not impossible we could see an Unofficial App Store emerge. One which requires digital signing of all the apps, and offers developers a payment processing and download hosting service, but does not require sandboxing or unpredictable app approval processes. I think Apple’s sandboxing policy may create a gap in the market by wilfully narrowing the scope of the App Store. I don’t know if that gap is big enough for someone to wedge an entire new product into, but I’d throw money at anyone who’s willing to try.

The author would like to thank everyone who helped compile the information in this article: Jonathan George, Craig Hockenberry, Chris Rawson, Erica Sadun, Anand Lal Shimpi, Fraser Speirs, Steve Troughton-Smith, and the other devs I spoke with off the record.

Does Gatekeeper point the way to an App Store-only OS X? originally appeared on TUAW – The Unofficial Apple Weblog on Thu, 23 Feb 2012 12:30:00 EST. Please see our terms for use of feeds.

Source | Permalink | Email this | Comments

It’s tough when you’re at the top of your game, because everybody wants to shoot you down. A new lawsuit against Apple by Brandywine Communications Technologies claims that our buddies in Cupertino are infringing on two patents that vaguely describe mobile voicemail.

And who is Brandywine? If your answer includes the words “patent troll,” you may already be a winner. Brandywine Communications Technologies is a firm that Verizon — in a lawsuit against the company — called “a patent holding company that is in the business of enforcing patent rights through the filing of various lawsuits.” In other words, a patent troll.

The two patents that Brandywine is suing over are No. 6,236,717 and No. 5,719,922, both of which cover a “simultaneous voice/data answering machine.” Not vague enough for you? Here’s the description from the patent filings: “A simultaneous voice and data modem coordinates the storage of voice messages and data messages on an audio answering machine and a personal computer, respectively. This allows the called party to subsequently retrieve, via the simultaneous voice and data modem, both a voice message and an associated data message, i.e., a multimedia message, where the called party listens to the voice message while viewing the data message. The called party can retrieve the multimedia message either locally or from a remote location.”

Sounds just like Visual Voicemail on the iPhone, doesn’t it?

Along with Lodsys and NTP, Brandywine appears to be working on the assumption that it’s easier to make money by filing lawsuits than by actually creating something of value. Apple has not commented on this latest lawsuit.

Apple sued by patent holder Brandywine over voicemail originally appeared on TUAW – The Unofficial Apple Weblog on Thu, 23 Feb 2012 11:05:00 EST. Please see our terms for use of feeds.

Source | Permalink | Email this | Comments