I was thinking about the latest news from Apple, that they were partnering with textbook publishers to bring cheaper textbooks directly to the iPad while at the same time releasing an application for anyone to publish iBooks for the Apple Bookstore.

Perhaps I am being cynical, but it’s always appeared to me that the main business model of a textbook publisher is to slightly tweak versions of a textbook, altering page numbers and quiz questions in order to force students to buy newer editions instead of used ones. Perhaps the industry is thinking that iBooks will eliminate the used book market, and they’re probably right. But this could also have some negative (for publishers) side effects as well.

Apple is lowering the distribution costs of textbooks dramatically. Assuming that schools actually pay for a set of iPads for each student, it becomes trivially easy (with the iBook publishing software) to create free textbooks for schools. Who would want to give textbooks away for free? Teachers. There are cases of teachers self-publishing for their own schools, but for this idea to really work, I think teachers would need to collaboratively create a textbook that meets either regional or national standards and release it for free on iBooks. If you don’t believe this will happen, take a look at Khan Academy.

Previous attempts to create free textbooks have been hit or miss. I am not quite sure how popular Wikibooks are in the classroom. The problem is probably that of traction and scale. Previously, no one has created a standard for e-textbook distribution. Apple is doing that with iBooks. The beautiful part is that they’re bootstrapping it with traditional publishers who are probably digging their own grave.

Of course, this could play out in a number of ways. Maybe iBooks will prove to be too costly for most public schools to adopt (I’m guessing this is very likely). If only private schools or schools with a lot of funding can support them, it may not become worthwhile to create free textbooks for all.

What I’d hope to see is a slow adoption of iPads in the classroom using iBooks as textbooks. Once a critical mass of schools is using iBooks, free textbooks will be developed and adopted by certain school districts and spread to others.

I’m glad to see that Apple is trying to “disrupt” (I lose some points here by using a word I hate) the textbook industry, and it’s awesome that they’re partnering with that industry to do it. I’m really looking forward to seeing how this plays out, hopefully for the benefit of our education system.

It’s been about 4 years since I announced the launch of Mapskrieg, my Google Maps and craigslist mashup web app. Since then, I’ve gone to school (again), worked for Microsoft and quit, and made a few apps. Today, I’m happy to announce the launch of my newest app, Mapskrieg for iOS!

I’ve been working on this app for a few weeks, and I think it’s ready for public consumption. It’s basically Mapskrieg, but developed natively for the iPhone and iPad. In the past, I’ve taken a sort of iterative approach of releasing fairly minimal apps and improving on them. For example, I released Threadless as an iPhone only app and later added the iPad support. I wanted to release Mapskrieg on both platforms so the launch would have a little more bang. Plus I think the iPad app is the better of the two, and I really wanted that one to stand out for the release. I’ve been getting much more comfortable with mobile development, and I’m very happy with the rate at which I was able to conceive and release this app.

That’s not to say I didn’t struggle or learn anything new with it. While a lot of the concepts are borrowed from my Threadless iPad app, I had to do a lot of stuff I hadn’t done before. For example, since Mapskrieg is going to rely on iAds to make money, I decided that both the iPad and iPhone versions would support iAd. Apple, in their infinite wisdom, made the split view controller a very useful and now, standard, design paradigm. Unfortunately, they don’t provide any support for using it with iAd at all. What the fucking fuck, Apple!? So I had to basically recreate the Split View (well, the landscape mode at least) in order to support iAds. It’ll be well worth it if I can rake in some iAd dough, though!

This post also comes almost 1 year after I quit my job at Microsoft. That milestone probably deserves its own post, but I’ll just say that I have not yet regretted my decision in the very least so far. This is as fun as it gets, folks!

Edit: Oh, I forgot to link to a demo video that I recorded for a contest. Check it out in case you don’t have an iOS device:

In order to prevent my future self from wasting like, 2 hours fucking around with UISplitViewController getting it to auto-rotate its subviews, here’s a little post!

