At WWDC this year, one topic of conversation that came up over and over was how to design for iOS 7. Like a lot of indies, I usually do much of the interaction design of my apps myself and use a proper designer only for the graphical design. This was feasible for me in the past not because I’m particularly gifted at interaction design, but because I always had plenty of examples to draw inspiration from. Apple’s built-in apps were, of course, the archetype for how an iOS app should behave, but lots of third-party apps also gave great examples of how to tackle the interaction problems that I encountered in my own apps. Now, of course, I see the weakness of that strategy. It worked great under iOS 6 because of all the third-party examples I could draw upon, but iOS 7 is a reset. Right now, there are exactly zero apps in the App Store that are designed for iOS 7, and that lack of example and inspiration is going to be a problem for me and for a lot of other indies as we prepare for the launch of iOS 7.
My concerns over iOS 7 preparations lingered during WWDC, but once I returned home I realized my mistake. In fact, there is already an app in the App Store from which I can draw inspiration for this new style. An app that adopts the look and feel of iOS 7 by elevating the content over the chrome. An app that uses color and animation in the style of iOS 7 to clarify content. [pullquote align=”right”]”For all intents and purposes, Vesper is the first iOS 7 app in the App Store.”[/pullquote] I realized that, for all intents and purposes, Vesper is the first iOS 7 app in the App Store. Despite being an iOS 6 app, Vesper adopts the major idioms of iOS 7 and serves as a great example of how developers can adopt those same idioms and still retain an individual identity for their app.
You may already be familiar with Vesper. It’s a notetaking app that launched towards the beginning of June 2013, just a few days before WWDC, and got a lot of press coverage in Mac and iOS circles. Vesper was created by Q Branch, which is made up of three people familiar to the iOS developer community: John Gruber, the writer behind Daring Fireball; Brent Simmons, the creator of NetNewsWire and Glassboard; and Dave Wiskus, a respected designer and the co-host of the Unprofessional podcast. It was clear from the beginning that these three created a great app, but it wasn’t until after WWDC that I realized Vesper actually anticpated a lot of what makes iOS 7 different.
One of the first things you notice when you launch Vesper is how clean the interface is. As you can see in the screenshot to the right, Q Branch used the bare minimum interface needed to support the functions of the app. In his post-mortem on the design of Vesper, Wiskus commented on the influence of the bare visual style of Letterpress:
As it happened, we were all heavily addicted to Letterpress, and we wondered aloud if that visual style might be where the puck was headed. If so, what would that mean for UI in general? The only way to pull it off well … was to strip away everything and add back only the pieces that we needed.
As it turns out they were right on the mark. This style of clean, edge-to-edge design that emphasizes content and deemphasizes the interface was exactly where iOS 7 was headed. As Jony Ive explained in the WWDC keynote address, “In many ways, we’ve tried to create an interface that is unobtrusive and deferential. One where the design recedes, and in doing so actually elevates your content.” And that’s exactly the effect we see in Vesper. Without toolbars, without even separator lines between table view cells, Vesper draws users’ eyes to the content so they can quickly access their information and be on their way. This deference to content is going to be a hallmark of iOS 7 design and will be something for all developers to keep in mind as they plan for the future.
In the end, though, Vesper is an iOS 6 app and there’s only so far that Q Branch could go in removing interface chrome and still have it fit visually within the iOS 6 ecosystem. The current iOS 7 beta goes even further than Q Branch could in removing interface elements, going so far as to use white navigation bars that blend in with backgrounds, and reducing buttons to mere words with no edge. With so few interface elements remaining in iOS 7, how can a developer draw attention to important parts of the display? The answer is color.
The developing convention in iOS 7 seems to be to colorize interface elements that are tappable or active, and to remove the color from elements that are inactive. Apple uses this convention in iOS 7 by desaturating interface elements that are “covered” by alert views, for instance. Vesper also uses this convention to great effect when the “hamburger” button is used to access the “basement”, as illustrated in the video to the right. As you watch the video, notice how the navigation bar smoothly animates from slate blue to white as it slides to the right. This color change is a subtle, but very effective way to communicate to the user that the navigation bar and its contents are no longer what is important in the interface once it’s slid out of the way.
Speaking of animation, it’s become clear from the WWDC Keynote that animation and movement are more important than ever in iOS 7. With so much of the interface chrome removed, animation has become the new affordance, giving hints to the user as to how different interface elements should be used. Animations in iOS 7 also serve the purpose of deference to content, which was mentioned earlier, by helping to provide continuity during screen transitions. This use of animation is illustrated very well by Vesper’s transition from a list of notes to an individual note.
As you watch the video of Vesper’s screen transition to the right, notice that it lacks the usual slide animation that we’ve come to expect when “pushing” content onto a navigation controller. Instead, the thumbnail content smoothly animates to it’s final position and is replaced by the full content. By never pushing the visible content off the screen, and instead animating it into place, the eye is able to track the visible content through its journey, and thereby continuity is established between one screen and the next. This continuity immediately orients the user to the placement and purpose of the screen’s content in a way that a simple slide animation never could. This type of animation is used throughout iOS 7 and I think developers will find that clarifying animations such as this will become expected in apps as the iOS 7 ecosystem matures.
One concern that I repeatedly heard from developers at WWDC dealt with their ability to maintain individual identities for their apps when adopting an iOS 7 look and feel. After all, if most of the interface chrome is removed from apps, how can one app be distinguished from another? How can an app avoid being mistaken for a system app, or worse, a competing app? This problem is exacerbated because of the example Apple has set in the built-in apps shipping with the iOS 7 beta. Perhaps in yet another nod to deference to content, all the navigation bars in these built-in apps are either white or black, with color primarily found only in buttons and other controls. Under these conditions, it’s hard to see how an app based on a navigation controller can establish its own identity.
Vesper shows us a way, though. First it bucks the trend of the built-in iOS 7 apps by using color in the navigation bar. Yes, it’s flat color, but it’s still color. With the navigation bar extended under the status bar, lighter weight fonts, and perhaps a bit of transparency, it’s easy to imagine Vesper’s navigation bar fitting in nicely on iOS 7. The second way that Vesper creates its own personality is through its use of typography. Again in his Vesper post-mortem, Wiskus wrote:
Fonts were probably our single largest expense. We tried many, many faces in Vesper to see what felt right, and striking a balance required a lot of careful consideration.… Eventually we landed on our beloved Ideal Sans. But the story of Vesper’s typography doesn’t end there. We still had to consider weights, colors, placement, cap style, number style, then throw it all away and go back to Helvetica, only to realize what a huge mistake we’d made and beg Ideal Sans for its forgiveness.
The result of Q Branch sweating the details of typography is an app that feels at home on iOS, but that has a subtle style all its own. With the typography improvements in iOS 7 that were alluded to in the WWDC keynote, developers now have the ability to go beyond what Q Branch did with Vesper and create an even more impressive typographic style that’s all their own.
With so much of iOS 7’s new design anticipated by Vesper, it’s natural to wonder how much of this is coincidence. Did Q Branch get tipped off? Or is this just a matter of great minds thinking alike? Who knows. With this group of characters, it could be either or both. Ultimately, though, it doesn’t really matter. What matters is that now we all can see the new direction that iOS is heading. We know that in iOS 7, content is king. We know that in iOS 7, color and animation are more important affordances than ever before. And thanks to Vesper, we now know that it’s possible to combine these traits of iOS 7 to create a unique app that retains an individual identity while at the same time fitting into the rest of the iOS 7 ecosystem. If you’re one of the many now thinking about your own app and its transition to iOS 7, I suggest that you consider what lessons you can take from Vesper. It’s a great app, but I think we’ll soon see that it’s a great iOS 7 app as well.
I’ve been doing a lot of speaking over the last few months on the topic of accessibility in mobile software.1 The part that I enjoy most about these speaking engagements is the opportunity it gives me to talk to other mobile developers and designers after my presentation is over. In these conversations, I’ve noticed a few recurring themes. Over and over I hear developers lament, “I wish I had the time to do accessibility right!” or, “I know accessibility is important, but it seems too complicated.” To address these problems, I’m happy to announce that we are now offering accessibility consulting through Leaf Hut Software. Specifically, we now offer accessibility reviews and accessibility training for developers, designers, and their teams.
If you have an app and want to ensure that it is as usable as possible by people with disabilities, but lack the time or experience to properly implement accessibility, Leaf Hut Software is happy to help. We can review your app and provide a detailed list of what you’re doing right as well as specific suggestions that would improve the accessibility of your app for those with visual, motor, and other disabilities. For teams that require it, we also offer development services to implement the suggestions that arise through the review process.
If your team lacks experience with designing accessibility into mobile software and wants to learn more, Leaf Hut Software can help with that too. Courses are available to train your team in applying Universal Design to mobile software, and in implementing VoiceOver in iOS apps. Training can be customized to suit your team’s current level of experience, and can be tailored to suit teams of developers, designers, or mixed teams. Don’t let a lack of knowledge be the thing that holds you back from creating world-class apps.
Mobile software has proven to be a liberating and empowering technology that’s opened doors of opportunity for people with disabilities, and I believe strongly that accessible software should be made as available as possible to the people who need it. Let Leaf Hut Software help you put your apps in the hands of everyone who needs them. For more information about our accessibility consulting services, please see our consulting page. To inquire further about our services, you can contact us by email.
For the benefit of non-developers, “accessibility” in the context of software refers to making software as usable as possible for people with disabilities, usually physical disabilities. ↩
Since it was first introduced in iOS 3.0, in-app purchase has emerged as an important tool that iOS developers can use to bolster their revenue and stay in the black. In-app purchase only helps, however, when money actually changes hands. To that end, Apple has invested a lot of effort to give developers the tools they need to ensure that the in-app purchase requests they receive are legitimate and not spoofed.
The most important tool that developers can use to ensure the legitimacy of an in-app purchase is the digital receipt that’s received from the App Store when a transaction is completed. This receipt is cryptographically signed and can be verified as genuine by submitting it to a special server that Apple provides. The trick is, this receipt has to be submitted in a particular way. As Apple points out in its documentation, developers should submit in-app purchase receipts from a separate server that they control in order to avoid opening doors for those who would steal their work.
Many developers have gotten sloppy with their receipt checking, though. Despite Apple’s advice, many developers don’t bother to submit receipts for verification from their own server. Instead, they simply send the receipts to Apple’s verification system directly from the iOS device that was used to purchase the product. Developers that take this shortcut are leaving themselves vulnerable to what’s known as a “man in the middle” attack, which can be used to trick the app into delivering in-app purchase products for free. This vulnerability was exploited in a big way in July, 2012, when a hacker set up a server that took advantage of sloppy receipt verification and allowed owners of iOS devices to receive, for free, digital goods that should have required an in-app purchase.
It’s easy to see why developers would take shortcuts. Setting up a separate server for in-app purchases is a pain. Since a receipt verification server would be handling purchases, a developer would want it to have high availability, with very little down time. That means that most common, low cost, shared web hosting providers are ruled out. Many alternatives to shared web hosting providers aren’t very attractive either. Most require either much higher fees, or expertise in tuning and maintaining a server, or both. In addition to these problems, writing the server-side code that interfaces with the iOS app and Apple’s receipt verification server isn’t necessarily easy. The languages and technologies used in server-side scripting are very different than those that are used to write iOS apps, so many developers have an additional learning curve to overcome.
Fortunately, several “backend as a service” (or BAAS) providers have sprung up recently, including companies like StackMob, Parse, and Kinvey. These BAAS providers essentially offer their customers a database that can be accessed over the web, but some of these providers offer additional services as well. For instance, one of StackMob’s selling points is that it allows customers to run their own code on the StackMob servers. This provides an opportunity for app developers to validate their in-app purchase receipts using StackMob as their Apple-recommended “separate server that the developer controls.”
Using StackMob as a receipt verification server offers a developer several benefits compared to other options. StackMob provides a professionally managed enterprise-ready platform. Since StackMob handles all the system administration responsibilities, the developer doesn’t have to worry about scaling, hardware configuration, and other similar headaches. Best of all, StackMob recently changed their pricing structure. Instead of charging per API call as they used to (and as most of their competitors continue to do), they now offer a package of basic functionality for free and then charge extra for add-ons. One of the features of their basic free plan happens to be custom server code. StackMob’s pricing can change at any time, of course, but as of today it appears that the only thing preventing StackMob from becoming a free in-app purchase receipt verification platform for all iOS developers is the lack of the custom server code needed to actually validate the receipts.
And so I offer my StackMobIAPReceiptVerification project, which is now available on GitHub. StackMobIAPReceiptVerification is an in-app purchase receipt verification routine I wrote to run on StackMob’s custom server code platform. Once installed, it accepts in-app purchase receipts, validates them on Apple’s servers, and responds with a success code and the information contained in the receipt (if the receipt is valid). Since the routine has a RESTful interface, it can be called using NSURLConnection (and related methods), or using StackMob’s iOS SDK. For all the details, check out the project’s page on GitHub.
I hope that other iOS developers find this project useful. I know that there are many out there who haven’t bothered to set up receipt verification only because of the nuisance of it all. Hopefully StackMobIAPReceiptVerification will remove some hurdles and make it easier to ensure that you’re being paid for your work.
The subject of App Store pricing has popped up on my radar a lot recently, and I’m a bit surprised since I thought that debate had been long-since settled. After all, prices quickly dropped after the launch of the iPhone App Store, and it’s been downhill ever since. Today, anything above 99¢ is regarded by many to be a "premium price," as so-called "freemium" pricing is becoming the norm in many categories.
I started hearing again about app pricing when Joe Cieplinski (@jcieplinski) gave his presentation titled "Avoiding the Race to the Bottom" at 360iDev. Then Twitter lit up last week with chatter about Michael Jurewitz’s (@Jury) well-received Çingleton talk in which he reportedly advised developers to double their prices if doing so would cost them less than half their user base. Most recently, <http://tapbots.com>Tapbots released its long-awaited Mac version of Tweetbot at the absolutely scandalous price of $19.99. So what can we take from all this recent discussion?
First, I think there’s a growing awareness on the part of developers of how hard it is to build a business on the back of 99¢ downloads. In his 360iDev presentation, Cieplinski displayed a graph of estimated App Store revenue among all developers. The graph was exponential, but in this case the long tail was really long. Only a small fraction of developers were in "viable business" territory. This is corroborated by a survey conducted last year that found that the median annual revenue for game developers is under three thousand dollars. Cieplinski’s point, and I think it’s a good one, was that you’re unlikely to build a long-term business on 70¢ of revenue per customer (99¢ less Apple’s 30%) without some really attractive in-app purchase or outside venture capital. (And as the joke goes, if you take VC, now you have two problems.) Instead, Cieplinski suggested that developers should charge a higher, more sustainable, price in order to reach their revenue goals over the long-term.
For example, let’s consider an app developer who has a $100,000 annual revenue target. To reach that target with an app priced at 99¢, he would need 142,857 purchases per year, or 391 downloads every single day. For most, getting almost 400 paid downloads day after day is unlikely, to say the least. But if he raises the price to $9.99, he would only needs 39 downloads per day to reach his target. If he raises his price to $14.99, he’d only needs 26. These are much more reasonable numbers for most developers considering the typical advertising budget. But will people pay these prices in the App Store? That brings me to my second point….
Many people made a really big deal out of the $19.99 price point that Tapbots recently chose for the Mac version of their incredibly popular Twitter client, Tweetbot. Some claimed it was way overpriced and labeled it a ripoff or worse. Tapbots’ pricing strategy was quickly proven, though, as Tweetbot for Mac climbed the Top Grossing charts. The success that Tweetbot enjoyed, despite being expensive by App Store standards, demonstrates that a lot of customers will pay more for a quality product than is usually asked. It also suggests a corollary: A lot of developers are leaving a lot of money on the table by undercharging for their software.
When I tweeted a similar sentiment a few days ago, some challenged me claiming that Tweetbot was a special case. They maintained that Tweetbot’s success at a sustainable price was possible only because of Twitter’s policies which introduced an artificial scarcity into the market. While it’s true that Twitter’s user- and developer-hostile policies have caused an artificial scarcity, to dismiss Tweetbot’s success as unique and unrepeatable is to ignore a fundamental underlying fact: A lot of people paid a lot more than is customary for that app. Tweetbot is proof positive that many people will pay sustainable prices. The question is, under what circumstances is that true?
Tweetbot’s success suggests that many of us have had the psychology of the App Store customer dead wrong. It’s not that App Store customers are price sensitive, it’s that they’re risk averse. Under the circumstances, their aversion to risk makes a lot of sense: They’re being asked to shell out their hard-earned money for an app that they haven’t tried before, and for which it’s hard to get a refund. Add in the fact that many of these customers have been burned before when they bought one of the thousands of garbage apps out there, and it’s easy to see why they would be resistant to paying a sustainable price for an app, sight unseen. Tapbots’ gold plated reputation for quality goes a long way towards reducing the risk that a customer associates with the purchase of Tweetbot for Mac, and I believe that’s why they succeeded at a higher, more sustainable, price than is ordinary.
When you look around the App Store, there are actually several companies that are prospering through the use of sustainable pricing. Instapaper has prospered despite being more expensive than its competitors. Cultured Code and AgileBits both have their apps priced at or above $9.99 and have thrived in the App Store. More than any other company, The Omni Group has made it their standard practice to choose and stick with sustainable prices for all their apps. But it’s not just productivity and business apps that can do well with sustainable pricing. Utilities like App Cubby’s Launch Center Pro, educational software like Vito Technology’s Star Walk, and even games like Sword & Sworcery have all done well with higher prices than the norm for their respective categories. The one thing that they all have in common is a reputation for quality and long-term value. This reputation has given their customers confidence in their purchase and allowed the companies to charge more for their products.
So how can the successes that these companies have had with sustainable pricing be duplicated by other developers who don’t (yet) have a similar reputation? The trick, I believe, is to do everything you can to reduce the perceived risk that potential customers associate with purchasing your app. Some things are obvious. Start with a quality app that does its job well. Have a really nice website – maybe even pay a designer to replace all your crappy programmer graphics. Have a beautiful app to show off in your App Store screenshots. Maybe put a video on your website showing your app in use. Other things aren’t quite as obvious. Have excellent customer support and make sure that that excellent support is highly visible. Place prominent support links in your app and on your web page. Also, use a self-hosted message board or a third-party solution like Get Satisfaction for support. This allows customers to receive self-service help, but it also shows off your excellent service to potential customers and lets them know that they won’t be left high and dry should something go wrong after their purchase. In general, anything you can do to impress upon the potential customer that you are legit and that they won’t be swindled will make it more likely that those potential customers will pay more for your app.
I can already hear your objection and yes, you’re right, these types of marketing activities won’t catch the attention of all potential customers. A lot of people who shop the App Store won’t do any research before purchasing, and won’t see the effort you’ve put forth. But if you’re charging a sustainable price, that’s ok. The sales you’re going to lose due to having a higher price are, quite frankly, customers that you didn’t want anyway. The customers you’re going to lose are the support headaches and those who leave a one star review for trivial reasons. By charging a sustainable price, you’ll be left with customers who have taken the time to educate themselves about your product, and who are motivated to seek support rather than leave a bad review. And because you will have charged a sustainable price, you’ll more than make up the difference from those lost sales through your increased per unit revenue.
So am I suggesting that every app should be priced at $9.99? No, certainly not. Every App Store category is a different market, and every app has different competitive forces at work upon it. A "sustainable price" is going to mean something different for every app. But, as Jurewitz suggested in his Çingleton presentation, I bet most apps could safely double their price. I bet most 99¢ apps would generate more revenue priced at $1.99, just as I bet most $3.99 apps would make more if priced at $7.99.
Messing with your product’s pricing is scary, I know. Our businesses rely on steady revenue, and whenever we raise our prices there’s a fear that we’ll price ourselves out of the market. The recent success that Tweetbot has had at a higher price point should serve as a wake up call to all of us, though, and embolden us to take a hard look at our own pricing strategy. Perhaps now is the time to start pricing for long-term success.
I wrote earlier that I attended 360iDev a couple weeks ago. I also got a chance to attend SecondConf in Chicago last weekend, where I had the opportunity to speak. SecondConf was a lot of fun, but I couldn’t help but notice that a lot of people weren’t getting as much out of the conference as they could have. I just wanted to walk up and say, “You’re doing it wrong!” I resisted that temptation, but in a spirit of helpfulness, I thought that I’d share with the world a few tips that I’ve discovered to help make your conference experience more enjoyable and valuable. So without further ado…
Attend Sessions
Every technical conference that I know of has sessions that you can attend. Do that. The conference organizer has gone to great lengths to select a line-up that includes experts in different topics. It would be silly to not take advantage of that resource. And when you attend a session, take notes. Take out your developer notebook (You do have a developer notebook, don’t you?) and jot down the the session name, the speaker’s name and his contact information. Then jot down anything that sounds interesting or that you might want to follow up on. This isn’t high school, and there isn’t going to be a test, so there’s no need to go crazy with the notes. Just jot down things that you didn’t know about before. Future you will be glad that you did.
Choose Wisely
If you’re attending a multi-track conference, you might get to choose which sessions to attend. But a choice is both a blessing and a curse. What if you choose wrong? What if you sit through a "meh" session only to later discover that the session right next door was incredible? How can you avoid disappointment? Well, there’s no sure-fire way to make sure you get into the best sessions, but one trick I’ve found is to choose which session to attend based on the speaker, not the topic. Choose a speaker who has a reputation for being outgoing and entertaining. In my experience, a great speaker can make even the most bland of topics interesting and memorable. Also, be wary of overly technical talks. No matter how important the technology, there’s nothing worse that sitting through slide after slide of code. When it comes to these types of code-intensive presentations, you’re probably better off buying the session video after the conference. Then at least you can rewind as needed.
Mix It Up
Sessions are great, but most of the value of attending a conference comes from the people you’ll meet. Meeting new people and strengthening existing relationships are the best use of your time while you’re there. Introduce yourself to others. Go out of your way to sit with people you don’t already know – maybe even ask a table of strangers if you can join them for lunch. Avoid only hanging out with people that you already know. Mix a little. Whatever you do, don’t hole up in your room working on code. Don’t like to "network"? Then don’t call it that. Call it "making new friends". Because that’s all you’re doing.
Leverage Social Media
Don’t worry, this isn’t going to devolve into some sort of SEO presentation on how to increase your Klout score. My point is, you probably already know people on Twitter that are attending your conference, so go out of your way to meet them. My new friend Matt Klosterman (@IfMatt) had a great shirt at 360iDev that read, “Hi! I’m @IfMatt. We should talk.” And you know what? It worked! It helped me recognize him, and sparked a conversation. But you don’t need a special t-shirt to hook up with your online friends. Get on Twitter and put the word out that you’re at the conference and would love to meet your followers. Or, better yet, organize a group to go out and get dinner. It’s one thing to follow someone online, but it’s quite another to have shaken their hand, and maybe shared a meal.
Be Memorable
I had the chance to hear Dave Wiskus (@dwiskus) speak at a conference recently, where he gave a talk entitled "Subjective C". His talk included a collection of stories and anecdotes about non-technical skills, and one of his slides was titled "Be Memorable". And you know what? When it comes to conferences, that’s really good advice. Meeting lots of people is great, but you want the relationships that you form to last beyond the conference. So how do you become memorable? Good question. Being memorable doesn’t have to mean being the life of the party. (Although it can, if that’s your thing.) What it really means is going out of your way to make an impact on someone else. Engage people in meaningful conversation. Introduce the people that you’re with to others. Thank the author of that open source code that you’re using in your project. The most important thing is to be authentic.
Have a Winning Strategy
For the more introverted among you, mingling at a conference and engaging a stranger in converstaion sounds like torture, I’m sure. So let me offer a surefire strategy. No matter how uncomfortable you feel in large social gatherings, there’s always someone more uncomfortable than you. Your job is to find them. So during the social hour (or between sessions), scan the crowd. Look for that one guy standing by himself with a drink in his hand and looking slightly uncomfortable. That’s your target. Walk up and introduce yourself. Ask him where he’s from and what projects he’s working on. That’s it. That’s your conversation starter. Talk for a few minutes, and then move on to the next wallflower. The best thing about this strategy is that you’re not imposing on anyone. Rather, you’re rescuing them! The people you’re approaching are just as uncomfortable as you are, but now they feel included. You’re the hero. And congratulations, you’ve just become memorable.
I’ve now had a few days to recuperate since returning from the 360iDev conference, recently held in Denver from September 10 to September 12, and I have to say it was a great time. While I was there I met a lot of great people, renewed some online friendships, and learned a lot as well. John Wilker (@360iDev) and his wife put a lot of time and effort into attracting quality speakers and making the whole show run smoothly, and it showed. In this post, I wanted to call out just a few of the presentations that I attended and some of the lessons that I took away from them. Hopefully, those lessons will be useful to others.
On Monday, Bill Magnuson (@billmag), the CTO of AppBoy, led a session on “Turning Your Mobile App Into a Business”. Bill had a lot of great ideas to share, but the main take-away that I got was that there is a lot of value in opening multiple channels of communication with your customers. It’s important to be on Twitter and to post to your blog (See? I’m trying!), but you should also be able to communicate with different slices of your customer base. Mailing lists are a great way to get the word out quickly to large segments of your customers, but more focused messaging (like in-app messaging) can also prove valuable – especially when you need to communicate with just the customers of a particular app. If you’re interested in what Bill had to say, you can check out his slides on Slideshare.
Later on Monday, Joe Cieplinski (@jcieplinski) of Bombing Brain Interactive addressed his audience on “Avoiding the Race to the Bottom”. Basically, his argument was that although it sometimes seems like cheap and free apps get all the attention on the App Store, they probably aren’t the best way to build a long-term business. In fact, he argues, higher priced “premium” apps often make for a better experience for everyone involved. Higher prices create a solid foundation on which to build a business and reduce support costs (since there are fewer customers to support), and the users of these apps enjoy better customer service as well as long-term maintenance and support. It ends up being a win for everyone.
The next day, I listened to Gustavo Ambrozio (@gpambrozio), a Brazilian born speaker of Portugese, wrestle with his self-professed hatred of English prepositions as he shared some of the lessons that he learned while developing an open source replacement for UIAlertView and UIActionSheet. Along the way, he delved into some not very well documented sections of UIKit, the meaning of “makeKeyAndVisible” (it makes the UIWindow accept keyboard input), and the beautiful simplicity of blocks. All in all, Gustavo proved to be a very engaging speaker who entertained as he educated his audience.
Finally, on Wednesday, Jay Freeman (@saurik), developer of the jailbreak app store Cydia, spoke to a small room of iOS developers and blew their mind. His talk was titled “iOS Application Security”, but really it was about the security of the many backend-as-a-service (BAAS) companies that are becoming so popular. His session was basically a running commentary on an hour-long demo that he conducted on the vulnerabilities of some third-party services. Over the course of his session, Jay decrypted supposedly secure passwords, pulled out potentially sensitive data that he shouldn’t have access to, and exposed the poor design decisions that allowed him to do all of this. This session was eyeopening to say the least, and I think every developer left the room with a better appreciation of how important proper data security is in a mobile app. Unfortunately, I don’t think that this session was recorded, so I’ll leave you with the tl;dr version: “Servers should never trust the client. Ever.”
Wednesday was also noteworthy as the day of the iPhone 5 announcement. I have to say, it was a lot of fun to sit in a ballroom and geek out with other iOS developers as we watched the Apple event. Luckily for John Wilker, pre-orders weren’t being taken immediately, so his WiFi network didn’t have to withstand the stress test of 350 developers simultaneously attempting to connect to the Apple Store. The Apple event was also fun for me because John allowed me to sponsor a giant round of Buzzword Bingo. John’s volunteers distributed the 400 bingo cards that I had printed with squares bearing phrases like “Magical”, and “One more thing”, as well as rumored features of the new iPhone such as its larger screen. As these phrases were said on stage by Apple presenters, players could mark them on their cards. For prizes, we had some t-shirts, Moleskine notebooks, and iTunes gift cards. It all went about as smoothly as I could have hoped, and I think everyone had a lot of fun.
I want to thank John Wilker, his presenters, and everyone involved with 360iDev for hosting an excellent conference. It’s always fun to meet with your peers (many of whom I have only “met” on the Internet) to share successes, frustrations, and ideas. It’s even more fun when you can do that at such a professionally organized event. If you develop for iOS and didn’t attend 360iDev this year, you should definitely plan to attend next year. Also, consider purchasing the recorded sessions. They’re full of information and first-hand experiences that you won’t get anywhere else. And to everyone I met at the conference: It was great talking to you. I’ll see you next year!
One of the nice things about Lucky developing for the iPhone is that it’s pretty easy to conform to the standard look in your app icons. The rounded corners are automatically applied, and unless you go out of your way to prevent it, a “gloss” is applied to the top of iPhone icons when they are displayed on the device. The result of these automatic transformations is that the standard iPhone app look is pretty easy to achieve.
That works great wholesale nba jerseys on when your icon is displayed on an iOS device, but what if you want to wholesale nba jerseys use your icon on Store your website, or even your business card? Well, that’s where an artistically challenged developer like me runs into problems. If you don’t get the gradients just right they look “off” and they’re distracting to anyone that knows what an iPhone icon is supposed to look like.
Luckily, for those who know how to use Photoshop, there are solutions. Several people have been generous with their time and cheap jerseys skills and have distributed templates for iPhone icons that can be used with Photoshop to get the correct corner radius and gloss. Developer One of the best templates that I’ve found was created by Sebastiaan de With who distributes the template on his blog Cocoia.
Unfortunately, I don’t have Photoshop. It’s pretty expensive, and I don’t have the budget for it. So I use GIMP which is a free image manipulation program that provides almost all the features that I (as a non-artist) will ever need. In fact, I’ve never run into a graphics lamenta problem that I felt capable of tackling that I couldn’t solve using GIMP. Except one: Wholesale Seattle Seahawks Jerseys GIMP won’t correctly open the PSD file that contains the iPhone icon template from Cocoia.
Luckily I have friends who have Photoshop and skills to make the most of them. Mike Berg of We Heart Games offered to pull out the parts of the template that apply to 512×512 cheap nba jerseys pixel icons and export them to PNG files that can be used in GIMP. I took the results of his work, made Management a few modification, and now offer up to the Internet as an iPhone app icon template for Gimp.
This template provides everything that you need to make faithful renderings of iPhone app icons at a size of 512×512 pixels. You can resize from there if you need to. Inside the ZIP file are a number of files. The file 512-shape-mask.png can be applied to a 512×512 pixel image as a layer mask to get rounded corners with the correct radius. The files 512-topBevel-and-gradient.png and 512-topGloss.png can be applied as layers to get the correct glossy look of an iPhone app icon. I also included a sample file Localization (512 demo.xcf) that demonstrates how you can use these images to generate the proper look.
I hope that this example proves helpful to other developers that use GIMP for their artwork, and a big thank you to Sebastiaan de With who created the original template.
Being an independent iPhone developer is Learned great, but it comes with some limitations that larger software shops aren’t as constrained by. In particular, time is a resource that is always in short supply. I’m the developer, designer, and support line for Daze End Software, and unfortunately, there never seems to be enough time in the day to get done everything that I’d like to do. So it’s nice that there’s a supportive community of indie cheap nfl jerseys iPhone developers that I can lean on. These guys are great. They offer a sympathetic ear when things go wrong, they offer advice when I Arrived!!! need guidance, and occasionally they save me several hours wholesale nba jerseys of work.
Such was the situation that I encountered recently with the release of iOS 4 for the iPhone. I received a bug report from a customer that I just could not reproduce. (And as all developers know, if you is can’t reproduce a bug, it’s awful hard to fix the bug.) As it turns out, the reason I cheap jerseys couldn’t reproduce the bug is отпуска: because I was in the wrong timezone. How did I figure that une out? Because the community of iPhone developers is awesome and generous with their time.
A Google search wholesale nfl jerseys turned up one lonely description of a problem in another developer’s app which sounded similar to the bug that had been reported in mine. I’d never met this developer before (either in real life, or online), but I took a chance and emailed him anyway. This developer, Greg, took the time to respond to my out-of-the-blue email with a detailed description of the root cause of the problem and the wholesale mlb jerseys steps needed in order to reproduce it. He saved me hours of time in debugging — hours that All I would much rather spend Schuldenbereinigung creating new features than debugging old ones.
So what’s the point of this post? It’s really just an excuse to give a shout out to Greg at More Mobile Software who took the time to help out a fellow developer. Thanks Greg! And thanks also to all the other iPhone developers out there that are helpful, supportive, and generally make iPhone development an enjoyable pursuit.