What we really need is a facility that provides access to at least some subset of WebKit HTML rendering capabilities at a level between CoreText and UIWebView—something that doesn’t require developers to essentially re-invent HTML and CSS but allows them to render at least some level of HTML formatted text to a native view without the overhead and inflexibility of UIWebView—basically, a next generation version of Mac OS X Cocoa’s NSAttributedString

My favourite “why is native iOS development sometimes expensive” story is the Tale of the Bold Username. In an alpha version of the iPhone app we built for Foodtree, we displayed comments like so:

Allen: These are some great-looking blueberries! This year I’m buying a few pounds and freezing them.

We’d just hired Angelina, who had a background in web development, and her first task was to change the formatting to look like this:

Allen  These are some great-looking blueberries! This year I’m buying a few pounds and freezing them.

She was surprised that we estimated it would take her two days. In HTML this would take a few seconds – possibly a few minutes. Sure enough, it took two full days to get the text layout reimplemented in the low-level C APIs, called CoreText¹.

As soon as we changed to a formatted multi-line label, we had to do a whole pile of work just to lay out the text, specify the character range we wanted to format, wrap the text, actually render, and then get the dimensions of the final output. Things were further complicated by the fact we needed to get the dimensions of the output for every row in the table before it could be displayed, since this determined the height of the rows and therefore the scrolling metrics.

Why not just use a WebView? In most cases we would, but this is was one little element that may appear hundreds of times in a scrolling TableView. The table needs to be able to scroll at 60fps, and there’s no way we can tear down and set up WebView fast enough.

Worse, in order to get the proper scrollbar height at load time, you’d need to render the whole content in every WebView for the entire table. We could reimplement the entire main view of the app in a WebView, but that would have a whole other set of performance and UI consequences, and be a lot of work.

I think Buzz’ conclusion is apt:

I think the absence of such an API on iOS is holding the platform back as a media platform more than almost anything else I can think of.

1. Uncharacteristically, we didn’t bill for the time – partly because she was learning, and partly because it seemed so ridiculous.

Watch me learn design via Prism's add button iterations.

There are a dozen apps that do the same thing as yours¹. To stand out, your users must to be delighted by your product – from icon to settings screen. You get there by designing, aligning, and refining each screen, nook, and edge case.

Most programmers act as if their ability to program prevents them from making something look good. This is bullshit. There are hundreds of counterexamples, ranging from Loren Brichter to Mike Rundle. You get good at design exactly the same way you get good at programming: you do it badly enough times to become mediocre, then you do it mediocrally until you become good.

Maybe you don’t enjoy design, which is fine. However, most engineers haven’t really tried it because they think they’re incapable. If you’re really unsure where to start, do a bit of reading about spacing and alignment. Spend some time trying to reproduce a nice-looking button or effect. Pull apart somebody’s .psd and reverse-engineer it.

Then here’s what you do: next time you’re tasked with adding a feature, take a serious shot at how it should look. Do your best to line up that new button with the existing ones. If the existing styles in the app clearly won’t work, try tweaking one until it’s close.

Your goal is to add a new feature, then have the designer that usually fixes your “programmer art” leave it alone². It may start small – an error message or edge case, or a new element that just needs to be well aligned and balanced with what’s already there.

The more design practice you get, the more opportunities it will open. The prototypes you present to superiors will become more impressive. Your personal website will stop looking like it’s from 1998. The designer time spent on your features will go to polish and “wow” instead of just getting things up to par with the rest of the product.

Before you know it³, you will have become a unicorn. That’s right, every startup’s dream: a Desingineer. You’ll likely continue to focus on programming, but you’ll have become more powerful than you could possibly imagine.

Or at least, you’ll make wonderful looking products that people want to use. That’s a good start.

1. If there aren’t, you’re either crazy, or there will be soon.
2. Admittedly this was very hard at Apple, but I got pretty good at it. The trick was to find some function or edge case that had yet to be mocked up by Design, and implement it so well that it looked like it had been reviewed.
3. Well actually, after thousands of hours of practice, but close enough.

The first 10% of our work on Prism was getting full-screen images loading from a few sites. The other 90% was crazy amounts of polish: captions, multi-threaded loading, Recommended Galleries, generating nice thumbnails, storing images for offline use, not storing too many images for offline use, and so on. We had to make a judgement call between being the best at we do (pulling images out of HTML) or instead focusing on supporting every site in the world. Looking at Prism 1.0, I think we made the right call.

Looking forward, there are a lot of sites we’d like to add support for – Twitter, Facebook, Google Reader, and Flickr are some big ones, but the sites users request will get support first. If you’re interested, please give Prism a try and let me know what you think.

Onward!