Most of the time, UISplitViewController doesn’t want to rotate because you didn’t set it as the root subview of the Window. This is pretty well documented on StackOverflow, etc. I thought this was why my splitviewblahblahblah wasn’t rotating. It turns out that, according to Apple’s documentation,

A split view controller relies on its two view controllers to determine whether interface orientation changes should be made. If one or both of the view controllers do not support the new orientation, no change is made. This is true even in portrait mode, where the first view controller is not displayed. Therefore, you must override the shouldAutorotateToInterfaceOrientation: method for both view controllers and return YES for all supported orientations.

The key here is that the view controller wasn’t autorotating because the subviews did not answer “YES!!!” (exclamation points added by me) to shouldAutoRotateToInterfaceOrientation. I was fucking around with the Split View Controller in Interface Builder (and later programmatically) to no avail. Adding the stupid autorotate thing to yes in the subviews made it work (shouldn’t it default to YES!?!??!).

Okay, lesson learned. Just don’t forget this next time, Hung!

(The following numbers I’m referring to are from the time period from 1/25 to 2/7)

For an idea of scale, my app, Anime Nano, gets about 600 iAd requests per day. My app analytics software (Flurry) is saying I’m getting about 600 sessions per day. The thing is that about 1/5 of those sessions are on the iPad (and I haven’t enabled iAd on the iPad yet), so I think that on average, the iPhone apps are making a little more than one iAd request per session.

Despite the fairly healthy rate of requests that I’m getting, iAds are only getting sent about 15% of the time. This percentage is what’s known as the “fill rate.” This is also what most developers complain about being too low. The clickthrough rate is actually pretty good at 0.81%.

When iAd fails to deliver (85% of the time), I fall back to AdMob. The fill rate for AdMob is a high 88%, though the past few days it’s been closer to 99%. The CTR, however, is a fairly low 0.25%, which is less than half of iAd. This is partly due to the fact that AdMob ads refresh more often, so the number of impressions is higher.

I’m going to describe my revenue in terms of percentages here since ad platforms typically don’t like it when publishers publish their income. Not sure if that’s changed lately, but whatever! In the time period from 1/25/2011 to 2/7/2011, I made 2.3x more with iAd than AdMob, even with the super low fill rate (and impressions) of iAd. This is pretty interesting since iAd only shows up 15% of the time. There were actually a few days where AdMob beat iAd, but there were a couple of days where iAd made a killing (relatively), probably from those super awesome interactive ads which I still haven’t experienced firsthand yet.

For now, I’m content with the fill rate of AdMob, though it sort of pains me to see such a low click rate and revenue per click. Something tells me that if AdMob worked harder at increasing ad quality (like iAd), they’d be able to charge more and their advertisers would probably see a better return on investment. Most of the advertisers don’t even bother to use an image ad, which I assume would increase the clickthrough rate.

I noticed something really strange when looking at ads on my app. There’s no way for advertisers to disable ads on devices that already have the app installed. I keep seeing Amazon Kindle ads on both my iPad and my iPhone that already have the application installed. As a developer, I know there’s a way to prevent those ads from showing by detecting whether the app is installed at runtime. I think this strange behavior happens on both iAd and AdMob. If anyone from either organization is reading this, contact me!

As far as the future of ads in mobile apps goes, I hope Apple will continue working on increasing the fill rate, and that AdMob tries to increase relevancy and ad quality. Right now it’s really frustrating to see my “inventory” not live up to its revenue potential.

Checkmate ended up winning third place out of many many competitive entries (leaders and the best!), so I’m super happy about that. Here’s a story in the University Record about it. The HiJack project that’s been getting a lot of press was the grand prize winner. Props to those guys!

Winning a prize in this contest was a really nice way to start my year. It’s really encouraging me to continue doing mobile apps and exploring what’s possible.

It’s no secret that I’ve been a huge fan of Threadless since I discovered it back in 2005 (see these blog posts for proof). I really love the fact that the community provides designs and decides which ones will be printed. The company is really only there to provide the machinery to make shirts and fulfill orders! I wanted to contribute to the community by making an unofficial Threadless app (and maybe get a little store credit to feed my t-shirt needs).

