Archive for July 31, 2014

Thursday, July 31, 2014

1Password App Extensions


The video embedded here, produced by our fearless co-founder Dave Teare, speaks for itself. Thanks to Apple’s incredible new developer features in iOS 8, third-party apps can let 1Password fill Logins without the user ever leaving the app. Yep, complete with Touch ID for unlocking the vault.


With just a few lines of code, your app can add 1Password support, enabling your users to:

  1. Access their 1Password Logins to automatically fill your login page.
  2. Use the Strong Password Generator to create unique passwords during registration, and save the new Login within 1Password.
  3. Quickly fill 1Password Logins directly into web views.

This is probably what I’m looking forward to most in iOS 8.

The Indie Game Bubble Is Popping

Jeff Vogel:

Because this flood of games is so unmanageable, Steam has been doing everything it can to throw open the gates and get out of the messy, stressful business of curation. This is absolutely inevitable. It’s also going to winnow out a lot of small developers, who don’t have the PR juice to get noticed in the crowd. (Think iTunes app store.)

With so much product, supply and demand kicks in. Indies now do a huge chunk (if not most) of their business through sales and bundles, elbowing each other out of the way for the chance to sell their game for a dollar or less. Making quick money by strip-mining their products, glutting game collections and making it more difficult for the developers who come after to make a sale. (I am NOT making a moral judgment here. It is the simple consequence of a long series of calm, rational business decisions.)


Suppose you are a super low-budget micro-developer like me. It’s not super-hard to survive, because I can get enough sales to get by with a little cheap marketing and word of mouth advertising. I’ll be all right.

Suppose, alternately, you are a huge AAA developer with massive budgets. You can afford the massive marketing necessary to generate the big sales you need to pay for your expensive games. You’ll be all right, until you’re not.

But suppose you’re a mid-tier (sometimes called AAA Indie) developer, with $500K-$2 million budgets. You have a problem. You need advertising to get sales, as word-of-mouth won’t cover it. But you can’t afford a big campaign. The only way you will turn a profit is if you get huge free marketing from Steam/iTunes placement and press articles.

Abusing Twitter API

Nicolas Seriot:

Twitter claims that the consumer keys are needed to kill applications used by spammers, but OAuth was simply not designed to be used for that purpose. Additionally, it may not be efficient at all, since spammers will use consumer tokens from official clients, and blocking official clients is not an option. Closing individual spammer accounts makes much more sense.


The consumer tokens are fundamentally insecure when used within a client application. Additionally, requesting the consumer keys to be kept secret effectively kills open-source applications.

Twitter asks developers to protect their keys in an environment where users have complete control over the execution flow and access to full address space, so it’s impossible to prevent keys extraction.

This problem is somehow similar to the DVD / HDMI / HDCP decryption. At some point, the user has to use a machine that will load in memory cryptographic keys that will be use to decrypt the protected content. It’s just a matter of time and motivation until motivated hackers extract the keys and can replicate the decryption process.

Twitter’s uses OAuth for something it is not made for.


It appears from our work that the main reason for switching from basic authentication to OAuth is not user security or spam fighting, but simply third-party applications control.

This post is from 2012, but the details are still interesting.

Making Money on Apps

Max Child:

So how do you do that? Three ways:

  1. Charge them for something that helps them make money.
  2. Charge them for an emotional experience.
  3. Don’t charge them, charge someone else for helping that someone else make money.


So what to do if you’re an indie developer? Pick a strategy. Most seem to be going with #2, and that’s fine. But I highly recommend you charge $0 up-front and build an emotional connection strong enough to charge more later.

The History of Civilization

Benj Edwards (via Ole Begemann):

By 1990, Sid Meier had cranked out flight simulator games for as long as he knew how, at the request of his boss and partner. But Meier’s life, and the world of computer games around him, had changed so much since the two men entered the market in 1982. Meier felt the undeniable urge to broaden his horizons as a designer; it was time to move on to greater things. Despite considerable opposition within the very company he co-founded, Meier broke the status quo and changed the course of computer strategy games forever. As the naysayers sank in his wake, he engineered lasting success and achieved design immortality with an epic game based on nothing less than the history of mankind.