Buzz Andersen, a longtime Objective-C developer, has a good example in  his post about dogmatic Native vs. Web arguments:

To me, one of the textbook examples of something the web is made for but is practically rocket science on iOS is text rendering. While users are accustomed to thinking of iOS apps as exceptionally beautiful and visually sophisticated, UIKit’s text rendering capabilities turn out to be frustratingly primitive, making it quite a challenge for even expert iOS developers to match the advanced page layout and text formatting capabilities of web browsers.

The point is that although ignoring the great strengths of native code can lead to an inferior app, ignoring the great strengths of Webkit can also lead to an inferior app. Dogma doesn’t help build wonderful products – choosing the right tools does.

JSConf was the largest crowd I’ve presented to so far (about 200 by my count) but it was worth the pressure for sure. Any feedback on my presentation style would be really helpful. Maybe next year I’ll give a talk entitled ‘Eliminating all the “uh”s and head bobbing you see in videos of yourself giving talks’.

A huge component of that polish is responsiveness: giving the user an instant reaction to everything they do. Making your app faster and more efficient is good, but there’s more to responsiveness than speed.

60 frames

Your goal is 60 frames per second: the natural frame rate of the device, faster than the user can perceive. During animations and transitions, 60fps means a smooth transition with no stuttering. Although this is important for all animations, it is crucial in animations that are responding to a user’s touch. Even a very subtle delay between touch and response will give the feeling that the app is sluggish. This is a big reason that JavaScript “fake scrolling” gets such a negative response from users.

When responding to user feedback, 60fps means no stalling. If your app stalls for a frame on any supported device, it’s a bug. As long as the delay is small it might not be a high priority bug, but it is still an opportunity. Profile your app to get an idea of where your frame rate drops. It’s often worth keeping an older device to do this testing on, since if you can even get the older device up to 30fps, you’ll be in good shape on newer devices.

Actually getting a faster frame rate often involves either avoiding waste like drawing offscreen views, unnecessary opacity, or inefficient algorithms. Often though, getting a smooth frame rate involves moving work off of the main UI thread.

Threading

By default, any code you write runs on the main UI thread. If you do anything on the main thread that takes more than 16 milliseconds, you’ve dropped a frame and there will be a perceptible stutter. 16 milliseconds is a really long time, especially on newer hardware, so this isn’t as dire as it sounds.

Your biggest thread-blocking monsters are I/O operations. If you read or write a file or do any network operation, you need to do it in a background thread. On iOS this is a lot simpler than it is in plain C. The NSURLConnection class works asynchronously by default, plus Grand Central Dispatch and Blocks make most things straightforward to make asynchronous.

Although moving file, network, and data crunching to separate threads is important for any app, it’s doubly vital on mobile. Your phone doesn’t have a wait cursor, and its network quality can be incredibly bad. If you block for long enough, the OS will kill your app.

Spinning

Now that your work is asynchronous, you need to let the user know something is happening. Provide a progress indicator if possible and worthwhile. Otherwise, get spinning.

Activity indicators (whether spinning, pulsing, or jiving) let your user know that you’re on the job and should go up after any perceptible delay. Without feedback, your app could have crashed, or it could have finished but without the results the user expected. You never want people wondering what your app is doing.

A special kind of activity indicator is placeholder content. Users can sometimes navigate through your app faster than you can render content, especially if you need to fetch something from the internet. For things like avatars and other peripheral information, a tasteful placeholder is definitely preferable to a distracting spinner.

Backend responses

So you have spinners now, but want to show them as briefly as possible. Although ideally you respond within 16ms, users are used to waiting for internet content to be delivered, especially when they know their wireless connection is weak. Even on a good wifi connection, your app’s request will have perceptible latency to get to the server and come back with a simple response.

Unfortunately, any time your backend servers take in responding is in addition to that latency. Every moment it takes for you to get a response back to the user is more frustration and impatience. Your goal should be to get content back to the user in 100ms¹. After one second, users lose their feeling of task flow. On the web, users are intolerant of waiting for servers to respond. Within a mobile app, they are even less tolerant – if you can’t provide a faster experience than a normal web site, you might as well just have a web site.

Launch time

While launching an entire app in one frame is not likely, launching before the user feels a wait is possible, and launching in a second is often straightforward. Launch time affects the most important use case for your app: first use. If you can’t get the app loaded and fully functional in a second, you should at least get it awake and giving activity indication in that time.

Doing some simple profiling of app launch will usually reveal unnecessary work you’re doing at launch. Whether it’s building views that aren’t being displayed yet, loading content that isn’t necessary, or blocking on some operation that could be threaded, you can often get some easy wins without a lot of work.

Tap highlights