My main reasoning for writing a native Threadless app is that I found it pretty hard to browse shirts, even in a fully fledged web browser let alone an iPhone browser. The Threadless site is by no means bad, but it’s hard to see what designs look like when the images are small and on models. I prefer viewing the actual design. So I built an app that makes it easy to 1) browse and find cool shirts and 2) share them with your friends.

In order to do this, I needed to get a database of shirts on Threadless. It’s kind of unfortunate that Threadless doesn’t have an API. At all. Threadless does, however, has a few feeds of shirts: one for shirts that are in stock and another for the weekly additions. I parsed this list of shirts and saved them in an App Engine database along with some other metadata like image urls, category info, etc. I also figured out a way to get the list of all Threadless shirts, including the ones that aren’t currently in stock. What this means is that the ♥s Threadless app will help you find more shirts than even the official website can. You can filter by category, color and run fulltext searches on the entire shirt database.

As far as the front end work went, I had to build a custom table view cell to scroll through shirts and a nested scrollview to view shirt images. The shirt view looks a lot like the native photo browser app for the iPhone. I also added features for sharing, including saving the image to your photo album, posting the design on Twitter and Facebook and emailing the shirt design as an attachment. I figure that covers most bases as far as sharing goes.

So far I’ve only designed and built the iPhone version. I think an iPad version would be neat, too, but I want to gauge the interest in the iPhone/iPod app before putting more time into this. If you like the app, let me know and write up a review for it!

Finally, here’s a video demo of the app, just for fun:

Many (but not all) Twitter clients have url schemes that allow you to open them with a particular message filled out, etc. There’s a few here, but it’s not a definitive list by any means. I gathered a bunch of the more popular ones and wrapped them in a helper class called ObjTweet.

Since I want to give back (and I wouldn’t mind the recognition), I’ve licensed this class under the GNU GPL license MIT License (thanks, Marcello for pointing out that the GPL license is pretty restrictive) and uploaded it to Github. Hopefully someone else finds it useful. My hope is also that people will help find some of the missing url schemes for other apps and build on ObjTweet. If you found this class and are using it, let me know! Hopefully it works as described.

It looks like you’ll be able to order prints from a number of templates, some of which can also include photos:

I think it’s neat that letterpress is becoming mainstream (again) enough that it warrants a feature in iLife. As far as my concerns about taking away business (which I haven’t quite decided to get into), I think it’s good that Apple’s pushing this kind of typing further into the mainstream. There’ll probably be a lot more people interested in letterpress, and not just for the personalized photo cards, etc.

On a technical note, I’m interested how Apple is going to farm out the print jobs. Do they have their own print shop with all the Heidelberg machines, or are they partnering with a shop? Depending on the volume of orders, I wonder what their turnaround time would be.

As I noted in an earlier post, Apple responded to a really low fill rate on their iAd program by enabling developer ads. Developer ads are simple banner ads that entice a user to download an iPhone app. Here’s what the use case looks like via Business Insider:

To Apple’s credit, the workflow is actually pretty good. It doesn’t require users to leave the app to download another one.

Since developers can’t really afford the insane $2 cost per click that the big media customers pay, Apple is charging $.25 a click instead, and no cost per impression. Theoretically, this should mean that the fill rate would be very high (as long as developers are not maxing out on their daily spend limit or too aggressively filtering out apps). Yet I’ve noticed a pretty big fall in fill rate (from about 30% to 20%) in the last month.

I think the main issue is that Apple never really intended iAd to be used for performance advertising. Performance advertising is about getting that direct action (in this case, an app download). Apple’s been pushing iAd as a great Brand advertising solution (where the user is not expected to go out and buy Dove soap from their phone). That’s why the premium brands are willing to pay so much per click and impression. By comparison, AdMob ads on the iPhone seem to be more geared toward performance advertising.