I never got into Civilization, but it’s fascinating how enduring it has been.

Personal Audio vs. Adam Carolla

Joe Mullin:

Personal Audio LLC is an East Texas shell company that gleaned national attention when it claimed it had the right to demand cash from every podcaster. The company was wielding a patent on “episodic content,” which it said included anyone doing a podcast, as well as many types of online video.

Now the company is trying to walk away from its highest-profile lawsuit against comedian Adam Carolla, without getting paid a penny—but Carolla won’t let the case drop.


Carolla sent Ars a statement saying he’ll continue to pursue counterclaims against Personal Audio, seeking to invalidate the patent “so that Personal Audio cannot sue other podcasters for infringement of US Patent 8,112,504.” Lotzi (Carolla’s company) has already “incurred hundreds of thousands of dollars in fees and expenses to defend itself” against the Personal Audio patents.

Gen. Hospital:

So, if I understand this correctly, Carolla solicited donations to fight this case. Personal Audio LLC want to drop the case now that they’re up against someone who aren’t scared. The way I see it, Carolla has got three options. One; agree to drop the case, and pay back his donors (impractical). Two; agree to drop the case, and keep the money (unethical). Three; refuse to drop the case, and spend the money the way the donors intended.

Update (2014-08-24): Daniel Nazer:

Adam Carolla has settled with the podcasting patent troll Personal Audio. Although the settlement is confidential, we can guess the terms. This is because Personal Audio sent out a press release last month saying it was willing to walk away from its suit with Carolla. So we can assume that Carolla did not pay Personal Audio a penny. We can also assume that, in exchange, Carolla has given up the opportunity to challenge the patent and the chance to get his attorney’s fees.


The most disappointing aspect of today’s settlement is how unsurprising it is. Almost every defendant, no matter how strong their case, ends up settling with the patent troll. Litigating patent cases is extraordinarily expensive. Carolla raised almost half a million dollars and that still would not have been enough to fund a defense through trial.


On his podcast he said he spent it all and over 100k on top of it on the pre-trial legal and expert fees.

Building a Business, Not an App

Ben Thompson:

[Mike] Love thinks the fact he started from day one with the new business model in mind gave him a competitive advantage to the dictionaries already in the store, but I think he sells himself short; after all, it’s been five years and only now are most independent developers starting to realize that free with in-app purchase is the only viable monetization model. To put it another way, Love differentiated himself again by being a student not just of APIs and frameworks, but of business models as well.


This point blew me away. Love invested real money into differentiating his free app (Love still had the great handwriting engine, but iOS’s built-in handwriting – while hugely inferior – had lessened that advantage). Love was confident that after he won in free, he could make up the difference with his plethora of paid add-ons, which at this point included not only additional dictionaries – several of them exclusives – but also modules like stroke order diagrams, different fonts, a document reader, and a year later, optical character recognition (OCR).


Much of that time has not been spent on development or design. Rather, it’s been spent understanding and listening to customers (which led to the aforementioned bundle change), making business deals with slow-moving publishers, careful consideration around pricing and app store presentation, investments in both free and paid differentiators, and a whole bunch of time spent on an Android app that doesn’t make that much direct money but that marks him as a leader in his space.

Core Data, External Binary Data Storage, and Migration

Alexander Edge:

I have benchmarked the difference between migration using binary data with external storage and using just a unique identifier. The sample project is on GitHub.

The test creates 1000 objects, each with a unique identifier and (optionally) a video file of 165KB as binary data. By adding a data model version with a new attribute, lightweight migration is performed on the next application launch.

When using binary data with external storage, migration took 37.5 seconds.

When not using binary data with external storage, migration took just 0.6 seconds.

It’s clear to see that storing large files in the file system with a naming scheme is the way to go. I have already begun working on an on-disk cache instead of using binary attributes.

External BLOB storage is important because storing BLOBs as linked lists in the database can be inefficient. When Core Data added -setAllowsExternalBinaryDataStorage:, this sounded like a good solution to the problem, but various problems were reported in early versions. It sounds like there are still issues, which is unfortunate because this sort of feature (commonly needed, tricky to do well) should be a selling point for a more full-featured framework like Core Data.