Every tap should have consequences when you lift your finger. First, though, comes an indication of a successful tap when you touch down. This provides a visual response for actions that cause a few frames to drop but last less than 100ms. Unlike with a keyboard or mouse, the user has no tactile feedback that they tapped successfully. They have no way of knowing they tapped on the right thing until it highlights.

Result: Joy

Congratulations! You now have a responsive app that is a joy to use. Of course, it also needs to be functional, usable, beautiful, and useful. But that is for another day.

1. IBM did this research decades ago, but Jakob Nielsen has various explorations of it online.

However, consumers have never bought in. Businesses do, prosumers do, enthusiasts do, but normal people don’t. For a decade people have tried to make “micro-subscriptions” a reality – a way for normal people to pay a small amount to get a content or service. They’ve all failed utterly.

There is no way people will put in their credit card info into various sites and apps to pay a $1/mo fee. The cognitive pain of creating accounts, entering and maintaining payment info, and being billed for it makes the whole thing a complete non-starter to most consumers. And so, consumer apps continue to be offered as advertising-supported affairs that need giant scale to be profitable, or, more recently, pay-once apps.

iOS subscriptions finally change this. Although Apple takes 30%¹, the one-click nature of the process and safety net of the App Store means for the mass market you’ll get way more than a 30% boost in sales.

The same app offering the same value to the mass market is going to get 50x as many customers through one-click subscribing at $1/mo than it would get through sending them to enter their credit card information on some website. I may be wrong – it may be more like 500x.

Entire products that were infeasible before are now feasible. Micro-subscriptions are here. Enough writing – back to writing an app that kicks ass with them.

1. I am aware Apple’s cut makes the “you must offer in-app if you have subscriptions” rule a slap in the face for some business models. Apple can’t really charge much less than 30% because they sell iTunes cards at retail, plus it would provide a way to route around their cut for app sales. Still, forcing everything through them sucks.

Now, it’s true there are some ways to make money from web apps already. There are actually three¹:

1. Sell advertising on your multimillion-user site. Often this requires VC to ramp up to a huge user base.
2. Sell your app as a service to companies that subscribe. This can be quite profitable but consumers aren’t willing to do this.
3. Get paid directly to build custom web apps.

The Chrome App Store is irrelevant for the above categories of software since they’re profitably humming away. However, there are a lot of potential web apps that don’t fit into the above categories. Specifically, consumer-oriented apps that aren’t appropriate for the “scale huge, sell ads” model. Some examples:

• Games
• Specialty consumer software (like WeddingDJ)
• Personal productivity and finance software
• Magazines and newspapers
• Most stuff on the iOS App Store

Most web developers in the above markets attempted to do the obvious: charge customers to use their sites. However, having to put in your credit card info or jump through a PayPal hoop to pay for something online is a pain in the ass. It can’t be understated: a credit card entry form is a brick wall to most consumers. The vast majority of them would never consider putting their credit card info in to pay for a web site, no matter how good it is.

Those same people don’t think twice about paying for apps, especially as a one-time fee. Hence, the great success of the iOS App Store. The App Store, and iTunes before it, and Amazon before it, showed that people will pay to buy things online if they can just click. Developers flocked to the iPhone because you can make money there, myself included.

A lot of people would love to make web apps for consumers, but their ideas aren’t viable under the advertising model. It’s insanely hard to bootstrap a consumer-facing web startup because of this. As a consequence, startups that would have been building web apps five years ago are now building iOS apps. The web is a great platform, but if consumers aren’t paying you, then you’re limited in what you can build.

So now we wait and see if consumers embrace the Chrome Web Store. If they do, expect to see a whole new wave of web apps.

1. Arguably, the fourth way to make money on a web app is to wrap it in PhoneGap and stick it on the iOS app store. While tangential, the fact this is a popular route reinforces my argument.

Get started by recognizing a vacuum. If you wish there was a meetup in your city for a given technology, there’s probably demand. It’s easier to get momentum behind something that’s hot like JavaScript, but as long as there’s interest, you can pull it off. Once you’ve picked a topic, gauge interest on your favourite social medium. If you can get 5 or 10 people on board to attend, you’re ready to apply the following recipe.

What (The Format)

Two speakers for 45 minutes each. People just can’t learn for longer than 45 minutes. If your talks are under an hour, they’re digestible, don’t leave people exhausted, but are long enough that you can get into a satisfyingly technical topic. Even shorter is fine.

Having two speakers will double your potential audience, and you’ll challenge people who might think they only care about one topic. You can’t really vet the talks in advance, but one rough talk paired with one strong one will still make for an enjoyable evening.

