→ What the iOS App Store needs is better search

Bloomberg reported that Apple has a team working on monetizing App Store search, ala Google ads. The idea is that developers could pay Apple for better placement in user searches. From the story:

Among the ideas being pursued, Apple is considering paid search, a Google-like model in which companies would pay to have their app shown at the top of search results based on what a customer is seeking. For instance, a game developer could pay to have its program shown when somebody looks for “football game,” “word puzzle” or “blackjack.”

Paid search, which Google turned into a multibillion-dollar business, would give Apple a new way to make money from the App Store. The growing marketing budgets of app developers such as “Clash of Clans” maker Supercell Oy have proven to be lucrative sources of revenue for Internet companies, including Facebook Inc. and Twitter Inc.

John Gruber has it right:

This sounds like a terrible idea. The one and only thing Apple should do with App Store search is make it more accurate. They don’t need to squeeze any more money from it. More accurate, reliable App Store search would help users and help good developers. It’s downright embarrassing that App Store search is still so bad. Google web search is better for searching Apple’s App Store than the App Store’s built-in search. That’s the problem Apple needs to address.


Quick Grades v. 1.0

Today I launched my first independent software project, Quick Grades. Quick Grades is a free easy grader iPhone app built for teachers. I created this app for my wife several years ago, and I kept it updated for her. This fall I rewrote it from scratch for iOS 8. My wife, the original tester, loves the app and uses it often—and my hope is that many other teachers discover it and feel the same way.

I will post more of the technical details later, but I want to give you a short overview of the app. For those of you who aren’t teachers, let me introduce to you a tool that nearly every teacher in America knows well, the EZ Grader.

A vintage cardboard EZ Grader

This tool allows a teacher to set the total number of points for an assignment, and then quickly refer back to it to get the correct score for each graded paper. These graders have been around forever. I remember my mom using hers in the early 80’s, and it is the same one that’s sold today. It’s a useful item for teachers, but it’s also one more thing to keep track of.

Many teachers now use apps instead of the old physical EZ Graders. It makes perfect sense, but most of the apps aren’t very good. The one I my wife used before was not user friendly. The font was hard to read, the color scheme was distracting and hurt readability, and it did not have sensible settings or options. After watching her struggle with the app one too many times, I decided to build her a new one.

After three years of updates just for her, and all the changes from iOS 5 through iOS 8, the app evolved quite a bit. The functionality never changed, but the simple premise of this app offered lots of room to experiment and find the right design.

A four column design with a scrolling table for the scores turned out the be the right approach. Other applications jam too much information into one view. The choice to use a scrolling table view allows for larger and more readable text, and scrolling to find the right score is intuitive and fast.

The second major design choice was to allow the user to decide exactly what columns they want. Every teacher likes to see a different view based on their grading systems and preferences. Allowing the user to remove certain columns from the view also improves readability.

Additionally, I made the easy decision not to interrupt my users and ask them to rate my app. This is a topic that has generated a lot of conversation in the last year, and I land firmly in the ‘anti-prompt’ camp. Yes, App Store ratings are important. Yes, I really do hope my users like the app enough to rate it favorably. But no, I will not be interrupting their work to ask them to do so.

This app is small and focused. It’s simple by design, and a perfect use case for a mobile app. Your phone is always with you, so you don’t have to keep up with the old cardboard EZ Grader. On a phone the simple interface is better than a more complicated one. Clean design and a focus on the user’s needs yields a simple, yet very useful app.

That’s my hope for every teacher that downloads Quick Grades—that it makes their work just a little bit easier. Our teachers work so hard, for so little pay and have many challenges in their way. If I can help by adding something to their toolbox that is just a bit better than the alternatives, then I will consider this project a success.

Quick Grades is now available for free on the iTunes App Store.


For New Projects, Swift or Objective-C?

In the coming days I will be launching a new app on the App Store. I built this application for my wife three years ago after watching her use another app to help grade papers. Because of my employment at the time I could not release it, but now I will be doing so.

This fall I rewrote it from scratch in Swift for iOS 8, and I really enjoyed it. Learning Swift, the good and the bad, was fun. Now, I am looking down the barrel at two new independent projects, one iOS and one OS X.

Objective-C was never a language I felt fully comfortable with. I was competent and was able to build several projects, but I never loved it. I enjoyed the power and flexibility of the Cocoa frameworks, I loved making apps for the iPhone and iPad, but Objective-C never completely fit me well. It was a means to an end.

Swift is a different story. While there are still wrinkles in the language and the community is working through best practices and conventions, it is surprisingly capable for a new language. Apple made a smart move in using the Objective-C runtime and working to make sure it was interoperable with Cocoa frameworks written in Objective-C. This is certainly where the power and flexibility come from. But the language itself is comfortable. It takes many of the things I like from other languages and melds them into a tool that really works for Cocoa.

For my next two projects I will almost certainly write them in Swift, unless I run into a technical limitation, because it’s simply more fun. I am considering Objective-C for one of them, solely to make sure I stay sharp with the language, but I’d be surprised if I do.

It may be reckless to adopt a new language so readily, and I may regret it, but I don’t think so. I cannot imagine Apple pulling back on Swift support after the start its had. For the time being I will be plunging into the near future with Swift. We’ll see how it goes.


Weird Swift syntax

No matter how long I stare, it’s just weird:

!options!.isEmpty

I changed it, and it still bothers me:

!(options!.isEmpty)

→ A valid counterpoint

From Poul-Henning Kamp:

That is the sorry reality of the bazaar Raymond praised in his book: a pile of old festering hacks, endlessly copied and pasted by a clueless generation of IT “professionals” who wouldn’t recognize sound IT architecture if you hit them over the head with it. It is hard to believe today, but under this embarrassing mess lies the ruins of the beautiful cathedral of Unix, deservedly famous for its simplicity of design, its economy of features, and its elegance of execution.

One of Brooks’s many excellent points is that quality happens only if somebody has the responsibility for it, and that “somebody” can be no more than one single person—with an exception for a dynamic duo. I am surprised that Brooks does not cite Unix as an example of this claim, since we can pinpoint with almost surgical precision the moment that Unix started to fragment: in the early 1990s when AT&T spun off Unix to commercialize it, thereby robbing it of its architects.

It’s very easy for me to get overly confident in the open source movement and ethos as the only way forward. It’s good to hear a valid counterpoint every once and a while.