By introducing developer ads, I think Apple has tried to appease publishers at the cost of the perceived premium value of iAds. Sure, the developer ads aren’t as flashy as the premium advertisers’, but $.25 versus $2 a click for the same piece of real estate is quite a difference. Add the perception that iAds for developers are not cost-effective and you could come to the conclusion that Apple is doing it wrong. It doesn’t help that the premium brand advertisers seem to be frustrated with the process of dealing with Apple as a gatekeeper.

So what can Apple do to fix this? They should go back to their specialization: doing one or a few things really well. They should focus on iAd as a brand advertising platform. They should work on getting as many large partners onto iAd as quickly as possible. This will alleviate the growing pains that publishers (including me) are feeling with fill rates. Right now it seems like Apple is reacting rather than acting; following rather than leading. They need to show that they’re serious about carving their own niche in the mobile advertising space.

Just about two weeks ago, I released my first paid iPhone app, Checkmate. The experience has been priceless, plus I made a few bucks as well. I thought I’d share the stuff I learned, both technical and otherwise.

Technical:

Core Location. Being the first iPhone app I’ve done that uses Core Location, I learned a lot about the process of starting up the location manager, filtering location updates and getting them to work in the background. The background stuff is pretty new, just released in iOS 4.

Design takes thought. One of the most difficult things in designing an app is balancing between user expectations (“it should work like magic”) and real-world constraints (battery, accuracy tradeoffs). I’ve taken the approach of leaving the details under the hood (another app that does something similar gives users full control) for simplicity. This is a deliberate design decision. I’ve found that many users are happy with the app, and some are unhappy. I assume there is a minority that is unhappy, but that they seem to be more vocal (more on that later).

Core Data. I also learned about Core Data, since I use that for storing venue data persistently. There’s a bit of a learning curve with Core Data, but I have a pretty good idea of how it works. I guess it helps that I’ve designed a bunch of database schema in the past.

Get to good enough. I definitely feel like I have accomplished something by releasing the app. I have wrestled in the past between releasing something when it’s “good enough” but not getting stuck in perfectionist limbo. In the case of Checkmate, I got to a point where I was happy enough with its performance (it works) and did not want to delay any further, lest I lose steam and give up on ever releasing it. Now that I’ve gotten a feedback loop going, it’ll be easier to improve and update the app anyway. As far as interface design goes, the app is a bit clunky for my taste. Having admitted that, I think I could go back and make some things more obvious (like the login screen) and polish up the user experience.

Business-ey

Ask for reviews. Ask satisfied customers for reviews. Because if you don’t, only the unhappy users will post them. And you’ll end up getting a pretty bad average rating. Even if your app makes crap into gold, there will be users who don’t see the value in it, or think that $2 is too much to pay. Encourage users to post reviews in-app and you’ll see a well-rounded view of what people think about your app.

It’s okay to have a competitor. While developing my app, I found that another similar app had launched and gotten some press from Techcrunch. This was a bit depressing as I wanted to have that exposure. I ended up using it as a motivator since the blog post and app validated my own idea. There’s always room for competition, especially if you can outdo them.

Popular takes all on the App Store. There have been blog posts on the subject of iTunes ranking and how valuable it is to make a top 100 list. Apps seem to be ranked in search based on their sales volume, which means that popular apps will become more popular. Having been featured on Mashable at launch, my app got to #2 for a “foursquare” search. This helped a lot for residual sales. I’m assuming that most apps are sold directly from app store searches. There are other ways to discover apps.

Have fun! It was really exhilarating to see my app get into the app store and into the hands of users. I set up a twitter account to communicate with users, monitored twitter searches for my app and answered emails sent through a contact form on my website. It was really fun having people react to work that I did. It’s probably one of the strongest motivators for me to keep doing what I’m doing.

I have learned a great deal from my first commercial app launch. I’m really glad that I had an idea and stuck with it to completion. I’m still learning a great deal from Checkmate. I know that this experience will make the launch of my next product/app (whatever it might be) more smooth, both for me and users!