To finish up each night, lead your crowd out for a drink. This turns a group of lecture attendees into a community. You’ll find out what people want to see at the next meetup, meet future speakers, and get to hang out with the perfect crowd: one you created around your favourite technology. Attending the talks is a filter that makes the beer conversation simply awesome.

When (The Schedule)

A weeknight every couple months is a good pace. You might get pushback on weeknights, but it turns out that a lot of the fun and interesting people are busy on Friday and Saturday nights. Speakers probably want to be home with their family on weekends, and meeting space and afterparty space is easier to find on weeknights.

If you have a really top-notch speaker who will only be in town at a specific time, schedule your event then. Still, every two months is a good frequency to make sure you don’t run out of good speakers or topics, encourage people to come out when it does happen, and keep yourself from burning out.

Who (The Speakers)

If possible, set the tone by being speaker #1. Then recruit the friends and the contacts you have in the field to come talk. Modest folks will claim they aren’t qualified, but most programmers are experts about certain topics without even realizing it.

Once the meetups are attracting people you don’t know, chat them up. Ask if they’d like to give a talk, or know anybody who would. When you go to conferences, seek out the people you’d love to see speak and pitch them – ask if they’ll be in your city anytime soon.² Have others do the same. Once speakers can see you’re a regular meetup that seems to be organized well, they’ll be willing to give a talk. In general, just find people who are doing great work and reach out to them.

When looking for speakers, look for advanced topics and specific talks. You’re better off blowing people’s minds than boring them. Going for advanced content will challenge people to learn, keep the list of new topics long, and excite the type of people you want. Focused talks also work as a nice filter for “the scene”³ taking over your event.

Where (The Space)

Most cities have coworking spaces for startups and small businesses that will happily host a tech meetup. The best spaces are walking distance to both the local tech startups and a good beer place. Once you grow beyond coworking spaces, seek out companies locally that are hiring programmers who use your technology.

These companies will be happy to sponsor space for your events. A couple key contacts here can be the key to getting speakers, space, and good people to go for beer with. For example, about half of VanJS’ speakers come directly or indirectly through the awesome folks at Joyent and Nitobi.

Why (The Reward)

Building a successful tech meetup connected me with lots of awesome people and helped me launch Steam Clock. More importantly, it gave me the meetup I’ve always wanted. I get to book the talks I want to see, and once the projector is set up and everything’s under control, I can sit back and learn something awesome. All in all, it’s definitely worth the hard work.

1. We’re #6 on Meetup by members for JavaScript-specific groups. If you look at recent attendance, we’re the largest outside of NYC and the Bay Area.
2. This is how I got John Resig to VanJS: I chatted with him at a conference and asked if he’d be in Vancouver anytime soon. Nothing magical to it, he’s just a cool guy.
3. What I mean by “the scene” is people who identify as part of the tech community, but don’t actually care much about your meetup’s topic. Bless their hearts, but before you know it you can have a Liveblogged Social Media Tweetup instead of a technology meetup. If that happens, the people that get shit done will stop coming to the events and go back to getting shit done.

1. If you use the famed Cocoia PSD for your icon, your icon can get back fringing on the App Store and on iOS 4. The best way to do an app icon is to submit it as a square and let Apple’s software apply the rounded corners.
2. Getting reviews can be hard (if your app doesn’t crash or annoy people). Giving out promo codes doesn’t work (code redeemers can’t review the app) and your beta testers have to buy the app to review it.
3. Submit all the forms to Apple as soon as you can. There are at least four, and they happen at the speed of mail¹.
4. Use AppViz instead of the Sales and Trends portion of iTunes Connect.
5. If you have an update that’s been waiting to be reviewed, you can’t upload a new binary and keep your spot in the queue. And I thought I was so clever.
6. If you don’t complete all steps of the registration of an app name, it can get stuck in limbo and be unusable. This is why our app is “My” WeddingDJ on the app store for now. It looks like Apple is trying to improve this somewhat.
7. Pay per click advertising is hard to do profitably. Even for a $5 app, it’s easy to pay more for clicks than you get in completed purchases. Since you can’t track a click through to a purchase, and your sales reports are daily, it’s hard to fine tune your campaigns.
8. If you do run an ad campaign, try targeting a specific country. If all your Facebook ads are in Australia and you got zero sales in Australia, then you know it’s not working.
9. It only takes $5 of sales to be the #12 highest grossing music app in Poland.

We’ve learned a lot more about the other facets of iOS development, so stay tuned for more.

1. There’s a general Paid Applications contract that everybody needs. If you’re Canadian, you need to fill out an HST form before you can sell your app. If you want to use Apple images on your website, there’s a form for that. If you want the Japanese government to not withhold 20% of your income, there’s a form for that.